Re: IPv6 networking: Bad news for small biz

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