Re: draft-ietf-v6ops-6to4-to-historic (yet again)

I support this proposal, for the following reasons:

1. Google's public IPv6 adoption data [1] shows that from the perspective of
a website, 6to4 is a tiny and decreasing percentage of IPv6 clients.
2. Geoff Huston's data, presented at v6ops in Prague, shows that 6to4
failure rate when connecting to dual-stack destinations is approximately
20%.
3. Large website operators such as Google, Yahoo, and Facebook have data
that show that 6to4 is an important reason for a large percentage of
dual-stack brokenness, and that dual-stack brokenness is the main reason why
their websites do not have IPv6 records today. Lack of IPv6 content is one
of the reasons most often cited by access networks when explaining the lack
of IPv6 deployment to end users.
4. A number of home gateway manufacturers are still coming out with new
devices that support 6to4 and even enable it by default when IPv6 is
enabled. Declaring 6to4 it to be historic would help ensure that those
manufacturers disable 6to4 in future products.
5. The advent of large-scale NAT will decrease the applicability of 6to4.
6. The advent of ISPs assigning bogon address space to users will
substantially
7. For those who want to do application development using IPv6, there are
alternatives to 6to4, such as manually configured tunnels. These are readily
available, work behind NATs, and in many cases offer lower latency and
higher reliability.

[1] http://www.google.com/intl/en/ipv6/statistics/

On Tue, Jul 26, 2011 at 09:47, Ronald Bonica <rbonica(_at_)juniper(_dot_)net> 
wrote:

> Brian,
>
> Does the following text work for you?
>
>                         Ron
>
>
> N. Meaning of HISTORIC
>
> For the purposes of this document, the term HISTORIC means:
>
> - 6-to-4 should not be configured by default on any implementation (host,
> cpe router, other)
>
> - Vendors will decide which future versions of their products will support
> 6-to-4. It is assumed that vendors will continue to support 6-to-4 until a)
> they are no longer economically incented to do so and b) they are
> economically incented to remove unused features from their products.
>
> - Operators will decide when to decommission 6-to-4 relays, if ever. It is
> assumed that operators will continue to operate 6-to-4 relays as long as
> they are economically incented to do so. When 6-to-4 traffic levels reach
> zero, operators will probably begin to consider decommissioning.
>
> The status of RFCs 3056 and 3068 should not be interpreted as a
> recommendation to remove 6-to-4 at any particular time.
>
>
> > -----Original Message-----
> > From: Brian E Carpenter 
> > [mailto:brian(_dot_)e(_dot_)carpenter(_at_)gmail(_dot_)com]
> > Sent: Monday, July 25, 2011 11:09 PM
> > To: Ronald Bonica
> > Cc: ietf(_at_)ietf(_dot_)org
> > Subject: Re: draft-ietf-v6ops-6to4-to-historic (yet again)
> >
> > To be clear, I'd like to see exact proposed text before expressing
> > support for the proposal. The trick is to get 6to4 disabled by default
> > at the user end, without disabling it for users who are getting good
> > service from it.
> >
> > Regards
> >    Brian
> >
> > On 2011-07-26 09:49, Brian E Carpenter wrote:
> > > >  Likewise, operators will decide whether/when 6-to-4 relays will be
> > removed from their networks.
> > > This is, of course, an undeniable statement of fact (as it is for any
> > other feature
> > > of the Internet). However, it needs to be made clear that doing so
> > *prematurely*
> > > would penalise existing successful users of those relays, and
> > therefore it should
> > > only be done when there is no successful traffic through them. Which
> > is when any
> > > operator would remove them anyway.
> > >
> > > Therefore, I don't see much value in this statement, and possible
> > harm to users.
> > > The ways to avoid such harm as far as possible are already in the RFC
> > Editor
> > > queue.
> > >
> > > Regards
> > >    Brian Carpenter
> > >
> > > On 2011-07-26 02:30, Ronald Bonica wrote:
> > > > Folks,
> > > >
> > > > After some discussion, the IESG is attempting to determine whether
> > there is IETF consensus to do the following:
> > > > - add a new section to draft-ietf-v6ops-6to4-to-historic
> > > > - publish draft-ietf-v6ops-6to4-to-historic as INFORMATIONAL
> > > >
> > > > draft-ietf-v6ops-6to4-to-historic will obsolete RFCs 3056 and 3068
> > and convert their status to HISTORIC. It will also contain a new
> > section describing what it means for RFCs 3056 and 3068 to be
> > classified as HISTORIC. The new section will say that:
> > > > - 6-to-4 should not be configured by default on any implementation
> > (hosts, cpe routers, other)
> > > > - vendors will decide whether/when 6-to-4 will be removed from
> > implementations. Likewise, operators will decide whether/when 6-to-4
> > relays will be removed from their networks. The status of RFCs 3056 and
> > 3068 should not be interpreted as a recommendation to remove 6-to-4 at
> > any particular time.
> > > > draft-ietf-v6ops-6to4-to-historic will not update RFC 2026. While it
> > clarifies the meaning of "HISTORIC" in this particular case, it does
> > not set a precedent for any future case.
> > > > Please post your views on this course of action by August 8, 2011.
> > Ron Bonica
> > > >
> > <speaking as OPS Area AD>
> > > > _______________________________________________
> > > > Ietf mailing list
> > > > Ietf(_at_)ietf(_dot_)org
> > > > https://www.ietf.org/mailman/listinfo/ietf
> _______________________________________________
> Ietf mailing list
> Ietf(_at_)ietf(_dot_)org
> https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf