Re: IPv6 networking: Bad news for small biz

Hi Margaret,

Indeed by no means I meant to exclude NPTv6 from the ID/LOC splitsolutions. I have just mentioned ILNP and LISP as host and network basedmost recent examples.

/* In fact I do not recall any one proposing NPTv6 via all the RRGID/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 creatingregistry which could allocate enterprises and end users permanentglobally scoped Identifiers. And truly I don't think this is for theenterprise X or vendor Y to propose it. It should be driven by IETF andperhaps executed by local RIRs.

Till I can go to URL or better just login on my device which willautomagically retrieve one of my IDs then seamlessly go via anytranslation points I happen to be closest to in order get to any pointin the Internet we will still be very far from achieving any form ofpractical value for ID/LOC technology.


Regards,
R.

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