[arin-ppml] Opposed to 2010-9 and 2010-12

[David Farmer]

On 10/14/10 18:22 CDT, Fred Baker wrote:
>
> On Oct 14, 2010, at 3:18 PM, Mark Townsley wrote:
>
>>> You asked me to tell you if you are contradicting someone from your organization... You are contradicting Tony Hain here, or, at least my understanding of what Tony has been saying.
>>
>> Thanks for the heads up.
>
>> From my perspective, in the equipment, the question is "do I assume that the ISP will give me a prefix that allows for multiple subnets, or do I assume that the ISP will give me a /64". Once you say "more than one", "how many" is a configuration issue, not an algorithmic one. If the allocation only allows for one LAN, I start worrying about proxy neighbor discovery and how best to handle a residential network that isn't actually tree-structured - the wired LAN, the wireless LAN, the separate LAN for A/V equipment, his office, her office, and so on, and noting that the wireless goes places the wired doesn't in weird and wonderful ways. If in the general case we make it simple for a residential/SOHO router to handle those issues (which a /60 would do in the vast majority of cases), I think we have done the world a favor - we have simplified the router, we have given users lots of options, the technology is predictable within that domain, the ISP can aggregate lotsa teeny sub
ne
>   ts within its /32-or-whatever, and the net result is a good thing.
>
> News flash: I'm going to go on record as disagreeing with Tony here. Tony, if I can paraphrase him, would like to see every ISP customer get 2^16 subnets because that "might be useful in the future". He has argued in the past that a mobile phone connected to a cell tower should get a /48 because it might have a LAN behind it. He points to IEEE 802.15.4 deployment in the Home Area Network, which is generally a mesh network technology. To turn it into a traditional network, it will need a lot of subnets. But it will need a lot more than that. Zigbee SEP 2.0 isn't a traditional IP network, and a 3GPP or LTE mobile phone with a LAN behind it isn't a gateway into anything that requires O(2^16) subnets to describe it.
>
> What I, were I an ISP, would want to do is provide my customers with a set of addressing capabilities at different price points. I certainly get that with respect to bandwidths and other service offerings. I would like to avoid deployment of residential/SOHO /64's, and I would like to avoid residential deployment of stateful NAT as we have done with IPv4 - address amplification is not needed in IPv6 and NAT technology has closed a lot of markets it's in the ISP's interest to open. I don't see any problem with my ISP giving me options at /60, /56, /52, and /48 as part of various connection packages at various price points. And if I am a truly low end user and don't have a router in my home - I am deploying an Ethernet switch or wireless on the ISP access LAN - I don't see any reason why my devices couldn't be endpoints in that access subnet if the ISP wanted to see it that way.

So from an ARIN policy perspective, without making a massively 
complicated policy that accounts for all of those different sizes, we 
need to assume an ISP's customers could all have /48s.  Right?  Beyond 
that, multi-site customers in theory could have a /48 per site in their 
network.

I don't want ARIN policy dictating /48s per site to the ISPs, but it 
needs to allow for it.  Also, I think it is best if we can avoid 
embedding technology specifics limits into ARIN policy, like mobile ISPs 
can only have a /60 per customer.   However, we can't realistically do 
that for 6rd.  This is especially true, if ISPs wants to encode the full 
32 bit IPv4 address in the IPv6 address.  A /56 is about the most that 
can reasonably be allowed for with 6rd with the full 32 bit IPv4 
address, which comes out to a /24.

More generally, if you have any good ideas how we can make policy for 
ARIN that doesn't essentially set the upper bounds for what ISPs can do, 
I love to hear them.

> If I were ARIN, I would tell my members that they should presume that their customers would appreciate a range of service offerings such as I described, and that the measure of how well they have used their IPv6 prefix will take into account the mechanisms they use to allocate it. Example, if one is looking for a new prefix, one has an old prefix that has been divided into /48, /52, /56, and /60 components, and the issue is that the /60 component is close to being used up, ARIN isn't going to force the ISP to renumber its customers before it can get the next chunk.
>
> I *would* recommend to ARIN that when it allocate a /32 to a member, it internally allocate a shorter prefix, so that the next allocation can turn the prefix into a /31 or whatever. And I *would* recommend that the initial allocation be sized based on the size of the member's existing IPv4 allocation - if the member can't describe their existing IPv4 network using the initial IPv6 allocation, the result is ARIN's fault, not the member's. But those points are probably not relevant to this discussion.

Essentially that is the current policy, but that doesn't work for 6rd, 
at least the way most ISPs want to deploy it, with the full 32 bit IPv4 
address encoded in the IPv6 address.   So if you provider customers 
/60s, ISPs need /28s, or /56s for customers, ISPs need /24.   After that 
I start getting week in the knees. :)

> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.


-- 
===============================================
David Farmer               Email:farmer at umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota	
2218 University Ave SE	    Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================