moving to IPv6

Paul Ferguson writes...

[playing devil's advocate here]

Of course, there is a rather large contingent of the
Internet community that is of the opinion that IPv6 is
a solution in search of a problem.

And we can most certainly go for a long time with IPv4. Just how long
that will be depends on things like new technologies coming along that
can impact how people use the Internet.

IPv4 space is not enough for dedicating 1 IP address to every person.
The question is when (or if) that will be needed. Under the current
user paradigm of dialing up to a provider for a short while to surf,
it may be indefinite. And that demand will be rolling off to level
out at some point in the U.S.

There are also increased costs involved in the processes being used to
manage allocations of IPv4 space. Space is allocated in pieces as needed,
which means either renumbering networks or introducing more routes into
the BGP4 stream. One big /64 of IPv6 space will last virtually any ISP
a century, unless they start trying to assign every grain of sand. And
there would be just one route for all that. Administrative costs, once
the software is in place that handles it, will be much less than with
IPv4 space.

With IPv4 space being managed better with CIDR, we do have more time to
find the right way to deploy IPv6. I remember the panic of a few years
ago. I was even called to ask if my then-employer would be able to
return part of their class B assignment. The big problem I see today
is not the amount of space, but the complexity of managing tight space,
and things like the number of routes involved.

Whether to IPv6 or not, maybe we should be looking at what next for BGP4.

Phil Howard <phil@charon.milepost.com> writes:

IPv4 space is not enough for dedicating 1 IP address to
every person.

Correction:

IP space is not enough for dedicating 1 IP address
with global scope permanently to every person.

Remember: CIDR requires renumbering, which means that the
permanence is no longer the case; this substantially added to the
lifetime expectancy of IP. NAT translates at NAT borders
which means addresses have local scope. This even more
substantially adds to the lifetime expectancy of IP.

NAT also mitigates the cost of renumbering to comply with CIDR.

Note that with aa decent evolution towards describing
services as a domain name and a service name that is
relative to the domain name, then the IPv4 address space
is essentially extended proportional to the number of
autonomous NAT domains and within each such domain
proportional to the number of useable ports to which the
service names may map.

There are also increased costs involved in the processes being used to
manage allocations of IPv4 space.

Allocations are local. ARIN/RIPE/APNIC allocate within
one large NAT domain, and not within other NAT domains.
As NAT continues being deployed, and in particular if very
large scale NAT (e.g., between ISPs) becomes workable and
efficient, then it is local registries and not
ARIN/RIPE/APNIC that will be managing allocations of local
IP addresses, and NATs managing translations at NAT domain borders.

With IPv4 space being managed better with CIDR, we do have more time to
find the right way to deploy IPv6.

No, with IPv4 space being managed better with CIDR we have
had time to develop and deploy NAT on a continually
growing scale, and have had the time to reflect that this
scales better than a migration to IPv6. What is not
completely clear is that IPv4ever is the best approach,
but what is completely clear is that NAT and the IPv6 work
on protocol translation means that a better protocol than
IPv6 can easily be deployed locally within a NAT/protocol
translation domain.

Whether to IPv6 or not, maybe we should be looking at what next for BGP4.

A chainsaw right through it.

  Sean.

Hi,
   Perhaps I'm being rather naive, but one of the really cool things about
the initial 6bone test address space was that the prefix was completely
AS based.. theoretically if an adressing scheme was adopted that did not
permit transferrible address space (think NAT) the entire backbone routing
table could be simply composed of AS paths and relationship's between AS's.
(if an addressing scheme based on AS or some kind of AS equivalent was
adopted) Ofcourse AS's all of a sudden become a hot commodity.. but
today, most routing policy is dictated based on AS more than by address
space..

nm

The question of CPU comes in when talking about large scale NAT
deployments. Anyone have concrete figures as to how much CPU this
involves on a large scale and with overloading multiple inside addresses
onto a few outside addresses? CPU speed is growing at a fairly fast clip,
but so is data traffic. At current prices, a R10000 based cisco box
should be beyond reach of all but the most well heeled companies, given
cisco's current pricing.

As for IPv6, the main issue is with reducing routing complexity. The
prefix can be made AS based entirely. If people bite the bullet and adopt
an addressing scheme that does not allow for transferable address blocks.
At this point the backbone routing tables become a set of mappings between
AS's and the relationships between the paths.

BGP takes a hit and a simpler, kinder, gentler protocol comes into place.

vijay