Subject: (ngtrans) W.G. Last Call on "Network Address Translation - Protocol Translation (NAT-PT)"

From: Bob Fink <[email-masked]>
Date: Mon, 09 Nov 1998 16:06:21 -0800

This is an NGtrans working group last call for comments on advancing the 
following document as an Experimental Standard:

	Title : Network Address Translation - Protocol Translation (NAT-PT)
	Author(s) : G. Tsirtsis, P. Srishuresh
	Filename : draft-ietf-ngtrans-natpt-03.txt
	Pages : 21 
	Date : 9-Nov-98

Please send substantive comments to the ngtrans mailing list, and minor 
editorial comments to the authors. This last call period will end two 
week from today on November 23, 1998.

Bob Fink/ Tony Hain

----------------------------cut here--------------------------------------
INTERNET-DRAFT                                 George Tsirtsis
NGTRANS  WG                                    BT Laboratories
Expires April, 1999                            Pyda Srishuresh
Category: EXPERIMENTAL                         Lucent Technologies
                                               November 1998

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

Status of this Memo

   This document is an Internet-Draft.  Internet-Drafts are working doc-
   uments of the Internet Engineering Task Force (IETF), its areas,  and
   its working groups.  Note that other groups may also distribute work-
   ing 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."

   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 (Northern Eu-
   rope),  ftp.nis.garr.it  (Southern  Europe),  munnari.oz.au  (Pacific
   Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).

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] and V6/V4 protocol translation
   theme as described in [SIIT].

Acknowledgements

   The authors  would  like  to  thank  Erik  Nordmark  whose   Protocol
   Translation details  in [SIIT] formed the bases of the  corresponding
   section 5 in this document

   Special  thanks to Pedro Marques  for  reviewing  the draft. Finally,
   many thanks  to Alan O'Neill and Martin  Tatham  since   the  initial

Tsirtsis & Srisuresh                                            [Page 1]
^L
Internet Draft    Network Address + Protocol Translator    November 1998

   idea  described in this document was developed after 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 ICMPv4 headers to ICMPv6 headers
      5.3 Translating IPv6 headers to IPv4 headers
      5.4 Translating ICMPv6 headers to ICMPv4 headers
      5.5 TCP/UDP Checksum Update
      5.6 FTP Control session payload

   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
   larger  address  space  than  IPv4, which for many, is the number one
   reason to move to IPv6. A basic requirement, however,   for  a  large

Tsirtsis & Srisuresh                                            [Page 2]
^L
Internet Draft    Network Address + Protocol Translator    November 1998

   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.  Further, it assumes that the V6
   hosts would use a V6 address based on their V4 address (V4 mapped  or
   V4  compatible)  as  their source V6 address and V4-mapped address of
   the target V4 machine as the destination V6 address. With  these  as-
   sumptions,  SIIT  purports  to do protocol independent translation of
   V4/V6 datagrams, requiring no state details on the sessions.

   Unlike SIIT, NAT-PT provides a transparent  end-to-end  solution  re-
   quiring  no  changes to end nodes. NAT-PT uses a pool of V4 addresses
   for assignment to V6 hosts on a dynamic basis as sessions are  initi-
   ated  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 NAT-PT to track the sessions it
   supports and mandates that inbound and outbound datagrams  pertaining
   to  a session traverse through the same NAT-PT router.  You will note
   that the topology restriction on NAT-PT are very similar to those de-
   scribed  for V4 NATs in [NAT]. Protocol translation details specified
   in [SIIT] would be used to extend address translation  with  protocol
   syntax/semantics translation.

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

      Network Address Translation (NAT)
            NAT  in this document is very similar, but not   the   same,
            with  IPv4  NAT as  described  in  [NAT].  IPv4  NAT  trans-
            lates  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.

      Protocol Translation (PT)
            PT in this document refers to   translation   of   an   IPv4

Tsirtsis & Srisuresh                                            [Page 3]
^L
Internet Draft    Network Address + Protocol Translator    November 1998

            packet  into   a  semantically equivalent  IPv6  packet  and
            vice  versa.

      Application Layer Gateway (ALG)
            Application  Level  Gateway  (ALG)  is  an application  spe-
            cific  agent  that allows a V6 host to communicate with a V4
            host  and vice  versa.  Some applications carry network  ad-
            dresses in payload.  NAT-PT is application independent (with
            the  notable  exception of  FTP)  and  does  not  snoop  the
            payload  to  fix IP addresses in payload. ALG is an alterna-
            tive to  NAT-PT  for  such applications.

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-
   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)

Tsirtsis & Srisuresh                                            [Page 4]
^L
Internet Draft    Network Address + Protocol Translator    November 1998

                           ^
                           |
                  [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 to the NAT-PT  gateway, where it  has  to  be
      translated 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, 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

Tsirtsis & Srisuresh                                            [Page 5]
^L
Internet Draft    Network Address + Protocol Translator    November 1998

      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.  The port translation and ICMP query iden-
      tifier translation works very similar to the way NAPT is described
      in [NAT].

      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.

      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

Tsirtsis & Srisuresh                                            [Page 6]
^L
Internet Draft    Network Address + Protocol Translator    November 1998

      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

      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.

Tsirtsis & Srisuresh                                            [Page 7]
^L
Internet Draft    Network Address + Protocol Translator    November 1998

   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
         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:

Tsirtsis & Srisuresh                                            [Page 8]
^L
Internet Draft    Network Address + Protocol Translator    November 1998

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

Tsirtsis & Srisuresh                                            [Page 9]
^L
Internet Draft    Network Address + Protocol Translator    November 1998

   ferent length. NAT-PT SHOULD translate all IP/ICMP headers  from  and
   to IPv6 in order to make end-to-end IPv6 to IPv4 communication possi-
   ble.   Due to the address translation function and possible port mul-
   tiplexing, NAT-PT SHOULD also make the appropriate adjustments to the
   upper  layer protocol (TCP/UDP) as well as to the  FTP  control  ses-
   sion payload.

   In  the  following paragraphs we are borrowing the translation mecha-
   nism from the SIIT specification and we make the changes  imposed  by
   the address translation.

   5.1  Translating IPv4 headers to IPv6 headers

      If  the  DF  flag is not set and the IPv4 packet will result in an
      IPv6 packet larger than 1280 bytes the IPv4 packet SHOULD be frag-
      mented prior  to  translating it.  Since IPv4 packets with DF  not
      set will always result in a fragment header  being  added  to  the
      packet,  the IPv4 packets  should  be  fragmented  so  that  their
      length,  excluding  the  IPv4 header, is at most 1232 bytes  (1280
      minus  40 for the IPv6 header and 8 for the Fragment header).  The
      resulting  fragments  are then translated independently using  the
      logic  described below.

      If  the  DF bit is set and the packet is not a fragment (i.e., the
      MF flag is not set and the Fragment Offset is zero) then there  is
      no  need  to add a fragment header to the packet.  The IPv6 header
      fields are set as follows:

         Version:
               6

         Flow ID:
               0 (all zero bits)

         Payload Length:
               Total  length  value  from IPv4 header, minus the size of
               the IPv4 header and IPv4 options, if present.

         Payload Type:
               Protocol field copied from IPv4 header

         Hop Limit:
               TTL value copied from IPv4 header, decremented by one.

         Source Address:
               The low-order 32 bits is the IPv4  source  address.   The
               high-order  96  bits  is the designated prefix for all v4

Tsirtsis & Srisuresh                                           [Page 10]
^L
Internet Draft    Network Address + Protocol Translator    November 1998

               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.

               If  IPv4  options  are present in the IPv4  packet,  they
               are  ignored  i.e.,  there  is no  attempt  to  translate
               them.

               If there is need to add a fragment header (the DF  bit is
               not  set  or  the packet is a fragment) the header fields
               are set as above with the following exceptions:

      IPv6 fields:
         Payload Length:
               Total   length   value   from IPv4 header, plus 8 for the
               fragment header, minus the size of the  IPv4  header  and
               IPv4 options, if present.

         Payload Type:
               Fragment Header (44).

      Fragment header fields:
         Next Header:
                Protocol field copied from IPv4 header.

         Fragment Offset:
               Fragment Offset copied from the IPv4 header.

         M flag:
               More Fragments bit copied from the IPv4 header.

         Identification:
               The   low-order   16  bits copied from the Identification
               field in the IPv4 header.  The high-order 16 bits  set to
               zero

   5.2 Translating ICMPv4 headers to ICMPv6 headers

      All  ICMP messages that are to be translated require that the ICMP
      checksum field be updated as part of the translation since ICMPv6,
      unlike ICMPv4, has a pseudo-header checksum just like UDP and TCP.

      The NAT-PT retains a mapping between the IPv4 DA and the IPv6  ad-
      dress  of  the  destination host. The checksum update needs to in-

Tsirtsis & Srisuresh                                           [Page 11]
^L
Internet Draft    Network Address + Protocol Translator    November 1998

      clude this IPv6 address in the calculation.

      In addition all ICMP packets needs to have the Type  value  trans-
      lated  and  for  ICMP  error  messages the included IP header also
      needs translation.

      The actions needed to translate various ICMPv4 messages are:

      ICMPv4 query messages:
         Echo and Echo Reply (Type 8 and Type 0)
               Adjust the type to 128 and 129, respectively, and  adjust
               the  ICMP checksum both take the type change into account
               and to include the ICMPv6 pseudo-header.

         Information Request/Reply (Type 15 and Type 16)
               Obsoleted in ICMPv4.  Silently drop.

         Timestamp and Timestamp Reply (Type 13 and Type 14)
               Obsoleted in ICMPv6.  Silently drop.

         Address Mask Request/Reply (Type 17 and Type 18)
               Obsoleted in ICMPv6.  Silently drop.

         ICMP Router Advertisement (Type 9)
               Single hop message.  Silently drop.

         ICMP Router Solicitation (Type 10)
               Single hop message.  Silently drop.

         Unknown ICMPv4 types
               Silently drop.

      IGMP messages:
         While there are ICMPv6 counterparts for the IGMP  messages  all
         the  "normal"  IGMP messages are single-hop messages and should
         be silently dropped by the  translator.   Other  IGMP  messages
         might  be  used  by  multicast  routing protocols and, since it
         would be a configuration error to try to have  router  adjacen-
         cies  across IPv4/IPv6 translators those packets should also be
         silently dropped.

      ICMPv4 error messages:
         Destination Unreachable (Type 3)
            For all that are not explicitly listed below set the Type to
            1.

            Translate the code field as follows:
               Code 0, 1: Set Code to 0 (no route to destination).

Tsirtsis & Srisuresh                                           [Page 12]
^L
Internet Draft    Network Address + Protocol Translator    November 1998

               Code 2: Translate to an ICMPv6 Parameter Problem (Type 4,
               Code 1) and make the Pointer point to  the  IPv6  Payload
               Type field.

               Code 3: Set Code to 4 (port unreachable).

               Code   4:  Translate  to an ICMPv6 Packet Too Big message
               (Type 2) with code 0.  The MTU field needs  to   be   ad-
               justed  for   the   difference  between the IPv4 and IPv6
               header sizes.  Note that if the IPv4   router   did   not
               set   the   MTU  field i.e. the router does not implement
               [PMTUv4], then the translator  should  use  the   plateau
               values   specified   in   [PMTUv4]  to determine a likely
               path MTU and include that path MTU in the ICMPv6  packet.
               (Use the greatest plateau value that is less than the re-
               turned Total Length field.)

               Code 5: Set Code to 2 (not a neighbor).

               Code 6,7: Set Code to 0 (no route to destination).

               Code 8: Set Code to 0 (no route to destination).

               Code 9, 10: Set Code to 1 (communication with destination
               administratively prohibited)

               Code  11, 12: Set Code to 0 (no route to destination).

         Redirect (Type 5)
            Single hop message.  Silently drop.

         Source Quench (Type 4)
            Obsoleted in ICMPv6.  Silently drop.

         Time Exceeded (Type 11)
            Set the Type field to 3.  The Code field is unchanged.

         Parameter Problem (Type 12)
            Set the Type field to 4.  The Pointer needs to be updated to
            point to the corresponding field in the  translated  include
            IP header.

      There are some differences between the IPv4 and the IPv6 ICMP  er-
      ror message formats as detailed above.  In addition, the ICMP  er-
      ror messages contain the IP header for the packet in  error  which
      needs to be translated just like a normal IP header.  The transla-
      tion will change the length  of  the  datagram  thus  the  Payload

Tsirtsis & Srisuresh                                           [Page 13]
^L
Internet Draft    Network Address + Protocol Translator    November 1998

      Length field in the outer IPv6 header will need to be updated.

      TCP/UDP/ICMP  query  headers  within  the ICMP error messages will
      need to be translated to account for checksum changes. In the case
      of  NAPT-PT,  even the TCP/UDP port numbers and ICMP Query ID will
      need to be translated.

   5.3  Translating IPv6 headers to IPv4 headers

      If there is no IPv6 Fragment header the IPv4 header fields are set
      as follows:

         Version:
               4

         Internet Header Length:
               5 (no IPv4 options)

         Type of Service:
               All zero.

         Total Length:
               Payload  length  value from IPv6 header, plus the size of
               the IPv4 header.

         Identification:
               All zero.

         Flags:
               The  More  Fragments  flag is set  to  zero.   The  Don't
               Fragments flag is set to one.

         Fragment Offset:
               All zero.

         Time to Live:
               Hop  Limit  value copied from IPv6 header, decremented by
               one.

         Protocol:
               Payload Type field copied from IPv6 header.

         Header Checksum:
               Computed once the IPv4 header has been created.

         Source Address:
               The NAT-PT retains a mapping between the IPv6  SA  and an

Tsirtsis & Srisuresh                                           [Page 14]
^L
Internet Draft    Network Address + Protocol Translator    November 1998

               IPv4 address from the pool of IPv4  addresses  available.
               The IPv6 SA is replaced by the  above  IPv4  address.

         Destination Address:
               IPv6   packets   that   are translated have a destination
               address that includes an IPv4 address in  the  lower   32
               bits   of   the  address.  Thus, the low-order 32 bits of
               the IPv6  destination address is copied   to   the   IPv4
               source address.

      If  any  of an IPv6 hop-by-hop options header, destination options
      header, or routing header are present in the IPv6 packet, they are
      ignored i.e., there is no attempt to translate them.  However, the
      Total Length field and the Protocol field would have to be adjust-
      ed to "skip" these extension headers.

      If  the  IPv6  packet contains a Fragment header the header fields
      are set as above with the following exceptions:

         Total Length:
               Payload length value from IPv6 header, minus  8  for  the
               Fragment header, plus the size of the IPv4 header.

         Identification:
               Copied  from  the low-order 16-bits in the Identification
               field in the Fragment header.

         Flags:
               The More Fragments flag is copied from the  M   flag   in
               the  Fragment header.  The Don't Fragments flag is set to
               zero allowing this  packet  to  be  fragmented  by   IPv4
               routers.

         Fragment Offset:
               Copied   from  the  Fragment Offset field in the Fragment
               Header.

         Protocol:
               Next Header value copied from Fragment heade

   5.4  Translating ICMPv6 headers to ICMPv4 headers

      All ICMP messages that are to be translated require that the  ICMP
      checksum field be updated as part of the translation since ICMPv6,
      unlike ICMPv4, has a pseudo-header checksum just like UDP and TCP.

      The  NAT-PT  retains a mapping between the IPv6 SA and an IPv4 ad-
      dress from the pool of IPv4 addresses. The checksum  update  needs

Tsirtsis & Srisuresh                                           [Page 15]
^L
Internet Draft    Network Address + Protocol Translator    November 1998

      to include this IPv4 address in the calculation.

      In  addition  all ICMP packets needs to have the Type value trans-
      lated and for ICMP error messages  the  included  IP  header  also
      needs translation.

      The actions needed to translate various ICMPv6 messages are:

      ICMPv6 informational messages:
         Echo Request and Echo Reply (Type 128 and 129)
               Adjust   the   type  to 0 and 8, respectively, and adjust
               the ICMP checksum both take the type  change   into   ac-
               count and to exclude the ICMPv6 pseudo-header.

         Group Membership Query/Report/Reduction (Type 130, 131, 132)
               Single hop message.  Silently drop.

         Neighbor Discover messages (Type 133 through 137)
               Single hop message.  Silently drop.

         Unknown informational messages
               Silently drop.

      ICMPv6 error messages:
         Destination Unreachable (Type 1)
         Set  the  Type  field to 3.  Translate the code field  as  fol-
         lows:
               Code 0: Set Code to 1 (host unreachable).
               Code 1: Set Code to 10  (communication  with  destination
               host administratively prohibited).
               Code 2: Set Code to 5 (source route failed).
               Code 3: Set Code to 1 (host unreachable).
               Code 4: Set Code to 3 (port unreachable).

         Packet Too Big (Type 2)
               Translate  to  an  ICMPv4  Destination  Unreachable  with
               code  4.  The  MTU  field needs to be  adjusted  for  the
               difference  between the IPv4 and IPv6 header sizes taking
               into  account  whether or not the  packet  in  error  in-
               cludes a Fragment header.

         Time Exceeded (Type 3)
               Set the Type to 11.  The Code field is unchanged.

         Parameter Problem (Type 4)
               If  the  Code  is 1 translate this to an ICMPv4  protocol
               unreachable  (Type 3, Code 2).  Otherwise set the Type to
               12  and  the Code to zero.  The Pointer needs  to  be up-

Tsirtsis & Srisuresh                                           [Page 16]
^L
Internet Draft    Network Address + Protocol Translator    November 1998

               dated  to  point  to   the  corresponding  field  in  the
               translated include IP header.

         Unknown error messages
               Silently drop.

      There are some differences between the IPv4 and the IPv6 ICMP  er-
      ror message formats as detailed above.  In addition, the ICMP  er-
      ror messages contain the IP header for the packet in  error  which
      needs  to be translated just like a normal IP header. The transla-
      tion will change the length  of  the  datagram  thus  the  Payload
      Length field in the outer IPv6 header might need to be updated.

      TCP/UDP/ICMP  query  headers  within  the ICMP error messages will
      need to be translated to account for checksum changes. In the case
      of  NAPT-PT,  even the TCP/UDP port numbers and ICMP Query ID will
      need to be translated.

   5.5  TCP/UDP Checksum Update

      The NAT-PT retains a mapping between an IPv6 address and  an  IPv4
      address  from the pool of IPv4 addresses available. The above map-
      ping is used in the translation process of every packet that  goes
      through the NAT-PT.

      TCP/UDP  checksum  SHOULD  be  recalculated according to  the  ad-
      dress  change:  Source Address for v6 to v4 translation;  Destina-
      tion  Address for v4 to v6 translation

      The incremental checksum adjustment algorithm may be borrowed from
      [NAT] draft.

      In  the  case of NAPT-PT, TCP/UDP checksum should be  recalculated
      on the  outbound to account for V6 source address and  V6  TCP/UDP
      port  changes.  Likewise, TCP/UDP checksum on the inbound  packets
      should be recalculated to account for destination v4  address  and
      destination TCP/UDP port changes.

   5.6 FTP Control session payload

      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

Tsirtsis & Srisuresh                                           [Page 17]
^L
Internet Draft    Network Address + Protocol Translator    November 1998

      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 NAT-PT should substitute this with the  NAT-
      PT assigned V4 address. In case of NAPT-PT, even the TCP port fol-
      lowing the IP address should be translated.  The  reverse  (trans-
      lation from  v4  address  to  V6 address) is true in  the  inbound
      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 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-
      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.

Tsirtsis & Srisuresh                                           [Page 18]
^L
Internet Draft    Network Address + Protocol Translator    November 1998

      Note that the same limitation does  not  apply  to  IPv6  routing,
      since  IPv4 routing cn be recognised from its form PREFIX::x.y.z.w
      (PREFIX::/96) and be treated differently.

   6.2 Protocol Translation Limitations

      A  number of IPv4 fields have changed meaning in IPv6 and transla-
      tion is not straightforward. For example the TOS field in IPv4 be-
      came meaningful mapping may be possible. As another  example,  the
      option  headers semantics and syntax have changed significantly in
      IPv6, some meaningful translation may also be possible in the  fu-
      ture 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 and transport layer security is
      not possible.  Also application layer security may not be possible
      for  applications   that   carry  IP  addresses to the application
      layer.  This is an inherent limitation from the  Network   Address
      Translation function.

   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  accessable  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

Tsirtsis & Srisuresh                                           [Page 19]
^L
Internet Draft    Network Address + Protocol Translator    November 1998

      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 by default 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 droped. This makes NAT-PT a use-
   ful 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 as described in 4.2.1 provides two way
   connectivity between the IPv6 stub domain and the IPv4 world allowing
   sessions to be initialised by IPv4 nodes outside the  IPv6  stub  do-
   main.   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.

9. REFERENCES

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

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

[PMTUv4]  J. Mogul, S. Deering, "Path MTU Discovery", RFC 1191, November
1990

Tsirtsis & Srisuresh                                           [Page 20]
^L
Internet Draft    Network Address + Protocol Translator    November 1998

[SIIT] E. Nordmark,    "Stateless    IP/ICMP     Translator     (SIIT)",
<draft-ietf-ngtrans-siit-02.txt>, Work in progress, November 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 Laboratoties
IPSWICH IP5 3RE
England
Phone: +44 1473 640756
Fax:   +44 1473 640709
e-mail: [email-masked]

Pyda Srisuresh
Lucent Technologies
4464 Willow Road
Pleasanton, CA 94588-8519
U.S.A.
Voice: (925) 737-2153
Fax:   (925) 737-2110
EMail: [email-masked]

Tsirtsis & Srisuresh                                           [Page 21]
^L
Internet Draft    Network Address + Protocol Translator    November 1998

---

From: Peter Dawson <[email-masked]>
Date: Tue, 10 Nov 1998 23:49:02 +0400

Sorry for this dumb question, but out of academic interests,
how does NAT_PT map IPv4 = > IPv6 and IPv6 = > IPv4
Multicast traffic  ??

/Pete

---

From: George Tsirtsis <[email-masked]>
Date: Wed, 11 Nov 1998 09:34:41 +0000 (GMT)

> how does NAT_PT map IPv4 = > IPv6 and IPv6 = > IPv4

I do not think this is a dumb question at all.
The NAT-PT spec does NOT deal with multicast traffic at this stage in any
partiqular way. I think we tried to get the basic unicast interoperability
done and in the future we might have something more to say about
multicast as well as about a number of other things that are not covered
by NAT-PT at this stage (e.g: option headers).

Also remember that this is to become an experimental RFC in order to gain
further implementation experience. As a result of that we might revisit
the document to add multicast and possibly other extensions.

Thanks

George
-----------------------------
Internet Transport Research |
BTLABS                      |
--------------------------------------------------------------------------
Notice: This contribution is the personal view of the author and does not
necessarily reflect the technical nor commercial direction of British
Telecommunications plc.
--------------------------------------------------------------------------

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 11 Nov 1998 17:08:09 +0000

Hi,

There is a specific problem with the header translation in
this draft - it does not specify the copying of the
Traffic Class octet in both directions (which is trivial,
and is correctly described in SIIT). It actually specifies
zeroing the TOS octet in IPv4, which breaks differentiated
services for no good reason. The statement about the TOS octet
in section 6.2 is now wrong, since the IESG approved the base
diff serv drafts last week.

Generally, it seems to me that rather than replicating material
from SIIT, it would be better to cite SIIT as is and only mention
any differences. This would avoid needless problems such as the
above, and probably simplify life for implementors.

Also, the warnings in 6.3 to 6.5 surely can be brought up to date,
with references to both the NAT WG and IAB drafts on architectural
issues. Address length doesn't have much impact on those issues.

  Brian Carpenter

---

From: George Tsirtsis <[email-masked]>
Date: Fri, 13 Nov 1998 10:02:44 +0000 (GMT)

> diff serv drafts last week.

OK, I can fix this thanks.

> above, and probably simplify life for implementors.

Brian,

The initial NAT-PTv00 draft  was just refering
to SIIT for the Protocol Translation part. At some point we realised that
this was not accurate and some changes to SIIT were required due to the
Address Translation in NAT-PT. When we attempted to just supply the
differences/changes from SIIT, it proved more difficult than it first
sounds. The reason is that slight changes are required in a number of
sections in SIIT and trying to give just the difference was resulting in a
document that did not make any sense by itself. As soon as we tried to add
words in order to make the document stand by itself it also became
apparent that we would be better off having the full document included
anyway.

I understand, however, that unecessary differences between NAT-PT and SIIT
may come up due to that fact, but I do not see this as a big problem.
Remember that there is no interoperability issue here and the documents
are for information only as are the NAT documents. So, the fact that
NAT-PT and SIIT may not do identical Protocol Translation is not going to
bring down any systems. Being very close, however, is clearly desirable.

Finnally, just by including only the differences we are not going to solve
the depedency problem because in a next version of SIIT, Erik might add
something (e.g: support for one of the option headers)  that in order to
work with NAT-PT may  required adjustments due to address
translation. So, we will have to update NAT-PT if we want the change to
also apply.

OK, this is my excuse anyway :)
Seriously, if the WG, the IESG and the implementors on this 
list feel that Brian's  suggestion will make the document better I will
make the necessary changes. 

Could we get the opinion of one of the implementors? Jim, Erik, Pedro,
what do you think? 

Regards

George