IPV6 renumbering painless?

Paul Vixie paul at vix.com
Fri Nov 12 17:09:18 UTC 2004


> I don't care whether you want to call it PI space or not, the bottom line
> is that it has all the same practical uses and effect as PI space, and,
> this is exactly what the real world is likely to do with v6 for any
> organization that wants to multihome without renumbering.  They'll get
> an AS and they'll get a /32, and, suddenly, each department within the
> company will become a "customer" of the IT-ISP department.
> 
> I'm not saying this is clean, friendly, nice, whatever.  However, it is
> what people are really going to do with the current v6 address allocation
> policies.

that's all true.  i want to add a detail, but because i'm a member-elect of
the arin board of trustees i have to put in the following disclaimer: I'm
Speaking For Myself And Not For ARIN.  that having been said, here's my view:

the current policies that allow organizations as small as isc to get a /32
are clearly wrong for the long term -- it lets the ipv6 /32 do what the
ipv4 /24 did: create a swamp.  we will be dealing with an ipv6 swamp for as
many years to come as we've already dealt with the ipv4 swamp.  HOWEVER, i
have two observations.  #1 is that the ipv4 swamp was a huge motivator for
ipv4 deployment in the early days, and its carrying costs today are still
worth paying just because of the market size it helped enable.  #2 is that
the ipv4 swamp has stayed about the same absolute size since CIDRD was closed,
and almost all growth since then has been of larger (PA) prefixes.

extrapolating this for ipv6 ought to cause a number of you to go out and get
ipv6 /32's today, before the swamp starts to fill up with other folks'
prefixes, which will ultimately lead the members of ARIN and other RIRs to
"raise the bar" for /32 allocations.  and i do not expect there to be a
provision for getting anything smaller than a /32 if you don't qualify for
a /32.  read this whole message more carefully if you are still unmotivated.



More information about the NANOG mailing list