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

Tony Hain alh-ietf at tndh.net
Thu Oct 14 20:11:00 EDT 2010


This entire thread is basically hot air swirling after more hot air......
While more traffic is good, this noise is a waste of everyone's time.

 

1)            The 6rd policy needs to be really simple and easy to get NOW.

2)            Assuring it goes away at some point requires appropriate
feedback to drive people away from it as soon as they can move.

 

Satisfying both of those should be easy. Establish a policy that says anyone
with IPv4 can get an IPv6 prefix between /16 & /24 as they see fit, then set
a  proportional fee schedule with a *substantial* escalation factor over
time.  

 

You don't need sunset clauses in the policy, and you don't need to
complicate things by obsessing about 'waste'. What you do need is a policy
that enables deployment TODAY. For those that need 6rd because they didn't
get their act together to enable a dual-stack infrastructure, there is a
cost to that delay, and the cost continues to grow until they get past their
legacy equipment. 

 

The hardest part of that approach is that the fee for a provider that is
offering dual-stack /48 to each customer should be substantially less than a
6rd deployment offering /60. It is not ARIN's role to define end  product
offerings, so differentiating the fee schedule for 2 ISPs requesting a /28
based on how they plan to use it is probably out of the question. That said,
financial backpressure will be much more effective than any proscriptive
language that makes it past ppml. We just need to make sure that there are
no unintended consequences related to consumer network innovation due to big
players opting for blocks that are too small.

 

Tony

 

 

From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
Behalf Of Owen DeLong
Sent: Thursday, October 14, 2010 2:49 PM
To: Mark Townsley
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] Opposed to 2010-9 and 2010-12

 

 

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

 

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.

 

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.

 

Owen

 

- Mark



 

I would point out that the only ISP I am aware of that is conducting
residential trials of IPv6 seems to be talking about giving only a /64 to
the home by default due to CPE issues. To me, that is a much greater problem
than having a /60 instead of a /56, because with a /64 you can't do any
subnetting at all.

 

True... /64 should be even more discouraged than /60, but, the reality is
that we should look at

/56 as a temporary expedient due to inefficiencies in 6rd and consider /48
the norm.

 

Owen

 

 

 

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


More information about the ARIN-PPML mailing list