RE: IPv6 allocations, deaggregation, etc.

["George Bonser" <gbonser () seven com>]

> -----Original Message-----
> From: Michael Dillon [mailto:wavetossed () googlemail com]
> Sent: Thursday, December 24, 2009 4:11 PM
> To: nanog () nanog org
> Subject: Re: IPv6 allocations, deaggregation, etc.
>
> > I can't in good conscience justify a /32.  That is just too much
> space.
>
> Then you need to go back to IPv6 101.

This is an end user application, not an ISP application.

Something between a /32 and a /48 would suffice.  The idea was that a /32 is too large (in my opinion) for an 
organization that isn't planning on having more than 20 sites in the next 5 years.  If it were 200, that would be a 
different story.

If having a block smaller than a /32 breaks something, then it needs to break early so it can be addressed before 
things progress much further.  And getting a /32 would appear to violate ARIN's policy:

6.5.8.2. Initial assignment size

Organizations that meet the direct assignment criteria are eligible to receive a direct assignment. The minimum size of 
the assignment is /48. Organizations requesting a larger assignment must provide documentation justifying the need for 
additional subnets. An HD-Ratio of .94 must be met for all assignments larger than a /48.

These assignments shall be made from a distinctly identified prefix and shall be made with a reservation for growth of 
at least a /44. This reservation may be assigned to other organizations later, at ARIN's discretion.



If we were to number all sites globally into a /45, we could meet the .94 HD-Ratio but with the potential problems 
noted in earlier traffic on this thread.  I am now leaning toward expanding my request to a /45 if we go with a global 
block or a /46 if we go with only using ARIN allocations in North American operations. 

> Don't try to fit more into a /48 than one single site.

Yeah, I think I pretty much "get" that, at this point.  I can hang small offices off of a data center, giving them one 
or more /56 nets each but yeah, trying to split a /48 between data centers is probably counter-productive.


> If you need to announce /33 or /34 prefixes to make things work, then
> deal with it. Talk to providers and explain what is going on. IPv6
> routing
> is in its infancy and many people tend to set it up and let it run on
> autopilot. There is no law saying that you must announce one and
> only one /32 aggregate everywhere.

Agreed.  Wasn't planning on it but if we did eventually become fully integrated globally, I would probably announce the 
larger aggregate(s) out of one main location, maybe handing any unassigned traffic to a honey-net or something.  At 
least if a mistake is made somewhere in addressing, that would give me a "backstop" so that we could provide a 
temporary fix for the problem quickly until it got fixed correctly.  If someone misconfigures something and traffic 
goes out with the wrong subnet SA but still in our block (say someone transposes a couple of subnet digits someplace), 
at least the reply traffic would come back to someplace I have some control over and could route (or tunnel) the reply 
traffic back to where it needs to go until the root cause could be fixed.  It would be ugly and slow for a while but it 
wouldn't be completely broken until a maintenance window where we could correct the underlying problem.  Things like 
that offers an opportunity to fix emergencies quickly and schedule more disruptive corrective actions for a later time 
when people can plan for the outage.  It is yet another advantage of having a larger global block over a gaggle of 
smaller scattered blocks.

> For real technical solutions to your problem, you are probably better
> off
> going to the IPv6-ops list  

Signed up yesterday :)

> --Michael Dillon

Thanks, Michael.

George