IPv6 end user addressing

Sat Aug 6 20:05:44 UTC 2011

On Aug 6, 2011, at 11:44 AM, Jimmy Hess wrote:

> On Sat, Aug 6, 2011 at 1:28 PM, William Herrin <bill at herrin.us> wrote:
> 
>> On Fri, Aug 5, 2011 at 12:17 PM, Brian Mengel <bmengel at gmail.com> wrote:
>> 
> 
> 
>> On the flip side, /56 allows for 16M end-users in your /32 ISP
>> allocation. After which you can trivially get as many additional /32's
>> as you want. Is there any reason you want to super-optimize to get
>> 268M end-users squashed in that /32?
>> 
> 
> Arguably,  if you only have one /32,  and you ever get  65,536 customers
> each with a /48,  getting as many /32s as you need should be no problem,
> also.
> 
> But you might want to give them /56s,   so you have more bits  to logically
> divide those customers by  region,  or   some other criteria  to enable
> more efficient aggregation.
> 
Policy supports you getting those bits left of the /32 instead now.

Look at ARIN 2011-3 which was adopted and ratified by the board and
is awaiting implementation by staff.

If you like this idea, support APNIC prop 98, too, please.

> That's the problem with the RIR's choice of  issuing  only  /32s  from which
> /48s are to be assigned.
> The customer has  80 bits to work with  in organizing their hosts.
> 

The /32 is only the default minimum for an ISP. A small ISP can probably work
with 16 bits. Larger ISPs were always expected to get more than a /32.

> But the ISP has only 16 bits  in a /32  to work with.
> 

Only if they're very small or not very intelligent in their RIR application.

Owen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2105 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110806/bcf9b504/attachment.bin>