On Aug 6, 2011, at 11:44 AM, Jimmy Hess wrote: > On Sat, Aug 6, 2011 at 1:28 PM, William Herrin <b...@herrin.us> wrote: > >> On Fri, Aug 5, 2011 at 12:17 PM, Brian Mengel <bmen...@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
smime.p7s
Description: S/MIME cryptographic signature
