Re: Using IPv6 with prefixes shorter than a /64 on a LAN

[Mark Andrews <marka () isc org>]

In message <4D4D5FFC.6020905 () 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. 
> (30-16=14).

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.
>
> Jack
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka () isc org