> -----Original Message----- > From: Michael Dillon [mailto:wavetos...@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
