Subject: [v6ops] my recommendation re: 6to4

From: Keith Moore <[email-masked]>
Date: Fri, 31 Oct 2014 18:47:56 -0400

Rather than reply individually to every message, I thought I'd just try 
to summarize here.

1. I think RFC 3068 should be reclassified as Historic.

A document should be published documenting this change, and the reasons 
for it, and recommending that relay routers be switched off.

The primary reason for this reclassification should be that the 3068 
mechanism relies on a v4 anycast address to implement a service location 
mechanism for a service that is controversial, and thus, some carriers 
don't wish to support it.   Related problems are (a) because the RFC 
3068 6to4 relay service uses anycast addresses, it's difficult to 
diagnose and trace problems with it, and (b) because there's no explicit 
relationship between a RFC 3068 6to4 relay and its users (on either 
side) there's also no clear support path.

It might be worth pointing out that similar problems could occur with 
any use of anycast addresses.  But the other use of anycast that crosses 
network boundaries of which I'm aware (e.g. root DNS servers) is not 
controversial - everybody accepts that it's vital that DNS roots be 
reachable.   (It's sad that far fewer considered IPv6 transition an 
essential service, but I understand that supporting a 6to4 relay router 
is a greater burden than just forwarding packets to a root server that 
someone else maintains.)

I recommend defining a sunset date, say N months after document 
publication, to give everyone ample time to adapt but also to avoid 
having everyone else's relay routers swamped.

---

The above applies to RFC 3068 routers accepting traffic at the 6to4 IPv4 
anycast address and forwarding packets into the IPv6 network. It might 
be worth separately addressing the question of IPv6 routers advertising 
the 2002:/16 prefix and forwarding packets into the IPv4 network.   I 
don't think the two cases are quite symmetrical, and it seems possible 
that it causes fewer problems for a v6 router to advertise 2002:/16 than 
for a v4 router to advertise 192.88.99/24. If nothing else, it's easy to 
traceroute the v6 side and figure out whether the traffic gets to the 
relay router, but the traceroute from the 6to4 side doesn't tell you 
much because the whole path over v4 just looks like one hop.

Having v6->v4 relay routers still be operational would permit sites 
using 6to4 to explicitly configure an explicit 6in4 tunnel to a relay 
router reachable via v4.    But the "lack of an explicit relationship" 
problem would remain.    I have also heard rumors of routers advertising 
2002:/16 but which only forwarded packets to a subset of IPv4 space.   
So there's a separate problem here, though I don't know how serious it 
is.   In general it might be a Bad Idea for multiple ASes to ever 
originate advertisements to the same prefix.

2.  The utility of protocol 41 in particular, and network transparency 
in general, should be affirmed.   Perhaps this would be most clearly 
expressed in a separate document, but I'll be happy for any statement I 
can get.   I've seen and heard of too many cases of carriers blocking 
protocol 41 even between hosts using static IPv4 addresses.

3.  Regarding  RFC 3056:   I think it should not be deprecated, as I 
think this sends the wrong message to carriers and network operators 
that have actively attacked 6to4.  However, unless some relay capability 
between 6to4 sites and native v6 can be salvaged (explicitly configured 
v4->v6, advertised 2002:/16 on the v6 side), it's certainly fair to say 
that RFC 3056 has less general applicability.    Consumer router vendors 
certainly shouldn't be touting 6to4 support as "IPv6 support".

So some sort of revised applicability statement for RFC 3056 might be in 
order.    If people are really attached to document classification as a 
way to do this, perhaps reclassifying it as Experimental or 
Informational would be appropriate.

4.  However the above actions are labeled, they make it all the more 
obvious that the Internet community lacks an obvious, recommended, and 
generally-applicable IPv6-over-IPv4 tunneling mechanism that can be 
implemented in a host or router (both are needed, but these could be 
separate mechanisms) and enabled with minimal user effort.   This seems 
like a gaping and embarrassing hole and a serious impediment to the 
universal use of IPv6, as there will continue to be legacy IPv4-only 
networks for some time.

Attempting to learn from the 6to4 experience, it appears that such a 
mechanism: (a) should not rely on IPv4 anycast for service discovery, at 
least not across network boundaries; (b) should have an explicit 
relationship between a user/customer and any v4-v6 relays; (c) should 
work through NATs; (d) should allow the user's ISP to provide the 
service (and allow that service to be automatically discovered), but not 
force the user to rely on his ISP to do so; and (e) there should be a 
well-defined mechanism to allow a network operator to filter or defeat 
the service for hosts on his network, while making it clear to the users 
of those hosts that that's what's happening.

*IMO our efforts should be focused on 
identifying/developing/refining/recommending such a mechanism, much more 
than on trying to figure out exactly how to kill 6to4 or any other 
existing transition mechanism.*   Provide a better way for people who 
are stuck (some or all of the time) on IPv4-only networks to use IPv6, 
and nobody (including me) will need to care about 6to4.   The need for 
6to4 hasn't gone away, it's just that the network has become much more 
hostile to it than when the mechanism was first defined.

Keith

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 31 Oct 2014 23:07:32 +0000

Hi Keith,

Just a couple of quick comments:

4.  However the above actions are labeled, they make it all the more obvious that the Internet community lacks an obvious, recommended, and generally-applicable IPv6-over-IPv4 tunneling mechanism that can be implemented in a host or router (both are needed, but these could be separate mechanisms) and enabled with minimal user effort.   This seems like a gaping and embarrassing hole and a serious impediment to the universal use of IPv6, as there will continue to be legacy IPv4-only networks for some time.

Maybe, but it does  not necessarily need to be ip-proto-41 based. For example, tunnels
over UDP are probably more likely to traverse middleboxes (including NATs, of course).
And, it need not be specific to IPv6-over-IPv4 – it would be much better to have a single
mechanism that can support tunneling of IPvX-over-IPvY for any values of X and Y.

IMO our efforts should be focused on identifying/developing/refining/recommending such a mechanism, much more than on trying to figure out exactly how to kill 6to4 or any other existing transition mechanism.

I take it from the emphasis that you truly believe there is a gap that needs to be filled.
Have a look at AERO as an emerging service that could satisfy the need.

Thanks – Fred
[email-masked]

From: v6ops [mailto:[email-masked]] On Behalf Of Keith Moore
Sent: Friday, October 31, 2014 3:48 PM
To: [email-masked] WG
Subject: [v6ops] my recommendation re: 6to4

Rather than reply individually to every message, I thought I'd just try to summarize here.

A document should be published documenting this change, and the reasons for it, and recommending that relay routers be switched off.

The primary reason for this reclassification should be that the 3068 mechanism relies on a v4 anycast address to implement a service location mechanism for a service that is controversial, and thus, some carriers don't wish to support it.   Related problems are (a) because the RFC 3068 6to4 relay service uses anycast addresses, it's difficult to diagnose and trace problems with it, and (b) because there's no explicit relationship between a RFC 3068 6to4 relay and its users (on either side) there's also no clear support path.

It might be worth pointing out that similar problems could occur with any use of anycast addresses.  But the other use of anycast that crosses network boundaries of which I'm aware (e.g. root DNS servers) is not controversial - everybody accepts that it's vital that DNS roots be reachable.   (It's sad that far fewer considered IPv6 transition an essential service, but I understand that supporting a 6to4 relay router is a greater burden than just forwarding packets to a root server that someone else maintains.)

I recommend defining a sunset date, say N months after document publication, to give everyone ample time to adapt but also to avoid having everyone else's relay routers swamped.

---

The above applies to RFC 3068 routers accepting traffic at the 6to4 IPv4 anycast address and forwarding packets into the IPv6 network.   It might be worth separately addressing the question of IPv6 routers advertising the 2002:/16 prefix and forwarding packets into the IPv4 network.   I don't think the two cases are quite symmetrical, and it seems possible that it causes fewer problems for a v6 router to advertise 2002:/16 than for a v4 router to advertise 192.88.99/24.   If nothing else, it's easy to traceroute the v6 side and figure out whether the traffic gets to the relay router, but the traceroute from the 6to4 side doesn't tell you much because the whole path over v4 just looks like one hop.

Having v6->v4 relay routers still be operational would permit sites using 6to4 to explicitly configure an explicit 6in4 tunnel to a relay router reachable via v4.    But the "lack of an explicit relationship" problem would remain.    I have also heard rumors of routers advertising 2002:/16 but which only forwarded packets to a subset of IPv4 space.   So there's a separate problem here, though I don't know how serious it is.   In general it might be a Bad Idea for multiple ASes to ever originate advertisements to the same prefix.

2.  The utility of protocol 41 in particular, and network transparency in general, should be affirmed.   Perhaps this would be most clearly expressed in a separate document, but I'll be happy for any statement I can get.   I've seen and heard of too many cases of carriers blocking protocol 41 even between hosts using static IPv4 addresses.

3.  Regarding  RFC 3056:   I think it should not be deprecated, as I think this sends the wrong message to carriers and network operators that have actively attacked 6to4.  However, unless some relay capability between 6to4 sites and native v6 can be salvaged (explicitly configured v4->v6, advertised 2002:/16 on the v6 side), it's certainly fair to say that RFC 3056 has less general applicability.    Consumer router vendors certainly shouldn't be touting 6to4 support as "IPv6 support".

So some sort of revised applicability statement for RFC 3056 might be in order.    If people are really attached to document classification as a way to do this, perhaps reclassifying it as Experimental or Informational would be appropriate.

4.  However the above actions are labeled, they make it all the more obvious that the Internet community lacks an obvious, recommended, and generally-applicable IPv6-over-IPv4 tunneling mechanism that can be implemented in a host or router (both are needed, but these could be separate mechanisms) and enabled with minimal user effort.   This seems like a gaping and embarrassing hole and a serious impediment to the universal use of IPv6, as there will continue to be legacy IPv4-only networks for some time.

Attempting to learn from the 6to4 experience, it appears that such a mechanism: (a) should not rely on IPv4 anycast for service discovery, at least not across network boundaries; (b) should have an explicit relationship between a user/customer and any v4-v6 relays; (c) should work through NATs; (d) should allow the user's ISP to provide the service (and allow that service to be automatically discovered), but not force the user to rely on his ISP to do so; and (e) there should be a well-defined mechanism to allow a network operator to filter or defeat the service for hosts on his network, while making it clear to the users of those hosts that that's what's happening.

IMO our efforts should be focused on identifying/developing/refining/recommending such a mechanism, much more than on trying to figure out exactly how to kill 6to4 or any other existing transition mechanism.   Provide a better way for people who are stuck (some or all of the time) on IPv4-only networks to use IPv6, and nobody (including me) will need to care about 6to4.   The need for 6to4 hasn't gone away, it's just that the network has become much more hostile to it than when the mechanism was first defined.

Keith

---

From: Keith Moore <[email-masked]>
Date: Fri, 31 Oct 2014 19:11:37 -0400

On 10/31/2014 07:07 PM, Templin, Fred L wrote:
> separate mechanisms) and enabled with minimal user effort.   This 
> seems like a gaping and embarrassing hole and a serious impediment to 
> the universal use of IPv6, as there will continue to be legacy 
> IPv4-only networks for some time.
>
> Maybe, but it does  not necessarily need to be ip-proto-41 based.
>

Concur.   And as you point out, that wouldn't work over NATs.

> identifying/developing/refining/recommending such a mechanism, much 
> more than on trying to figure out exactly how to kill 6to4 or any 
> other existing transition mechanism.*
>

Indeed I do, though it's possible that either I missed one that 
satisfies the criteria, or there are some mechanisms that only need a 
bit of tweaking (like a service discovery mechanism).    But the message 
was already long enough so I didn't want to try to start a discussion 
about the merits of specific approaches in the same message.

How do you feel about the criteria (a)-(e) that I listed?   Are they 
sufficient?

Keith

p.s. I'll take a look at AERO.

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 31 Oct 2014 23:33:21 +0000

Hi Keith,

How do you feel about the criteria (a)-(e) that I listed?   Are they sufficient?

I thought they sounded fine, but would also add that the same mechanisms that
would be applied in ISP networks should also be applicable for enterprise networks
and any other manner of network that provides basic connectivity to the end user.
Mobility and security are other aspects that may also need to be considered.

Thanks – Fred

From: Keith Moore [mailto:[email-masked]]
Sent: Friday, October 31, 2014 4:12 PM
To: Templin, Fred L; [email-masked] WG
Subject: Re: [v6ops] my recommendation re: 6to4

Indeed I do, though it's possible that either I missed one that satisfies the criteria, or there are some mechanisms that only need a bit of tweaking (like a service discovery mechanism).    But the message was already long enough so I didn't want to try to start a discussion about the merits of specific approaches in the same message.

How do you feel about the criteria (a)-(e) that I listed?   Are they sufficient?

Keith

---

From: Keith Moore <[email-masked]>
Date: Fri, 31 Oct 2014 19:34:03 -0400

> Mobility and security are other aspects that may also need to be 
Makes sense.

Keith