Using IPv6 with prefixes shorter than a /64 on a LAN
marka at isc.org
Sat Feb 5 19:01:45 CST 2011
In message <4D4D5FFC.6020905 at brightok.net>, Jack Bates writes:
> On 2/5/2011 6:47 AM, Mark Andrews wrote:
> > So why the ~!#! are you insisting on comparing IPv4 allocations with IPv6
> > alocations.
> Because that is where the comparison must be made, at the RIR allocation
> size/rate level.
> > There are two sizes. Those that fit into a /32 and those that don't.
> > The latter ones have to justify their allocations.
> Yeah, tell that to the fee schedules.
> > No. You need to compare it to the number of customer sites. If you
> > have 1 customer with wires going to two locations thats two /48's.
> That's definitely the wrong way to look at it. Sure that's related to
> justification to an RIR to get an allocation, but ISPs will end up with
> much more flexible address space.
> > Residential ISPs shift 16 bits (48-32=16). You shift less if you
> > have less than 64000 customers sites and don't get address space
> > from a larger ISP. Commercial ISPs shift more as what was multiple
> > address at one sites becomes 1 /48.
> 64,000 customer sites isn't required to receive more than a /32 (unless
> a single router makes up your entire network).
No, but you still need to have reserved growth space sensibly. /32 for
a town of 3000 is overkill.
Last assume you are serving a home customers so you were at 1 address
per customer. You still size your pops based on expected customers
and having some growth room without having to renumber. n customers
requires f(n) sized block of space. The only difference with IPv6 is
f(n) << 80 bits to support /48's instead of single addresses.
Expected growth rates in customers don't change because you are
suddenly dealing with IPv6.
> Well, I currently have a /30, which is a 14 bit shift right from my /16.
And did you change the amount of growth space you allowed for each pop?
Were you already constrained in your IPv4 growth space and just restored
your desired growth margins?
> In the near future I expect to be somewhere between a /24
> and a /28, which is an 8 to 12 bit shift right from my IPv4 /16 allocation.
Only if you can serve all those customers from that /16. You are
then not comparing apples to apples. You are comparing a net with
no growth space (IPv4) to one with growth space (IPv6).
> Still, that is a considerable number of bits we'll have left when the
> dust settles and the RIR allocation rate drastically slows.
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka at isc.org
More information about the NANOG