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

[Owen DeLong]

On Oct 14, 2010, at 5:35 AM, Mark Townsley wrote:

> 
> On 10/14/10 11:23 AM, michael.dillon at bt.com wrote:
>>> If ARIN really wanted to take a step forward towards helping the
>>> quality
>>> of IPv6 deployment on the Internet via deprecation of IPv6 space, it
>>> would start efforts to see 2002::/16 deprecated. First things first.
>> It is none of ARIN's business. That particular allocation was made by
>> the IETF/IANA and is outside of ARIN's control.
> My comment above was in response to the suggestion that ARIN "should
> make strong efforts to communicate and preserve the notion that
> [RFC5969] is a transitional and therefore temporary solution".
> Certainly, if ARIN should "communicate" that RFC 5969 is bad, it should
> do the same for RFC 3056 and 3068.
> 
I think that ARIN has communicated that 6to4 is a temporary transitional
technology and I would not oppose such communication.

> On 10/13/10 11:33 PM, Owen DeLong wrote:
>> I don't think we should deprecate 6to4 any faster than we should
>> deprecate 6rd. In reality, they share pretty much the same level of
>> problems and ugliness.
> That's not what observable data suggests. Broken 6to4 has a measurable
> impact on a broken IPv6 connectivity, and one of the reasons some
> content providers are very hesitant to offer AAAAs 6to4 hosts. That's
> not the case with 6rd. The technology is similar, but how it is deployed
> and operated is very different.
> 
The only difference between the two that is causing that observation
is that clients do not "automatically" engage in 6rd and it is not built
on anycast. In fact, if we were to deploy working 6to4 gateways more
widely, the broken 6to4 issue would pretty much evaporate.

> See:
> 
> http://tools.ietf.org/html/draft-vandevelde-v6ops-harmful-tunnels-01
> 

However, wider deployment of 6to4 (as noted by Comcast) is actually
a better solution to that problem than deprecation of 6to4.

Owen