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

[Fred Baker]

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 subnets 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.

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.