[governance] IPv[4,6, 4/6] was IGF delhi format

[Thomas Narten]

Karl Auerbach <karl at cavebear.com> writes:

> I remember when I was at Sun in the early 1990's when the idea of IPv6 
> was born.

> And even then people were saying - "hey, the real problem is not 
> addresses but, rather, routing."

Both are problems. Routing is a problem for ISPs (and ultimately for
end users, because they care about multihomining and provider
independence, but end users do not see this pain directly for the most
part).

ISPs complain about IPv6 because it does not help them with *their*
problem (route scaling), and they don't see any benefit from IPv6.

Lack of globally unique addresses is a big problem for end sites and
users and applications writers. But it is not really a problem for
ISPs, which is why they view IPv6 differently.

> IPv6 doesn't help routing at all, in fact, because it doesn't share
> with IPv4, it adds an additional burden without alleviating the
> existing burden.

That is true at one level, but I think somewhat overblown too. One of
the myths that gets thrown out is that IPv6 makes the route scaling
problem WORSE because it has so many more addresses. More addresses
means potentially more routes. But this is a strawman of sorts. The
real issue is growth (which presumably everyone wants to
encourage). The exact same route scaling problems already exist with
IPv4, except that there are fewer total addresses possible,
effectively limiting growth. 

That said, it turns out that exhaustion of the IPv4 free pool will
almost certainly further strain the routing system (independent of
IPv6). What is necessary to keep the routing infrastructure intact is
massive aggregation. Aggregation means having route prefixes in the
routing table that are as short as possible, so that each individual
route entry covers as many addresses as possible. (The more addresses
covered, the fewer total prefixes that are needed to be able to
provide connectivity to ALL destinations.)

But as the free pool exhausts, and people make more efficient use of
IPv4 space, they will almost certainly try to route increasingly
longer prefixes (i.e, those covering fewer addresses). As an example,
suppose someone has a /16 (class B) address, which currently takes up
one entry in the global routing system. As addresses become scarce,
there will be a temptation to divide that block up into smaller pieces
and sell the individual smaller pieces to those that need them (or are
willing to pay). That single /16 can easily be divided into 256 /24s,
but now each of those 256 /24s requires its own routing slot in the
global routing table.  Repeat as needed. It doesn't take long to
imagine the routing table growing substantially (i.e.,
doubling/tripling/quadrupling who knows where it ends).

(For those that want to know more about the overall problem of route
scaling, have a look at
http://tools.ietf.org/html/draft-narten-radir-problem-statement) 

> And I have yet to obtain a real answer of how I can deploy a new IPv6 
> network without simultaneously having to deploy a parallel IPv4 network 
> - every time I need an IPv6 block I'm going to need an IPv4 block.  All 
> of those devices on store  shelves are V4 only.  And I have yet to see 
> really good answers to the question of how an IPv6 client (user sitting 
> at a web broswer) is going to seemlessly reach and use all of those 
> IPv4-only services out there on the installed base internet.

There is no good/easy/perfect/ideal way for an IPv6-only site/device
to communicate with an IPv4-only site/device. That is life.  That is
reality. People need to get over it.

That is why the IPv6 deployment recommendation is dual-stack. If you
try to make an IPv6-only device talk to an IPv4-device, you need to do
protocol translation of some sort. There are technical/operational
issues with that approach. The simple summary of this is that your
application simply may not work when such translation is done, as
translation doesn't work in all cases.  The IETF has oscillated
between developing such an approach and deprecating it. Have a look at
RFC4966 "Reasons to Move the Network Address Translator - Protocol
Translator (NAT-PT) to Historic"
(http://www.ietf.org/rfc/rfc4966.txt).

My personal opionion is that the IETF should resurrect the technology
and try to make it is usable as possible, while documenting the known
problems. But it will never be ideal and hence it is NOT a magic
bullet, like some would like it it be.

> In my mind I perceive IPv6 as a new internet that lays alongside the 
> existing IPv4 internet.  It shares the physical wires, yes, but not much 
> else.

I don't like this view, as it emphasizes differences and suggests a
walled-garden between the two. In truth, IPv6 is a small evolution
from IPv4. 98% of IPv6 is the same as IPv4. There is much more
similarity than there is difference. (Yet people seem to focus on the
differences...)

Indeed, it is that similarity that ultimately makes folk unwilling to
deploy IPv6. A basic design decision that was made early was that the
IPv6 service model would stay exactly the same as it is for IPv4. That
way, TCP, HTTP, the DNS (and all existing protocols) would continue to
work exactly the same over IPv6 as over IPv4 (module differences in
the packet format, which are more syntactic than substantative). This
was done to ease interoperability.

But, because IPv6 doesn't provide a flashy/new/cool service (compared
to IPv4), it's also pretty much impossible to design a killer
application that only works over IPv6 and can't work over IPv4. The
only one I can imagine is one that involves exploiting IPv6's massive
address space and its ability to get away from the needs for NATs.

> Apart from IPv4 address scarcity - a problem that we have learned to
> resolve in large part through NATs, there is not a lot of pressure
> to move.

NATs do not resolve the address scarcity problem. They are at best a
tactical approach. (I'll expand on this in a separate note).

> It is still my opinion that we are headed for a lumpy internet - with 
> lumps of address spaces connected by application level gateways.

Absolutely. ALGs are one way to have IPv6-only applications be able to
interact with IPv4-only applications. They are no panacea though. For
one thing, you need one for each individual application/protocol...

> Such a lumpy internet would resemble the cellular telephone networks
> in that a few services - such as voice calls - easily and fairly
> transparently cross the boundaries.  But those boundaries will
> become difficult to traverse for new things or for user-created
> tools; innovation from the edge will be limited to occur only within
> a lump not across lumps.

Actually, I see this as the inevitable direction we are heading in
with IPv4 and NATs. IPv6 provides the only viable alternative to this
(unfortunate) model.

Thomas
____________________________________________________________
You received this message as a subscriber on the list:
     governance at lists.cpsr.org
To be removed from the list, send any message to:
     governance-unsubscribe at lists.cpsr.org

For all list information and functions, see:
     http://lists.cpsr.org/lists/info/governance