Since widespread IPv6-only adoption in some time frame might make it not worthwhile to develop a solution for IPv4, the question of IPv6 transition mechanisms is crucial for the RRG.
NAT-PT is one approach to enabling an IPv6-only host to communicate with the IPv4 Internet. What other approaches are there? If there are none, then IPv6-only hosts are only going to be viable for most end-users in an environment where almost all other hosts have IPv6 addresses. That is an enormous chicken and egg problem, and the current very low adoption rate of IPv6, even for dual-stack, gives me no reason to think there is a substantial chicken to lay a real egg, or such an egg to grow into a chicken. There is just an imaginary chicken and her imaginary egg, which some folks can easily imagine coming to life. I can't imagine this occurring in the next decade, except perhaps for captive customers in certain countries and with cellphones which don't need to run the full set of IPv4 application protocols. A diagrammatic explanation of NAT-PT is here: http://www.lucastomicki.net/naptd.php http://www.lucastomicki.net/naptd.docs.php (My previous message linked to other NAT-PT things.) This Linux NAT-PT has three separate pools of IPv4 addresses for translating three classes of packets: TCP, UDP and ICMP. What about SCTP? RFC 4966 (2007-07) changes the status of the NAT-PT RFC 2766 to "historic". It lists many problems and doesn't recommend an alternative. Are there any reports on practical systems which provide usable Internet services today with IPv6-only addresses, even with some use of IPv4 space to provide limited connectivity to the IPv4 Internet via NAT-PT or some other mechanism? If someone cites Application Level Gateways, please provide specifics and discuss the problems of having such application-specific things in the network itself. Also, there are problems with any such IPv6 to IPv6 ALG or NAT, as mentioned at: http://tools.ietf.org/html/rfc4966#page-5: /---- Issues that are independent of the use of a DNS-ALG and are, therefore, applicable to any form of an IPv6-IPv4 translator: * Disruption of all protocols that embed IP addresses (and/or ports) in packet payloads or apply integrity mechanisms using IP addresses (and ports). * Inability to redirect traffic for protocols that lack demultiplexing capabilities or are not built on top of specific transport-layer protocols in situations where one NAPT-PT is translating for multiple IPv6 hosts. * Requirement for applications to use keepalive mechanisms to workaround connectivity issues caused by premature NAT-PT state timeout. * Loss of information due to incompatible semantics between IPv4 and IPv6 versions of headers and protocols. * Need for additional state and/or packet reconstruction in NAPT-PT translators dealing with packet fragmentation. * Interaction with SCTP and multihoming. * Need for NAT-PT to act as proxy for correspondent node when IPv6 node is mobile, with consequent restrictions on mobility. * NAT-PT not being able to handle multicast traffic. Issues that are exacerbated by the use of a DNS-ALG and are, therefore, also applicable to any form of an IPv6-IPv4 translator: * Constraints on network topology. * Scalability concerns together with introduction of a single point of failure and a security attack nexus. * Lack of address mapping persistence: Some applications require address retention between sessions. The user traffic will be disrupted if a different mapping is used. The use of the DNS- ALG to create address mappings with limited lifetimes means that applications must start using the address shortly after the mapping is created, as well as keep it alive once they start using it. * Creation of a DoS (Denial of Service) threat relating to exhaustion of memory and address/port pool resources on the translator. \---- Is there a test-bed showing how IPv6-only services can be implemented such that ordinary end-users would pay for such a service when they could also choose an ordinary IPv4 service? Without something really substantial or promising, I don't see how the RRG can assume that IPv6-only adoption and consequent migration from IPv4 will happen anything like soon enough that the IPv4 routing scaling problem doesn't need to be solved. I will observe radio silence for at least 24 hours. - Robin -- to unsubscribe send a message to [EMAIL PROTECTED] with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
