Current Consensus on IPv6 Customer Allocation Size

Marc Blanchet marc.blanchet at viagenie.ca
Wed Aug 1 22:29:57 CEST 2012


Consider reading RFC3531 for allocation methods that could help you have more flexibility in your address space, whatever initial boundaries you decide at the beginning.

Marc.

Le 2012-08-01 à 12:17, Tim Densmore a écrit :

> Hi Folks,
> 
> I have read through multiple threads regarding this issue (though most of them are years old), and know it may be a can of worms, but I need some insight into what people are actually doing in 2012. ARIN "suggests" a /48 for all customers or sites as far as I can tell, though apparently in the past they also had language including /56 assignments in some docs.  I'm trying to come up with a reasonable numbering plan that can accommodate /48 customer assignments from our /32.
> 
> Basically, here's how I'm looking at things in a nutshell.  We currently have 8 POPs that need subnets allocated, but obviously I want to leave room for future growth.  This leaves me with /36 or /37 per-POP (yes, I know that the idea of /37 might bother some folks) which would allow me 16 or 32 POPs respectively.  Some POPs are obviously smaller than others, but I don't want to get into variable sized allocations per-POP.  Even with a /36 per-POP, when using /48, this allows me a maximum of 4096 allocations before having to add a second /36 to the same POP.  This is fine for business connections, but kind of dicey for residential services. Obviously we could go back to ARIN for another allocation if we end up in a bind down the road, but there is a real cost associated with changing designation from a "small" to "large" org (we actually qualify as a medium org, but nibble boundary allocations) that I'd prefer to avoid.
> 
> Is the current (again, 2012 - most threads and books that I have read are al least a few years old) consensus that a /48 per-residential-user really justified?  Opinions or pointers to current Fine Manuals to read would be most appreciated.
> 
> Thanks,
> 
> TD



More information about the ipv6-ops mailing list