Subject: [v6ops] 6to4-historic summary point: 4. "Phase out plan"

From: Fred Baker <[email-masked]>
Date: Wed, 27 Apr 2011 13:17:32 -0700

> 4. "Phase out plan"
> -------------------
>   - Now that we have an official WGLC, I'm going to repeat what I wrote in a previous thread: this draft should
>     not published in its current form because it sets no standard for network operations without 6to4.
>     A phaseout plan for RFC 3056 and RFC 3068 would be required before I could drop my objections to this draft.
> 
> Action: None.

Does the working group agree with the summarization of the concern? Do we agree with the proposed (in)action?

Reply if the answer is "no", and give a better suggestion.

---

From: "t.petch" <[email-masked]>
Date: Thu, 28 Apr 2011 15:04:32 +0200

----- Original Message -----
From: "Fred Baker" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, April 27, 2011 10:17 PM

> Reply if the answer is "no", and give a better suggestion.

I agree with the inaction, ie my answer is yes, but think that the new paragraph
on 6rd (which I like) is
such a standard and might be called out as such.

Tom Petch

---

From: james woodyatt <[email-masked]>
Date: Thu, 28 Apr 2011 16:08:49 -0700

> Reply if the answer is "no", and give a better suggestion.

For the record, I agree with the characterization of concern quoted above.  I remain opposed to the draft unless action is taken to establish a phaseout plan.  I will now offer "a better suggestion" for why action should be taken.

Among content providers, there is a powerful perception that the continued operation of 6to4 tunnels in the Internet is preventing the transition of their commercial services to general dual-stack IPv6/IPv4 availability.  As content providers continue to stall on making content available over IPv6 as well as IPv4, it has the side effect of starving the service providers and end users of any incentive to upgrade legacy networks to support IPv6.  In short, 6to4 is perceived by content providers to be a show-stopper for their IPv6 transition.

For this reason, I continue to maintain that IETF has a stark choice between only two alternatives:

A) explicitly phase out 6to4 with an aggressive reclamation of the 2002::/16 and 192.88.99/24 prefixes in the default-free zone and the establishment of a new requirement for hosts not to auto-configure interface addresses statelessly with the 2002::/16 prefix;

B) allow continued operation of 6to4 to squelch the supply of IPv6 native content, and thereby create powerful incentives for service providers, large enterprises and equipment vendors to ignore the IPv6 transition altogether.

I prefer option A over option B, and I see no other alternatives.  Ceterum censeo Carthaginem esse delendam.

--
james woodyatt <[email-masked]>
member of technical staff, core os networking

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 29 Apr 2011 11:39:29 +1200

James,

I really think your description is a caricature of the situation.

But I have covered this in, I hope, a constructive and positive way
in draft-ietf-v6ops-6to4-advisory, especially in section 5, so
I will not repeat myself here. However, the measures described there
obviate any need for aggressive destruction of 6to4 infrastructure
for those who are happily using it.

    Brian

On 2011-04-29 11:08, james woodyatt wrote:
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Tore Anderson <[email-masked]>
Date: Fri, 29 Apr 2011 02:04:41 +0200

* james woodyatt

> Among content providers, there is a powerful perception that the
> continued operation of 6to4 tunnels in the Internet is preventing the
> transition of their commercial services to general dual-stack
> IPv6/IPv4 availability.  As content providers continue to stall on
> making content available over IPv6 as well as IPv4, it has the side
> effect of starving the service providers and end users of any
> incentive to upgrade legacy networks to support IPv6.  In short, 6to4
> is perceived by content providers to be a show-stopper for their IPv6
> transition.
> 
> A) explicitly phase out 6to4 with an aggressive reclamation of the
> 2002::/16 and 192.88.99/24 prefixes in the default-free zone and the
> establishment of a new requirement for hosts not to auto-configure
> interface addresses statelessly with the 2002::/16 prefix;

Hi James,

I'm strongly opposed to this alternative. If 2002::/16 and 192.88.99/24
was null-routed everywhere right now, everyone successfully using 6to4
today (intentionally or not) will become a «broken user».

These broken users are what we content providers really hate. We don't
actually hate the 6to4 protocol itself, rather the fact that it is
responsible for so many of those broken users. (Case in point: According
to Geoff, the Teredo protocol is at least as bad as 6to4 in practise,
but since it doesn't really create the broken users 6to4 does you don't
see us getting worked up over it.)

Your proposal A will surely give 6to4 a quick and merciless death, but
at the expense of creating millions of new broken users that won't go
away until all the affected users have replaced their problematic
software and/or hardware. Which would probably take many years. That is
really counter-productive if the goal is to help content providers
deploy IPv6; we want fewer, not more, broken users. The more broken
users there are out there, the more difficult it is for us to deploy IPv6.

Best regards,
-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com/
Tel: +47 21 54 41 27

---

From: Mark Andrews <[email-masked]>
Date: Fri, 29 Apr 2011 13:11:23 +1000

There is third alternative.  Actively contact the address holders
of sites that have embrionic TCP connections from 6to4 address with
the date, time and the embedded IP address.

"
You appear to have a broken 6to4[1] IPv6 connection as we logged
embrionic[2] TCP connections from the following IPv6 address at the
following times.  Please see ... for how to check to see if 6to4
is actually broken for you and some steps that can be taken to fix
it.  Failure to fix this will result in slow network performance
to any site that supports both IPv4 and IPv6.

	<IPv6>  <IPv4> <DATE> <TIME>
	<IPv6>  <IPv4> <DATE> <TIME>
	<IPv6>  <IPv4> <DATE> <TIME>
	<IPv6>  <IPv4> <DATE> <TIME>

[1] <insert reference>
[2] The initial TCP SYN packet (including retries) was recieved at the
    start of the TCP connection but the SYN ACK packet that completes
    the initial TCP handshake to a establish a TCP connection was not
    recieved.
"

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Erik Kline <[email-masked]>
Date: Fri, 29 Apr 2011 13:38:00 +0900

>    the initial TCP handshake to a establish a TCP connection was not

Already asked; not permitted.  I doubt highly if anyone is willing to
weather the privacy shitstorm this would bring down.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 29 Apr 2011 15:11:43 +1000

In message <[email-masked]>, Erik Kline wri
tes:
> > There is third alternative. =C2=A0Actively contact the address holders
> > following times. =C2=A0Please see ... for how to check to see if 6to4
> > it. =C2=A0Failure to fix this will result in slow network performance
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0<IPv6> =C2=A0<IPv4> <DATE> <TIME>
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0<IPv6> =C2=A0<IPv4> <DATE> <TIME>
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0<IPv6> =C2=A0<IPv4> <DATE> <TIME>
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0<IPv6> =C2=A0<IPv4> <DATE> <TIME>
> >
> > [1] <insert reference>
> > =C2=A0 =C2=A0start of the TCP connection but the SYN ACK packet that comp=
> letes
> > =C2=A0 =C2=A0the initial TCP handshake to a establish a TCP connection wa=
> s not
> > =C2=A0 =C2=A0recieved.
> > "
> 

What privacy shitstorm?  This is a push operation.  You are not
asking anyone to reveal anything.  They will either fix the problem
or not.

I report DNS operational issues all the time.  This is really no
different.  Sometimes the nameservers are fixed, sometimes they are
not.

Mark

---

From: Erik Kline <[email-masked]>
Date: Fri, 29 Apr 2011 14:20:20 +0900

> different.  Sometimes the nameservers are fixed, sometimes they are

I think tech-tech and NOC-NOC communications are understandably
different.  If I read your proposal right you will need someone to
contact *end users* about what you're seeing in their traffic.  Some
will understand, and perhaps even appreciate.  But, it's still too
close to tracking and privacy concerns, I fear.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 29 Apr 2011 15:46:18 +1000

In message <BANLkTikPJjUhrm5d3T=J+O7+p6nVpX7c=[email-masked]>, Erik Kline wri
> close to tracking and privacy concerns, I fear.

It would require ISP's to forward the notices or generate their own
as many of the sources would not be directly identifiable from whois
records.  It doesn't however require feedback.

ISP's could do this themselves by looking for SYN and SYN+ACK without
a final ACK to complete the initial handshake in 6to4 encapsulated
traffic on their network.

"As part of program to identify and fix broken IPv6 6to4 connections
...."

Or better still install a IPv6 6to4 relay and send out a message
saying they are doing it to their customers along with a message
saying that they are installing a 6to4 relay to improve their
customer's internet experience and will be looking for customers
with broken 6to4 connections so they can inform them of the problem.

Mark