Subject: [v6ops] Deprecating 2002::/16 - 6to4 Historic Status

From: Christopher Palmer <[email-masked]>
Date: Wed, 6 Apr 2011 22:43:37 +0000

In  "Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status"

There is this recommendation:

IANA is requested to mark the 2002::/16 prefix as "deprecated",
   pointing to this document.  Reassignment of the prefix for any usage
   requires justification via an IETF Standards Action [RFC5226].

It is not clear why this is necessary.

If major vendors were to disable 6to4 by default, that would fix the brokenness issue, while still allow for this prefix to be used in specialized or enthusiast scenarios. Isn't any other action overkill?

Thanks!
----------------------------
[email-masked]
Program Manager
IPv6 @ Windows

---

From: Carlos Martinez-Cagnazzo <[email-masked]>
Date: Wed, 6 Apr 2011 19:59:26 -0300

I agree with Cristopher's comment. Personally I believe we should fix
what is wrong with 6to4 (mostly the anycast part), and make it more
manageable from an operators point of view rather than just dispose of
what can be a very valuable transition tool.

regards

Carlos

On Wed, Apr 6, 2011 at 7:43 PM, Christopher Palmer
<[email-masked]> wrote:
> In  “Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to
> Historic status”
>
>
>
> If major vendors were to disable 6to4 by default, that would fix the
> brokenness issue, while still allow for this prefix to be used in
> specialized or enthusiast scenarios. Isn’t any other action overkill?
>
>
>
> Thanks!
>
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>
>

-- 
--
=========================
Carlos M. Martinez-Cagnazzo
http://www.labs.lacnic.net
=========================

---

From: Erik Kline <[email-masked]>
Date: Wed, 6 Apr 2011 23:13:24 +0000

Were you able to watch Geoff Huston's presentation?  It generally addressed
these misconceptions.

---

From: james woodyatt <[email-masked]>
Date: Wed, 06 Apr 2011 16:15:12 -0700

> It is not clear why this is necessary.

Because this draft obsoletes the documents to which IANA currently points for the 2002::/16 prefix.  Not sure what having IANA mark the prefix as "deprecated" is hoped to accomplish... but the rest of the IANA Considerations section is fine with me.

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

---

From: Carlos Martinez-Cagnazzo <[email-masked]>
Date: Wed, 6 Apr 2011 20:21:02 -0300

I was there, but I'm not sure I follow what you mean. If you can be
more specific, I would appreciate it.

---

From: Erik Kline <[email-masked]>
Date: Wed, 6 Apr 2011 23:29:36 +0000

I would refer specifically to the numbers for 6to4 customers where the
return path was directly on the server, i.e. the client-to-server relay was
not a problem (because the SYN packet reached the servers) and the
server-to-client relay was not a problem (because the server was
encapsulating directly).  Even in that scenario the connection completion
rate was abysmal, IIRC.

All of which reinforces the notion that it's not a valuable transition
mechanism.  It's a experimental thing, and plenty useful as such.  But it's
not production quality unless it's fully managed (i.e. it can be confirmed
that no proto41 blocking is going on, etc).  In which case it's basically
6rd or static tunnels.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 07 Apr 2011 10:07:52 +1000

In message <[email-masked]>, Erik Kline wri
> that no proto41 blocking is going on, etc).  In which case it's basically

I suspect that a lot of the problem isn't 6to4 but rather just IPv6.
Just blocking IPv6 in and failing to block IPv6 out will produce
exactly these symptoms.  6to4 is just the working IPv6 path they
have.  The packets do get back to the originating machine where
they are dropped before getting to the application.

Sure there is some protocol 41 filtering and there are some firewalls
that only allow return traffic from the anycast address but I suspect
that if we followed up and found out the actual failure causes in most
cases it isn't 6to4 that is the problem.  6to4 is working fine.  The
packets get out and back to the originating machine.

Sites that have deliberately turned on IPv6 don't have this problem
as the firewalls have been configured to permit IPv6 traffic.

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

---

From: Christopher Palmer <[email-masked]>
Date: Thu, 7 Apr 2011 00:21:25 +0000

It still seems like overkill.

If hosts no longer enable 6to4 by default, this scenario will never occur. There is no need to additionally deprecate the prefix – to essentially turn off 6to4 twice?

What operational value does deprecating the prefix provide?

Best!
Chris

From: Erik Kline [mailto:[email-masked]]
Sent: Wednesday, April 06, 2011 4:30 PM
To: Carlos Martinez-Cagnazzo
Cc: Christopher Palmer; [email-masked]
Subject: Re: [v6ops] Deprecating 2002::/16 - 6to4 Historic Status

I would refer specifically to the numbers for 6to4 customers where the return path was directly on the server, i.e. the client-to-server relay was not a problem (because the SYN packet reached the servers) and the server-to-client relay was not a problem (because the server was encapsulating directly).  Even in that scenario the connection completion rate was abysmal, IIRC.

All of which reinforces the notion that it's not a valuable transition mechanism.  It's a experimental thing, and plenty useful as such.  But it's not production quality unless it's fully managed (i.e. it can be confirmed that no proto41 blocking is going on, etc).  In which case it's basically 6rd or static tunnels.
On 6 April 2011 23:21, Carlos Martinez-Cagnazzo <[email-masked]<mailto:[email-masked]>> wrote:
I was there, but I'm not sure I follow what you mean. If you can be
more specific, I would appreciate it.

---

From: Joel Jaeggli <[email-masked]>
Date: Wed, 6 Apr 2011 18:26:37 -0700

It can't be fixed. You can engage in incremental improvements which you should do (even as it is deprecated), but 6to4 remains a pitfall which hosts that have it enabled will trip over in the dark due to properties of their ipv4 connectivity. A host with a public but natted v4 address will alwas get hosed by this.

Joel's widget number 2

---

From: Christopher Palmer <[email-masked]>
Date: Thu, 7 Apr 2011 01:38:29 +0000

"A host with a public but natted v4 address will alwas get hosed by this."

A host in that condition will have a broken 6to4 address, but won't experience a degradation in their web experience if they have RFC 3484 implemented. 

So really this would be the third proposed 6to4 mitigation:

1. Ensuring that IPv4->IPv4 is ranked higher than 6to4->IPv6 in the RFC 3484.
2. Changing default host behavior. (still being debated)
3. Deprecation of the prefix.

Given (1) and (2), the operational value of 3 is still lost on me. Is the expectation that ISPs stop routing 6to4 packets? Is this a signal that we don't just hate 6to4, but we super hate it?

Chris

-----Original Message-----
From: Joel Jaeggli [mailto:[email-masked]] 
Sent: Wednesday, April 06, 2011 6:27 PM
To: Carlos Martinez-Cagnazzo
Cc: Erik Kline; [email-masked]; Christopher Palmer
Subject: Re: [v6ops] Deprecating 2002::/16 - 6to4 Historic Status

Joel's widget number 2

---

From: Doug Barton <[email-masked]>
Date: Wed, 06 Apr 2011 20:19:44 -0700

> Given (1) and (2), the operational value of 3 is still lost on me. Is the expectation that ISPs stop routing 6to4 packets? Is this a signal that we don't just hate 6to4, but we super hate it?

You're attaching emotion to something that is purely a technical issue. 
2002::/16 is prominently located in the global unicast block (arguably a 
mistake to start with) and therefore IANA needs explicit instructions 
that it should not be allocated for any other purpose until a suitable 
"cooling off" period. I'd say about 50 years ought to do it. :)

Marking it deprecated for use on the public Internet doesn't prevent 
someone else from using the range for private purposes, as you alluded 
to in your first post.

hth,

Doug

-- 

	Nothin' ever doesn't change, but nothin' changes much.
			-- OK Go

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/

---

From: Christopher Palmer <[email-masked]>
Date: Thu, 7 Apr 2011 04:29:24 +0000

So, a 6to4 client will experience no change in their 6to4 experience. Relays will still be as available and routable (or not) as they are today?

I'm very green in terms of IETF participation, so I apologize if my requests for clarity concerning this matter are entirely foolish. 

(1) It would be good to indicate that the anycast prefix and general routing of 6to4 relays would be unchanged by this proposal. From this conversation it would appear that is the case.

This line is comforting:
" In order to limit the impact of end-users, it is recommended that operators retain their existing 6to4 relay routers..."

Maybe a bit more would be nice? 

(2) It would be nice to indicate that Intranets can still use 6to4 addressing (section 5.9 of RFC 3056). 

I again apologize for being pedantic, but 6to4 is not a "non-feature" from our perspective. 

I'm fairly concerned about pulling out the rug on the arguable small, but certainly enthusiastic group of folks who intentionally use 6to4 as a method of enjoying the growing IPv6 Internet. Making them opt-in is one thing, just killing the technology entirely and immediately is a more hairy idea.

Best!
Chris

-----Original Message-----
From: Doug Barton [mailto:[email-masked]] 
Sent: Wednesday, April 06, 2011 8:20 PM
To: Christopher Palmer
Cc: Joel Jaeggli; Carlos Martinez-Cagnazzo; [email-masked]
Subject: Re: [v6ops] Deprecating 2002::/16 - 6to4 Historic Status

hth,

Doug

--

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 7 Apr 2011 07:16:39 +0200 (CEST)

On Thu, 7 Apr 2011, Christopher Palmer wrote:

> I'm fairly concerned about pulling out the rug on the arguable small, 
> but certainly enthusiastic group of folks who intentionally use 6to4 as 
> a method of enjoying the growing IPv6 Internet. Making them opt-in is 
> one thing, just killing the technology entirely and immediately is a 
> more hairy idea.

I don't think there is consensus to kill it. The consensus is that 
preferring 6to4 above IPv4 is bad right now (and in the forseeable 
future).

My preference as to what should happen are in the order of preference 
(this is Microsoft Windows Vista and Win7 specifically):

1. Fix ICS (quickly) so that it doesn't send out RA on the WAN interface. 
Stop by default issuing AAAA queries if only connectivity is 6to4 (but 
make it configurable). Still prefer IPv4 over IPv6. Keep 6to4 on, just 
like teredo.

2. Turn off default turned on 6to4 by means of a quick patch, make it 
configurable so user can turn it on again. Fix ICS and preference a bit 
later.

3. Kill Windows 6to4 totally by means of removing A record. If possible, 
make workaround so user can enter 192.88.99.1 manually somewhere if they 
want to enable it.

If 1 and 2 can't be done before IPv6 day, I'd prefer 3. 1 and 2 needs to 
be high enough priority that Windows Update installs it automatically.

I want operators to keep their 6to4 relays up and running for at least 1-2 
years still, I agree that users should be migrated off of 6to4 first, THEN 
we remove the infrastructure when most of them are gone.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Doug Barton <[email-masked]>
Date: Wed, 06 Apr 2011 22:32:59 -0700

On 4/6/2011 10:16 PM, Mikael Abrahamsson wrote:
> preferring 6to4 above IPv4 is bad right now (and in the forseeable future).

I think moving it down the list is the absolute minimum. My preference 
personally is that it be killed, but I'm interested in arguments that 
people might have about what benefits it can provide here and now.

Doug

--

---

From: Tore Anderson <[email-masked]>
Date: Thu, 07 Apr 2011 09:41:52 +0200

Hi Mikael,

* Mikael Abrahamsson

> 1. Fix ICS (quickly) so that it doesn't send out RA on the WAN

IMO, fix *any* router or «internet sharing» implementation that sends
out RAs without having a proper native IPv6 prefix available for this
purpose (for example from DHCPv6-PD). Including, but not limited to, RAs
with a 6to4 Prefix Information Option, a site-local PIO, and with no PIO.

In a nutshell, if there's no IPv6 connectivity to share in the first
place, don't attempt to magically conjure one up.

Windows ICS is certainly not the only implementation that does this, but
I suspect it's the most ubiquitous one.

> 3. Kill Windows 6to4 totally by means of removing A record.

Doesn't work - see my recent message to the 6to4-advisory thread.

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

---

From: Pekka Savola <[email-masked]>
Date: Thu, 7 Apr 2011 10:44:17 +0300 (EEST)

> Given (1) and (2), the operational value of 3 is still lost on me. Is the expectation that ISPs stop routing 6to4 packets? Is this a signal that we don't just hate 6to4, but we super hate it?

This will require an update in the RFC 3484 implementation.  Maybe 
this is what you meant, or maybe not.

Joel is probably referring to this:

http://tools.ietf.org/html/draft-ietf-6man-rfc3484-revise-02#section-2.4

(This issue has a lot of history -- known for some 7-8yrs, see 
http://tools.ietf.org/html/draft-ietf-v6ops-v6onbydefault-03#section-2.1)

If I understand this correctly:

The NAT44ting/6to4 gateway has public IP 1.1.1.1 (WAN)
It is advertising 2002:0101:0101:0::/64 out on LAN.
It is doing NAT on LAN.

Hence, hosts behind such gateway have IPv6 address 
2002:0101:0101:0::EUI64 and 192.168.1.1.

When connecting to a dual-stack server with IP addresses 2.2.2.2 and 
2001:db8::1.

It will use 6to4 instead of IPv4 through NAT. FAIL.

If the client would have had IP address 1.1.1.2 and 
2002:0101:0101:0::EUI64, with (current) RFC3484 implementation, it 
would have preferred IPv4 instead of 6to4.

So, there are are really two layers of RFC3484 brokenness:

  1) not implemented at all
  2) 6to4 is used if v4 has mismatching scope (private->public)

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 07 Apr 2011 19:58:33 +1200

On 2011-04-07 15:19, Doug Barton wrote:
>> A host in that condition will have a broken 6to4 address, but won't
>> experience a degradation in their web experience if they have RFC 3484
>> implemented.
>>
>> Given (1) and (2), the operational value of 3 is still lost on me. Is
>> the expectation that ISPs stop routing 6to4 packets? Is this a signal
>> that we don't just hate 6to4, but we super hate it?
> 

The essential point is that the IANA listing should refer to the new
RFCs and not just to RFC 3056 and 3068. I think it's OK to use the
word 'deprecated' - that doesn't mean forbidden. Nobody should be
slapping on arbitrary route filters as a result - they should be doing
what the -advisory- draft suggests, which is to proactively manage the
routing of the deprecated prefixes.

BTW, classful addressing was deprecated 18 years ago (RFC 1519) but there
are still plenty of people who use the A,B,C terminology. I don't think we
need to worry about deprecation of 2002::/16 having immediate effect on
the running network.

    Brian

---

From: Ole Troan <[email-masked]>
Date: Thu, 7 Apr 2011 10:04:38 +0200

Chris,

are you happy with the use of "deprecate" given the explanations provided in this thread?

not to forego matters, but I think we have managed to get a time slot in the chair's busy WGLC schedule, so there would be another opportunity to discuss this before sending the document onwards.

cheers,
Ole

> In  “Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status”
>  
> If major vendors were to disable 6to4 by default, that would fix the brokenness issue, while still allow for this prefix to be used in specialized or enthusiast scenarios. Isn’t any other action overkill?
>  
> Thanks!

---

From: Dmitry Anipko <[email-masked]>
Date: Thu, 7 Apr 2011 01:15:16 -0700

Hi Pekka,

>> When connecting to a dual-stack server with IP addresses 2.2.2.2 and 
2001:db8::1.It will use 6to4 instead of IPv4 through NAT. FAIL.
>>  2) 6to4 is used if v4 has mismatching scope (private->public)

Windows implementation treats RFC 1918 prefixes as public, specifically due to this reason, so on Windows, in this scenario v4->v4 is preferred over 6to4->native v6.

Thank you,
Dmitry

---

From: Roger Jørgensen <[email-masked]>
Date: Thu, 7 Apr 2011 10:29:36 +0200

> what can be a very valuable transition tool.

6to4 cause problem with IPv6 and is/will be seen as a problem, maybe
even showstopper for some not-so-technical people wanting to
implementy IPv6.

I would think it is a very good idea to make it deprecated so everyone
can see that we have done something with the problem.

... and on the more technical side, lots of other people have given
their input on why.

-- 

Roger Jorgensen           |
[email-masked]          | - IPv6 is The Key!
http://www.jorgensen.no   | [email-masked]

---

From: Tore Anderson <[email-masked]>
Date: Thu, 07 Apr 2011 10:45:41 +0200

Hi Chris,

* Christopher Palmer

> So, a 6to4 client will experience no change in their 6to4 experience.
> Relays will still be as available and routable (or not) as they are
> today?
> 
> I'm very green in terms of IETF participation, so I apologize if my
> requests for clarity concerning this matter are entirely foolish.
> 
> (1) It would be good to indicate that the anycast prefix and general
> routing of 6to4 relays would be unchanged by this proposal. From this
> conversation it would appear that is the case.
> 
> This line is comforting:

> " In order to limit the impact of end-users, it is recommended that
> operators retain their existing 6to4 relay routers..."
> 

The document you're looking for is I-D.ietf-v6ops-6to4-advisory.

The point of the 6to4-to-historic document is not to tell operators to
immediately shut off all relays, drop all proto-41 traffic, and
null-route 2002::/16 and 192.88.99.0/24. It is not intended to pull the
rug out from under anyone.

The point is to send a clear message that the technology has problems
that won't/can't get properly fixed, and that vendors are therefore
discouraged from implementing it in any new products (especially in a
on-by-default fashion).

The expectation is that eventually, (almost) all of the 6to4 users have
gone away voluntary, either because they have replaced their old
hardware/software with newer stuff that do not implement 6to4 [by
default], or ideally because they have been provisioned with native IPv6
connectivity and no longer have use for it. When 6to4 has fallen into
disuse, then the operators can start shutting off their relays.

In the interim, I-D.ietf-v6ops-6to4-advisory attempts to ensure that the
existing user base will have the best possible service.

> but certainly enthusiastic group of folks who intentionally use 6to4
> as a method of enjoying the growing IPv6 Internet. Making them opt-in
> is one thing, just killing the technology entirely and immediately is
> a more hairy idea.

I'm assuming you're speaking specifically about Windows here, and what
to do with its 6to4-on-by default legacy, so I'll answer specifically.
>From my point of view as a operator of dual-stacked web sites, the local
6to4 adapter being on by default in Windows is largely unproblematic,
due to the fact that all major web browsers are using the
RFC3484-compliant Windows system resolver these days.

(Note, I have absolutely no idea whether or not most other applications,
e.g. MUAs, are all using the system resolver or if they would get into
6to4-related problems connecting to dual-stacked SMTP/IMAP servers.)

However, the ICS behaviour of sharing the on-by-default 6to4
connectivity (or non-connectivity) is *very* problematic, along with all
the other RA types it transmits by default (site-local PIO and no PIO).
Especially in flat layer-2 campus style networks with unmananged clients.

So, a Windows Update that changes ICS to not send out RAs *at all*
(unless the Windows host in question has *native* IPv6 connectivity to
share of course), would be an absolute godsend. At least make it
configurable, and make the setting default to off. There is already some
precedent for doing so - both Cisco Linksys and Apple has recently done
so in software updates for their respective home router products.

In Windows 8, however, I hope you disable 6to4 by default. :-)

Best regards,

---

From: Mohacsi Janos <[email-masked]>
Date: Thu, 7 Apr 2011 10:56:09 +0200 (CEST)

On Thu, 7 Apr 2011, Dmitry Anipko wrote:

> Windows implementation treats RFC 1918 prefixes as public, specifically 
> due to this reason, so on Windows, in this scenario v4->v4 is preferred 
> over 6to4->native v6.

Same for FreeBSD, OpenBSD and NetBSD.

---

From: Tore Anderson <[email-masked]>
Date: Thu, 07 Apr 2011 11:07:30 +0200

Carlos,

* Carlos Martinez-Cagnazzo

> Personally I believe we should fix what is wrong with 6to4 (mostly
> the anycast part)

The unicast part is also broken.

Last year I was measuring the dual-stack brokenness levels in the
Norwegian end-user population. Someone suggested to me to try to take
the 6to4 anycast brokenness out of the equation, which I tried to do by
«triple-stacking» the web server, going from:

dualstack.api.no. A 87.238.40.2
dualstack.api.no. AAAA 2a02:c0:1010:2::2

To:

dualstack.api.no. A 87.238.40.2
dualstack.api.no. AAAA 2002:57ee:2802::1
dualstack.api.no. AAAA 2a02:c0:1010:2::2

This shifted the traffic from the 6to4-enabled end users from using the
anycast relays, to using the original unicast «router 6to4». The result
was that the overall measured brokenness increased about ten-fold (from
around 0.03% to 0.3%).

Make sure to also check Geoff Huston's «Stacking it up» presentation,
he's confirmed a huge failure rate (~15% IIRC) in the situation where he
see a TCP SYN come in from a 6to4 client (so it's known that the inbound
relay is working), and when he runs a local return relay (so it's known
that the outbound relay is working too).

After having spent two years doing everything I can think of in my power
to «fix» the operational problems 6to4 is causing me, I've come to the
conclusion that it's simply not possible.

Best regards,

---

From: Nicolas Antoniello <[email-masked]>
Date: Thu, 7 Apr 2011 11:02:31 -0300

Dear all,

I believe this discussion has as technical as non-technical points to
consider... but just to clarify myself:
Why setting the 2002::/16 as "deprecated" (whether this mean that it can be
re-assigned or not) when we are still selling PCs OSs and router OSs with
6to4 support; and no talking about the bunch of 6to4 still working out
there.

Why don't (in case it could not be fixed) first stop supporting 6to4 (at
least put it at the bottom of the OS options for transition mechanisms),
wait a relative prudent time, and then (just then) "deprecate" the prefix?

I have the sense we are putting the carriage in front of the horses here
(why the sudden hurry?).

Opinion?

Best,
Nicolas

On Thu, Apr 7, 2011 at 05:04, Ole Troan <[email-masked]> wrote:

> not to forego matters, but I think we have managed to get a time slot in
> the chair's busy WGLC schedule, so there would be another opportunity to
> discuss this before sending the document onwards.
>
> cheers,
> Ole
>
>
>

---

From: Carlos Martinez-Cagnazzo <[email-masked]>
Date: Thu, 7 Apr 2011 12:05:12 -0300

Well put Erik, I agree with you. If we take out (most) of the
automatic part it ceases to be 6to4.

---

From: "George, Wes E [NTK]" <[email-masked]>
Date: Thu, 7 Apr 2011 15:19:00 +0000

I fail to see the connection between leaving the prefixes alone but deprecating the protocol. Either it's considered a supported
protocol (including its defined well-known prefixes) or it’s not. Doing something with the prefixes later doesn’t change that,
because that’s largely a record-keeping exercise on IANA’s part.
I think you’re putting too much emphasis on the importance of the prefixes themselves, and are making a bigger deal out of
deprecation than is necessary. Deprecation != unceremonious shutdown, and there’s no internet police that will show up if you choose
to continue using it. We’re simply saying that if it breaks, especially in one of the ways that we already know that it’s likely to
do so, you’re on your own.

http://en.wikipedia.org/wiki/Deprecation
In computer software or authoring programs standards and documentation, the term deprecation is applied to software features that
are superseded and should be avoided. Although deprecated features remain in the current version, their use may raise warning
messages recommending alternative practices, and deprecation may indicate that the feature will be removed in the future. Features
are deprecated—rather than being removed—in order to provide backward compatibility and give programmers who have used the feature
time to bring their code into compliance with the new standard.

Also, we *are* saying in the draft to stop putting out new devices with 6to4 support, and recommending a gradual wind-down of 6to4
relay support so that existing functional implementations are minimally impacted.

As I said at the mic, beyond Geoff’s evidence as to how “well” 6to4 works, 6to4 is about to get broken in a whole series of new ways
because of the prevalence of NAT + non-RFC1918 addresses. It’s in our best interest to try to get ahead of that and say that it is
no longer a recommended method of IPv6 connectivity, or we’ll waste a lot of time trying to fix something that is increasingly
looking unfixable at the expense of real IPv6 deployment. 

Thanks, 
Wes George

From: [email-masked] [mailto:[email-masked]] On Behalf Of Nicolas Antoniello
Sent: Thursday, April 07, 2011 10:03 AM
To: Ole Troan
Cc: [email-masked]; Christopher Palmer
Subject: Re: [v6ops] Deprecating 2002::/16 - 6to4 Historic Status

Dear all,

I believe this discussion has as technical as non-technical points to consider... but just to clarify myself:
Why setting the 2002::/16 as "deprecated" (whether this mean that it can be re-assigned or not) when we are still selling PCs OSs
and router OSs with 6to4 support; and no talking about the bunch of 6to4 still working out there.

Why don't (in case it could not be fixed) first stop supporting 6to4 (at least put it at the bottom of the OS options for transition
mechanisms), wait a relative prudent time, and then (just then) "deprecate" the prefix?

I have the sense we are putting the carriage in front of the horses here (why the sudden hurry?).

Opinion?

Best,
Nicolas

not to forego matters, but I think we have managed to get a time slot in the chair's busy WGLC schedule, so there would be another
opportunity to discuss this before sending the document onwards.

cheers,
Ole

> If major vendors were to disable 6to4 by default, that would fix the brokenness issue, while still allow for this prefix to be
used in specialized or enthusiast scenarios. Isn’t any other action overkill?

---

From: james woodyatt <[email-masked]>
Date: Thu, 07 Apr 2011 11:33:51 -0700

> I'm very green in terms of IETF participation, so I apologize if my requests for clarity concerning this matter are entirely foolish. 

Christopher, this is a Standards Track draft, which means the very first thing you should do when reading it for content is look for all the capitalized normative keywords.  Especially the phrases that use MUST and MUST NOT keywords.  Its intended audience is plainly other IETF participants, and not the makers of Internet equipment, as it places no requirements on them whatsoever.  It makes some non-normative recommendations to operators, that may be relevant, but it doesn't say anything that will show up in an IPv6 Ready certification test.

When I briefed my managers about this draft, I told them that it currently requires us to do absolutely nothing in the foreseeable future, and it explicitly permits us to continue doing what we are doing today.  My reading of the document suggests that you can safely ignore its current form as well.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 08 Apr 2011 19:02:23 +1200

James,

All vendors can choose to ignore all RFCs , if they want to :-)

However, I think we are suggesting that if MS can find a way to patch
existing hosts that will make it less likely that they use 6to4 anycast
unintentionally, that would be a Good Thing. A MUST is not required for
that.

netsh interface ipv6 6to4 set state state=disabled

Regards
   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 08 Apr 2011 19:04:15 +1200

Correct. Actually I don't care whether the prefixes are labelled
'deprecated' or simply 'reserved'. The purpose is to prevent
IANA allocating them for a large number of years.

Regards
   Brian

On 2011-04-08 03:19, George, Wes E [NTK] wrote:
> ------------------------------------------------------------------------
>

---

From: Nicolas Antoniello <[email-masked]>
Date: Fri, 8 Apr 2011 09:12:21 -0300

Hi Wes,

Ok, I think I got your point.
Thanks for the explanation.

Also agree with Bryan: - "The purpose is to prevent
IANA allocating them for a large number of years".

Regards,
Nicolas

On Thu, Apr 7, 2011 at 12:19, George, Wes E [NTK] <
[email-masked]> wrote:

> I fail to see the connection between leaving the prefixes alone but
> deprecating the protocol. Either it's considered a supported
> protocol (including its defined well-known prefixes) or it’s not. Doing
> something with the prefixes later doesn’t change that,
> I think you’re putting too much emphasis on the importance of the prefixes
> themselves, and are making a bigger deal out of
> deprecation than is necessary. Deprecation != unceremonious shutdown, and
> there’s no internet police that will show up if you choose
> to continue using it. We’re simply saying that if it breaks, especially in
> one of the ways that we already know that it’s likely to
> In computer software or authoring programs standards and documentation, the
> term deprecation is applied to software features that
> are superseded and should be avoided. Although deprecated features remain
> in the current version, their use may raise warning
> messages recommending alternative practices, and deprecation may indicate
> that the feature will be removed in the future. Features
> are deprecated—rather than being removed—in order to provide backward
> compatibility and give programmers who have used the feature
> Also, we *are* saying in the draft to stop putting out new devices with
> 6to4 support, and recommending a gradual wind-down of 6to4
> As I said at the mic, beyond Geoff’s evidence as to how “well” 6to4 works,
> 6to4 is about to get broken in a whole series of new ways
> because of the prevalence of NAT + non-RFC1918 addresses. It’s in our best
> interest to try to get ahead of that and say that it is
> no longer a recommended method of IPv6 connectivity, or we’ll waste a lot
> of time trying to fix something that is increasingly
> re-assigned or not) when we are still selling PCs OSs
> least put it at the bottom of the OS options for transition
> the chair's busy WGLC schedule, so there would be another
> brokenness issue, while still allow for this prefix to be

---

From: james woodyatt <[email-masked]>
Date: Fri, 08 Apr 2011 09:12:10 -0700

On Apr 8, 2011, at 12:02 AM, Brian E Carpenter wrote:
> 
> However, I think we are suggesting that if MS can find a way to patch existing hosts that will make it less likely that they use 6to4 anycast unintentionally, that would be a Good Thing. A MUST is not required for that.

An RFC is not required for that.

This draft would send a much stronger signal to implementors if it were to contain language more like what you see in RFC 3701 for phasing out the 6bone.  I draw your attention to this excerpt:

   Thus after the 6bone phaseout date June 6, 2006, it is the intent
   that no 6bone 3FFE prefixes, of any size/length, be used on the
   Internet in any form.  Network operators may filter 3FFE prefixes on
   their borders to ensure these prefixes are not misused.

If IETF were to publish a phaseout plan for 6to4, then it would be more difficult for vendors of host and home gateway operating systems to ignore.  If we knew that network operators were given guidance by IETF to stop routing 2002::/16 in the default free zone after some future date, then that would help me convince certain product engineering people I know to consider patches for existing field deployments.  Failing that however, I'm pretty sure this draft as it stands today will be too easily ignored.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 09 Apr 2011 19:33:26 +1200

> If IETF were to publish a phaseout plan for 6to4, then it would be more difficult for vendors of host and home gateway operating systems to ignore.  If we knew that network operators were given gui…

IMHO that is exactly what we should not do. Breaking 6to4 worse than
it is already broken is not in the interests of users or of
service providers (whose help desks would incur the resulting costs).

On the contrary, we need the 6to4 relays that exist to work impeccably,
and that requires careful attention to routing both 2002::/16 and the
anycast prefix.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 09 Apr 2011 19:38:02 +1200

P.S. The phaseout plan is to wait until existing hosts and CPEs that
do 6to4 by default go to landfill or e-cycling. So we need to operate
relays for another ten years.

Regards
   Brian

---

From: Cameron Byrne <[email-masked]>
Date: Sat, 9 Apr 2011 07:59:44 -0700

> > This draft would send a much stronger signal to implementors if it were
to contain language more like what you see in RFC 3701 for phasing out the
6bone.  I draw your attention to this excerpt:
> > If IETF were to publish a phaseout plan for 6to4, then it would be more
difficult for vendors of host and home gateway operating systems to ignore.
 If we knew that network operators were given guidance by IETF to stop
routing 2002::/16 in the default free zone after some future date, then that
would help me convince certain product engineering people I know to consider
patches for existing field deployments.  Failing that however, I'm pretty
sure this draft as it stands today will be too easily ignored.
> and that requires careful attention to routing both 2002::/16 and the

Working impeccable is a lot to ask given that customers generally don't know
or care about 6to4 and it does not and will not provide revenue

Cb

---

From: Cameron Byrne <[email-masked]>
Date: Sat, 9 Apr 2011 08:05:29 -0700

> relays for another ten years.

This is a tall ask from someone, with all due respect for your
contributions, does not run a network or support desk.

Do you happen to have a supporting business case or are we making
proclamations that are not really intended for reality?

I believe the sp consensus is turn 6to4 off by default asap. It's more
trouble than it is worth and will get worse with cgn

Cb

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 10 Apr 2011 03:07:03 +1200

On 2011-04-10 02:59, Cameron Byrne wrote:
...
> or care about 6to4 and it does not and will not provide revenue

Help desk calls cause negative revenue, and so do dissatisfied content
providers. Also, careless configuration of routing for the 6to4 prefixes
can offer a free ride to non-customers. I don't see any category of operator
that will not get indirect OPEX benefits from making 6to4 relays work better.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 10 Apr 2011 03:09:56 +1200

> trouble than it is worth and will get worse with cgn

My previous reply answers this too. Try to get it turned off
by all means, but you can't turn off most of the legacy boxes.

Everthing will get worse with CGN, but you are right and
draft-ietf-v6ops-6to4-advisory calls this out.

   Brian

---

From: james woodyatt <[email-masked]>
Date: Sat, 09 Apr 2011 09:17:50 -0700

> service providers (whose help desks would incur the resulting costs).

I agree, though I'm not sure the service and content providers pushing this move care about the help desk costs associated with this move.  They probably know they'll be sharing the burden with equipment makers.

However, the 6to4 To Historic draft is too easy for equipment makers to ignore because it sets no standard for equipment makers and it includes no phaseout plan for operators.  That's why I opposed taking it up as a working group item.  If we're going to deprecate 6to4 properly, then it needs a phaseout plan.  We MUST break it worse than it is already broken, or it will only be phased out when IPv4 itself is phased out.

> and that requires careful attention to routing both 2002::/16 and the

I'm an enthusiastic supporter of the 6to4/Teredo advisory draft.

---

From: "George, Wes E [NTK]" <[email-masked]>
Date: Mon, 11 Apr 2011 02:21:49 +0000

From: [email-masked] [mailto:[email-masked]] On Behalf Of Cameron Byrne
Sent: Saturday, April 09, 2011 11:05 AM
To: Brian E Carpenter
Cc: IPv6 Ops WG
Subject: Re: [v6ops] Deprecating 2002::/16 - 6to4 Historic Status

> relays for another ten years.
This is a tall ask from someone, with all due respect for your contributions, does not run a network or support desk.
Do you happen to have a supporting business case or are we making proclamations that are not really intended for reality?
I believe the sp consensus is turn 6to4 off by default asap. It's more trouble than it is worth and will get worse with cgn 
Cb

[WEG] No matter what the behavior in new hosts may change to after this draft, Brian is right. For the same reason that we can't get
more things to get software updates to support real IPv6, a software change to update the defaults on out-of-warranty consumer
electronics is unlikely (both in availability and in getting people to apply it), and therefore the phaseout plan is accurate
regardless of what SP consensus may be. No one is mandating that you support relays beyond when you think it makes sense in your
network, whether that be a business case discussion, or a technical consideration, or both. That includes deciding to turn them off
tomorrow, or never deploying relays at all, or doing things that you know will break it like using routable space as NAT space, etc.
This is simply acknowledging that there is some set of folks that are successfully using 6to4, and we ought not unceremoniously
break it if we can avoid doing so. I don't think that's such a tall order.

Wes George

---

From: Kevin Day <[email-masked]>
Date: Sun, 10 Apr 2011 21:50:07 -0500

> I believe the sp consensus is turn 6to4 off by default asap. It's more trouble than it is worth and will get worse with cgn

We run a public 6to4 relay announced to the world.

Despite its problems, we're seeing overall usage on it go up, with an overall trend of around a 5% increase each month.

I don't know if this is because others are shutting their relays down, more people are using 6to4, other providers are forcing a selection onto our relay because we go through great pains to make sure it's actually working, or there's just more v6 content out there.

If the argument isn't "Even if 6to4 is your only option, you're better off not having v6 at all", has anyone else looked at statistics on public 6to4 relays to see what kind of usage growth/loss is happening lately? I have no personal stake in what happens to 6to4, but if there actually is a pattern of growth with it now, we probably should be looking at why that's happening before discussions of pulling the plug get too far.

Another single-datapoint anecdote: We used to receive at least one complaint a month about our 6to4 relay not working (which pretty much always was traced down to the reverse path being broken, not us), but those complaints have pretty much stopped entirely in the last year. I don't know if this is because people are getting better at deploying 6to4, or if people know enough to switch to another option if it's broken.

-- Kevin

---

From: Victor Kuarsingh <[email-masked]>
Date: Sun, 10 Apr 2011 23:04:12 -0400

On 10/04/11 10:21 PM, "George, Wes E [NTK]" <[email-masked]>
wrote:

>[WEG] No matter what the behavior in new hosts may change to after this
>draft, Brian is right. For the same reason that we can't get
>more things to get software updates to support real IPv6, a software
>change to update the defaults on out-of-warranty consumer
>electronics is unlikely (both in availability and in getting people to
>apply it), and therefore the phaseout plan is accurate
>regardless of what SP consensus may be. No one is mandating that you
>support relays beyond when you think it makes sense in your
>network, whether that be a business case discussion, or a technical
>consideration, or both. That includes deciding to turn them off
>tomorrow, or never deploying relays at all, or doing things that you know
>will break it like using routable space as NAT space, etc.
>This is simply acknowledging that there is some set of folks that are
>successfully using 6to4, and we ought not unceremoniously

[Victor] Whereas I support the overall efforts to move 6to4 to historical,
it's operation in the network will continue for a some time.  Although
device vendors "may" change the default behavior, the reality is that most
customers don¹t proactively update firmware, run updates etc, and many
devices out there today (as noted by Wes) will not see firmware updates.
Many of these devices will need to be turned off to stop their 6to4
operation.

As an operator, I do not support the willful blocking or hinderance of
valid traffic.  As long as 6to4 traffic exists in the network, it's our
job to make it work as best possible. I think the efforts to make it work
are far more achievable in the near future then those efforts to kill it
off.  This is due based on the premise that killing it off requires the
uncontrolled masses to take positive steps to upgrade/update [when those
actually occur] - whereas making it work can be achieved by a controlled
set of ISPs and knowledgeable staff).  I guess over time 6to4 traffic will
decline (not sure how long this will take) and then we can stop worrying
about it.  

I think Brian's draft (draft-ietf-v6ops-6to4-advisory) sums up what is
needed to help 6to4 work as best possible while the realization of Ole's
draft (draft-ietf-v6ops-6to4-to-historic)  takes hold (over time).  This
would help my general populous of which some are using 6to4.  As for the
CGN use case (using non-RFC1918), there is an option here which works.

For me, the reality is that 6to4 traffic exists for now so I will to deal
with it; when it's gone all the better (Not just declared gone, but
actually gone).

Regards,

Victor K

---

From: Joel Jaeggli <[email-masked]>
Date: Sun, 10 Apr 2011 23:38:03 -0700

> with it; when it's gone all the better (Not just declared gone, but

Right, this is my sense...

We would prefer that hosts not do it.

For now we support the hosts that do as best we can. The sooner they
stop, the better.

joel

---

From: "Gunter Van de Velde (gvandeve)" <[email-masked]>
Date: Wed, 13 Apr 2011 10:25:06 +0200

Another single-datapoint anecdote: We used to receive at least one
complaint a month about our 6to4 relay not working (which pretty much
always was traced down to the reverse path being broken, not us), but
those complaints have pretty much stopped entirely in the last year. I
don't know if this is because people are getting better at deploying
6to4, or if people know enough to switch to another option if it's
broken.

GV> They probably did an internet-searched and discovered that they have
the problem go away with disabling IPv6 on their device :-)

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 13 Apr 2011 22:06:57 +1200

> the problem go away with disabling IPv6 on their device :-)

This is not very scientific as an analysis. We need data, as in the excellent
example below, to get some idea of the total usage as well as the problem cases:

http://stats.ottix.net/ipv6/

   Brian

---

From: Mark Townsley <[email-masked]>
Date: Wed, 13 Apr 2011 12:20:26 +0200

> http://stats.ottix.net/ipv6/

Nice data. How are you discerning problem cases from this though?

---

From: "Gunter Van de Velde (gvandeve)" <[email-masked]>
Date: Wed, 13 Apr 2011 12:20:31 +0200

GV> I agree on that statement about being non-scientific. Good link btw. My comment was partially mentioned 
with my tongue-in-cheek, because that is what I would have done to resolve the issue.
(and yes, there are stats out there telling that people look 10 times more to disable IPv6 in comparison to enable IPv6:
http://www.google.com/trends?q=disable+ipv6%2C+enable+ipv6&ctab=0&geo=all&date=all&sort=0)

G/

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 14 Apr 2011 03:26:16 +1200

> Nice data. How are you discerning problem cases from this though?

You can't, but the person who runs that site is aware of Geoff Huston
and Emile Aben's work on counting failed sessions, and may be integrating
that sort of analysis too. At the moment you'd have to assume that
the failure rates Geoff and Emile have reported would apply everywhere.

    Brian

---

From: "William F. Maton Sotomayor" <[email-masked]>
Date: Sun, 17 Apr 2011 16:34:34 -0400 (EDT)

> the failure rates Geoff and Emile have reported would apply everywhere.

Indeed.  I'm working with Emile to supply some data to get this ball 
rolling.

wfms

---

From: Geoff Huston <[email-masked]>
Date: Thu, 21 Apr 2011 21:43:03 +1000

> I suspect that a lot of the problem isn't 6to4 but rather just IPv6.

The experimental data does not appear to support this hypothesis. The
evidence points strongly to protocol 41 filters at the boundary of
customer nets, as the connection drop rates for 6to4 are between 15% to 20%
of connections where the 1st SYN is seen, while the connection drop rates for
unicast V6 is around 2%. This significant disparity in failure rates points
to specific issues surrounding auto-tunnelling from the end host, and the
most logical issue is proto 41 filtering.

Geoff

---

From: Geoff Huston <[email-masked]>
Date: Thu, 21 Apr 2011 22:05:50 +1000

> Another single-datapoint anecdote: We used to receive at least one complaint a month about our 6to4 relay not working (which pretty much always was traced down to the reverse path being broken, not…

I could offer a possible explanation here - there is some evidence in the collected data sets to suggest that the peer-to-peer applications are making use of IPv6, and there is some considerable amount of 6to4 and teredo traffic as a result of this. However most peer-to-peer application rely on massive redundancy in the assembled infrastructure, and if one peer is not responsive the application simply (and generally silently) just moves on.

So when the browsers and the OSes depref'ed 6to4 for dual stack over the past 12 months, the level of use of 6to4 in a point-to-point scenario waned, and the relative incidence of clients who use 6to4 in a dual stack continues to wane - its around 0.02% as far as I can see at present (http://www.potaroo.net/stats/1x1/sitec/6v6dspref.png). But the failure rate has been between 15% and 20% (higher on weekdays), where "failure" is defined as the remove V6 end seeing the initial SYN packet, but nothing more.

So the pool folk who were likely to notice the failure and complain have been, in relative terms at any rate, falling. While the pool of folk using 6to4 are rising, but their manner of use is such that failure is largely ignored.

   Geoff