Hi Robert, Do you realize that NPTv6 _is_ an ID/LOC split solution? The external addresses are locators, much like the outer header addresses in LISP, and the internal addresses are IDs, much like the inner header addresses in LISP. The tunnel is compressed away through the use of algorithmic, 1:1 translation. NPTv6 has a great advantage over LISP and other tunnel-based ID/LOC solutions in that the packet format of NPTv6 packets remains fully backward compatible with IPv6, allowing for full incremental deployment (one site can deploy it, without losing connectivity to anyone) through seamless backward-compatibility with existing IPv6 implementations.
An NPTv6-aware end-node within an NPTv6 site could "un-do" the translation of internal addresses within its own stack, so that applications on the end-node would actually be using their own external addresses, rather than their internal addresses. If this were widely implemented, it could restore end-to-end transparency, eliminating the need for ALGs and restoring the ability to do third-party referrals by IP address, etc. To enable this translation, the end node would need to be configured with its own external prefix(es), perhaps via DHCPv6 or IPv6 RAs. Of course, IPv4 NAT can also be viewed as an ID/LOC split solution. In fact, the advantages of an ID/LOC split solution (address independence, avoiding renumbering, internal topology hiding, etc.) are the main drivers for the wide-spread deployment of IPv6 NAT in enterprises. In most casts, those enterprises already have sufficient IPv4 "swamp space" to number their internal networks, or would have no difficulty getting sufficient IPv4 addresses from their ISP, so their use of NAT is _not_ motivated by an IPv4 address shortage. The major problems with IPv4 NA(P)T are caused by port mapping/address sharing and state-based (vs. algorithmic) translation, both of which were eliminated in NPTv6. It is possible, though, that these issues could be (at least partially) addressed through the use of PCP (the Port Control Protocol) on an IPv4 NAT-aware end-node. In fact, if we can briefly set aside our distaste for NAT-based solutions, I think we'll realize that NAT-based ID/LOC solutions (such as NPTv6) have several advantages over tunnel-based ID/LOC solutions (such as LISP), particularly in the areas of incremental deployment and backwards compatibility. Unfortunately, it is not clear that the market cares enough about end-to-end transparency to fund the development of NPTv6 or IPv4 NAT-aware end-nodes, because while end-to-end transparency is something that we in the IETF hold dear, it does not have enough practical value for Internet-connected enterprises that they have been willing to incur any cost or inconvenience to maintain it. In fact, in many cases, they prefer _not_ to have it. Margaret > Hi Steven, > > While it is obvious that we have no time to redesign IPv6 for the set of > valid reasons you mentioned one could observe that we do have time to deploy > it wisely via ID/LOC split architecture model. > > Dual stack networks and all networking gear stays intact and depending on the > choice of ID/LOC split solution some hosts may require a patch. > > I believe some/most of problems from the quoted article and repeated in this > thread would get solved with such model. > > Perhaps it's time to build LISP to ILNP inter-working and roll. > > Regards, > R. > > >> v6 is not the protocol I would have chosen. For that matter, it's not the >> protocol I pushed for, as hard as I could, in the IPng directorate. At this >> point -- with all of its technical mistakes, IETF omissions, and difficulty >> of converting, we're stuck with it; we simply do not have time -- even if >> we agreed now on what we should have done, way back when -- to start over. >> Do the arithmetic... Assume we know, today, the basic structure of a >> perfect replacement for v4. It would take a minimum of 3 years to get >> through the IETF, not because of process but because there are so many >> things that it touches, like the DNS, BGP, OSPF, and more. There are >> also all of the little side-pieces, like the ARP/ND replacement, the PPP >> goo, etc. After that, it's 3 years of design/code/test by Microsoft, >> Apple, Cisco, Juniper, et al., following which we have the whole education >> cycle, the replacement cycle while old boxes die off and are replaced, and >> more. (Look at how many Windows XP boxes still exist -- and we're well >> into the second major release of Windows since then, and Windows 8 might >> be out before the end of the year.) By my arithmetic, it's a dozen years >> minimum,*after* we've agreed on the basic design. >> >> >> --Steve Bellovin,https://www.cs.columbia.edu/~smb >
