INTERNET-DRAFT George Tsirtsis NGTRANS WG BT Laboratories Expires June, 1999 Pyda Srishuresh Category: EXPERIMENTAL Lucent Technologies January 1999 Network Address Translation - Protocol Translation (NAT-PT) 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-TERM] and V6/V4 protocol transla- tion theme as described in [SIIT]. 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. Tsirtsis & Srisuresh [Page 1] Internet Draft Network Address + Protocol Translator January 1999 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 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. Tsirtsis & Srisuresh [Page 2] Internet Draft Network Address + Protocol Translator January 1999 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. 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. 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- Tsirtsis & Srisuresh [Page 3] Internet Draft Network Address + Protocol Translator January 1999 so supported as the ICMP header carries a query identifier that is used to corelate 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 conjucntion 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- 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 Tsirtsis & Srisuresh [Page 4] Internet Draft Network Address + Protocol Translator January 1999 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 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. Tsirtsis & Srisuresh [Page 5] Internet Draft Network Address + Protocol Translator January 1999 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. 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 Tsirtsis & Srisuresh [Page 6] Internet Draft Network Address + Protocol Translator January 1999 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 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- Tsirtsis & Srisuresh [Page 7] Internet Draft Network Address + Protocol Translator January 1999 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 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. Tsirtsis & Srisuresh [Page 8] Internet Draft Network Address + Protocol Translator January 1999 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 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. Tsirtsis & Srisuresh [Page 9] Internet Draft Network Address + Protocol Translator January 1999 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 seperate 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 performes 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: 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 Tsirtsis & Srisuresh [Page 10] Internet Draft Network Address + Protocol Translator January 1999 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]. In the case of NAPT-PT, TCP/UDP checksum should be recalculated on the outbound (V6 to V4) to account for V6 source address and V6 TCP/UDP port changes. Likewise, TCP/UDP checksum on the in- bound packets (V4 to V6) should be recalculated to account for destination V4 address and destination TCP/UDP port changes. Also note that ICMPv6, unlike ICMPv4, has a pseudo-header checksum just like UDP and TCP. When the ICMPv6 header is computed for V4 to V6 translation [SIIT], the checksum calculation needs to take into account the address changes due to the address translation function of NAT-PT. The necessary changes to source and destina- tion addresses as well as IPv4 checksum is also required for the packet headers carried inside the ICMP packets. 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 Tsirtsis & Srisuresh [Page 11] Internet Draft Network Address + Protocol Translator January 1999 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- 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 Tsirtsis & Srisuresh [Page 12] Internet Draft Network Address + Protocol Translator January 1999 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 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 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 DNS servers and end-host resolvers, the scheme suggested in this document will not work. 7. Applicability Statement Tsirtsis & Srisuresh [Page 13] Internet Draft Network Address + Protocol Translator January 1999 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 droped. This makes NAT-PT a useful tool to IPv6 only stub networks that need to be able to maintain connectivity with the IPv4 world without the need to deploy servers visible to the IPv4 world. NAT-PT combined with a DNS-ALG provides bi-directional connectivity between the IPv6 stub domain and the IPv4 world allowing sessions to be initialised by IPv4 nodes outside the IPv6 stub domain. This makes NAT-PT useful for IPv6 only stub networks that need to deploy servers visible to the IPv4 world. 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 Exten- sions", 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" Tsirtsis & Srisuresh [Page 14] Internet Draft Network Address + Protocol Translator January 1999 [SIIT] E. Nordmark, "Stateless IP/ICMP Translator (SIIT)", , 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 Laboratoties IPSWICH IP5 3RE England Phone: +44 1473 640756 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 15] Internet Draft Network Address + Protocol Translator January 1999