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

[Owen DeLong]

On Oct 14, 2010, at 3:18 PM, Mark Townsley wrote:

> On 10/14/10 11:48 PM, Owen DeLong wrote:
>> 
>> 
>> On Oct 14, 2010, at 2:36 PM, Mark Townsley wrote:
>> 
>>> On 10/14/10 11:06 PM, Owen DeLong wrote:
>>>> 
>>>> 
>>>> On Oct 14, 2010, at 1:51 PM, Lorenzo Colitti wrote:
>>>> 
>>>>> On Thu, Oct 14, 2010 at 8:02 AM, Owen DeLong <owen at delong.com> wrote:
>>>>> If you can get 6rd to fit in  single /16, then, perhaps we could consider allowing it to be permanent.
>>>>> 
>>>>> However, if ~3,000 ARIN members deploy 6rd /24s, then, you're talking about the vast majority of an entire /12 just in the ARIN region.
>>>>> 
>>>>> Why not we make it a /28, and thus give the customer a /60? The customer still gets 16 subnets for his house, and when 6rd goes away (since, as you point out there are other disadvantages beyond address space use compared to native IPv6), then the subnet will be /56 (since, following your reasoning, that is what competitors with native IPv6 access will be providing).
>>>>> 
>>>> /60s are horrible... They completely stifle any ability for the customer to do PD-based topology
>>>> within the site.
>>> I think you are assuming what the PD-based topology mechanisms are going to be. They haven't really been designed, and certainly haven't been coded and shipped yet. All we are doing at this point is providing a playing field. Within that field:
>>> 
>>> /60 is an *enormous* improvement over /64. Night and day.
>>> 
>>> /56 is certainly better than /60, but not night and day as with /64 and /60. 
>>> 
>>> The point here is that if we design home routing and PD for 2^4 subnets, it's not hard to take that and extend it for 2^8 or 2^16. Not so if you are starting with 2^1.
>>> 
>> With all due respect, I must strongly disagree here. Whatever we decide here will likely impact and set the standards by which home gateways are designed going forward.
>> 
>> We agree that /64 is a non-starter.
>> 
>> I strongly believe that the target should be /48.
> Aren't ARIN's own guidelines:
> 
> "/56 for small sites, those expected to need only a few subnets over the next 5 years."
> 
Yes. That's a guideline that was passed early on. In fact, it's one I supported at the time.

We all make mistakes as we learn. 

> But I suppose you will explain to me why that text doesn't say what I think it says.
> 
Nope... It says what you think it says. However, note also that the IETF recommendation
is /48 and that ARIN does allow for /48 to all end sites regardless of size.

> In any case, based even on what I am hearing from folks with large-scale native plans in place, I wouldn't hold my breadth that your target will be reached. 
> 
Well... I think the largest end-user base on IPv6 today (outside of some private cable networks in Japan) is giving any customer that requests one a /48.

It's at least a start.

You really should have a conversation with Tony Hain about the reasons he thinks /56 is a bad idea.
He makes a pretty compelling case.

>> That 6rd has such terrible deficiencies in its use of address space that we cannot afford /48 and therefore must compromise to /56.
>> 
>> Further compromising to /60 runs the risk of that becoming a de facto industry standard which will potentially be very difficult to overcome.
> You are worried about /60 when the real worry is /64. 

I'm worried about both /60 and /64.

>> 
>> 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.
> 
>>> Consumer products will be designed to operate within the lowest common denominator of the above. If we can make that /60 vs. /64, that's a big win and we might see some potential for upsell into /56 for "bigger home networks". But, if we have to do a ton of work to make networks work within a single /64 anyway, once we have done that, it's hard to argue for supporting multiple subnets as well. I'm trying to avoid having to do the work at all for /64, but that can only happen if I know the minimum number of subnets in the home is greater than 1. 
>>> 
>> That is, indeed, the source of my concern. If consumer products are developed only to the lowest common denominator,
>> we risk establishing /60 as that point. /56 is bad enough. As I have said, we should strongly encourage /48 as the
>> standard around which development occurs while recognizing /56 as a necessary limitation of 6rd.
> /60 could at least have the same type of design as /56 and operate within both with different scaling levels. Supporting /64, even for the simple day one task of a guest and local SSID, is so radically different that this couldn't happen. 
> 
I have never supported /64. I'm not sure why you keep coming back to that.

For some time, now, I have advocated /48. In this conversation I've accepted the reality that /48s are not feasible
with 6rd due to the incredible waste in 6rd addressing. As such, I think /56 is the best available compromise for
6rd.

> There is step function of complexity at /64. 
> 
No argument. I've NEVER supported the idea of /64 for end sites.

>> 
>> I don't think we are disagreeing here, and I don't think anyone is advocating /64s. The AC has approved and forwarded
>> to last call policy which enables /56s for 6rd, but, encourages treating those as temporary and transitional in nature.
>> I think this is the best compromise.
> I'm not going to stand in the way of /24 for 6rd, but if it comes with a ton of strings attached, I'd rather see a less encumbered /28. 
> 
I won't support any size prefix less encumbered than the current draft policy sent to last call by the AC.
The encumbrances stated are due to the nature of 6rd and not the prefix size.

Owen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101014/9a8d7c83/attachment.htm>