One document matched: draft-ietf-ngtrans-natpt-00.txt

INTERNET-DRAFT                                 George Tsirtsis, BTLABS
                                               December 1997


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


Status of this Memo

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

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

   Please check the I-D abstract  listing  contained  in  each  Internet
   Draft  directory  to  learn  the  current status of this or any other
   Internet Draft.


Abstract

   This document specifies a transition mechanism in addition  to  those
   already  specified  in  RFC  1933.   The new mechanism can be used to
   allow IPv6-only hosts  to  communicate  with  IPv4-only  hosts  using
   Network  Address  Translation,  for efficient use of the IPv4 address
   space, and Protocol  Translation,  in  order  to  avoid  implementing
   dual-stack  in  every  machine  that  migrates to IPv6. This proposal
   attempts to reuse as much functionality  as  possible  from  existing
   proposals like [NAT], [NNAT] and [SIIT].


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

   Up to now the proposed solution was the dual  stack  machines.  These
   are  machines that have both an IPv4 and an IPv6 stack, which enables
   them to communicate with machines from both worlds. This approach has
   a number of problems like the fact that dual stack IPv6 machines need
   to be assigned global IPv4  addresses,  which  counteracts  the  main
   reason  to  move to IPv6 in the first place (lack of address space in
   IPv4).  The NNAT proposal deals with this  problem  in  [NNAT].  Dual
   stack  solutions,  however, have the added disadvantage of having two
   systems in the same machine, although hybrid stacks go  some  way  to
   overcome  the complexity. Some maintain that the additional burden of
   maintaining  two  stacks   is   negligible,   mainly   due   to   the
   simplification  of  the  IPv6 maintenance through auto-configuration,
   automatic renumbering etc.  In  some  cases,  however,  it  could  be
   unreasonable  to  mandate  the  existence  of both IPv4 and IPv6 in a
   network, in order to maintain interoperability with IPv4.

   The SIIT proposal [SIIT] describes a protocol  translation  mechanism
   that  allows  communication between IPv6-only and IPv4-only machines.
   This proposal describes in detail the  translation  of  IP  and  ICMP
   headers  from  IPv4  to  IPv6  and  vice versa. The way the IPv6 host
   acquires its IPv4 address, as  well  as,  the  way  that  IPv4  hosts
   initiate connections with IPv6 hosts is not included in SIIT.

   The NAT-PT proposal, described in this document, can be viewed as the
   stateful instance of the SIIT proposal, combined with Network Address
   Translation (NAT). NAT-PT reuses the packet translation mechanism  as
   described  in  [SIIT],  the NAT idea as described in [NAT] and the RT
   DNS record idea described in [NNAT].

   Protocol Translation as described in [SIIT] is stateless. This  means
   that  each  packet  is translated individually and independently from
   all the  others.  In  NAT-PT,  all  packets  of  a  session  MUST  be
   translated  with  the  same address mapping.  Mechanisms to recognise
   the start and end of a session are described in [LSNAT].

   Apart from the address mapping, the rest of the  translation  can  be
   either  stateless,  exactly  like  in [SIIT], or stateful (by caching
   translation information per session).   For  the  remainder  of  this
   document we assume stateful translation in the NAT-PT.

   Since NAT-PT performs address translation,  applications  that  carry
   the IP address in the higher layers (like FTP) will not work. In this
   case Application Layer Gateways (ALG)  MAY  be  required  to  provide
   services   to   that  kind  of  applications.   Some  kind  of  local
   intelligence and state could also be used for the translation of more
   complicated  functions,  ranging  from  QoS mapping to translation of
   option headers. The definition of this add-on functionality is out of
   the scope of this document.


2. Terminology


   2.1 NAT-PT Terminology

      Session initiation packet
         This is  the  first  packet  of  a  session  (TCP/UDP)  and  is
         recognised as described in [LSNAT].

      Network Address Translation (NAT)
         NAT in this document is very similar, but not  the  same,  with
         IPv4  NAT  as  described  in  [NAT].  IPv4  NAT translates IPv4
         addresses (e.g: private to global). Here by  NAT  we  mean  the
         translation  of  an  IPv4  address  to  an  IPv6 address or the
         translation of an IP v6 address to the IPv4 address.

      Protocol Translation (PT)
         PT in this document means the  translation  of  an  IPv4/ICMPv4
         header  to  an  IPv6/ICMPv6  header  or  the  translation of an
         IPv6/ICMPv6 header  to  an  IPv4/ICMPv4  header.  The  detailed
         translation process is described in [SIIT].


   2.2 Specification Language

      The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL  NOT,  SHOULD,
      SHOULD  NOT,  RECOMMENDED,  MAY, and OPTIONAL, when they appear in
      this   document, are to be interpreted as described in [KEYWORDS].


3. Operation

   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 Outgoing Communication  (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.0

      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 = 0::132.146.243.30

      The packet is routed (by static routes)  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
      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.

      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  transla  tion  will  be  as  follows.   SA=0::132.146.243.30,
      DA=FEDC:BA98::7654:3210.   Note that this packet can now be routed
      inside the IPv6-only network as normal.


   3.2 Incoming Communication

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

      Figure 2: IPv4 to IPv6 communication

      Incoming communication is a bit more complicated  because  of  the
      address  translation.  If Host C wants to communicate with Host A,
      Host C can not send a packet to Host A because Host C can not  use
      an IPv6 address and Host A does not have an IPv4 address.

      Host A, however, has a DNS name, which has the same format in IPv4
      and  IPv6. Host C make a name lookup through its local DNS server.
      The DNS server does not have a record of IPv4 address attached  to
      this  name  so  it  forwards  the  request to a parent server. The
      request at some point reaches the Primary DNS server of  the  IPv6
      site, which redirects the request to the NAT-PT (e.g: using the RT
      record as described in [NNAT]). The NAT-PT returns  a  valid  IPv4
      address  (e.g:  from  its pool of addresses) to the DNS server and
      eventually the reply returns to Host C, while  NAT-PT  caches  the
      address  mapping  for a fixed amount of time (Discussion! How much
      time?)

      Host C now can initiate a connection to Host A with an IPv4 packet
      which  includes  the  following  addresses  SA=132.146.243.30  and
      DA=120.130.26.10. On receiving the packet, the NAT-PT,  recognises
      the session and translates the packets and its addresses as normal
      to SA=0::132.146.243.30 and DA= FEDC:BA98::7654:3210.


4. Security Considerations

   All security considerations associated with  NAT  routers,  described
   in  [NAT]  as  well  as  those  described  in  [SIIT]  and [NNAT] are
   applicable to NAT-PT


REFERENCES

[KEYWORDS]  S.  Bradner,  "Key  words  for  use  in  RFCs  to   Indicate
Requirement Levels", RFC 2119, March 1997.

[LSNAT] P. Srisuresh, et.al., Load  Share  Network  Address  Translator,
ftp://ietf.org/internet-drafts/draft-srisuresh-lsnat-00.tx,     November
1997

[NAT] P. Srisuresh, et.al., The IP  Network  Address  Translator  (NAT),
ftp://ietf.org/internet-drafts/draft-rfced-info-srisuresh-03.txt,
September 1997

[NNAT] Jim  Bound,  No  Network  Address  Translation  (NNAT)  for  IPv6
,ftp://ietf.org/internet-drafts/draft-ietf-ngtrans-nnat-00.txt, November
1997

[SIIT]   Erik   Nordmark,   Stateless   IP/ICMP    Translator    (SIIT),
ftp://ietf.org/internet-drafts/draft-ietf-ngtrans-header-trans-01.txt
November 20, 1997


ACKNOWLEDGMENTS

   Many thanks to my colleagues Alan O'Neill  and  Martin  Tatham  whose
   help and support made this possible.


AUTHOR

George Tsirtsis
Internet Transport Group
B29 Room 129
BT Laboratoties
Martlesham Heath
IPSWICH
Suffolk IP5 3RE
England

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


DISCLAIMER

Notice: This contribution has been prepared to  assist  the  IETF  as  a
basis   for  discussion.  It  is  not  a  binding  proposal  on  British
telecommunications plc;  specifically,  British  Telecommunications  plc
reserves  the  right  to modify, delete and amend any statements contain
herein.