|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
Hi Margaret,Indeed by no means I meant to exclude NPTv6 from the ID/LOC split solutions. I have just mentioned ILNP and LISP as host and network based most recent examples.
/* In fact I do not recall any one proposing NPTv6 via all the RRG ID/LOC split debates, but maybe I have just missed it. */
> 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. I think this little thread so far shows that they are interested.However one can not claim we have solution till we start with creating registry which could allocate enterprises and end users permanent globally scoped Identifiers. And truly I don't think this is for the enterprise X or vendor Y to propose it. It should be driven by IETF and perhaps executed by local RIRs.
Till I can go to URL or better just login on my device which will automagically retrieve one of my IDs then seamlessly go via any translation points I happen to be closest to in order get to any point in the Internet we will still be very far from achieving any form of practical value for ID/LOC technology.
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. MargaretHi 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