[arin-ppml] IPv6 Allocation Planning

[Owen DeLong]

On Aug 11, 2010, at 11:13 AM, Charles O'Hern wrote:

> Owen DeLong wrote:
>> On Aug 10, 2010, at 2:25 PM, Charles O'Hern wrote
>> What if you properly gave them /48s? If a /40 works for you at /56, then,
>> a /36 works for you at /48s.
>> 
>> 
> I was simplifying a bit.  About a third of our customers are dynamic
> 802.11 hotspot customers.  Since those are each single hosts, I can't
> foresee allocating  more than a /64 per hotspot with each host getting a
> single dynamic address.  But this perception could be based on a great
> deal of ignorance of the future of these types of connections.  (maybe a
> vlan per customer with each vlan using a /64, but the still only gets
> its one host address.)
> 
Then you lack imagination. Why not give a /48 (or more) per hot spot
and let the hotspots do DHCP-PD to devices that want to act as routers
giving them /56s (if they need multiple nets) or /64s (if they only have
one collection of devices behind them)?

> For static connections to residences I'd need at most 2000 /48's.   A
> /36 would be plenty.

Exactly.

>>> Yes, as soon as either of our upstreams has it available, and if we are
>>> still unable to obtain an ARIN allocation, we'll be requesting at least
>>> two /48's.  The problem  then will be getting upstream A to advertise
>>> and transport the traffic for destination addresses allocated to us from
>>> upstream B, and visa versa.
>>> 
>> 
>> Yeah, that's ugly and best avoided. I think we can improve policy to
>> make it possible for you to:
>> 
>> 1.	Get /36s
>> 2.	For others to get even larger blocks if they want them.
>> 3.	To have ARIN round allocations up to nibble boundaries.
>> 
>> That way we can make it easier for those that choose to to avoid
>> disaggregation. Might not be the perfect solution, but, I think it is an
>> improvement on the current situation.
>> 
>> Owen
>> 
>> 
> Yes, that would be great.  I'm hoping that ARIN does revise their fee
> schedule.
> 
Actually, no need to revise the fee schedule. If we make it possible
for you to get a /36, the existing fee schedule meets your requirements.
Simple policy change. Look for a draft shortly after the October meeting,
if not before.

> Frankly I don't care if we get a /36 or a /32.  I'd just like a IPv6
> allocation of 'equivalent' size of our current IPv4 allocation, whatever
> that equivalent size is, without increasing our fees.  Ideally I want to
> be able to assign each end user a /48, have enough /48 networks
> available in a continguous block for forseeable customer growth and
> advertise one aggregate route to each of our upstream AS's.
> 
There isn't an equivalent. IPv4 allocations are based on host counts
and dense assignment with host density efficiency being the primary
goal and aggregation coming in second due to address scarcity.

IPv6 allocations are based on network counts and sparse assignment
with aggregation being the primary goal and network density
efficiency being a distant second. Host density efficiency is actually
meaningless in IPv6. (Note: Host density efficiency in this context
is the Nhosts/Naddresses, this is not related to the "Host Density
Ratio" mentioned in policy which has nothing to do with hosts and
is unfortunately poorly named IMHO).

Owen