[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00

INTERNET-DRAFT                                                 Jim Bound
NGTRANS Tools Working Group                       Digital Equipment Corp
November 1997



             No Network Address Translation (NNAT) for IPv6

                    <draft-ietf-ngtrans-nnat-00.txt>


Status of this Memo

        This document is a submission by the Next Generation Transition
        Working Group of the Internet Engineering Task Force (IETF).
        Comments should be submitted to the ngtrans@sunroof.eng.sun.com
        mailing list.

        This document is an Internet-Draft.  Internet-Drafts are working
        documents of the Internet Engineering Task Force (IETF), its
        areas, and its working groups.  Note that other groups may also
        distribute working documents as Internet-Drafts.

        Internet-Drafts are draft documents valid for a maximum of six
        months and may be updated, replaced, or obsoleted by other
        documents at any time.  It is inappropriate to use Internet-
        Drafts as reference material or to cite them other than as
        "work in progress."

        To view the entire list of current Internet-Drafts, please check
        the "1id-abstracts.txt" listing contained in the Internet-Drafts
        Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
        (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East
        Coast), or ftp.isi.edu (US West Coast).


Abstract

   The initial deployment of IPv6 will require a tightly coupled use of
   IPv4 addresses to support the interoperation of IPv6 and IPv4.  Nodes
   will be able to be deployed with IPv6 addresses, but will still need
   to communicate with IPv4 nodes that do not have a dual IP layer
   supporting both IPv4 and IPv6.  This specification defines a
   mechanism called No Network Address Translation (NNAT), which will
   assign an IPv6 node a temporary IPv4 address, which can be used to
   communicate with a node that supports only IPv4.
















Bound           Expires May 1998                                [Page 1]


INTERNET-DRAFT       draft-ietf-ngtrans-nnat-00.txt        November 1997


Table of Contents:

1. Introduction....................................................3
2. Terminology.....................................................3
   2.1 IPv6 NNAT Terminology.......................................3
   2.2 Specification Language......................................4
3. NNAT Design Model...............................................5
4. IPv4 Query of an IPv6 Node......................................5
   4.1 Reaching the Site Primary DNS Server........................5
   4.2 Relaying the A Record Query to the NNAT Server..............5
5. NNAT Server Processing of a DNS A Query.........................6
   5.1 DNS and DHCPv6 Processing...................................6
   5.2 Cleaning up the NNAT IPv4 Assigned Address..................7
   5.3 Conceptual Model of an Implementation.......................7
6. DHCPv6 Reconfigure IPv4 Address Extension.......................7
7. Security Considerations.........................................8
8. Year 2000 Considerations........................................8
Appendix A - Open Issues...........................................8
Appendix B - Draft Changes and Rationale History...................8
Acknowledgements...................................................8
References.........................................................9
Authors' Address..................................................10






































Bound           Expires May 1998                                [Page 2]


INTERNET-DRAFT       draft-ietf-ngtrans-nnat-00.txt        November 1997


1. Introduction

   The initial deployment of IPv6 will require a tightly coupled use of
   IPv4 addresses to support the interoperation of IPv6 and IPv4.  Nodes
   will be able to be deployed with IPv6 addresses, but will still need
   to communicate with IPv4 nodes that do not have a dual IP layer
   supporting both IPv4 and IPv6.  This specification defines a
   mechanism called No Network Address Translation (NNAT), which will
   assign an IPv6 node a temporary IPv4 address, which can be used to
   communicate with a node that supports only IPv4.

   NNAT uses the DNS [2,9] mechanisms to resolve a query for an IPv6
   node name by an IPv4 node that wishes to communicate with the IPv4
   stack of an IPv6 node that supports both IPv6 and IPv4.  The IPv6
   node that is the object of such a query will be assigned a temporary
   IPv4 address, thru DHCPv6 [4], and the IPv4 node performing the query
   will receive the address assigned to the IPv6 node in the query
   response.  Communications between the two nodes can then begin
   directly without any intermediate nodes performing Network Address
   Translation [15] or Application Level Gateway [7] functions.

   The reason for this specification is that users deploying IPv6 will
   not want (and most likely will not be able) to assign IPv4 addresses
   to IPv6 nodes as they are deployed into their site, because IPv4
   addresses are a rare commodity.  But, IPv4 addresses will be needed
   to permit IPv6 nodes to communicate with IPv6 nodes, which can
   support both IPv4 and IPv6 communications.

   The specification will begin by defining the terminology (section 2),
   then discuss the NNAT design model (section 3), then define the
   mechanism used for an IPv4 node to query an IPv6 node (section 4),
   then discuss the NNAT Server processing to support this mechanism
   (section 5), and complete the mechanism by defining the DHCPv6
   Extension needed to assign a temporary IPv4 address to an IPv6 node
   (section 6). The specification then discusses Security (section 7)
   and Year 2000 considerations (section 8).  Appendix A will discuss
   Open Issues that need to be discussed in the ngtrans Tools Working
   Group and Appendix B will keep a historical account of changes to the
   draft and rationale for those changes as they occur.


2. Terminology


2.1 IPv6 NNAT Terminology

      IPv6 Protocol Terms:    See [3]

      IPv6 Transition Terms:  See [16]

      DHCPv6 Terms:           See [4,5]

      NNAT Server:            A Server that supports DNS [2] and DHCPv6 [4,5]
                              and communications between DNS and DHCPv6, which
                              is implementation defined.  See section 4 and 5.





Bound           Expires May 1998                                [Page 3]


INTERNET-DRAFT       draft-ietf-ngtrans-nnat-00.txt        November 1997


2.2 Specification Language

      In this document, several words are used to signify the requirements
      of the specification, in accordance with RFC 2119 [10].  These words
      are often capitalized.

         MUST          This word, or the adjective "required", means that
                       the definition is an absolute requirement of the
                       specification.

         MUST NOT      This phrase means that the definition is an absolute
                       prohibition of the specification.

         SHOULD        This word, or the adjective "recommended", means
                       that there may exist valid reasons in particular
                       circumstances to ignore this item, but the full
                       implications must be understood and carefully
                       weighed before choosing a different course.
                       Unexpected results may result otherwise.

         MAY           This word, or the adjective "optional", means that
                       this item is one of an allowed set of alternatives.
                       An implementation which does not include this option
                       MUST be prepared to interoperate with another
                       implementation which does include the option.

         silently discard
                       The implementation discards the packet without
                       further processing, and without indicating an error
                       to the sender.  The implementation SHOULD provide
                       the capability of logging the error, including the
                       contents of the discarded packet, and SHOULD record
                       the event in a statistics counter.



























Bound           Expires May 1998                                [Page 4]


INTERNET-DRAFT       draft-ietf-ngtrans-nnat-00.txt        November 1997


3. NNAT Design Model

   The design model assumes that NNAT MUST only be used to obtain a
   temporary IPv4 address for an IPv6 node from the receipt of a DNS
   query for a DNS A Type  Relative Record [1,2].  If an IPv6 node needs
   to obtain an IPv4 address to initiate communications, it SHOULD
   locate that address using DHCPv4 [17], using its IPv4 stack.

   For an IPv6 node to participate in the NNAT mechanism it MUST have a
   dual IP layer, supporting both an IPv4 and IPv6 stack.  This
   specification makes the assumption that for IPv6 initial deployment
   Host nodes will not ship an IPv6-only stack implementation.  For
   embedded system type nodes that support only an IPv6 stack NNAT
   cannot be a solution.

   It is beyond the scope of this specification to define the mechanisms
   used to describe the variant routing configurations to verify that
   IPv4 connectivity exists between the IPv6 node and the ingress or
   egress points of the IPv6 nodes site, to communicate with the IPv4
   node establishing communications.  It is assumed that IPv4-in-IPv6
   and IPv6-in-IPv4 configured and automatic tunnels can be used as
   defined in other transition mechanism documents [13, 14, 16].



4. IPv4 Query of an IPv6 Node

   NNAT supports IPv4 DNS querys from the Internet or within a site to
   establish communications with an IPv6 node.  An IPv4 node will not
   necessarily know that it is trying to establish communications with
   an IPv6 node.  The IPv4 node will communicate with the IPv6 node by
   first obtaining an IPv4 address for the IPv6 node as it does for any
   other node (e.g. gethostbyname API).



4.1 Reaching the Site Primary DNS Server

      The IPv4 DNS query will reach the Primary DNS Name Server for the
      IPv6 node.  It is implementation defined how the DNS query passes
      thru a domains Firewall [7] to reach the IPv6 nodes Primary DNS
      Server. This is a per user policy that is beyond the scope of this
      specification.



4.2 Relaying the A Record Query to the NNAT Server

      When the Primary DNS Server for the IPv6 node processes the IPv4
      nodes query, it will do a lookup for that IPv6 node and find a
      Route Through (RT) DNS Type Record [9].  The RT record will inform
      the Primary DNS Server to forward the query to an intermediate DNS
      Server, which will respond to the IPv4 node that made the original
      query, after a temporary IPv4 address has been assigned to the
      IPv6 node.

      The intermediate DNS Server is also the NNAT Server.



Bound           Expires May 1998                                [Page 5]


INTERNET-DRAFT       draft-ietf-ngtrans-nnat-00.txt        November 1997


      For Example:

        IPv4 node "v4node.abc.com" querys for "v6node.xyz.com"

        Query reaches Primary DNS Server for "v6node.xyz.com".

        Primary DNS Server finds:

        v6node.xyz.com   IN   RT   5   nnat6.xyz.com

        Primary DNS Server forwards the query to "nnat6.xyz.com"




5. NNAT Server Processing of a DNS A Query



5.1 DNS and DHCPv6 Processing

      At this point the NNAT Server has received the DNS query from the
      Primary DNS Server.  An NNAT Server MUST support both a DNS Server
      and DHCPv6 Server implementation to perform the necessary NNAT
      operations. The NNAT DNS Server will communicate to the DHCPv6
      Server that an IPv6 node is being queried for an IPv4 address.

      The DHCPv6 Server will look within its pool of IPv4 addresses for
      NNAT IPv4 temporary addresses for assignment.  If an address is
      available the DHCPv6 Server will send a DHCPv6 Reconfigure Message
      to the IPv6 node to temporarily assign the node an IPv4 address.
      The DHCPv6 extension to this is defined in section 6.

      Then the DHCPv6 Server MUST send a dynamic update to DNS [6] to
      add an A type record to the Primary DNS Server, where the query
      came from to the NNAT Server.  The Time-To-Live (TTL) field in the
      update MUST not be set to be greater than the lifetime (section 6)
      for the IPv4 address assigned to the IPv6 node.  The TTL value
      will permit the A record to be cached for at least as long as the
      lifetime.

      Then the DHCPv6 Server MUST communicate to the NNAT DNS Server the
      IPv4 address assigned to the IPv6 node.

      Then the NNAT DNS Server responds to the query of the IPv4 node
      with the IPv4 address of the IPv6 node.

      When the query is received by the NNAT DNS Server and an IPv4
      address cannot be assigned, the NNAT DNS Server MUST respond to
      the IPv4 node that the IPv6 node A Record could not be found.

   For Example:


        NNAT DNS Server informs DHCPv6 it needs an IPv4 address
        for v6node.xyz.com.

        DHCPv6 Server assigns 15.131.12.6 to v6node.xyz.com thru


Bound           Expires May 1998                                [Page 6]


INTERNET-DRAFT       draft-ietf-ngtrans-nnat-00.txt        November 1997


        the Reconfigure IPv4 Address Extension with a lifetime
        of 5 hours.

        DHCPv6 updates the Primary DNS Server:

         v6node.xyz.com 18000 IN A 15.131.12.6 ; Explicit TTL cache for 5 hours

        DHCPv6 Server informs NNAT DNS Server of the IPv4 Address.

        NNAT DNS Server responds to "v4node.abc.com" query.



5.2 Cleaning up the NNAT IPv4 Assigned Address

      Once the IPv4 address expires the DHCPv6 Server will permit the
      IPv4 address to be reused.  But before the address can be reused
      the DHCPv6 Server MUST delete the IPv4 address from the Primary
      DNS Server, thru the Dyanamic Updates to DNS mechanism.



5.3 Conceptual Model of an Implementation

      A conceptual model (not part of this specification) for the NNAT
      DNS Server and DHCPv6 Server to communicate could be a number of
      mechanisms that support interprocess communications between two
      processes (e.g.  Threads, Local Domain Sockets, Shared Memory).
      The IPv4 pool of addresses maintained by the DHCPv6 server is
      implementation defined how that is obtained and configured as is
      specified for IPv6 addresses in DHCPv6.  Once the IPv4 address is
      assigned it can be kept as part of the IPv6 nodes binding entry on
      the DHCPv6 Server as other configuration data as specified in
      DHCPv6.



6. DHCPv6 Reconfigure IPv4 Address Extension

   The DHCPv6 Reconfigure IPv4 Address Extension provides an IPv6 DHCPv6
   Client with a temporary IPv4 address.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Type             |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          IPv4 Address                         |
   |                          (4 octets)                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Lifetime                            |
   |                          (4 octets)                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:                   TBD
   Length:                 8
   IPv4 Address:           32bit IPv4 Address
   Lifetime:               Absolute Time in Seconds


Bound           Expires May 1998                                [Page 7]


INTERNET-DRAFT       draft-ietf-ngtrans-nnat-00.txt        November 1997


7. Security Considerations

   The NNAT mechanism can use all the defined security specifications
   for each functional part of the operation.  For DNS the DNS Security
   Extensions/Update can be used [11, 12], for DHCPv6 the DHCPv6
   Authentication Message can be used [5], and for communications
   between the IPv6 node, once it has an IPv4 address, and the remote
   IPv4 node, IPSEC [8] can be used as NNAT does not break secure end-
   to-end communications at any point in the mechanism.



8. Year 2000 Considerations

   There are no Year 2000 issues in this specification.



Appendix A - Open Issues


   -  The draft does not speak of PTR records for the IPv6 node
      A record once its created.  But its only useful during the
      lifetime of the assigned IPv4 address.

   -  RFC 1183 RT Record is Experimental and there is some concern
      its obsolete.  Though some implementations still support some
      code for the RT record.  Also the Route Through semantics
      specified may need to strongly state the query is passed thru
      to the NNAT server.  This needs to be discussed.

   -  The Primary Server must look for the IPv6 node A record first
      before finding the RT record.  This needs to be verified
      as an implementation issue.

   -  WHen the NNAT Server responds to the query it may not be
      authorative.  This needs to be verified and checked.



Appendix B - Draft Changes and Rationale History

   None at this time.



Acknowledgements

   The author would like to thank Erik Nordmark for spending time
   working with him on this idea and suggesting the use of the DHCPv6
   Reconfigure Message, Gerd Hoelzing for suggesting the use of the DNS
   RT Record, and Robert Watson who suggested that the NNAT DHCPv6 and
   DNS Server be co-located.







Bound           Expires May 1998                                [Page 8]


INTERNET-DRAFT       draft-ietf-ngtrans-nnat-00.txt        November 1997


References

   [1]  Mockapetris, P., "Domain Names - Concepts and Facilities", STD
        13, RFC 1034, USC/Information Sciences Institute, November 1987.

   [2]  Mockapetris, P., "Domain Names - Implementation and Specifica-
        tion", STD 13, RFC 1035, USC/Information Sciences Institute,
        November 1987.

   [3]  S. Deering and R. Hinden.  Internet Protocol, Version 6 (IPv6)
        Architecture", RFC 1883, December 1995.

   [4]  J. Bound and C. Perkins.  Dynamic Host Configuration Protocol
        for IPv6.  draft-ietf-dhc-dhcpv6-11.txt November 1997 (work
        in progress).

   [5]  C. Perkins.  Extensions for the Dynamic Host Configuration
        Protocol for IPv6.  draft-ietf-dhc-dhcpv6ext-08.txt November
        1997. (work in progress).

   [6]  P. Vixie, S. Thomson, Y. Rekhter, and J. Bound. Dynamic Updates
        to the Domain Name System (DNS).  RFC 2136, April 1997.

   [7]  William R. Cheswick and Steven Bellovin.  Firewalls and Internet
        Security.  Addison-Wesley, Reading, MA 1994 (ISBN:
        0-201-63357-4).

   [8]  IPSEC *TBD* - This needs to include the Arch, Auth, and ESP specs.

   [9]  C. Everhart, L. Mamakos, R. Ullmann, P. Mockapetris. New
        DNS RR Definitions, RFC 1183, October 1990.

   [10] S. Bradner.  Key words for use in RFCs to indicate Requirment
        Levels.  RFC 2119, March 1997.

   [11] D. Eastlake and C. Kaufman. Domain Name System Security
        Extensions.  RFC 2065, January 1997.

   [12] D. Eastlake. Secure Domain Name System Dynamic Update.
        RFC 2137, April 1997.

   [13] R. Callon and D. Haskins. Routing Aspects Of IPv6 Transition
        RFC 2185, September 1997.

   [14] A. Conta and S. Deering.  Generic Packet Tunneling in IPv6.
        draft-ietf-ipngwg-ipv6-tunnel-07.txt. December 1996.
        (work in progress)

   [15] E. Nordmark. IPv4/IPv6 Stateless Header Translator
        draft-ietf-ngtrans-header-trans-00.txt. July 1997.
        (work in progress)

   [16] R. Gilligan and E. Nordmark.  Transition Mechanisms for IPv6
        Hosts and Routers.  RFC 1933, April 1996.

   [17] R. Droms.  Dynamic Host Configuration Protocol.
        RFC 2131, March 1997.



Bound           Expires May 1998                                [Page 9]


INTERNET-DRAFT       draft-ietf-ngtrans-nnat-00.txt        November 1997


Authors' Address

    Jim Bound
    Digital Equipment Corporation
    110 Spitbrook Road, ZKO3-3/U14
    Nashua, NH 03062
    Phone: (603) 881-0400
    Email: bound@zk3.dec.com




















































Bound           Expires May 1998                               [Page 10]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/