IPv6 end user addressing
Owen DeLong
owen at delong.com
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>
More information about the NANOG
mailing list