Moving to IPV6

[Robert E. Seastrom]

Josh Smith <juicewvu at gmail.com> writes:

> <snip>
>> Anyway, the *real* problem that IPv6 fails to fix is one that I'm
>> surprised that Mike didn't mention since he had an IETF draft or three
>> that would have fixed it. Â That problem is one of routing table
>> growth. Â In the middle of the Internet are large routers - not like
>> the one that you have on your cablemodem, but ranging in size from 2
>> rack units tall and weighing some 40 pounds to several adjacent 42u
>> racks and weighing a couple of tons. Â They carry the routes for
>> Internet provider allocations. Â This is called the default-free zone
>> or DFZ, because you don't carry a default route or gateway - you're
>> supposed to know how to get everywhere. Â A full routing table in IPv4
>> land is 375k routes, approximately. Â In IPv6 land it is 4500 routes.
>> Both are growing exponentially. Â Processing power on the routers'
>> management systems to sort out the routing information is not. Â You
>> can see where this is headed... Â eventually...
> <snip>
>
> Correct me if I'm wrong, I'm definitely not an expert on global
> routing or the DFZ, but isn't one of the driving factors behind the
> current ipv6 allocation policy
> (http://www.iana.org/reports/2002/ipv6-allocation-policy-26jun02) to
> allow for greater route aggregation than is currently possible with
> ipv4 allocations.  I believe the thought is that if an ISP is
> delegated enough contiguous address space upfront they are able to
> better aggregate the routes they advertise upstream thus reducing the
> number of routes making it to the global routing table?

Yes, the sparse allocation policy is meant to address this.  Certainly
the slow-start allocation policy of IPv4 which burned routing table
slots in the interests of prolonging the life of the address pool is
no longer justified given the size of the IPv6 address space.

There are other reasons to deaggregate than "we got the addresses at
different times and therefore can't aggregate" though.  One Layer 8/9
reason is M&A.  Another is that selective advertisement of certain
ranges of one's address space can be used for very coarse grained
traffic engineering.  There are also likely to be ever more multihomed
organizations in the future, many of them with /48s, because the SOX
or SAS70 auditors got on their case for not having adequate continuity
of business or DR capabilities.  IPv6 _does not solve the multihomed
end site problem_.  Various hacks like multi-numbering hosts and shim6
notwithstanding, a multihomed end site still eats a routing table slot
in the DFZ of a router on the other side of the planet.

There are numerous flaws in the document that you cited, which is
almost a decade old.  The people who worked on it are all
extraordinarily smart (and a lot of them are still doing policy and
standards today) but they did not have a crystal ball.  The way that
it is worded has caused RIRs to default to assigning /32s and set the
bar quite high for larger initial allocations and require high levels
of justification when attempting anything larger.  The "IPv4 thinking"
reflected in these nascent policy documents is slowly getting fixed
both through the public policy process and via suggestion boxes such
as the ACSP in the ARIN region.  ARIN recently changed from "assign
the /32, reserve the /29" to "assign the /32, assign the /28" based on
observations from many of us that chopping things more finely than on
a nybble boundary was optimizing for space conservation rather than
brain cell conservation and that this decision was wrongheaded.
Likewise, the justification has been loosened substantially, and many
ISPs are doing do-overs to get bigger chunks of IPv6 space from ARIN.
I believe that the same is true, to a lesser degree, in RIPE and
APNIC.  Not sure about LACNIC and AfriNIC.

So the direction of travel is correct but there is still much to do.
I have made the case in the recent past that a /32 is only suitable
for the degenerate case of "super small ISP", like ClueTrust, and that
anyone of a more than trivial size should be getting a /28 which turns
out to be a very nice number in terms of /48 end sites and POP level
aggregation.

I'd be happy to discuss further, as one of the geeks with operational
experience who "takes a hit for the team" by playing in the internet
numbers policy world.  :)

-r