Moving to IPV6

[Josh Smith]

On Mon, Feb 7, 2011 at 9:39 AM, Robert E. Seastrom <rs at seastrom.com> wrote:
>
> 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.

I realize that there are definitely more reasons for deaggregation
than "we got the addresses at different times problem" I was just
trying to point out that one of the major (i think??) contributors to
the size of the current ipv4 routing table is at least potentially
addressed by new allocation policies for ipv6 address space.
>
> 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.

I know the policy document I linked to is quiet old however it was the
newest revision I could find with a very quick google before I sent my
reply to the thread.  If you have a link to an updated policy document
I would be very interested in reading it.

>
> 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.  :)
>

I think we are both in agreement that ipv6 is a huge step forward from
ipv4 and while it may introduce some new, perhaps currently unknown,
problems it is a step forward for the internet as a whole.  I'm also
an operational geek with interests (albeit it from the sidelines) in
the internet numbers policy world.

<snip>

While we are talking about ipv6 allocations does anyone know if there
are any plans for an ipv6 allocation similar to the network 44 ipv4
(ampr.org) allocation for hams?


Thanks,
-- 
Josh Smith
KD8HRX
email/jabber:  juicewvu at gmail.com
phone:  304.237.9369(c)