[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 Laboratories
Category: EXPERIMENTAL                                    Pyda Srisuresh
Expire in six months                                 Lucent Technologies
                                                           February 1999


      Network Address Translation - Protocol Translation (NAT-PT)
                   <draft-ietf-ngtrans-natpt-05.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
   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."

   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 a transition mechanism in addition  to  those
   already   specified in   [TRANS].   The  new  mechanism  provides  an
   end-to-end solution to allow IPv6-only hosts  to   communicate   with
   IPv4-only   hosts  and vice versa using Network  Address  Translation
   and Protocol  Translation. The scheme described does not require  du-
   al-stack  hosts; nor  does it mandate any routing related changes  on
   the hosts. The scheme is based on a combination of  address  transla-
   tion  theme  as  described  in [NAT-TERM] and V6/V4 protocol transla-
   tion theme as described in [SIIT].





Tsirtsis & Srisuresh                                            [Page 1]

Internet Draft    Network Address + Protocol Translator    February 1999


Acknowledgements

   Special  thanks  to Pedro Marques for reviewing an earlier version of
   the draft.  Finally, many thanks  to Alan O'Neill and Martin   Tatham
   since   the initial idea described in this document was developed af-
   ter discussions with them.


Index

   1. Introduction

   2. Terminology

   3. Network Address Translation operation
      3.1 NAT-PT Outgoing Sessions (IPv6 to IPv4)
      3.2 NAPT-PT Outgoing Sessions (IPv6 to IPv4)

   4. IP v4 Address Assignment
      4.1 V4 Address assignment for outgoing connections
      4.2 V4 Address assignment for incoming connections
         4.2.1 DNS Application Layer Gateway (ALG) support

   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
      5.4 FTP Application level Gateway (FTP-ALG) support

   6. NAT-PT Limitations and Future Work
      6.1 Topology limitations
      6.2 Protocol Translation Limitations
      6.3 Impact of Address Translation
      6.4 Lack of end-to-end security
      6.5 DNS Translation and DNSSEC

   7. Applicability Statement

   8. Security Considerations

   9. References


1. Introduction

   IPv6 is the upcoming IP  protocol  that  was  designed  in  order  to
   modernise IPv4, which was designed in the 1970s. IPv6 has a number of
   advantages over IPv4 including the  fact  that  it  provides  a  much



Tsirtsis & Srisuresh                                            [Page 2]

Internet Draft    Network Address + Protocol Translator    February 1999


   larger  address  space  than  IPv4, which for many, is the number one
   reason to move to IPv6. A basic requirement, however,   for  a  large
   number  of people is to be able to communicate with IPv4 hosts during
   the transition period. Keeping in mind that  the  chances  are   that
   IPv4   and   IPv6  will  have  to  coexist  for  a  very  long  time,
   interoperability becomes a very important issue.

   The SIIT proposal [SIIT] describes a protocol  translation  mechanism
   that  allows  communication between IPv6-only and IPv4-only machines.
   This proposal assumes that V6 hosts are somehow assigned a V4 address
   for   communicating  with  V4  hosts.  With  these  assumptions, SIIT
   purports  to do protocol independent translation of V4/V6  datagrams,
   requiring no state details on the sessions.

   NAT-PT  uses  a  pool of V4 addresses for assignment to V6 hosts 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 restriction on NAT-PT are very similar to
   those described for V4 NATs in [NAT-TERM]. Protocol  translation  de-
   tails specified in [SIIT] would be used to extend address translation
   with  protocol syntax/semantics translation. A detailed applicability
   statement for NAT-PT may be found at the  end  of  this  document  in
   section 7.


2. Terminology


      Session initiation packet
            This  is  the  first  packet  of  an IP  session.  Only  the
            first  packet of a TCP session can be identified  in  a  de-
            terministic way, with the presence of SYN bit and absence of
            ACK  bit  in  TCP  header.  There is no deterministic way to
            recognise the start of a UDP or any non-TCP session.   [NAT-
            TERM].

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




Tsirtsis & Srisuresh                                            [Page 3]

Internet Draft    Network Address + Protocol Translator    February 1999


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

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

      Application Level Gateway (ALG)
            Application  Level  Gateway  (ALG) [NAT-TERM]  is  an appli-
            cation specific agent that allows a V6 host  to  communicate
            with  a  V4  host  and vice  versa.  Some applications carry
            network addresses in payload.  NAT-PT is  application  inde-
            pendent  and  does not snoop the payload to fix IP addresses
            in payload. ALG works in conjunction with NAT-PT to  provide
            application level  transparency.


3. Network Address Translation operation

   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 hosts in a private network
   could traverse through whichever NAT device has the best  metric  for
   an external host.

   NAT-PT  is  application  independent. Applications such as "FTP" that
   include IP addresses in payload  will  need to be supported by appli-
   cation  specific  ALGs  in conjunction with NAT-PT. This document de-
   scribes the functioning of FTP and DNS  ALGs in conjunction with NAT-



Tsirtsis & Srisuresh                                            [Page 4]

Internet Draft    Network Address + Protocol Translator    February 1999


   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 both sides, when an
   IPv6 domain is connected to an IPv4 domain through a NAT-PT.


   3.1 NAT-PT Outgoing Sessions (IPv6 to IPv4)


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

            Figure 1: IPv6 to IPv4 communication
            Host IPv6-A has an IPv6 address -> FEDC:BA98::7654:3210
            Host IPv6-B has an IPv6 address -> FEDC:BA98::7654:3211
            Host 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

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

            Source Address, SA=FEDC:BA98::7654:3210 and
            Destination Address, DA = prefix::132.146.243.30

      NOTE:  The  prefix PREFIX::/96 is advertised in the stub domain by
      the NAT-PT and it points to it. The pre-configured prefix  has  to
      be  routable  only  inside  the  stub domain representing the IPv4
      world.

      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



Tsirtsis & Srisuresh                                            [Page 5]

Internet Draft    Network Address + Protocol Translator    February 1999


      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, while
      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.  The  returning  traffic  will be recognised as
      belonging to the same session and the packet will use  the  cached
      information  in  order to be translated, while the addresses after
      the        translation       will       be       as       follows.
      SA=PREFIX::132.146.243.30,  DA=FEDC:BA98::7654:3210.    Note  that
      this packet can now be routed inside the IPv6-only network as nor-
      mal.


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

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

      NAPT-PT  also solves a problem that is inherent with NAT-PT.  That
      is, NAT-PT would fall flat when the pool of V4 addresses  assigned
      for  translation  purposes  is exhausted. Once the address pool is
      exhausted, newer V6 hosts cannot establish sessions with the  out-
      side world anymore.  NAPT-PT, on the other hand, will allow for  a
      maximum of 63K TCP and 63K UDP sessions before falling  flat  with
      no TCP and UDP ports left to assign.

      In the example sited in figure 1, say, we have NAPT-PT on the bor-
      der router (instead of NAT-PT) and all V6 addresses are mapped in-
      to a single v4 address 120.130.26.10.

      Say the IPv6 Host A wanted to set up a TCP session with  the  IPv4
      Host  C.

      Host 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.




Tsirtsis & Srisuresh                                            [Page 6]

Internet Draft    Network Address + Protocol Translator    February 1999


      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

      As for inbound sessions, they are restricted  to  one  server  per
      service made possible by static TCP/UDP port mapping. For example,
      say the Host [IPv6-A] in figure 1 is the only HTTP server  in  the
      V6 domain. Host  [IPv4-C] sends a packet:

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

      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  (http
            port)

      In the above example, note that all sessions  to  NAPT  registered
      address  with  service  port  of 80 will be redirected to the same
      host [IPv6-A].


4. IPv4 Address Assignment

   IPv4 addresses are assigned by NAT-PT to a V6 host, when NAT-PT iden-
   tifies the  start of session, inbound or outbound. Identification  of
   session start on the inbound is done differently  from  that  on  the
   outbound.  However, the same V4 address pool is used for assigning to
   V6 hosts, irrespective of whether a  session  is  initiated  outbound
   from a V6 host or initiated inbound from a V4 host.

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


   4.1 V4 Address assignment for outgoing connections



Tsirtsis & Srisuresh                                            [Page 7]

Internet Draft    Network Address + Protocol Translator    February 1999



      Outbound session start is based on identifying the first packet of
      a session. For ex: SYN, !ACK for TCP sessions.

      V6 hosts learn the address of V4 hosts from the DNS server in  the
      V4  domain or the DNS server internal to the V6 network. We recom-
      mend that DNS servers internal to V6 maintain mapping of names  to
      IP  V6  addresses  for  internal  hosts and possibly some external
      hosts.  External DNS servers in the V4 domain maintain  name  map-
      ping for external hosts (i.e., V4 hosts) alone.

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

   4.2 V4 Address assignment for incoming connections

      In  order  to initiate incoming sessions, a V4 host obtains the V4
      address of the V6 host it is trying to connect to by making a  DNS
      request.  This  request  constitutes  the start of a potential new
      session.

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

            Figure 2: IPv4 to IPv6 communication

         Host IPv6-A has an IPv6 address -> FEDC:BA98::7654:3210
         Host IPv6-B has an IPv6 address -> FEDC:BA98::7654:3211
         Host 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


      4.2.1 DNS Application Layer Gateway (ALG) support

         In figure 2 above, when Host C name resolver makes a name  look
         up  request  for  Host A, the lookup query is redirected to the
         DNS server on the V6 network. Considering that NAT-PT is resid-
         ing   on the border router between V4 and V6 networks, this re-
         quest datagram would traverse through the  NAT-PT  router.  The
         DNS  ALG on NAT-PT  would modify  the DNS Queries going into V6



Tsirtsis & Srisuresh                                            [Page 8]

Internet Draft    Network Address + Protocol Translator    February 1999


         domain as follows:

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

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

            a)  Translate  DNS  responses  for  "AAAA"  records into 'A'
            records,
            b) Replace the V6 address sent by the V6 DNS server with the
            V4 address internally assigned by the NAT-PT router.

         If a V4 address is not previously assigned  to  this  V6  host,
         NAT-PT would assign it this time. The TTL values on all DNS re-
         source records (RRs) passing through NAT-PT would be set to  0.

         This  technique  is  also  useful for outgoing communication as
         well. We saw that a v6host that needs to communicate with  a v4
         hosts needs to use a specific prefix (PREFIX::) in front of the
         IPv4 address of the v4host. The above technique allows the  use
         of this prefix without any configuration in the hosts. E.g.: In
         Figure 2, Host-A makes a name look-up on the  Host-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  NAT-PT.  The  reply follows the same route but now the
         NAT-PT translates the reply adding the appropriate prefix.  So,
         if the reply is:

            HostC    A     132.146.243.30, it is translated to
            HostC   AAAA   PREFIX::132.146.243.30

         Now  Host  A can use this address as any other IPv6 address and
         the v6 DNS server can even cache it as long as the prefix  does
         not change.

         An  additional  problem is how the v6 DNS server in the v6 stub
         domain talks to the v4 domain outside the v6 stub  domain.  Re-
         member that  there  are  no  dual stack hosts here. The v4  DNS
         server needs to point to a v4 address, part of the v4 pool   of
         addresses,  available to the NAT-PT. The NAT-PT keeps a one-to-
         one mapping between this v4 address and the IPv6 address of the



Tsirtsis & Srisuresh                                            [Page 9]

Internet Draft    Network Address + Protocol Translator    February 1999


         v6 DNS server. In the other direction, the v6 DNS server points
         to the IPv4 address of the v4 DNS servers with the prefix (PRE-
         FIX::) which  indicates  non  IPv6 address. This mechanism  can
         easily be extended to accommodate secondary DNS servers.

         Note that the scheme described above impacts DNSSEC and look at
         section 6.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  v4 to  v6
   and vice versa in order to make end-to-end IPv6 to IPv4 communication
   possible.  Due to the address translation function and possible  port
   multiplexing,  NAT-PT SHOULD also make the appropriate adjustments to
   the upper layer protocol (TCP/UDP) header. A separate section on 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 adequately in [SIIT]. Here  are  the
   required modifications on SIIT that are imposed by 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
               communications  and points to the  NAT-PT gateway   (PRE-
               FIX::/96)

         Destination Address:
               The  NAT-PT  retains a mapping between the  IPv4  DA  and
               the IPv6 address of the destination host. The IPv4  DA 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 calculated as follows:



Tsirtsis & Srisuresh                                           [Page 10]

Internet Draft    Network Address + Protocol Translator    February 1999



         Source Address:
               The NAT-PT retains a mapping between the IPv6  SA  and an
               IPv4 address from the pool of IPv4  addresses  available.
               The IPv6 SA is replaced by the  above  IPv4  address.


   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 checksum, when set to a non-zero value and TCP checksum SHOULD
      be  recalculated to reflect the address  change from v4 to v6. The
      incremental  checksum adjustment algorithm may  be  borrowed  from
      [NAT]. In the case of NAPT-PT, TCP/UDP checksum should be adjusted
      to account for the address and TCP/UDP  port  changes, going  from
      V4 to V6 address.

      When the checksum of V4 UDP packet is set  to  zero,  NAT-PT  must
      evaluate  checksum  in its  entirety  for  the  V6-translated  UDP
      packet.  If  a  V4  UDP  packet  with  checksum  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  ICMPv6  header
      checksum is computed [SIIT], the checksum needs to be adjusted  to
      to account for the additional pseudo-header.  Note, there may also
      be adjustments required to the checksum due to changes  in  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 checksum 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 checksum should be  adjusted to account  for  the  address
      and TCP/UDP  port  changes, going from V6 to V4 address.  For  UDP



Tsirtsis & Srisuresh                                           [Page 11]

Internet Draft    Network Address + Protocol Translator    February 1999


      packets, optionally, the checksum may simply be assigned zero.

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


   5.4 FTP Application level Gateway (FTP-ALG) support

      FTP control session carries in its payload the IP address and  TCP
      port  information pertaining to the data session it  supports,  an
      FTP ALG on NAT-PT is needed to provide support for the popular In-
      ternet application.

      The arguments to the File Transfer Protocol (FTP) PORT command and
      PASV response include an IP address (V4 or V6 address) and  a  TCP
      port  in ASCII. If the IP address in PORT command or PASV response
      is  a  V6  address,  then  FTP-ALG should substitute this with the
      NAT-PT assigned V4 address. In case of NAPT-PT, even the TCP  port
      following  the  IP  address  should  be  translated.  The  reverse
      (translation from  v4  address  to  V6 address) is true in the in-
      bound packets.

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

      If the new size is same as the previous,  only  the  TCP  checksum
      needs  adjustment  as  a result of payload translation. If the new
      size  is  different from the previous, TCP sequence numbers should
      also be changed to reflect the change in  length  of  FTP  control
      session  payload. The IP packet length field in V4 header  or  the
      IP payload  length in V6 field should also be changed by the  same
      delta  change in payload size. A special table is used by the FTP-
      ALG to correct the TCP sequence  and  acknowledge  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 pack-
      ets and  sequence  number delta for inbound packets. The  sequence
      number deltas are negative (i.e., payload size decreases)  on  the
      outbound  and  positive  (i.e., payload increases) on the inbound.
      Sequence number for an outbound packet is increased  by  the  out-



Tsirtsis & Srisuresh                                           [Page 12]

Internet Draft    Network Address + Protocol Translator    February 1999


      bound sequence  number  delta  and acknowledgement number for  the
      same outbound packet is decreased by the inbound  sequence  number
      delta.   Likewise,  sequence  number  for an inbound packet is in-
      creased by the inbound sequence number delta  and  acknowledgement
      number  for  the  same inbound packet is decreased by the outbound
      sequence number delta.


6. NAT-PT Limitations and Future Work

   6.1 Topology limitations

      There  are  limitations  to  using  the  translation method. It is
      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 either originated from the domain
      or destined to the domain.

      Note, this limitation does  not  apply   to   packets  originating
      from  or  directed  to dual-stack hosts that do not require packet
      translation.  This is because in a dual-stack set-up, IPv4 address
      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 in-
      formation

   6.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,  some
      meaningful  translation  may  also be possible in the future using
      NAT-PT.

   6.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 services to that kind of applications.

   6.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



Tsirtsis & Srisuresh                                           [Page 13]

Internet Draft    Network Address + Protocol Translator    February 1999


      layer.   This  is an inherent limitation from the Network  Address
      Translation function.

      Independent of NAT-PT, end-to-end IPsec security is  not  possible
      across different routing realms. The two end-nodes that seek IPsec
      network level security must both support one of IPv4 or IPv6.


   6.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,  if  DNS-SEC  were to become  the norm in both V4 and  V6
      DNS servers and end-host resolvers, the scheme  suggested  in this
      document will not work.


7. 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 and it is con-
   nected 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 provides
   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



Tsirtsis & Srisuresh                                           [Page 14]

Internet Draft    Network Address + Protocol Translator    February 1999


   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.


8. Security Considerations

   Section  6.4  of  this  document describes the  fact  that end-to-end
   network and transport layer security is not possible when  a  session
   is  intercepted by a NAT-PT.  Also application layer security may not
   be possible for applications  that  carry  IP  addresses to  the  ap-
   plication layer.

   Section  6.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.


9. REFERENCES

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

[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-terminology-01.txt>, Work in Progress, October 1998.

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

[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



Tsirtsis & Srisuresh                                           [Page 15]

Internet Draft    Network Address + Protocol Translator    February 1999


Fax:   +44 1473 640709
e-mail: george@gideon.bt.co.uk

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 16]


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