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

[Owen DeLong]

On Oct 13, 2010, at 9:59 AM, Leo Bicknell wrote:

> In a message written on Wed, Oct 13, 2010 at 06:38:14PM +0200, Mark Townsley wrote:
>> If you don't like /56, wait until you have tasted /64. That is what is
> 
> I would be fine with requiring 6rd to provide a /64, while keeping
> the standard that native connections get a /48.  This provides
> incentive to the end user to pressure their ISP to move from 6rd
> to native, and/or to switch providers to one with native connectivity.
> 
More likely it provides the lasting impression that /64s are the normal
subscriber allocation and breaks significant possible innovation.
My complaint about /56s was that they are too small, not that they
are too large.

> Given the realities of 6rd needing 32 bits to map IPv4 into this
> doesn't seem like such a bad thing.
> 
I say we swallow hard and let 6rd eat something approaching a /12
of /24s handed out to providers to facilitate /56s. Hopefully the fact that
/56 is not /48 will eventually lead to the deprecation of 6rd in favor of
native IPv6, but, at least we aren't completely breaking end user
innovations in favor of unnecessary address conservation.

>> On one hand, you accept that some ISPs are stuck and need 6rd to deploy
>> IPv6 now, but on the other hand you are saying that the community (i.e.,
>> the ISP's competitors) have the power to rip their IPv6 deployment out
>> from under them at any time. I know you want to be sure that 6rd goes
>> away, but this is still throwing the baby out with the bathwater.
> 
> I too want to be sure the community can make 6rd go away, because
> it is amazing waste of bits, and mapping all the old trash into 6rd
> space.  Still, you make a valid point, no one should want to deploy
> something that could be ripped out from under them at any time.
> 
Noone should WANT to deploy 6rd. It's one of those things that we
swallow hard, hold our noses, and deploy as a hot-fix until our
vendors catch up and provide working IPv6 last mile technologies.

Once the vendors catch up, we should all want to rip it out as quickly
as practicable. Not just because it's a huge waste of bits (in fact, that's
among the least of its issues IMHO).

> I would support making all 6rd prefixes have a minimum lifetime,
> perhaps 7-10 years (which should cover even the longest equipment
> refresh cycles), after which the community can pull support at any
> time.  That way 6rd users have a guaranteed minimum, it can easily
> be extended (by the community doing nothing and letting them keep
> going), and the community can still pull the plug on this waste.
> 
The pulling of support won't come in the form of an ARIN decision,
it will come in the form of providers deciding to filter the prefixes
that were dedicated to 6rd.

> "ARIN will demand the return of all 6rd prefixes when the prefix is no
> longer in use for 6rd services, or when the community decides that 6rd
> is no longer a benefit to the community.  This cannot occur before
> January 1st, 2020."
> 
ARIN demand for return is pretty irrelevant to the equation.

Owen