[arin-ppml] IPv6 Allocation Planning

Charles O'Hern charles at office.tcsn.net
Wed Aug 11 19:20:38 EDT 2010


Owen DeLong wrote:
> On Aug 11, 2010, at 12:30 PM, Charles O'Hern wrote:
>
>   
>> Owen DeLong wrote:
>>     
>>> 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)?
>>>
>>>
>>>       
>> That's a bit ad hominem... Lets just say that the intended purpose of a
>> network is whatever my bosses tell me.  My imagination is only exercised
>> in the implementation.
>>     
>
> You are correct and I apologize. (And have done so publicly as well)
>
>   
Again, thank you, sir.
> However, IPv6 is intended to facilitate innovative things like being able
> to bring multiple devices in their own network on your person into a
> public wireless environment and have one of the devices act as the
> designated router for the rest of the network. Assigning /64s or worse
> /128s in such an environment is harmful to that design and unnecessarily
> limiting on the end users.
>
>   
I'm aiming at baby steps at this point, although I don't want to make
any plan that prevents being able to implement this kind of
functionality.  My immediate purpose implementing IPv6 is imitation of
the functions of the IPv4 network.  Customer Premises Equipment connects
at layer2, gets addresses (v4 and v6, CPE interface and any subnets
assigned/routed to them), authenticates with us in some manner, and gets
throughput to the 'world-at-large'.  While I have started testing using
FD00::/32 addresses, I know that i have a lot to learn.  Imitation
itself is probably a poor term, but a prime goal is transparent
functionality to the EU.

Your example is inspiring, and convinces me that I should have the
address resources available for such uses, but I feel I need to keep my
focus on the mundane here and now wherein I just need things to appear
work as they have for years when the customer says 'go'.
>
> Yeah, Scott also pointed that out. I bet if we get a /36 policy in place,
> the ACSP for getting the x-small boundary moved up to meet it would
> be possible. I don't think that we want to facilitate ISPs going smaller
> than /36, but, I agree we do need to facilitate smaller ISPs having
> similar fees to their current structure.
>
>   
<snip> as I was still not seeing why you were pushing the /36 policy
addition, until I read more.
> Yep... The problem here is that the /32 is a remaining vestige of a day when
> the IETF thought that they could allow router vendors and very large ISPs
> to set addressing policy through the IETF process.
>
> If you look back on the history to proposal 2002-3, you'll see that I actually
> pioneered the idea of the RIRs being able to tell the IETF to stuff it, go back
> to protocol design and leave those that administer the addressing to the
> policies thereof.
>
> ARIN is in a bit of a tough spot in that fewer ISPs will be coming back to the
> well every year (which is actually a good thing for the internet), but, that means
> ARIN has the same customer base facing in the vast majority of cases,
> reduced fees and ARIN facing significantly reduced revenues while still
> trying to operate many of the same functions for the community.
>
> With so many organizations that previously got allocations in larger
> categories being able to fit in to a /32, it will make life interesting.
>
>   
So because many orgs which had larger-than-small allocations (and
multiple allocations) of IPv4 fit into the Small IPv6 category, ARIN is
drawing in less fees.  To keep the books balanced they can't reduce the
fee for the Small category.  AH-HA  This makes sense.
> Nonetheless, I don't think that issue should be solved on the backs
> of those least able to absorb sudden fee increases. Reducing the
> price of a /32 would be too detrimental to ARIN (and by extension
> the community that ARIN supports). I think that the majority of the
> larger providers that can fit within a /32 will not choose to fit within
> a /36 while smaller organizations can do so easily.
>
> I think it is also important where possible to avoid financial incentives
> for bad addressing practices (such as making /36s so cheap that
> they make it attractive to give end users /96s if that's what it takes
> to cram all your addressing into  a /36 no matter how large you are).
>   
I'm not certain how ARIN can prevent bad addressing policies without
intrusive audits.  The best pressure IMO on the ISP practices will come
from the EU's that pay them and the firmware implementations of the
hardware vendors that sell their products to the same EU.
This may be a bit out of the ballpark, but do we (anyone) have an idea
if the soho cpe vendors will set their firmware to allow a subnet size
smaller than /64?  With our customer base we haven't yet been seeing
soho devices with IPv6 capabilities to know how they are going to work.
How do we make sure EU's know that they are supposed to get at least 18
billion billion addresses from their connection?  If the EU's have it in
their minds that they have a 'right' to a /64, or /48 or whatever, they
will demand it of their ISP.
*pauses to envision the torches and pitchforks*
> I think that having a policy that allows an ISP with fewer than
> 200 customers to obtain a /36 and realigning the x-small
> fee boundary to /36 would solve that problem without undue
> harm to ARIN revenues in the process.
>
> Owen
>
> (You are welcome to post this to the list, but, since you emailed me
> privately, I will not post your email to the list without permission.)
>   
Thank you sir.  I think I will.  Your points about the effects of IPv6
allocation on ARIN's financials are enlightening.

-- 
Charles O'Hern
Network Operations
 
TCSN - The Computer Shop Netlink
1306 Pine St. Paso Robles CA 93446
1-(805) 227-7000  1-(800) 974-DISK
http://www.tcsn.net  abuse at tcsn.net




More information about the ARIN-PPML mailing list