Network Working Group I. van Beijnum Internet-Draft IMDEA Networks Expires: May 22, 2008 November 19, 2007 Modified Network Address Translation - Protocol Translation draft-van-beijnum-modified-nat-pt-02 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 22, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract A smooth transition from IPv4 to IPv6 requires that either all hosts are upgraded to dual stack before the first hosts can become IPv6- only, or that there be some mechanism for IPv6-only hosts to talk to IPv4-only hosts. Expecting the former within a reasonable timeframe isn't realistic, based on current adoption of dual stack combined with the latest projections for the IPv4 depletion that point to a date early in the next decade. And the IETF has recently deprecated the main mechanism that allows the latter: NAT-PT. van Beijnum Expires May 22, 2008 [Page 1] Internet-Draft Modified NAT-PT November 2007 This document proposes modifications to NAT-PT that address the reasons why the mechanism was deprecated. This should allow future deployment of the modified NAT-PT as an IPv4-to-IPv6 transition mechanism, giving operators the option of running their networks largely IPv6-only. 1. Introduction The original NAT-PT mechanism outlined in [RFC2766] couples three underlying techniques to arrive at a comprehensive solution that allows IPv6-only hosts to initiate connections or associations towards IPv4-only hosts: 1. Stateless IP and ICMP Translation [RFC2765] 2. Network Address / Port Translation 3. A DNS Application Layer Gateway [RFC2694] Basically, when an IPv6 host wants to connect to a service, it looks up the associated host/service name in the DNS. If no AAAA records are available for the name in question, the DNS ALG synthesizes an AAAA record based on the A record for the host/service and a prefix that's routed to a translation device. The IPv6 host initiates communication towards the resulting IPv6 address. The associated packets end up at the translator, which recovers the original IPv4 destination address, translates between IPv6 and IPv4, performs IPv4 NAT and sends the resulting packet to the IPv4 destination. Return packets are translated back and sent to the IPv6 host. [RFC4966] explains why this is problematic. The main objections boil down to hosts being exposed to an unexpected environment, issues with referrals in the absence of relevant Application Layer Gateways, generation of synthetic DNS responses that may be harmful if not properly contained and constraints on network topology. This document proposes to make the IPv6-side is aware of the translation in order to avoid the majority of the problems associated with the original NAT-PT. Additionally, it specifies a way for IPv4 hosts in sites that only have IPv6 to have access to the IPv4 internet. Although this document goes into some detail, it's intended as a discussion document; as such, not every aspect is completely worked out. In some circles, a distinction is made between Network Address van Beijnum Expires May 22, 2008 [Page 2] Internet-Draft Modified NAT-PT November 2007 Translation (NAT) which only translates just addresses, and Network Address/Port Translation (NAPT) which translates both addresses and TCP/UDP port numbers. No such distinction is made here; "NAT" is used to refer to both types of translation. 2. IPv6-to-IPv4 There are two modifications to existing NAT-PT possible to allow for IPv6-only hosts to connect to IPv4-only hosts. The only one mandated by this document is the use of A records. 3. Use of A records In the original NAT-PT design a DNS ALG would create synthetic AAAA DNS records for FQDNs that only have A records. This behavior is no longer supported; IPv6 hosts that want to communicate with IPv4 hosts must now look up the A records themselves and create a synthetic IPv6 destination address from the IPv4 address bits and a /96 prefix that is routed to the translator. The /96 prefix and hence the translation device used may be configured administratively, but an anycasted default prefix (TBD) is made available so that IPv6 hosts can use a topologically close translation device without configuration. Discussion: do we want to reuse the IPv4-mapped IPv6 address range for this? On the surface, that would seem to make sense. However, it has been long standing policy that IPv4-mapped IPv6 addresses do no appear on the wire. 3.1. Use of a synthetic IPv4 source address Optionally, IPv6-only hosts may support IPv4 (and IPv4-mapped IPv6) socket calls for compatibility with applications that don't support native IPv6 communication and/or need to be aware of the fact that communication is happening over IPv4 and is subject to NAT. A natural way to indicate this is through the use of an IPv4 source address from [RFC1918] space. An IPv6-only host implementing IPv4 compatible socket calls picks one of its global scope IPv6 addresses as the source address for MNAT-PT. It then generates a local IPv4 address in the prefix 172.31.0.0/16, where the lower 16 bits are chosen such that a TCP or UDP checksum computed over the IPv6 addresses that appear on the wire are the same as those resulting from the synthetic IPv4 source address and the IPv4 destination address. van Beijnum Expires May 22, 2008 [Page 3] Internet-Draft Modified NAT-PT November 2007 This means that the value of the lower 16 bits in the synthetic IPv4 address are generated through the one's complement addition of the 16-bit words that make up the 96 bit prefix used for IPv4 destinations reachable through the translator and the selected IPv6 source address. Then, a one's complement subtraction of the value 44063 (decimal) is performed to adjust for the 172.31.0.0/16 prefix. The result of this is that TCP and UDP checksums computed over both the IPv4 and MNAT-PT IPv6 representations of packets destined for the translator are the same. UDP packets MUST have a valid checksum. Although adjusting checksums during translation steps is relatively easy, knowing that IPv4 and IPv6 versions of the checksum are identical may allow for a more flexible implementation, where it's not necessary to keep track of whether a packet was or will be translated when a checksum is computed. The resulting synthetic IPv4 address is internally used as the source address in all IPv4 processing. 3.2. Operation Packets towards to-be-translated IPv4 destinations are transmitted over the network as usual. The translation device performs SIIT translation and IPv4 NAT. The possible artificial IPv4 source address is ignored during these steps, since it is not required by either step except as a means to keep track of which sessions on the public IPv4 side map to which sessions on the "internal" side. However, since different hosts served by the same translation device may have selected the same artificial IPv4 address, (de)multiplexing based on this value won't work well. So the SIIT and NAT functions must be integrated such that the NAT associates sessions on the public IPv4 side directly with the IPv6 side without a private IPv4 intermediate. 4. IPv4-to-IPv6 operation In order for IPv6-only hosts to receive incoming TCP sessions and UDP packets that aren't replies to UDP packets sent earlier, TCP and UDP packets towards a certain address / port combination translated to a corresponding IPv6 address in MNAT-PT translators. State is kept to be able to translate return packets from IPv6 to IPv4. Holders of IPv4 address space (including [RFC1918] address space) may set up translation mappings administratively for IPv4 addresses under their control. In addition, one or more blocks of IPv4 address space are set aside to make IPv6-only hosts reachable for IPv4-only hosts. These address blocks are translated by all MNAT-PT translators in an anycast-like fashion. van Beijnum Expires May 22, 2008 [Page 4] Internet-Draft Modified NAT-PT November 2007 MNAT-PT translators MUST encode the IPv4 source address in the lower 32 bits of the IPv6 source address in translated packets. This means that translators must have a /96 range of IPv6 addresses available to perform this type of translation. Encoding of the IPv4 source address in the IPv6 source address allows conformant applications or operating systems to recover the original IPv4 source address of the correspondent. However, this only works if the incoming packets are indeed translated IPv4 packets. If this functionality is desired, administrators must take care to keep incoming translated IPv4 sessions and normal IPv6 sessions apart by making these arrive at different addresses. Note that for this type of translation, there is no requirement that checksums calculated over the IPv4 and IPv6 pseudo headers are the same: translators must adjust checksums. 4.1. DNS As it's impractical to configure all MNAT-PT translators globally with the full set of translation mappings, the mappings are stored in the DNS in the following format: a7.a6.a5.a3.p3.p2.p1.p0.a2.a1.a1.a0.ip4ip6.arpa. a0 - a7 are bits 0 - 3 ... 28 - 31 from the IPv4 address, respectively. p0 - p3 are bits 0 - 3 ... 12 - 15 from the port number, respectively. The groups of four bits are represented by a hexadecimal digit. So a packet to 192.0.2.171 port 993 would map to: b.a.2.0.1.e.3.0.0.0.0.c.ip4ip6.arpa. Each individual name within this domain uses a PTR record to point to a name elsewhere in the domain tree, which in turn hold one or more SRV records. The holder of an address / port combination can publish a port number and name (presumably mapping to one or more AAAA records) where the service is located at any given point in time. The translator caches at least one packet while it performs the necessary DNS lookups to create a translation mapping. It is unavoidable that packets may be lost or delayed while DNS lookups are performed. 4.2. IPv4 address space for IPv6 services A /8 block of IPv4 address space, combined with the 16 bits from the port number, would allow for 2^40 IPv6-only services to be available from the IPv4-only internet. Presumably, this would be enough to accommodate a smooth transition from IPv4 to IPv6. (Additional blocks could be made available later; implementors of MNAT-PT van Beijnum Expires May 22, 2008 [Page 5] Internet-Draft Modified NAT-PT November 2007 translators MUST make it possible to add additional IPv4 blocks to the list of IPv4-to-IPv6 translation addresses.) A /8 block of IPv4 address space could be taken from unused unicast space. However, it may be possible to reuse a part of the IPv4 address space that isn't currently usable. Since any hosts are unable to send packets to class E address space, that wouldn't be a suitable choice, but possibly parts of the 0.0.0.0/8 or 127.0.0.0/8 blocks could be used for this. It may even be possible to reuse the addresses ending in all-zeroes or all-ones from class C address space, which are generally presumed to be unusable. Further investigation is warranted. 5. IPv4-IPv6-IPv4 operation It would be optimistic to expect that all hosts implement IPv6 and the mechanisms outlined above within a limited timeframe. As such, it is useful to support both hosts that don't implement the changes set forth in this document, and even hosts that don't implement IPv6 at all. In these cases, a gateway device may be employed that manages a block of private IPv4 address space using DHCP and translates these to IPv6 addresses. The local device performs SIIT between the resulting IPv4 and IPv6 address pairs but not IPv4 NAT. Since the remote translator that translates from IPv6 to public IPv4 requires a unique IPv6 address in order to demultiplex, the local gateway MUST use a dedicated IPv6 address for each local IPv4 address. Any [RFC1918] address may be used locally as long as the requirements are met that only a single local IPv4 address maps to an IPv6 address, and that the addresses are equivalent for the purposes of computing checksums. A way to conform to these requirements is to construct the IPv6 address from the IPv4 address as follows: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 64-bit subnet prefix |F0|ID|CHKSM| IPv4 addr | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ Bit 70 in the address MUST be set to 0 to indicate a non globally unique address. The ID bits can contain a value that allows different gateways to live on the same subnet. In the absence of any administrative settings or the detection of duplicate addresses, this could be the lower 8 bits of the gateway's MAC address. The CHKSM bits are chosen such that they compensate for the differences in the checksum generated over the IPv4 pseudo-header and the checksum generated over the IPv6 pseudo-header. This means that this value is the one's complement of the one's complement addition of the 16-bit words from the top 96 bits of the address of remote modified NAT-PT van Beijnum Expires May 22, 2008 [Page 6] Internet-Draft Modified NAT-PT November 2007 translator and all the 16-bit words from the top 80 bits of IPv6 address that is being constructed. The local gateway SHOULD also perform IPv6 routing or otherwise allow IPv6 connectivity so that hosts that do support IPv6, but not MNAT-PT, have the ability to communicate directly over IPv6 in addition to being able to use translated IPv4 connectivity. There are two open issues: how do IPv4 hosts using different local gateways but the same modified NAT-PT translator communicate, and how do NAT traversal protocols such as uPnP, NAT-PMP and others work. 6. Control connection If a non-anycast address range is used to IPv6-to-IPv4 translation, it's likely that users of the translator in question may be authorized to use the translator, but this fact isn't obvious from the source addresses used by the IPv6 host in question. A lightweight way to authenticate an IPv6 host to a translator would be for the host to set up a TLS-protected TCP session towards an address held by the translator, and exchange credentials over this connection. Afterwards, the session could be kept alive and be used as a generic control connection, for the purposes of detecting loss of state in the translation device and negotiating NAT parameters. It should be possible to reuse an existing IETF protocol for this purpose. Discussion: do we want to perform generic NAT traversal functions though the control connection, or do we want to use existing uPnP and NAT-PMP protocols for this? There are security issues with these protocols, but they are widely used in home networks. The use of protocols like STUN is also possible, but these aren't widely deployed in home networks. 7. Examples The anycast range for IPv6-to-IPv4 translation is assumed to be 1000::/96 in these examples, and the IPv4 address of the translator is 10.0.0.96. (10.0.0.96 is used as an example public IPv4 address, not as a private address here.) 7.1. IPv6-to-IPv4 IPv6 host pc1.beispiel.de 2001:db8:31::dead:beef wants to communicate with IPv4 host www.example.com, which holds address 192.0.2.58. pc1.beispiel.de doesn't use a synthetic IPv4 source address. van Beijnum Expires May 22, 2008 [Page 7] Internet-Draft Modified NAT-PT November 2007 1. pc1.beispiel.de looks up AAAA records for www.example.com with no results 2. pc1.beispiel.de looks up A records for www.example.com: 192.0.2.58 3. pc1.beispiel.de initiates a TCP session from 2001:db8:31::dead: beef port 1025 to 1000::192.0.2.58 port 80 4. the translator sets up a translation mapping from { [2001:db8: 31::dead:beef]:1025 [1000::192.0.2.58]:80 } to { [10.0.0.96]: 49152 [192.0.2.58]:80 } 5. the translator translates packets back and forth until the session is no longer used and the mapping is garbage collected 7.2. IPv6-to-IPv4 with synthetic IPv4 source address IPv6 host pc2.beispiel.de 2001:db8:31::cafe wants to communicate with IPv4 host www.example.com, which holds address 192.0.2.58. pc2.beispiel.de uses a synthetic IPv4 source address. 1. pc2.beispiel.de does a one's complement addition of the values 1000, 0000, 0000, 0000, 0000, 0000 (the translator anycast address), 2001, 0db8, 0031, 0000, 0000, 0000, 0000, cafe (its source address) which results in 08e9 2. pc2.beispiel.de does a one's complement subtraction of ac1f (172.31) from 08e9 = a336 (163.54) 3. pc2.beispiel.de configures a virtual network interface with IPv4 address 172.31.163.54 4. pc2.beispiel.de looks up AAAA records for www.example.com with no results 5. pc2.beispiel.de looks up A records for www.example.com: 192.0.2.58 6. pc2.beispiel.de initiates a TCP session from 2001:db8:31::cafe port 1025 to 1000::192.0.2.58 port 80 7. the translator sets up a translation mapping from { [2001:db8: 31::cafe]:1025 [1000::192.0.2.58]:80 } to { 10.0.0.96:49153 192.0.2.58:80 } 8. the translator translates packets back and forth until the session is no longer used and the mapping is garbage collected van Beijnum Expires May 22, 2008 [Page 8] Internet-Draft Modified NAT-PT November 2007 7.3. IPv4-to-IPv6-to-IPv4 IPv4 host pc3.beispiel.de wants to communicate over the IPv6 internet with IPv4 host www.example.com, which holds address 192.0.2.58. 1. the local translator gives out IPv4 address 192.168.1.3 to pc3.beispiel.de and sets up a mapping between private IPv4 address 192.168.1.3 and IPv6 address 2001:db8:31:0:f0aa: d16a.192.168.1.3 2. note that in one's complement math the addition of 1000, 0000, 0000, 0000, 0000, 0000, 2001, 0db8, 0031, 0000, f0aa, d16a equals ffff (-0, which is equal to 0) 3. pc3.beispiel.de looks up A records for www.example.com: 192.0.2.58 4. pc3.beispiel.de initiates a TCP session from 192.168.1.3 port 1025 to 192.0.2.58 port 80 5. the local translator translates the packet { 192.168.1.3:1025 192.0.2.58:80 } to { [2001:db8:31:0:f0aa:d16a.192.168.1.3]:80 [1000::192.0.2.58]:80 } 6. the remote MNAT-PT translator sets up a translation mapping from { [2001:db8:31:0:f0aa:d16a.192.168.1.3]:80 [1000::192.0.2.58]:80 } to { 10.0.0.96:49154 192.0.2.58:80 } 7. the remote translator translates packets back and forth until the session is no longer used and the mapping is garbage collected 7.4. IPv4-to-IPv6 IPv4 host mac1.example.com holding address 192.0.2.253 wants to communicate with IPv6 host pc1.beispiel.de. The port number available for this service is 32767. In order to accommodate incoming sessions, pc1.beispiel.de has set up the following entries in the DNS: pc1.beispiel.de. A 0.48.64.80 0.5.0.4.f.f.f.7.0.3.0.0.ip4ip6.arpa. PTR pc1._ftp._tcp.beispiel.de. pc1._ftp._tcp.beispiel.de. SRV 0 0 21 pc1-dynamic.ddns.beispiel.de. pc1-dynamic.ddns.beispiel.de. AAAA 2001:db8:31::dead:beef van Beijnum Expires May 22, 2008 [Page 9] Internet-Draft Modified NAT-PT November 2007 The closest MNAT-PT translator uses prefix 2001:db8:ffff::/96 for translations from IPv4 to IPv6. 1. mac1.example.com wants to connect to pc1.beispiel.de on port 32767 2. mac1.example.com looks up A records for pc1.beispiel.de in the DNS: 0.48.64.80 3. mac1.example.com sets up a TCP session from 192.0.2.253:1025 to 0.48.64.80:32767 4. the packet for 0.48.64.80 is routed towards the nearest MNAT-PT translator 5. the translator transfers 0.48.64.80:32767 into 0.5.0.4.f.f.f.7.0.3.0.0.ip4ip6.arpa 6. the translator looks up PTR records: pc1._ftp._tcp.beispiel.de 7. the translator looks up SRV records: 0 0 21 pc1- dynamic.ddns.beispiel.de 8. the translator looks up AAAA records: 2001:db8:31::dead:beef 9. the translator sets up a mapping from { 192.0.2.253:1025 0.48.64.80:32767 } to { [2001:db8:ffff::192.0.2.253]:1025 [2001: db8:31::dead:beef]:21 } 10. the translator translates packets back and forth until the session is no longer used and the mapping is garbage collected 8. Advantages and disadvantages 8.1. Disadvantages The disadvantage of this mechanism is that for IPv6-to-IPv4 operation, it's required that the IPv6 host supports at least the use of A records and set up IPv6 connections to a translator. As such, deployment is non-trivial. Incoming sessions for IPv6 hosts can happen without necessarily requiring changes to the TCP/IP stack or applications, but in that case, applications may operate under the assumption that they're talking to IPv6 correspondents, while in fact they are communicating with IPv4 correspondents. This may result in a mismatch in IP protocol version for protocols that embed IP addresses. van Beijnum Expires May 22, 2008 [Page 10] Internet-Draft Modified NAT-PT November 2007 8.2. Advantages There are several advantages. An important one is that NAT issues only come up when the host is communicating towards IPv4 addresses. As such, it's trivial for applications to limit NAT workaround code to sessions towards IPv4 destinations and assume global addressability for IPv6 destinations. Since there is no DNS ALG, there are no issues with possible leakage of synthetic AAAA records. Both IPv4 applications that use IPv4 socket calls and IPv6 applications that use IPv6 socket calls with IPv4-mapped IPv6 addresses can work over MNAT-PT. Alternatively, light-weight implementations may omit all IPv4 code except the ability to resolve A records. 8.3. Advantages over providing real NATed IPv4 connectivity An obvious way to enjoy many of the same benefits would be to build a network that supports both IPv6 and IPv4 with NATed connectivity. However, this means that there must be an IPv4 network infrastructure in place in the form of IPv4 routers and IPv4 address provisioning (DHCP). Today, this is easy to do in smaller installations if there is a single public IPv4 address available. However, in larger networks the planning of private IPv4 addressing can become cumbersome, and when IPv4 addresses are scarce, it may be unavoidable to implement multiple levels of NAT. Multiple levels of NAT at the very least impose the limits of the most restrictive NAT, and also make hole punching that is used to be able to receive incoming connections much harder as a single set of port numbers must be shared by a larger number of hosts. NAT traversal technologies may or may not support multiple layers of NAT. With MNAT-PT, it's only necessary to provision IPv6 connectivity and addressing, which is easier to plan for because unlike IPv4, a standard /64 IPv6 subnet supports arbitrary numbers of hosts. The translation device that performs NAT and the hosts making use of the MNAT-PT service can be located with few topological constraints, so multiple layers of NAT are much easier to avoid. 9. Evaluation of RFC4966 concerns This section provides an overview of the issues raised in [RFC4966] and how they apply to the use of modified NAT-PT with modifications on the IPv6 side. van Beijnum Expires May 22, 2008 [Page 11] Internet-Draft Modified NAT-PT November 2007 9.1. Issues with Lack of Address Persistence To-be-translated IPv4 destination addresses map to the same IPv6 destination address until the host selects a different /96 prefix. However, if addresses are stored in their IPv4 form, this doesn't lead to broken referrals. Issues with mapping persistence from the IPv4 side to the IPv6 side are the same as with regular NAT and can be solved in the same way: by having the application or OS set up a persistent mapping that allows incoming connections. 9.2. DoS Attacks on Memory and Address/Port Pools Denial-of-service issues are mostly the same as with regular NAT. When a non-anycast translator is used, it's likely that authentication through a control connection is required, allowing for easy rejection of to-be-translated traffic coming from addresses that don't have an active control connection. However, unless the IPv6 source host and the translator are prepared to set up an IPsec tunnel, there is no way to reject to-be-translated traffic which spoofs the source address of a host with an active control connection. If the source host uses an IPv6 source address for this communication that it doesn't use for other types of communication, only on-path attackers or hosts on the same subnet have easy knowledge of the source address in question. 9.3. Issues Directly Related to Use of DNS-ALG N/A. 9.4. Impact on IPv6 Application Development Applications see regular IPv4 destination addresses for to-be- translated destinations so they can engage IP version specific code paths as required. The presence of the [RFC1918] synthetic source address makes it possible for applications to use NAT workarounds for to-be-translated destinations. The extra work the application needs to do here is the same as it would when running on a dual stack host. Alternatively, TCP/IP stacks may forego implementing the synthetic IPv4 source address and/or applications may choose to remain ignorant of whether they're communicating with an IPv4 or IPv6 correspondent. In those cases, address-based referrals are likely to break for IPv4 destinations unless the MNAT-PT translator employs an Application Layer Gateway for the protocol that's used. van Beijnum Expires May 22, 2008 [Page 12] Internet-Draft Modified NAT-PT November 2007 10. Acknowledgments This document has benefited from ideas from Marcelo Bagnulo, Brian Carpenter and Alain Durand. Readers are encouraged to also review [I-D.carpenter-shanti], [I-D.durand-v6ops-natv4v6v4] and [I-D.bagnulo-v6ops-6man-nat64-pb-statement]. 11. IANA considerations None at this time. 12. Security considerations Security considerations need to be worked out in a revision of this document. In the past, security issues have been identified with the use of IPv4-mapped IPv6 addresses. If these addresses were to appear on the wire, neither IPv4 nor IPv6 filters would recognize them as packets associated with IPv4 operation, possibly allowing the bypassing of access restrictions. Implementers should take care to avoid having mechanisms that restrict access based on IPv4 addresses without also taking into account various translation mechanisms. 13. References 13.1. Normative References [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [RFC2694] Srisuresh, P., Tsirtsis, G., Akkiraju, P., and A. Heffernan, "DNS extensions to Network Address Translators (DNS_ALG)", RFC 2694, September 1999. [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)", RFC 2765, February 2000. [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, February 2000. van Beijnum Expires May 22, 2008 [Page 13] Internet-Draft Modified NAT-PT November 2007 [RFC4966] Aoun, C. and E. Davies, "Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status", RFC 4966, July 2007. 13.2. Informative References [I-D.carpenter-shanti] Carpenter, B., "Shimmed IPv4/IPv6 Address Network Translation Interface (SHANTI)", draft-carpenter-shanti-01 (work in progress), November 2007. [I-D.durand-v6ops-natv4v6v4] Durand, A., "Non dual-stack IPv6 deployments for broadband providers", draft-durand-v6ops-natv4v6v4-00 (work in progress), November 2007. [I-D.bagnulo-v6ops-6man-nat64-pb-statement] Bagnulo, M., "IPv6 - IPv4 Translators (NAT64) - Problem Statement and Analysis", draft-bagnulo-v6ops-6man-nat64-pb-statement-00 (work in progress), November 2007. Appendix A. Document and discussion information Revision history: o Version 00: initial version o Version 01: added mechanisms that require changes at the IPv4 side o Version 02: added support for incoming sessions from IPv4-only to IPv6-only host and IPv4-IPv6-IPv4 translation; removed mechanisms that require changes at the IPv4 side to avoid confusion The latest version of this document will always be available at http://www.muada.com/drafts/. Please direct questions and comments to the v6ops mailinglist or directly to the author. van Beijnum Expires May 22, 2008 [Page 14] Internet-Draft Modified NAT-PT November 2007 Author's Address Iljitsch van Beijnum IMDEA Networks Av. Universidad 30 Leganes, Madrid 28911 ES Phone: +34-91-6246245 Email: iljitsch@muada.com van Beijnum Expires May 22, 2008 [Page 15] Internet-Draft Modified NAT-PT November 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). van Beijnum Expires May 22, 2008 [Page 16]