[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 02 03 04 05 06 RFC 2766

INTERNET-DRAFT                                 George Tsirtsis
NGTRANS  WG                                    BT
Expires December, 1999                         Pyda Srishuresh
                                               Lucent Technologies
                                               June 1999

      Network Address Translation - Protocol Translation (NAT-PT)
                   <draft-ietf-ngtrans-natpt-06.txt>

Status of this Memo

   This  document  is  an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents  of  the  Internet  Engineering
   Task Force (IETF), its areas, and its working groups.  Note that oth-
   er 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 mate-
   rial or to cite them other than as "work in progress."

   The   list   of   current   Internet-Drafts   can   be   accessed  at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow  Directories  can  be  accessed  at
   http://www.ietf.org/shadow.html.

Abstract

   This  document specifies an IPv4-to-IPv6 transition mechanism, in ad-
   dition to those already  specified in  [TRANS].  This   solution  al-
   lows  IPv6-only  nodes  to  transparently  communicate with IPv4-only
   nodes and vice versa  using  a combination of Network  Address Trans-
   lation  and  Protocol Translation. The scheme described does not man-
   date dual-stacks (i.e., IPv4 as well as V6 protocol support) or  spe-
   cial  purpose  routing  requirments (such as requiring tunneling sup-
   port) on  end hosts. This scheme is based on a combination of address
   translation  theme  as  described  in  [NAT-TERM]  and V6/V4 protocol
   translation theme as described in [SIIT]

Acknowledgements

   Special thanks to Pedro Marques for reviewing an earlier  version  of
   the  draft.   Also, many thanks to Alan O'Neill and Martin Tatham, as
   the mechanism described in  this  document  was  initially  developed
   through discussions with them.

Tsirtsis & Srisuresh                                            [Page 1]

Internet Draft    Network Address + Protocol Translator        June 1999

Index

   1. Introduction

   2. Terminology

   3. Network Address Translation operation (V6 to V4)
      3.1 NAT-PT Outgoing Sessions (V6 to V4)
      3.2 NAPT-PT Outgoing Sessions (V6 to V4) with a single V4 address

   4. Use of DNS-ALG for Address assignment
      4.1 V4 Address Assignment for Incoming Connections (V4 to V6)
      4.2 V4 Address Assignment for Outgoing Connections (V6 to V4)

   5. Protocol Translation Details
      5.1 Translating IPv4 Headers to IPv6 Headers
      5.2 Translating IPv6 Headers to IPv4 Headers
      5.3 TCP/UDP/ICMP Checksum Update

   6. FTP Application Level Gateway (FTP-ALG) Support

   7. NAT-PT Limitations and Future Work
      7.1 Topology Limitations
      7.2 Protocol Translation Limitations
      7.3 Impact of Address Translation
      7.4 Lack of End-to-End Security
      7.5 DNS Translation and DNSSEC

   8. Applicability Statement

   9. Security Considerations

   10. References

Tsirtsis & Srisuresh                                            [Page 2]

Internet Draft    Network Address + Protocol Translator        June 1999

1. Introduction

   IPv6  is  a new version of the IP protocol designed to modernize IPv4
   which was designed in the 1970s. IPv6 has a number of advantages over
   IPv4  that will allow for future Internet growth and will simplify IP
   configuration and administration. IPv6 has  a  larger  address  space
   than  IPv4, an addressing model that promotes aggressive route aggre-
   gation and a powerful autoconfiguration mechanism.  In  time,  it  is
   expected that Internet growth and a need for a plug-and-play solution
   will result in widespread adoption of IPv6.

   There is expected to be a long transition period during which it will
   be  necessary  for IPv4 and IPv6 nodes to coexist and communicate.  A
   strong, flexible set of IPv4-to-IPv6 transition and coexistence mech-
   anisms will be required during this transition period.

   The  SIIT  proposal [SIIT] describes a protocol translation mechanism
   that  allows  communication between IPv6-only and IPv4-only nodes via
   protocol  independent translation of IPv4 and IPv6 datagrams, requir-
   ing no state information for the session.  This proposal assumes that
   V6  nodes  are assigned a V4 address for communicating with V4 nodes,
   and does not specify a mechanism for the assignment of these address-
   es.

   NAT-PT  uses  a  pool of V4 addresses for assignment to V6 nodes on a
   dynamic basis as sessions are  initiated  across  V4-V6   boundaries.
   These  assigned  addresses  in turn are used to transparently replace
   the original addresses used by  V6  end nodes  and  vice versa.  This
   requires  no changes to end nodes and IP packet routing is completely
   transparent to end nodes. It does, however, require NAT-PT  to  track
   the sessions it supports and mandates that inbound and outbound data-
   grams pertaining to  a session traverse the same NAT-PT router.   You
   will  note  that the topology restrictions on NAT-PT are very similar
   to those described for V4 NATs in [NAT-TERM].  Protocol   translation
   details  specified in [SIIT] would be used to extend address transla-
   tion with  protocol syntax/semantics translation. A detailed applica-
   bility statement for NAT-PT may be found at the  end  of  this  docu-
   ment in section 7.

   By combining SIIT  protocol  translation  with  the  dynamic  address
   translation capabilities of NAT, NAT-PT provides a complete mechanism
   for IPv6-only nodes to communicate with IPv4-only nodes.

Tsirtsis & Srisuresh                                            [Page 3]

Internet Draft    Network Address + Protocol Translator        June 1999

2. Terminology

      Session initiation packet
            This  is  the  first  packet  of  an IP  session.  The first
            packet of a TCP session can be identified in a deterministic
            way, by the presence of a SYN bit and the absence of an  ACK
            bit  in  the  TCP  header.  There is no deterministic way to
            recognise the start of a UDP session or of any non-TCP  ses-
            sion.  A  heuristic  approach  would  be to assume the first
            packet with hitherto non-existent session parameters (namely
            src  IP  address, destination IP address, protocol, src port
            no, destination port number) as constituting  the  start  of
            new session. [NAT-TERM].

      Network Address Translation (NAT)
            The  term  NAT  in this document is very similar to the IPv4
            NAT described in [NAT-TERM], but is not identical.  IPv4 NAT
            translates   one IPv4  address into another IPv4 address. In
            this document, NAT refers to translation of an IPv4  address
            into an IPv6 address and vice versa.

      Network Address Port Translation (NAPT)
            NAPT [NAT-TERM] is a method by which nodes in a private net-
            work domain are allowed simultaneous access to nodes in  the
            external  network  transparently using a single external ad-
            dress.  This is made possible by multiplexing transport lay-
            er   identifiers of private nodes into the transport identi-
            fiers of the single assigned   external  address.  For  this
            reason,  only  the  applications based on TCP and UDP proto-
            cols are supported by NAPT. ICMP  query  based  applications
            are also supported  as the ICMP header carries a query iden-
            tifier that is used to correlate responses with requests.

      Protocol Translation (PT)
            PT in this document refers to the  translation  of  an  IPv4
            packet   into a semantically equivalent IPv6 packet and vice
            versa.  Protocol translation details are described  in  [SI-
            IT].

      Application Level Gateway (ALG)
            Application  Level  Gateway  (ALG) [NAT-TERM]  is  an appli-
            cation specific agent that allows a V6 node  to  communicate
            with  a  V4  node  and vice  versa.  Some applications carry
            network addresses in payloads. NAT-PT is application unaware
            and  does  not snoop the payload. ALG could work in conjunc-
            tion with NAT-PT to provide application level  transparency.

Tsirtsis & Srisuresh                                            [Page 4]

Internet Draft    Network Address + Protocol Translator        June 1999

3. Network Address Translation operation (V6 to V4)

   NAT-PT  offers  a  straight forward end-to-end  solution  with trans-
   parent  routing and address/protocol translation. Operation of NAT-PT
   is  described in the following sub-sections. There are limitations to
   using the translation method. Is it mandatory that all  requests  and
   responses  pertaining to a session be routed via the same NAT router.
   One way to ascertain this would be to have  NAT  based  on  a  border
   router  that is unique to a stub domain, where all IP packets are ei-
   ther originated from the domain or destined to the domain. There  are
   other  ways  to ensure this with multiple NAT devices.. For example, a
   private domain could have  two  distinct  exit  points to   different
   providers  and  the  session flow from the nodes in a private network
   could traverse through whichever NAT device has the best  metric  for
   an external node.

   NAT-PT  is  application  independent. Applications such as "FTP" that
   include IP addresses in the payload will need to be supported by  ap-
   plication   specific  ALGs  in conjunction with NAT-PT. This document
   describes the functioning of FTP and DNS  ALGs  in  conjunction  with
   NAT-PT.  Specifications  of  ALGs  for  other applications is outside
   the scope of this document.

   NAT-PT is also limited by the fact that it  can  translate  only  the
   shared  semantics  between the V4 and V6 protocols. Features specific
   only to V6 or features not supported in V6 will not be  supported  by
   NAT-PT.

   In the following paragraphs we describe the operation of  NAT-PT  and
   the  way  that  connections can be initiated from either side when an
   IPv6 domain is connected to an IPv4 domain through a NAT-PT.

   3.1 NAT-PT Outgoing Sessions (V6 to V4)

                 [IPv6-B]-+
                          |                  +==============+
                 [IPv6-A]-+-[NAT-PT]---------| IPv4 network |--[IPv4-C]
                               |             +==============+
                        (pool of v4 addresses)

             Figure 1: IPv6 to IPv4 communication
             Node IPv6-A has an IPv6 address -> FEDC:BA98::7654:3210
             Node IPv6-B has an IPv6 address -> FEDC:BA98::7654:3211
             Node IPv4-C has an IPv4 address -> 132.146.243.30

      NAT-PT  has  a  pool  of  addresses  including  the  IPv4   subnet
      120.130.26/24

Tsirtsis & Srisuresh                                            [Page 5]

Internet Draft    Network Address + Protocol Translator        June 1999

      Say the IPv6 Node A wants to communicate with  the  IPv4  Node  C.
      Node A creates a packet with:

            Source  Address, SA=FEDC:BA98::7654:3210 and Destination Ad-
            dress, DA = PREFIX::132.146.243.30

      NOTE:  The  prefix PREFIX::/96 is advertised in the stub domain by
      the NAT-PT, and packets addressed to this PREFIX will be routed to
      the NAT-PT.  The pre-configured PREFIX only needs to  be  routable
      within  the  IPv6  stub  domain and as such it can be any routable
      prefix that the  network administrator choses. It can NOT for  ex-
      ample  be a mapped prefix (::FFFF/96) since this is illegal on the
      wire nor an IPv4 compatible prefix (::/96) since this is only  le-
      gal as a tunnel end-point.

      The packet is routed via the NAT-PT gateway, where it is translat-
      ed to IPv4.

      If the outgoing packet is not a session initialisation packet, the
      NAT-PT  SHOULD  already  have  stored some state about the related
      session, including assigned IPv4 address and cached parameters for
      the   translation.    If  this  state  does  not exist, the packet
      SHOULD be silently discarded.

      If the packet  is  a  session  initialisation  packet,  the   NAT-
      PT  locally  allocates   an  address  (e.g:  120.130.26.10)   from
      its pool   of  addresses  and  the packet is translated  to  IPv4.
      The  translation  parameters  are  cached  for the duration of the
      session and the IPv6 to IPv4 mapping is retained by NAT-PT.

      The   resulting   IPv4    packet    has    SA=120.130.26.10    and
      DA=132.146.243.30.   Any returning  traffic  will be recognised as
      belonging to the same session by  NAT-PT.   NAT-PT  will  use  the
      cached  information  to  translate  the  packet, and the resulting
      addresses        will        be         SA=PREFIX::132.146.243.30,
      DA=FEDC:BA98::7654:3210.  Note  that this packet can now be routed
      inside the IPv6-only stub network as normal.

   3.2 NAPT-PT Outgoing Sessions (V6 to V4) with a single V4 address

      NAPT-PT, which stands for "Network Address Port Translation + Pro-
      tocol Translation", would allow V6 nodes to communicate  with  the
      V4  nodes  transparently  using  a  single V4 address. The TCP/UDP
      ports of the V6 nodes are translated into  TCP/UDP  ports  of  the
      registered  V4 address.

      While NAT-PT support is limited to TCP,UDP and other  port  multi-
      plexing type of applications, NAPT-PT solves a problem that is in-

Tsirtsis & Srisuresh                                            [Page 6]

Internet Draft    Network Address + Protocol Translator        June 1999

      herent with NAT-PT.  That is, NAT-PT would fall flat when the pool
      of  V4 addresses  assigned for  translation  purposes  is exhaust-
      ed. Once the address pool is exhausted, newer V6 nodes cannot  es-
      tablish sessions with the  outside world anymore.  NAPT-PT, on the
      other hand, will allow for  a maximum of 63K TCP and 63K UDP  ses-
      sions  per IPv4 address before having no TCP and UDP ports left to
      assign.

      To modify the example sited in figure 1, we could have NAPT-PT  on
      the  border  router (instead of NAT-PT) and all V6 addresses could
      be mapped to a single v4 address 120.130.26.10.

      IPv6 Node A would establish a TCP session with the IPv4 Node  C as
      follows:

      Node A creates a packet with:

      Source Address, SA=FEDC:BA98::7654:3210 , source TCP port  =  3017
      and Destination Address, DA = PREFIX::132.146.243.30,  destination
      TCP port = 23.

      When the packet reaches the NAPT-PT box, NAPT-PT would assign  one
      of the TCP ports from the assigned V4 address to translate the tu-
      ple of (Source Address, Source TCP port) as follows:

            SA=120.130.26.10,  source TCP port = 1025    and
            DA=132.146.243.30, destination TCP port = 23.

      The  returning  traffic  from 132.146.243.30, TCP port 23 will  be
      recognised as belonging to the same session and will be translated
      back to V6 as follows:

            SA = PREFIX::132.146.243.30, source TCP port = 23;
            DA = FEDC:BA98::7654:3210 ,  destination TCP port = 3017

      Inbound NAPT-PT sessions are restricted  to  one  server  per ser-
      vice, assigned via static TCP/UDP port mapping. For  example,  the
      Node [IPv6-A] in figure 1 may be the only HTTP server (port 80) in
      the V6 domain. Node  [IPv4-C] sends a packet:

            SA=132.146.243.30, source TCP port = 1025    and
            DA=120.130.26.10, destination TCP port = 80

      NAPT-PT will translate this packet to:
            SA=PREFIX::132.146.243.30, source TCP port = 1025
            DA=FEDC:BA98::7654:3210, destination TCP  port  =  80

      In the above example, note that all sessions which  reach  NAPT-PT

Tsirtsis & Srisuresh                                            [Page 7]

Internet Draft    Network Address + Protocol Translator        June 1999

      with  a destination port of 80 will be redirected to the same node
      [IPv6-A].

4. Use of DNS-ALG for Address Assignment

   An IPv4 address is assigned by NAT-PT to a V6 node when NAT-PT  iden-
   tifies the  start of session, inbound or outbound. Identification  of
   the start of a new inbound session is performed differently than  for
   outbound sessions.  However, the same V4 address pool is used for as-
   signment to V6 nodes, irrespective of whether a  session is initiated
   outbound from a V6 node or initiated inbound from a V4 node.

   Policies  determining  what type of sessions are allowed and in which
   direction and from/to which nodes is out of the scope of this   docu-
   ment.

   IPv4 name to address mappings are held in the DNS with "A" records.
   IPv6  name to address mappings are at the moment held in the DNS with
   "AAAA" records. "A6" records have also been defined but at  the  time
   of writing they are neither fully standardized nor deployed.

   In  any  case, the DNS-ALG's principle of operation described in this
   section is the same with either "AAAA" or "A6" records. The only dif-
   ference is that a name resolution using "A6" records may require more
   than one query - reply pairs. NAT-PT SHOULD, in that case, track  all
   the  replies  in the transaction before translating an "A6" record to
   an "A" record.

   4.1 V4 Address assignment for incoming connections (V4 to V6)

              [DNS]--+
                     |              [DNS]------[DNS]-------[DNS]
            [IPv6-B]-+                           |           |
                     |                  +==============+     |
            [IPv6-A]-+----[NAT-PT]------| IPv4 network |--[IPv4-C]
                             |          +==============+
                       (pool of v4 addresses)
            Figure 2: IPv4 to IPv6 communication
            Node IPv6-A has an IPv6 address -> FEDC:BA98::7654:3210
            Node IPv6-B has an IPv6 address -> FEDC:BA98::7654:3211
            Node IPv4-C has an IPv4 address -> 132.146.243.30

      NAT-PT   has  a  pool  of  addresses  including  the  IPv4  subnet
      120.130.26/24

      In  figure 2 above, when Node C's name resolver sends a name  look
      up  request  for  Node A, the lookup query is directed to the  DNS

Tsirtsis & Srisuresh                                            [Page 8]

Internet Draft    Network Address + Protocol Translator        June 1999

      server  on  the V6 network. Considering that NAT-PT is residing on
      the border router between V4 and V6 networks, this  request  data-
      gram  would traverse through the  NAT-PT  router.  The DNS  ALG on
      NAT-PT  would modify  the DNS Queries going into the V6 domain  as
      follows:  (Note  that  a  DNS UDP packet is recognized by the fact
      that its source or destination port number is 53)

         a) For Node Name to Node Address Query requests:
            Change the Query type from "A" to "AAAA" or "A6".
         b) For Node address to Node name query requests:
            Replace the string "IN-ADDR.ARPA" with the string "IP6.INT".
            Replace  the  V4 address octets (in reverse order) preceding
            the string "IN-ADDR.ARPA"  with the corresponding V6 address
            (if there exists a map) octets in reverse order.

      In the opposite direction, when a DNS response traverses from  the
      DNS  server  on the V6 network to the V4 node,  the  DNS-ALG  once
      again traps the DNS packet and would:

         a)   Translate  DNS  responses  for "AAAA" or "A6" records into
         "A" records, (only translate "A6" records  when  the  name  has
         completely been resolved)
         b)  Replace  the  V6 address resolved by the V6 DNS with the V4
         address internally assigned by the NAT-PT router.

      If a V4 address is not previously assigned  to   this   V6   node,
      NAT-PT  would  assign  one at this time. The TTL values on all DNS
      resource records (RRs) passing through NAT-PT SHOULD be set  to  0
      so that DNS servers/clients do not cache temporarily assigned RRs.
      Note, however, that due to some buggy DNS client implementations a
      value of 1 might in some cases work better.  The TTL values should
      be left unchanged for statically mapped addresses.

      This  technique, as described below,  is  also  useful for  outgo-
      ing communication.

   4.2 V4 Address assignment for outgoing connections (V6 to V4)

      V6 nodes learn the address of V4 nodes from the DNS server in  the
      V4  domain or from the DNS server internal to the V6  network.  We
      recommend  that DNS servers internal to V6 domains maintain a map-
      ping of names to IPv6 addresses for internal  nodes  and  possibly
      for  some external nodes.  In the case where the DNS server in the
      v6 domain contains the mapping for  external  V4  nodes,  the  DNS
      queries  will  not  cross the V6 domain and that would obviate the
      need for DNS-ALG intervention. Otherwise, the queries  will  cross
      the  V6  domain and are subject to DNS-ALG intervention. We recom-
      mend external DNS servers in the V4 domain maintain  name  mapping

Tsirtsis & Srisuresh                                            [Page 9]

Internet Draft    Network Address + Protocol Translator        June 1999

      for  external  nodes  (i.e.,  V4 nodes) only. Thus, zone transfers
      across IPv4 - IPv6 boundaries are strongly discouraged.

      In the case of NAPT-PT, a TCP/UDP source port is assigned from the
      registered V4 address upon detection of each new outbound session.

      We saw that a V6 node that needs to communicate with   a  V4  node
      needs  to use a specific prefix (PREFIX::/96) in front of the IPv4
      address of the V4 node. The above technique  allows  the   use  of
      this  PREFIX without any configuration in the nodes. E.g.: In Fig-
      ure 2, Node-A makes a name look-up ("AAAA"  or  "A6"  record)  for
      Node-C.   The   DNS  query   goes   to  the V6 DNS server and from
      there to the V4 DNS server outside the V6 stub  domain,  after  it
      has  been   translated  by   the  DNS-ALG.  The  reply follows the
      same route but now the DNS-ALG translates the reply adding the ap-
      propriate PREFIX.  So, if the reply is

         NodeC    A     132.146.243.30, it is translated to
         NodeC   AAAA   PREFIX::132.146.243.30 or to
         NodeC    A6    PREFIX::132.146.243.30

      Now   Node  A can use this address like any other IPv6 address and
      the V6 DNS server can even cache it as long as  the  PREFIX   does
      not change.

      An   issue  here   is  how the V6 DNS server in the V6 stub domain
      talks to the V4 domain outside the V6 stub domain.  Remember  that
      there   are  no  dual stack nodes here. The external V4 DNS server
      needs to point to a V4 address, part of the V4 pool of  addresses,
      available  to  NAT-PT.  NAT-PT  keeps a one-to-one mapping between
      this V4 address and the V6 address of the internal V6 DNS  server.
      In  the  other direction, the V6 DNS server points to a V6 address
      formed by the IPv4 address of the external V4 DNS servers and  the
      prefix  (PREFIX::/96)  that indicates non IPv6 nodes.  This mecha-
      nism  can easily be extended to accommodate secondary DNS servers.

      Note  that  the  scheme  described in this section impacts DNSSEC.
      See section 7.5 of this document for details.

5. Protocol Translation Details

   The IPv4 and ICMPv4 headers are similar to their V6 counterparts  but
   a  number of field are either missing, have different meaning or dif-
   ferent length. NAT-PT SHOULD translate all IP/ICMP headers from v4 to
   v6 and vice versa in order to make end-to-end IPv6 to IPv4 communica-
   tion possible.  Due to the address translation function and  possible
   port  multiplexing,   NAT-PT SHOULD also make appropriate adjustments
   to the upper layer protocol (TCP/UDP) headers. A separate section  on

Tsirtsis & Srisuresh                                           [Page 10]

Internet Draft    Network Address + Protocol Translator        June 1999

   FTP-ALG describes the changes FTP-ALG would make to FTP payload as an
   FTP packet traverses from v4 to v6 realm or vice versa.

   Protocol Translation details are described in [SIIT], but  there  are
   some  modifications  required to SIIT because of the fact that NAT-PT
   also performs Network Address Translation.

   5.1  Translating IPv4 headers to IPv6 headers

      This is done exactly the same as in SIIT apart from the  following
      fields:

         Source Address:
            The   low-order   32  bits is the IPv4  source  address. The
            high-order 96 bits is the designated PREFIX for all v4  com-
            munications.   Addresses using this PREFIX will be routed to
            the NAT-PT gateway (PREFIX::/96)

         Destination Address:
            NAT-PT  retains a mapping between the IPv4  destination  ad-
            dress and the IPv6 address of the destination node. The IPv4
            destination address is replaced by the IPv6 address retained
            in that mapping.

   5.2  Translating IPv6 headers to IPv4 headers

      This is done exactly the same as in SIIT apart from the Source Ad-
      dress which should be determined as follows:

         Source Address:
            The NAT-PT retains a mapping between the IPv6 source address
            and  an  IPv4 address from the pool of IPv4 addresses avail-
            able. The IPv6 source address is replaced by  the  IPv4  ad-
            dress retained in that mapping.

   5.3  TCP/UDP/ICMP Checksum Update

      NAT-PT  retains  mapping  between IPv6 address and an IPv4 address
      from the pool of IPv4 addresses available. This mapping is used in
      the translation of packets that go through NAT-PT.

      The  following sub-sections describe  TCP/UDP/ICMP checksum update
      procedure in NAT-PT, as packets are translated  from V4 to V6  and
      vice versa.

            5.3.1. TCP/UDP/ICMP Checksum Update from IPv4 to IPv6

            UDP  checksums, when set to a non-zero value, and TCP check-

Tsirtsis & Srisuresh                                           [Page 11]

Internet Draft    Network Address + Protocol Translator        June 1999

            sum SHOULD be  recalculated to reflect the  address   change
            from  v4  to  v6. The incremental  checksum adjustment algo-
            rithm may  be  borrowed  from [NAT]. In the case of NAPT-PT,
            TCP/UDP  checksum  should be adjusted to account for the ad-
            dress and TCP/UDP  port  changes, going  from V4 to  V6  ad-
            dress.

            When the checksum of a V4 UDP packet is set to zero,  NAT-PT
            must evaluate  the checksum   in  its   entirety   for   the
            V6-translated  UDP packet.  If a V4 UDP packet with a check-
            sum of zero arrives  in fragments,  NAT-PT  must  queue  the
            fragments   until   they   can   be assembled into  a single
            non-fragmented packet and evaluate  the  checksum  prior  to
            forwarding the translated V6 UDP packet.

            ICMPv6,  unlike  ICMPv4, uses a pseudo-header, just like UDP
            and TCP during checksum computation.  As a result,  when the
            ICMPv6   header  checksum  is  computed [SIIT], the checksum
            needs to be adjusted  to to account for the additional pseu-
            do-header.   Note, there may also be adjustments required to
            the checksum due to changes  in  the source and  destination
            addresses  (and  changes  in TCP/UDP/ICMP identifiers in the
            case of NAPT-PT) of the payload carried within ICMP.

         5.3.2. TCP/UDP/ICMP Checksum Update from IPv6 to IPv4

            TCP and UDP checksums SHOULD be recalculated to reflect  the
            address  change  from  v6 to v4.  The  incremental  checksum
            adjustment algorithm may be  borrowed from  [NAT].  In   the
            case   of  NAPT-PT, TCP/UDP checksums should be  adjusted to
            account  for  the  address and TCP/UDP  port  changes, going
            from  V6 to V4 addresses.  For  UDP packets, optionally, the
            checksum may simply be changed to zero.

            The checksum calculation for a V4 ICMP  header needs to   be
            derived from  the  V6 ICMP  header  by  running  the  check-
            sum  adjustment algorithm [NAT]  to  remove  the  V6  pseudo
            header  from  the  computation.  Note,  the adjustment  must
            additionally  take  into account changes to the checksum  as
            a result of updates to the source  and destination addresses
            (and transport ports in the case of  NAPT-PT)  made  to  the
            payload carried within ICMP.

6. FTP Application Level Gateway (FTP-ALG) Support

   Because  an  FTP  control session carries, in its payload, the IP ad-
   dress and  TCP port  information for the data session, an FTP-ALG  is
   required  to  provide application level transparency for this popular

Tsirtsis & Srisuresh                                           [Page 12]

Internet Draft    Network Address + Protocol Translator        June 1999

   Internet application.

   In the FTP application runnning on a legacy V4 node, arguments to the
   FTP  PORT  command and arguments in PASV response(successful) include
   an IP V4 address  and  a  TCP port,  both  represented  in  ASCII  as
   h1,h2,h3,h4,p1,p2. However, [FTP-IPV6] suggests EPRT and EPSV command
   extensions to FTP, with an intent to eventually  retire  the  use  of
   PORT  and  PASV  commands. These extensions may be used on a V4 or V6
   node. FTP-ALG, facilitating transparent FTP between V4 and V6  nodes,
   works as follows.

   A  V4  host  may or may not have the EPRT and EPSV command extensions
   implemented in its FTP application.  If a V4 host originates the  FTP
   session  and  uses  PORT  or PASV command, the FTP-ALG will translate
   these commands into EPRT and  EPSV  commands  respectively  prior  to
   forarding  to the V6 node. Likewise, EPSV response from V6 nodes will
   be translated into PASV response prior to  forwarding  to  V4  nodes.
   The  format of EPRT and EPSV commands and EPSV response may be speci-
   fied as follows[FTP-IPV6].

      EPRT<space><d><net-prt><d><net-addr><d><tcp-port><d>
      EPSV<space><net-prt>
            (or)
      EPSV<space>ALL

      Format  of  EPSV response(Positive): 229 <text indicating extended
      passive mode> (<d><d><d><tcp-port><d>)

   PORT command from a V4 node is translated into EPRT command, by  set-
   ting the protocol <net-prt> field to AF #2 (IPV6) and translating the
   V4 host Address (represented as h1,h2,h3,h4) into its NAT-PT assigned
   V6  address  in ::: notation in the <net-addr> field. TCP port repre-
   sented by p1,p2 in PORT command must be specified as a decimal  <tcp-
   port>  in  the EPRT command. Further, <tcp-port> translation may also
   be required in the case of NAPT-PT. PASV command from a V4 node is be
   translated  into a EPSV command with the <net-prt> argument set to AF
   #2.  EPSV response from a V6 node is translated  into  PASV  response
   prior to forwarding to the target V4 host.

   If  a  V4 host originated the FTP session and was using EPRT and EPSV
   commands, the FTP-ALG will simply translate the parameters  to  these
   commands, without altering the commands themselves. The protocol Num-
   ber <net-prt> field will be translated from AF #1 to AF #2.  <net-ad-
   dr> will be translated from the V4 address in ASCII to its NAT-PT as-
   signed V6 address in ::: notation. <tcp-port> argument  in  EPSV  re-
   sponse requires translation only in the case of NAPT-PT.

   However, if a V6 host originates the FTP session, the FTP-ALG has two

Tsirtsis & Srisuresh                                           [Page 13]

Internet Draft    Network Address + Protocol Translator        June 1999

   approaches to pursue. In the first approach, the FTP-ALG  will  leave
   the  command strings "EPRT" and "EPSV" unaltered and simply translate
   the <net-prt>, <net-addr> and <tcp-port> arguments  from  V6  to  its
   NAT-PT (or NAPT-PT) assigned V4 information. <tcp-port> is translated
   only in the case of NAPT-PT. Same goes  for  EPSV  response  from  V4
   node. This is the approach we recommend to ensure forward support for
   RFC 2428.  However, with this approach, the V4 hosts are mandated  to
   have  their  FTP application upgraded to support EPRT and EPSV exten-
   sions to allow access to V4 and V6 hosts, alike.

   In the second  approach,  the  FTP-ALG  will  translate  the  command
   strings  "EPRT" and "EPSV" and their parameters from the V6 node into
   their equivalent NAT-PT assigned V4 node info and  attach  to  "PORT"
   and  "PASV"  commands prior to forwarding to V4 node.  Likewise, PASV
   response from V4 nodes is translated into EPSV response prior to for-
   warding to the target V6 nodes.  However, the FTP-ALG would be unable
   translate the command "EPSV<space>ALL" issued by V6 nodes. In such  a
   case,  the  V4  host, which receives the command, may return an error
   code indicating unsupported function. This  -ve  response  may  cause
   many RFC 2428 compliant FTP applications to simply fail, because EPSV
   support is mandated by RFC 2428. The benefit of this  approach,  how-
   ever,  is  that is does not impose any FTP upgrade requirements on V4
   hosts.

   Note, all translations are ASCII encoded translations.  As  a result,
   these  translations  may  result in a change in the size of packet.

   If  the  new size is the same as the previous, only  the TCP checksum
   needs adjustment as a result of the payload translation. If  the  new
   size   is   different  from the previous, TCP sequence numbers should
   also be changed to reflect the change in  the length of the FTP  con-
   trol  session payload. The IP packet length field in the V4 header or
   the IP payload  length field in the V6 header should also be  changed
   to  reflect  the new payload size. A table is used by the FTP- ALG to
   correct the TCP sequence  and  acknowledgement numbers   in  the  TCP
   header for control packets in both directions.

   The  table entries should have the source  address, source data port,
   destination address and destination data port for V4 and V6  portions
   of  the  session, sequence number delta  for outbound control packets
   and  sequence  number delta for inbound control packets.

   The sequence number for an outbound control packet is  increased   by
   the  outbound sequence  number  delta, and the acknowledgement number
   for  the same outbound packet is decreased by  the  inbound  sequence
   number delta.   Likewise,  the sequence  number for an inbound packet
   is increased by the inbound sequence number delta  and  the  acknowl-
   edgement  number for the same inbound packet is decreased by the out-

Tsirtsis & Srisuresh                                           [Page 14]

Internet Draft    Network Address + Protocol Translator        June 1999

   bound sequence number delta.

7. NAT-PT Limitations and Future Work

   7.1 Topology limitations

      There are limitations to using the NAT-PT translation  method.  It
      is mandatory that all requests and responses pertaining to a  ses-
      sion be routed via the same NAT-PT router. One  way  to  guarantee
      this  would  be  to  have  NAT-PT based on a border router that is
      unique to  a  stub domain, where all IP packets are either  origi-
      nated from the domain or destined to the domain.

      Note,  this  limitation  does   not  apply to packets  originating
      from  or  directed  to dual-stack nodes that do not require packet
      translation.   This  is  because  in a dual-stack set-up, IPv4 ad-
      dresses implied in a V6 address can be identified from the address
      format  PREFIX::x.y.z.w  and  a dual-stack router can  accordingly
      route  a packet  between v4 and dual-stack nodes without  tracking
      state information.

   7.2 Protocol Translation Limitations

      A  number of IPv4 fields have changed meaning in IPv6 and transla-
      tion is  not  straightforward. For  example,  the option   headers
      semantics and syntax have  changed  significantly  in  IPv6.  More
      meaningful translations may be possible in the future  using  NAT-
      PT.

   7.3 Impact of Address Translation

      Since  NAT-PT  performs  address  translation,  applications  that
      carry  the  IP  address  in  the higher layers will  not work.  In
      this  case  Application Layer Gateways (ALG)  need to  be incorpo-
      rated to provide support for those applications.

   7.4 Lack of end-to-end security

      One of the most important limitations of the  NAT-PT  proposal  is
      the  fact  that end-to-end network layer security is not possible.
      Also  transport and application layer security may not be possible
      for applications  that  carry  IP  addresses  to  the  application
      layer. This  is an inherent limitation  of  the  Network   Address
      Translation function.

      Independent of NAT-PT, end-to-end IPSec security is  not  possible
      across different address realms. The two end-nodes that seek IPSec

Tsirtsis & Srisuresh                                           [Page 15]

Internet Draft    Network Address + Protocol Translator        June 1999

      network level security must both support one of IPv4 or IPv6.

   7.5 DNS Translation and DNSSEC

      The scheme described in  section  4.2  involves translation of DNS
      messages.  It  is  clear  that  this scheme can not be deployed in
      combination  with secure  DNS.  I.e.,  an  authoritative  DNS name
      server  in  the  V6  domain  cannot  sign  replies to queries that
      originate   from the  V4 world.  As  a result, an V4 end-node that
      demands  DNS replies  to be signed  will reject  replies that have
      been tampered with by NAT-PT.

      The good  news,  however,  is  that only servers in V6 domain that
      need to be  accessible  from  the  V4 world  pay the price for the
      above limitation, as V4 end-nodes may not access V6 servers due to
      DNS replies not being signed.

      Also  note that  zone transfers between DNS-SEC servers within the
      same V6 network are not impacted.

      Clearly,  with  DNS SEC deployment in DNS servers and end-host re-
      solvers, the scheme  suggested  in this document would not work.

8. Applicability Statement

   NAT-PT can be a valuable transition tool at the border of a stub net-
   work   that   has   been  deployed as an IPv6 only network when it is
   connected to an Internet that is either V4-only or a combination   of
   V4 and V6.

   NAT-PT,  in  its  simplest form, without the support of DNS-ALG, pro-
   vides one way connectivity between an IPv6 stub domain and the   IPv4
   world  meaning  that only sessions initialised by IPv6 nodes internal
   to the IPv6 stub domain can be translated, while  sessions  initiated
   by   IPv4 nodes  are dropped. This makes NAT-PT a useful tool to IPv6
   only stub networks that need to be able to maintain connectivity with
   the   IPv4  world  without  the need to deploy servers visible to the
   IPv4 world.

   NAT-PT  combined  with a DNS-ALG provides bi-directional connectivity
   between the IPv6 stub domain and the IPv4 world allowing sessions  to
   be  initialised  by  IPv4  nodes  outside the IPv6 stub domain.  This
   makes NAT-PT useful for IPv6 only stub  networks that need to  deploy
   servers visible to the IPv4 world.

9. Security Considerations

Tsirtsis & Srisuresh                                           [Page 16]

Internet Draft    Network Address + Protocol Translator        June 1999

   Section  7.4  of  this  document describes the  fact  that end-to-end
   network  and  transport layer security are not possible when  a  ses-
   sion is  intercepted by a NAT-PT.  Also  application  layer  security
   may  not  be possible for applications  that  carry  IP  addresses in
   the application layer.

   Section  7.5 of this document describes the fact that the DNS-ALG can
   not be deployed in combination with secure DNS.

   Finally, all of the security considerations described  in  [NAT-TERM]
   are applicable to this document as well.

10. REFERENCES

[FTP-IPV6] M. Allman, S. Ostermann, C. Metz, "FTP  Extensions  for  IPv6
and NATs", RFC 2428, September 1998.

[DNSSEC]  D.  Eastlake,  "Domain Name  System  Security Extensions", RFC
2065, March 1999.

[NAT] K. Egevang, P. Francis, The IP Network Address  Translator  (NAT),
RFC 1631, May 1994

[NAT-TERM]  P.  Srisuresh,  M.  Holdrege, "IP Network Address Translator
(NAT)   Terminology   and    Considerations"  <draft-ietf-nat-terminolo-
gy-03.txt>, Work in Progress, June 1999.

[SIIT]  E.  Nordmark,    "Stateless    IP/ICMP    Translator    (SIIT)",
<draft-ietf-ngtrans-siit-05.txt>, Work in progress, January 1999.

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

AUTHORS

George Tsirtsis
Internet Transport Group
B29 Room 129
BT Laboratories
IPSWICH IP5 3RE
England
Phone: +44 1473 640756
Fax:   +44 1473 640709
e-mail: george.tsirtsis@bt.com
e-mail (alternative): gtsirt@hotmail.com

Tsirtsis & Srisuresh                                           [Page 17]

Internet Draft    Network Address + Protocol Translator        June 1999

Pyda Srisuresh
Lucent Technologies
4464 Willow Road
Pleasanton, CA 94588-8519
U.S.A.
Voice: (925) 737-2153
Fax:   (925) 737-2110
EMail: suresh@ra.lucent.com

Tsirtsis & Srisuresh                                           [Page 18]


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