Subject: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt

From: [email-masked]
Date: Mon, 20 Oct 2014 23:38:29 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the IPv6 Operations Working Group of the IETF.

        Title           : Deprecating Connection of IPv6 Domains via IPv4 Clouds (6to4)
        Authors         : Ole Troan
                          Brian Carpenter
	Filename        : draft-ietf-v6ops-6to4-to-historic-06.txt
	Pages           : 7
	Date            : 2014-10-20

Abstract:
   Experience with the "Connection of IPv6 Domains via IPv4 Clouds
   (6to4)" IPv6 transition mechanism has shown that the mechanism is
   unsuitable for widespread deployment and use in the Internet.  This
   document requests that RFC3056 and the companion document "An Anycast
   Prefix for 6to4 Relay Routers" RFC3068 are made obsolete and moved to
   historic status.  It also recommends that future products should not
   support 6to4 and that existing deployments should be reviewed.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-6to4-to-historic/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic-06

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-6to4-to-historic-06

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Gert Doering <[email-masked]>
Date: Tue, 21 Oct 2014 12:29:55 +0200

Hiya,

> 	Filename        : draft-ietf-v6ops-6to4-to-historic-06.txt

Support.  Both for the cause as for the text as written.

It's good to see a respin of the draft, taking into account recent
developments in clients (HE) and networks (6rd) and making clear which
parts are problematic, and which "similar-looking" parts are not
(namely, 6rd, and non-relay-using 6to4 between two IPv4-only hosts)

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 21 Oct 2014 12:00:31 +0100

support, with one suggestion.  The current revision says:

>    The references to the 6to4 relay anycast addresses (192.88.99.0/24)
>    should be removed as soon as practical from the revision of the
>    Special Use IPv4 addresses [RFC6890].

As this prefix will be widely hard-coded in many places for the foreseeable
future, it would probably be a good idea to prevent the relay prefix from
being reassigned using the same proposed mechanism as for 2002::/16.

Suggested new text:

> 4. Deprecation
>
> This document formally deprecates the [RFC3056] 6to4 transition
> mechanism, the IPv6 6to4 prefix (2002::/16), and the 6to4 relay anycast
> prefix (192.88.99.0/24). These prefixes MUST NOT be reassigned for other
> use except by a future IETF standards action.

Nick

---

From: David Farmer <[email-masked]>
Date: Tue, 21 Oct 2014 08:32:29 -0500

> support, with one suggestion.  The current revision says:

+1

>> use except by a future IETF standards action.

+1 to the suggestion as well.

However, there is an additional issue regarding the deprecation of the 
prefixes.  Do the two prefixes immediately become BOGONs?  And, should 
they be filtered as BOGONs?  If NOT, then please provide specific 
guidance otherwise.

If that is the intended result, then I would suggest beyond the current 
guidance to relay operators that there also should be guidance to 
general network operators that they deliberately consider when they 
should stop accepting routes for the two relay prefixes from outside 
there networks.  Also, should only the routes be filtered?  Should 
traffic be filtered too?  Should you start with routes and then traffic 
later?

Specifically, I'm concerned when groups like Team Cymru add these relay 
prefixes to their recommendations, and how that should occur.  When this 
occurs there is likely to be a dramatic effect.  I'm not sure specific 
guidance for a group like Team Cymru is needed within the draft, but it 
might not be a bad idea to talk that part through on the list.

Thanks.

-- 
================================================
David Farmer               Email: [email-masked]
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: 1-612-626-0815
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
================================================

---

From: Tore Anderson <[email-masked]>
Date: Tue, 21 Oct 2014 15:43:26 +0200

* Gert Doering

+1

Tore

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 21 Oct 2014 14:58:13 +0100

On 21/10/2014 14:32, David Farmer wrote:
> Do the two prefixes immediately become BOGONs?

>From what I read, no.  If they did, the draft would be objectionable
because it breaks stuff right now.

> And, should they be filtered as BOGONs?  If NOT, then please provide
> specific guidance otherwise.

There's guidance there: don't add any new relay servers; if you have one
already, think about removing it and then think twice.

Nick

---

From: Tim Chown <[email-masked]>
Date: Tue, 21 Oct 2014 15:30:40 +0100

Tim

> (namely, 6rd, and non-relay-using 6to4 between two IPv4-only hosts)

Yes, very much so.

In the last bullet point of section 3, might add “, as is becoming increasingly common as ISPs who are unable to acquire additional globally unique IPv4 address space turn to CGN.” or words to that affect.

Anything to say about the use of the prefix in address selection policy tables (noting that 3ffe::/16 is still cited there)?

There’s a paragraph at the end that says:

  "Peer-to-peer usage of the 6to4 mechanism, not depending on the
   anycast mechanism, might exist in the Internet, largely unknown to
   operators.  This is harmless to third parties and the current
   document is not intended to prevent such traffic continuing."

which is a little at odds with the Historic status for 3056? If it’s made historic, and support removed, it would harm them…?

Tim

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 21 Oct 2014 23:34:46 +0900

On Tue, Oct 21, 2014 at 11:30 PM, Tim Chown <[email-masked]> wrote:

> which is a little at odds with the Historic status for 3056? If it’s made
> historic, and support removed, it would harm them…?
>

Would it make sense to move only 3068 to historic, and not 3056?

---

From: JF Tremblay <[email-masked]>
Date: Tue, 21 Oct 2014 10:39:03 -0400

> +1 to the suggestion as well.

I support this document and Nick’s new text. 

> However, there is an additional issue regarding the deprecation of the prefixes.  Do the two prefixes immediately become BOGONs?  And, should they be filtered as BOGONs?  If NOT, then please provide specific guidance otherwise.

My 2 cents: bogonize them asap. 

> If that is the intended result, then I would suggest beyond the current guidance to relay operators that there also should be guidance to general network operators that they deliberately consider when they should stop accepting routes for the two relay prefixes from outside there networks.  Also, should only the routes be filtered?  Should traffic be filtered too?  Should you start with routes and then traffic later?

Another 2 cents: SHOULD both on route and traffic filtering. The faster it fails the better imho.  

JF

---

From: Victor Kuarsingh <[email-masked]>
Date: Tue, 21 Oct 2014 11:17:13 -0400

On 2014-10-21 10:34 AM, Lorenzo Colitti wrote:
> On Tue, Oct 21, 2014 at 11:30 PM, Tim Chown <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     which is a little at odds with the Historic status for 3056? If
>     it’s made historic, and support removed, it would harm them…?
>
>
That seems to make sense to me.

regards,

Victor K

>
>
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 21 Oct 2014 15:44:12 +0000

It’s good to see the commentary on this already. To recap:

v6ops discussed this draft way back when and sent it to the IESG. The IETF Last Call left at least one AD with the belief that there was, in his words, “no consensus supporting the proposed action”, and the IESG dropped it. If we choose to send it up again, I think we need to make sure we have the right action (I note Lorenzo’s question, whether we should only deprecate one RFC, not two) and the arguments all together.

On Oct 20, 2014, at 11:38 PM, [email-masked] wrote:

> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: David Farmer <[email-masked]>
Date: Tue, 21 Oct 2014 11:05:10 -0500

On 10/21/14, 09:34 , Lorenzo Colitti wrote:
>     which is a little at odds with the Historic status for 3056? If it’s
>     made historic, and support removed, it would harm them…?
>
>

Yes, deprecate the 6to4 relay function, which means that only the 
192.88.99.0/24 prefix would deprecated.  2002::/16 would remain valid 
but only in the context of peer-to-peer 6to4, and it therefore SHOULD 
NOT be advertised to the IPv6 global Internet.

---

From: David Farmer <[email-masked]>
Date: Tue, 21 Oct 2014 11:12:53 -0500

> because it breaks stuff right now.

For some, once the prefixes have been deprecated then they are by 
definition BOGONs and should be filtered, both the routes and the 
traffic.  If that is not the intended result then either don't deprecate 
the prefixes or be explicit about how they should be treated.

> already, think about removing it and then think twice.

Yea, the nuance you and I see will be missed by many if not most, so 
let's not be so nuanced, let's be very blunt and explicit about what to 
do and what not to do.

Further, I don't think the only guidance should be to relay operators. 
As a network operator, when do I drop any routes for the relays at all? 
  Is it preferred to be using a relay on the other side of the planet or 
to have no relay at all?

Also, when we are down to one relay left what is suppose to happen, does 
that last operator get decide when the world no longer needs 6to4 
relays?  What if they never turn it off?  Isn't what we are doing with 
this draft deciding that the world no longer needs 6to4 relays.  If not 
then what is, I'm confused.

---

From: Ronald Bonica <[email-masked]>
Date: Tue, 21 Oct 2014 17:00:38 +0000

Also support.

> -----Original Message-----
> From: v6ops [mailto:[email-masked]] On Behalf Of Nick Hilliard
> Sent: Tuesday, October 21, 2014 7:01 AM
> To: [email-masked]
> Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt
> 
> > mechanism, the IPv6 6to4 prefix (2002::/16), and the 6to4 relay
> > anycast prefix (192.88.99.0/24). These prefixes MUST NOT be reassigned
> > for other use except by a future IETF standards action.
> 
> Nick
>

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 22 Oct 2014 08:10:24 +1300

On 22/10/2014 04:44, Fred Baker (fred) wrote:
> It’s good to see the commentary on this already. 

Yep. Fred, we may not need it, but could you reserve 15 minutes
in the Honolulu agenda, in case opinions have not converged by then?
It would have to be Monday morning as I have a clash Monday afternoon.

> To recap:

I think reality has moved on since then.

   Brian

> ------------------------------------------------------------------------
>

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 22 Oct 2014 08:21:36 +1300

> NOT be advertised to the IPv6 global Internet.

When I got my fingers on the XML file I found myself in two minds
about this. Deprecating RFC 3056 sends a stronger message about future
releases and deployments, but it does not stop existing systems from working.
Filtering 192.88.99.0/24 will break current usage 100% for affected
clients, which is clean and simple. But filtering 2002::/16 in some
places will insert black holes that break current usage for some
servers and will look pretty random to clients.

So I think my preference is
- deprecate 3056 to get the message across
- recommend filtering 192.88.99.0/24 so that clients see clean failure
- do not recommend filtering 2002::/16 so that return paths still work.

BTW, we changed the proposed status to BCP so that we can use
normative language for such recommendations.

   Brian

---

From: Ross Chandler <[email-masked]>
Date: Wed, 22 Oct 2014 00:49:44 +0100

> On 21 Oct 2014, at 16:17, Victor Kuarsingh <[email-masked]> wrote:
> 
> 
>> On Tue, Oct 21, 2014 at 11:30 PM, Tim Chown <[email-masked] <mailto:[email-masked]>> wrote:
+1  historic for 3068

Would like there to be a  clear recommendation to filter 192.88.99.0/24 and  2002::/16 coming in from the Internet DFZ.

+1 to Section 4 of  http://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic-06 <http://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic-06>

Regards
Ross

---

From: Keith Moore <[email-masked]>
Date: Tue, 28 Oct 2014 22:29:18 -0400

I must continue to object to this document and protocol action as long 
as native v6 support is not widely available.

The other problem that I have with this document is that it (still) 
blames 6to4 for failures caused by widespread poor practice in router 
configuration.

If an IP network fails to forward protocol 41 packets, it's the network 
that's broken, not the use of protocol 41.

I do not see the need for this document or protocol action, as the 
recommended behavior of disabling 6to4 by default is already sufficient 
to keep users from being accidentally burned by hosts or applications 
using 6to4 paths in preference to IPv4 paths.

Keith

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 29 Oct 2014 11:35:56 +0900

Keith,

would you still object if this document were amended so it only declares
RFC 3068 (the 6to4 relay router) historic?

The way I see it, RFC 3068 proposes a model which operational experience
has shown to be slow and unreliable, because it relies on the "kindness of
whatever stranger BGP has selected" to route packets between 6to4 addresses
and native addresses.

Cheers,
Lorenzo

On Wed, Oct 29, 2014 at 11:29 AM, Keith Moore <[email-masked]>
wrote:

> I must continue to object to this document and protocol action as long as
> native v6 support is not widely available.
>
> The other problem that I have with this document is that it (still) blames
> 6to4 for failures caused by widespread poor practice in router
> configuration.
>
> recommended behavior of disabling 6to4 by default is already sufficient to
> keep users from being accidentally burned by hosts or applications using
> 6to4 paths in preference to IPv4 paths.
>
> Keith
>
>

---

From: Keith Moore <[email-masked]>
Date: Tue, 28 Oct 2014 22:45:49 -0400

On 10/28/2014 10:35 PM, Lorenzo Colitti wrote:
> would you still object if this document were amended so it only 
> declares RFC 3068 (the 6to4 relay router) historic?

I would certainly find that position more reasonable than the one taken 
by the current document.
> The way I see it, RFC 3068 proposes a model which operational 
> experience has shown to be slow and unreliable, because it relies on 
> the "kindness of whatever stranger BGP has selected" to route packets 
> between 6to4 addresses and native addresses.

I don't disagree with that characterization.  Though as far as I've been 
able to tell the bigger problem is that a great many border routers are 
(mis?)configured to deny incoming protocol 41 traffic even if there's 
been outgoing protocol 41 traffic to the same IPv4 destination.

(the increased difficulty of filtering 6to4 traffic based on actual 
source/destination addresses might also be part of the reason for that)

Keith

p.s. Aside from the potential of this proposal to break things for 
people who are currently successfully using 6to4 and who do not yet have 
a native v6 alternative available, other things that bug me rather 
strongly about this document are its implicit position(s) that (a) 
IP-in-IP tunneling is something you shouldn't expect to work and 
therefore shouldn't be doing and (b) you shouldn't be using tunneling to 
bypass your ISPs routing.   I am emphatically opposed to both of those 
positions and feel that this document takes a really carrier-centric 
(and customer-hostile) view that is not appropriate for IETF to be taking.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 29 Oct 2014 16:30:11 +1300

> been outgoing protocol 41 traffic to the same IPv4 destination.

As far as we know anything, we know that the guidance in RFC 6343 hasn't
been widely applied (and it is quite complex). Border routers and
firewalls are really out of anybody's control except site IT managers,
and apparently they haven't read the RFC. Or maybe they have, and they
want to block automatic tunnels.

We also know (I just checked the numbers today) that anycast-based 6to4
traffic from Google's users is down to 0.2% of total IPv6 traffic (having
been about 10% in 2011).

Personally I have changed my mind. The progress on ISP-provided IPv6 has
been significant, Teredo has basically vanished, and I don't see a case for
paying the operational and trouble-shooting costs of 6to4 any more. The draft
is constructed so that it doesn't affect current peer to peer usage; declaring
an RFC historic doesn't change running code. The crucial point that *isn't*
covered in the draft yet is recommendations about filtering the IPv4 and
IPv6 prefixes, and I hope we'll be discussing that in HNL. (Keith,
will you be there? For me it's only one island over so it turns out to be
a convenient flight with only one hour's time change.)

    Brian

---

From: Havard Eidnes <[email-masked]>
Date: Wed, 29 Oct 2014 10:04:10 +0100 (CET)

> If an IP network fails to forward protocol 41 packets, it's the
> network that's broken, not the use of protocol 41.

Well, like it or not, some people like to organization-centrally
manage firewalls or packet filters as a first line of defense against
malware spreading uncontrollably, or to protect the soft underbelly of
internal hosts.  I don't know any devices which are in widespread use
and which allows such a filtering device to unwrap the outer
encapsulation payload to be able to filter on the layer-3 or layer-4
information in the encapsulated packet.  This leaves such managers
with the choice of "pass IP protocol 41 unfiltered" or "don't allow IP
protocol 41 to pass through".  Given the risk of the former to expose
internal systems to unfiltered access from the vast Internet, where
not everyone's intentions are benign, it is quite understandable the
choice most people make in this situation.  Calling this out as
"widespread poor practice" is IMHO a mis-characterization.

I would perhaps rather call it a lack of attention to deployment
considerations in the protocol design.

So ... count my voice in support of this document and protocol
action.

Best regards,

- Håvard

---

From: Keith Moore <[email-masked]>
Date: Wed, 29 Oct 2014 05:32:12 -0400

> "widespread poor practice" is IMHO a mis-characterization.

The fix, of course, would have been to either provide native v6 access 
if were available,  or to set up a 6to4 router at the border and filter 
on the unencapsulated IPv6 traffic.    In either of those cases 
host-to-host 6to4 would have been no longer needed or useful, and there 
would have been few problems with blocking 6to4 traffic between internal 
and external hosts.

(And how many enterprise networks were still using public v4 addresses 
internally anyway?)

So if you prefer, the "widespread poor practice" was ignoring the 
impending exhaustion of v4 address space, failing to make any plans to 
accommodate v6, and pretending that by simply blocking protocol 41 the 
need to transition to IPv6 would go away.

Keith

---

From: Antonio Querubin <[email-masked]>
Date: Thu, 30 Oct 2014 07:06:40 -1000 (HST)

> paying the operational and trouble-shooting costs of 6to4 any more. The draft

Progress?  Perhaps.  Significant?  Depends on whether any of your ISPs 
provide IPv6.  In my pond the average joe consumer still doesn't have easy 
access to native IPv6 from the local ISPs.  I know because I worked for 
the last local ISP that did.  It was bought out by someone who didn't care 
for IPv6 and promptly shut it all off - no I didn't stick around.  Since 
then I don't know of any local ISP that offers native IPv6 to non-business 
customers.

I suspect there are many other places where this would be true.  If the 
response is 'go get a tunnel' I would ask how easily/quickly could you set 
that up for a new residential DSL or cable modem user using a single 
computer?

For that matter how many typical off-the-shelf consumer grade routers 
provide 6in4 tunnelling capability?  I've looked at the box advertising on 
many of these units and check the websites of the vendors.  It's near 
impossible to tell which models can do tunnelling.

While the goal of this proposal is commendable I think it's a bit 
premature - not until native IPv6 has significant penetration and/or 6in4 
tunnelling is more commonplace in consumer grade routers.  Progress is 
good but availability is what counts operationally.

Antonio Querubin
e-mail:  [email-masked]
xmpp:  [email-masked]

---

From: Keith Moore <[email-masked]>
Date: Thu, 30 Oct 2014 13:17:40 -0400

On 10/30/2014 01:06 PM, Antonio Querubin wrote:
> provide IPv6.

I would say it depends on whether *most* of your ISPs provide native 
IPv6.   If only one of your ISPs provides IPv6, being forced into 
choosing that provider is not a good situation.

And more and more ISPs are being accused of blocking tunnels for 
consumer-grade accounts.   This isn't something that IETF should be 
endorsing in any way.   Internet service is supposed to be about making 
a best effort to faithfully forward IP packets to their destinations.   
Outside of very narrow circumstances, carriers that intercept, alter, 
block, or pessimize certain kinds of IP traffic on a routine basis are a 
threat to the utility of the Internet.

Keith

---

From: Owen DeLong <[email-masked]>
Date: Thu, 30 Oct 2014 11:10:51 -0700

> 
> p.s. Aside from the potential of this proposal to break things for people who are currently successfully using 6to4 and who do not yet have a native v6 alternative available, other things that bug me rather strongly about this document are its implicit position(s) that (a) IP-in-IP tunneling is something you shouldn't expect to work and therefore shouldn't be doing and (b) you shouldn't be using tunneling to bypass your ISPs routing.   I am emphatically opposed to both of those positions and feel that this document takes a really carrier-centric (and customer-hostile) view that is not appropriate for IETF to be taking.

I agree with both of these objections.

Owen

---

From: Gert Doering <[email-masked]>
Date: Thu, 30 Oct 2014 19:52:37 +0100

Hi,

> good but availability is what counts operationally.

Before you get a 6to4 tunnel, stick to IPv4-only.  6to4 tunneled IPv6
to the "wild Internet" (unlike "to your friend who also uses 6to4, no
gateway involved") will be SO much worse than "just use native IPv4"
that you're doing nobody a favour doing this.

6to4 is not "get a tunnel from he.net" - which actually works quite well.

Gert Doering
        -- NetMaster

---

From: Gert Doering <[email-masked]>
Date: Thu, 30 Oct 2014 19:54:19 +0100

Hi,

> I agree with both of these objections.

Neither is expressed in this draft.

"IPv6 in IPv4 tunneling using some 3rd party relay which is not maintained
well enough and since you do not know who's relay you are using, you can
not even tell them that it's broken" - this is what you should avoid.

Gert Doering
        -- NetMaster

---

From: Keith Moore <[email-masked]>
Date: Thu, 30 Oct 2014 15:21:18 -0400

> that you're doing nobody a favour doing this.
It's a mistake to assume that the reason for using IPv6 is to talk to 
the "wild Internet" (especially if you define "wild Internet" as the set 
of hosts that talk  IPv4 and might also happen to talk IPv6).   The 
motivation to use IPv6 is driven by different applications than IPv4 was.

Keith

---

From: Keith Moore <[email-masked]>
Date: Thu, 30 Oct 2014 15:22:20 -0400

> not even tell them that it's broken" - this is what you should avoid.
Mostly agree.   But the current document isn't just about deprecating 
RFC 3068.

Keith

---

From: Gert Doering <[email-masked]>
Date: Thu, 30 Oct 2014 21:41:15 +0100

Hi,

> motivation to use IPv6 is driven by different applications than IPv4 was.

So in which way does this draft impact your ability to talk IPv6 between
your nodes?

Gert Doering
        -- NetMaster

---

From: Keith Moore <[email-masked]>
Date: Thu, 30 Oct 2014 16:44:35 -0400

> So in which way does this draft impact your ability to talk IPv6 between
It impacts my ability to talk IPv6 with any other nodes for which 6to4 
currently works, which are not necessarily "my" nodes, nor nodes that 
also support IPv4.   To give one example, I've found that video 
conferencing over 6to4 can work in situations in which STUN-based NAT 
traversal fails.

Keith

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 31 Oct 2014 11:48:25 +1300

On 31/10/2014 06:06, Antonio Querubin wrote:
> provide IPv6.  In my pond the average joe consumer still doesn't have
> easy access to native IPv6 from the local ISPs.  I know because I worked
> for the last local ISP that did.  It was bought out by someone who
> didn't care for IPv6 and promptly shut it all off - no I didn't stick
> around.  Since then I don't know of any local ISP that offers native
> IPv6 to non-business customers.
> 
> response is 'go get a tunnel' I would ask how easily/quickly could you
> set that up for a new residential DSL or cable modem user using a single
> computer?

No, the response is actually "You're better off with IPv4 for now", sadly.
The Google data convince me that 6to4 is simply not useful any more.
A few years ago it was 10% of Google's IPv6 traffic; now it's 0.2%.
It was designed as a subversive technology to get around IPv4-only
operators, but because of NAT44 it has simply failed except for
a tiny minority.

> provide 6in4 tunnelling capability?  I've looked at the box advertising
> on many of these units and check the websites of the vendors.  It's near

Those boxes are all NAT44 (to a very close approximation) and NAT44
breaks host-based anycast 6to4 completely. The tiny amount of 6to4
traffic that Google sees must come from either non-NATted IPv4 hosts or
6to4-capable CPE routers.

> premature - not until native IPv6 has significant penetration 

Google is seeing ~4.5% of clients via IPv6, compared to ~0.5%
in 2011. Of course it's a matter of opinion whether that is
"significant" or not.

> and/or
> 6in4 tunnelling is more commonplace in consumer grade routers.

I predict that this will not change, but we might see pressure for
464xlat in CPEs.

   Brian

  Progress
> is good but availability is what counts operationally.

> .

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 30 Oct 2014 22:57:04 +0000

On 30/10/2014 20:44, Keith Moore wrote:
> currently works, which are not necessarily "my" nodes, nor nodes that also
> support IPv4.   To give one example, I've found that video conferencing
> over 6to4 can work in situations in which STUN-based NAT traversal fails.

No, it doesn't.  6to4 will continue to work for the foreseeable future and
this draft will change exactly nothing in this regard.

If it stops working in the distant future, it's going to be because
operators have stopped caring about it to the point that their relays will
either decay to the point that they no longer work, as happened in IE
earlier this year (no-one noticed, btw).

If this happens, get yourself a free ipv6 tunnel from a tunnel broker -
there are several of the around, including SixXS and HE.  They work very
nicely and are actively cared for by their operators.

Nick

---

From: Owen DeLong <[email-masked]>
Date: Thu, 30 Oct 2014 16:06:14 -0700

> On Oct 30, 2014, at 3:48 PM, Brian E Carpenter <[email-masked]> wrote:
> 

I could set it up very quickly and easily. I could probably do it in under 15 minutes,
but let’s say 1/2 hour to be overly cautious.

http://tunnelbroker.net <http://tunnelbroker.net/>

There’s even help for exactly how to configure a variety of systems and routers.

> in 2011. Of course it's a matter of opinion whether that is

I think more significant is that 100% of Comcast Residential customers now have
the ability to go IPv6 if they have capable equipment.

I expect as modems/routers get replaced over the next 1-2 years, that’s going to make for
a much bigger increase than the last 3 years.

>> 6in4 tunnelling is more commonplace in consumer grade routers.

It’s not that uncommon today. DDWRT generally supports it. Almost all of the IPv6 capable consumer grade routers from D-Link, Netgear, Apple, et al support it.

> I predict that this will not change, but we might see pressure for

464xlat isn’t currently there. 6in4 is pretty common in my experience.

YMMV.

Owen

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 30 Oct 2014 23:09:18 +0000

Keith,

On 29/10/2014 02:45, Keith Moore wrote:
> other things that bug me rather strongly about
> this document are its implicit position(s) that (a) IP-in-IP tunneling is
> something you shouldn't expect to work and therefore shouldn't be doing and
> (b) you shouldn't be using tunneling to bypass your ISPs routing.  I am
> emphatically opposed to both of those positions 

These are straw men arguments.  This is not helpful.

Regarding your objection (b), this is not stated or implied anywhere in the
document.

Regarding (a), we aren't talking about generic IP-in-IP tunnelling; instead
we're talking specifically about inter-domain anycast 6to4, which is a very
specific application of IPoIP.

You've also misunderstood something more important:  the data on 6to4
tunnelling suggests that instead of it being something you shouldn't expect
to work, it's something that you should explicitly expect not to work in
many situations.

It is an actively harmful technology where there is undeniable data to show
that it continues to cause high levels of measurable problems in many
cases.  Given the terminal level of breakage, it beggars belief how and why
anyone would think that this was an appropriate technology for providing
reliable ipv6 connectivity in the general case.

These problems will never go away because they depend on everyone running
bug-free networks.  Expecting otherwise is unrealistic beyond bound.

If it works for you, then good for you. This document will not stop it
working in future.

Nick

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 30 Oct 2014 23:13:32 +0000

On 30/10/2014 17:17, Keith Moore wrote:
> endorsing in any way.

This is another straw man argument - the IETF is endorsing nothing of the sort.

Nick

---

From: Keith Moore <[email-masked]>
Date: Thu, 30 Oct 2014 19:27:13 -0400

> A few years ago it was 10% of Google's IPv6 traffic; now it's 0.2%.

Google's data is no indication of the utility of 6to4.   The trend 
reflects a number of things not related to 6to4's utility, including 
increased native v6 connectivity among Google's users,  the increased 
deployment of better address prefix selection algorithms and happy 
eyeballs, the recent recommendations to disable 6to4 by default.   ANd 
of course it only measures people trying to reach Google, which while a 
popular use of the Internet, is in no way representative of the vast 
variety of Internet applications.

And the whole point of 6to4 (outside of experimental use) isn't to reach 
hosts that are reachable via IPv4; it's to reach hosts that /aren't/ 
reachable by IPv4.  Obviously for any scenario in which IPv4 works to 
reach a destination, 6to4 will never work better, at least not for 
two-party applications.

Similarly, the point of 6to4 isn't to communicate between hosts that 
both already have native IPv6 access.

> operators, but because of NAT44 it has simply failed except for

NAT44, hostile operators, and clueless or hostile network admins.
> 6to4-capable CPE routers.

I have a router that does NAT44 but also supports 6to4.  It acts as a v4 
NAT and a v6 router.  I don't know about current product offerings, but 
there used to be several consumer-grade products that did this.   The 
one I have worked fine for me for many years, until my ISP started 
blocking protocol it for no good reason.   (I do have a static IPv4 
address.)

> in 2011. Of course it's a matter of opinion whether that is

It's not enough penetration to justify a conclusion that most people 
using 6to4 have a viable alternative.

Keith

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 31 Oct 2014 13:12:35 +1300

>> p.s. Aside from the potential of this proposal to break things for people who are currently successfully using 6to4 and who do not yet have a native v6 alternative available, other things that bug…

I really don't see that in the document. The problems with anycast 6to4
are not generic problems of protocol 41, and afaik the blocking of
protocol 41, when it occurs, is mainly done by corporate firewalls.
Enterprises would often like to block any kind of non-encrypted
IP-in-IP tunnel because they view them as security bypasses. Anyway,
please suggest text changes.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 31 Oct 2014 13:26:39 +1300

> It’s not that uncommon today. DDWRT generally supports it. Almost all of the IPv6 capable consumer grade routers from D-Link, Netgear, Apple, et al support it.

You mean support for manually configured tunnels per RFC 4213, or what?
(My FritzBox has great native IPv6 support but no tunnel support that
I can find, and my D-Link box is old.)

   Brian

---

From: Jeroen Massar <[email-masked]>
Date: Fri, 31 Oct 2014 08:28:15 +0100

> conferencing over 6to4 can work in situations in which STUN-based NAT

You are saying you can transport proto-41 packets through a NAT setup,
that while STUN does not work?

I would really love to see the details. As NATs that know about proto-41
or are able to stick it to a specific endpoint are rare.

In most cases to get proto-41 working behind NAT you will have to force
the NAT box into "DMZ mode" (or whatever the flavor of the name is). And
even then, typically they do not do proto-41.

The DMZ trick will fail anyway, as you cannot teach your local host to
use the local IP address (eg 192.0.2.1) and configure it to listen to a
6to4 address of 2002:<public>:<ipaddr>::<something>

Thus I am *really* wondering how that is supposed to work.

Unless you mean you let the NAT box do the 6to4, as then, indeed things
get better. That requires also the other host to do 6to4. But in that
situation you will have an up-to-date enough host that will properly
handle STUN, uPNP or NAT-PMP and should thus not have any issues with NAT.

You will have a much better chance using Teredo in this situation (which
is what Xbox One does btw :)

Or much better: just use TSP or AYIYA, then you have determinism on your
side.

Greets,
 Jeroen

---

From: Jeroen Massar <[email-masked]>
Date: Fri, 31 Oct 2014 08:31:57 +0100

On Thu, Oct 30, 2014 at 07:06:40AM -1000, Antonio Querubin wrote:
> and/or 6in4 tunnelling is more commonplace in consumer grade
> routers.

If a device can do 6to4 then it is also doing 6in4.
Same for those devices doing 6rd.

Though with 6rd you can trick them to be configured as a 6in4 tunnel in
a /32bit space, and thus a single endpoint. For 6to4 that is not
possible. But in the end that is just a GUI issue.

> Progress is good but availability is what counts operationally.

With the large amount of failure scenarios of 6to4, I can only assume
you want 6to4 gone as well ;)

Greets,
 Jeroen

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 31 Oct 2014 12:03:25 +0100

Hi Brian,

I take advantage of your invitation to suggest text changes although I 
am not sure it covers topics unrelated to the one discussed in that email.

I think the document should mention what are the recommended 
alternatives.  Until now we see recommendations of particular tunnel 
brokers such as Hurricane Electric's (is it really that company behind 
it or just a reuse from a distant past?) and SixXs or AYIYA, and also 
recommendations to move to native IPv6.

There should be balance between these recommendations, because:

- tunnel broker should be considered as intermediate solution to native 
IPv6 and as such may incur additional renumbering efforts.
- tunnel broker offers some advantages over 6to4, e.g. IPsec security is 
possible because it's not an anycast address.
- tunnel broker creates new inconvenients, e.g. a new 'focal point' or 
single point of failure.
- tunnel brokers seem well used and maintained.

Alex

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Fri, 31 Oct 2014 13:43:57 +0000

I also support the suggestion to only impact RFC 3068 and leave some direct 6to4 connectivity 'current'.

BTW, adding 192.88.99.0/24 to the bogons will not really help in anyway as the client (the entry point in the 6to4 tunnel) will not be able to signal the IPv6 node of lack of IPv6 connectivity in most implementations.

-éric

From: Lorenzo Colitti <[email-masked]<mailto:[email-masked]>>
Date: mardi 21 octobre 2014 15:34
Would it make sense to move only 3068 to historic, and not 3056?

---

From: Keith Moore <[email-masked]>
Date: Fri, 31 Oct 2014 10:02:55 -0400

> or are able to stick it to a specific endpoint are rare.
In this case I'm using such a NAT that implements a IPv6 router with 
6to4 as its external interface and "normal" v6 (unencapsulated, with 
SLAAC, RD, etc.) on the internal one.   (In some cases it's also 
possible to build a 6to4 router that operates outside of the NAT, 
processes protocol 41 packets itself, and sends protocol 1, 6 and 17 
packets to the NAT.  The 6to4 router and the NAT have separate 
connections to the LAN.)

Keith

---

From: Ole Troan <[email-masked]>
Date: Fri, 31 Oct 2014 15:05:44 +0100

Eric,

> I also support the suggestion to only impact RFC 3068 and leave some direct 6to4 connectivity 'current'.

for my education, any idea what use cases there are / could be for direct 6to4 connectivity? 
given that:
 - you shouldn't put 6to4 addresses in DNS
 - 6to4 likely breaks if address sharing is in place

just speculating here; is it because tunnelling bypasses filters / throttling? if so doesn't e.g. peer applications bypass that by other means?

> BTW, adding 192.88.99.0/24 to the bogons will not really help in anyway as the client (the entry point in the 6to4 tunnel) will not be able to signal the IPv6 node of lack of IPv6 connectivity in m…

cheers,
Ole

---

From: Keith Moore <[email-masked]>
Date: Fri, 31 Oct 2014 10:05:46 -0400

> If a device can do 6to4 then it is also doing 6in4.
Actually, no.   I've seen several devices that only support one v6 
mechanism (6to4) and claim to support v6 (lame, I admit).

Keith

---

From: Gert Doering <[email-masked]>
Date: Fri, 31 Oct 2014 15:08:01 +0100

Hi,

> packets to the NAT.  The 6to4 router and the NAT have separate 

Which is, pretty much, "peer to peer 6to4", just implemented in a router
for "users in its /48", and not just in a host for itself.

Doesn't make a big difference in the grand scheme - peer to peer 6to4
is known to work, no matter how implemented, while 6to4-to-native is 
known to not-work except in controlled environments (which "the Internet"
isn't - inside our DCs it works surprisingly well, but it's still a 
nuisance if boxes start tunneling just because they can)

Gert Doering
        -- NetMaster

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Fri, 31 Oct 2014 14:14:02 +0000

I know that there have been designs using 6to4 to provide private IPv6
connectivity among dual-stack islands where the CE router has a public
IPv4 address only and uses some 6to4 combined with IPv6-BGP allow routing
among those private islands. So, not a single IPv6 packets with 2002::/16
prefix.

Not sure though whether those designs are still in use.

-éric

On 31/10/14 15:05, "Ole Troan" <[email-masked]> wrote:

>just speculating here; is it because tunnelling bypasses filters /
>throttling? if so doesn't e.g. peer applications bypass that by other
>means?
>
>> BTW, adding 192.88.99.0/24 to the bogons will not really help in anyway
>>as the client (the entry point in the 6to4 tunnel) will not be able to
>>signal the IPv6 node of lack of IPv6 connectivity in most
>>implementations. 
>
>cheers,
>Ole

---

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

> for my education, any idea what use cases there are / could be for direct 6to4 connectivity?

Any application that uses IPv6 and involves some hosts that don't have 
native (non-NATted) IPv4 access.

>   - you shouldn't put 6to4 addresses in DNS

There's nothing wrong with putting 6to4 addresses in DNS, just like 
there's nothing wrong with putting ULIAs in DNS.

>   - 6to4 likely breaks if address sharing is in place
What do you mean by "address sharing"?   (If you mean the same v4 
address is associated with multiple end sites using carrier-side NAT, I 
agree.)
> just speculating here; is it because tunnelling bypasses filters / throttling? if so doesn't e.g. peer applications bypass that by other means?
No, it's because global v4 addresses are scarce and 6to4 provides a way 
around that.

Keith

---

From: Jeroen Massar <[email-masked]>
Date: Fri, 31 Oct 2014 15:17:32 +0100

> packets to the NAT.  The 6to4 router and the NAT have separate

No need to have separate connections for that. Apple Airports don't for
instance.

As it is 6to4 and use of it is very limited due to Happy Eyeballs I can
only recommend to find a firmware upgrade or schedule the device for
replacement. You still have time before this draft becomes a standard...

> mechanism (6to4) and claim to support v6 (lame, I admit).

Read the next sentence in my message: it is a UI thing.
You need to implement proto-41 before you can do 6to4 on top of that.

As for "support IPv6", does the device have a "IPv6 Ready" logo on it?
(https://www.ipv6ready.org/) If yes, then we need to kick those folks
hard to stop giving out numbers for it.

Device, make/model details would be great. 99% probability it has a
Linux variant inside anyways.

Greets,
 Jeroen

---

From: Keith Moore <[email-masked]>
Date: Fri, 31 Oct 2014 10:17:44 -0400

> for "users in its /48", and not just in a host for itself.

Actually it supports both "peer to peer 6to4" and connectivity to native 
v6 via a relay router.   I believe the relay router is configurable but 
defaults to the anycast address.

> known to not-work except in controlled environments

The latter statement is simply false.

Keith

---

From: "Metzler, Dan J" <[email-masked]>
Date: Fri, 31 Oct 2014 14:21:26 +0000

I agree with the statement regarding mentioning alternatives in the document, (perhaps in the introduction?), but I'd point out the tunneling protocol(s) that could be used as an alternative, and then if desired, optionally list some tunnel brokers along with that information.  Hurricane Electric is 6in4 or straight tunneling in protocol 41, which is not affected by this document.

I wonder if perhaps some of the confusion from the discussion on this list is from a faulty assumption that this document might be getting rid of the protocols used by the tunnel brokers.
For example, if a Hurricane Electric tunnel relied on 6to4, that may lead one to the impression that one should no longer use a tunnel broker like Hurricane Electric because of the statement that 6to4 is deprecated. 

The reason to focus on the protocols is because when you're buying a router or looking at specs of an existing router, it is the protocol supported that determines the set of viable options.

Or perhaps a reference to RFC 3053 <http://tools.ietf.org/html/rfc3053>  may be of use, though it may be somewhat dated, to distinguish between what this document is talking about and just a configured tunnel to a broker.

I saw 6rd was mentioned pretty well, but that's more of a temporary transitional solution for an organization like an ISP, should they decide to implement IPv6, which is what differentiates from configured tunnel brokers that let you bypass the slow to adopt ISPs.  (I realize 6rd was explained more from the context of differentiating from 6to4.)

Aside from adding some of this additional wording I would be supportive of the intent of this document.

Thanks,

- Dan Metzler 

> From: v6ops [mailto:[email-masked]] On Behalf Of Alexandru
> Petrescu
> Sent: Friday, October 31, 2014 6:03 AM
> To: Brian E Carpenter; Owen DeLong
> Cc: [email-masked] WG; Keith Moore
> Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt -
> alternatives to 6to4
> 
> Hi Brian,
> 
> I take advantage of your invitation to suggest text changes although I am not
> sure it covers topics unrelated to the one discussed in that email.
> 
> brokers such as Hurricane Electric's (is it really that company behind it or just
> a reuse from a distant past?) and SixXs or AYIYA, and also recommendations
> to move to native IPv6.
> 
> - tunnel broker creates new inconvenients, e.g. a new 'focal point' or single
> point of failure.
> >>> p.s. Aside from the potential of this proposal to break things for people
> who are currently successfully using 6to4 and who do not yet have a native
> v6 alternative available, other things that bug me rather strongly about this
> document are its implicit position(s) that (a) IP-in-IP tunneling is something
> you shouldn't expect to work and therefore shouldn't be doing and (b) you
> shouldn't be using tunneling to bypass your ISPs routing.   I am emphatically
> opposed to both of those positions and feel that this document takes a
> really carrier-centric (and customer-hostile) view that is not appropriate for
> IETF to be taking.
> >
> > I really don't see that in the document. The problems with anycast
> > 6to4 are not generic problems of protocol 41, and afaik the blocking
> > of protocol 41, when it occurs, is mainly done by corporate firewalls.

---

From: Gert Doering <[email-masked]>
Date: Fri, 31 Oct 2014 15:30:18 +0100

Hi,

> The latter statement is simply false.

So, you know better than the people who actually *measure* and come to 
that conclusion based on observable reality?  Call me impressed.

Ever occurred to you that you might have just been lucky that 6to4-to-native
worked from your personal vantage points (due to topological closeness
to well-maintained relays in the forward and back direction), but that
the Internet is slightly bigger than what you can see *and* nobody will
guarantee you that this relay will still be there tomorrow?

(Could someone just find out which relay Keith is using and break it,
like, introduce 30% packet loss?  Might be more convincing than just
measurements and results)

Gert Doering
        -- NetMaster

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 31 Oct 2014 23:30:33 +0900

>  - 6to4 likely breaks if address sharing is in place

One use that comes to mind is bringing IPv6 connectivity to machines inside
a legacy IPv4-only datacenter where the network gear does not support IPv6.

---

From: Jeroen Massar <[email-masked]>
Date: Fri, 31 Oct 2014 15:35:48 +0100

On 2014-10-31 15:30, Lorenzo Colitti wrote:
> On Fri, Oct 31, 2014 at 11:05 PM, Ole Troan <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> One use that comes to mind is bringing IPv6 connectivity to machines
> inside a legacy IPv4-only datacenter where the network gear does not
> support IPv6.

Put a box on each Ethernet segment that does support IPv6, effectively
putting a second IPv6-only router everywhere.

That 'box' could be one of the servers that you already have on that
segment.

Any other model, eg putting a tunnel on every host, will not scale
(though, with Puppet or other it won't be a big pain...)

I don't see where 6to4 comes into play there.

Greets,
 Jeroen

---

From: Keith Moore <[email-masked]>
Date: Fri, 31 Oct 2014 10:36:48 -0400

> For example, if a Hurricane Electric tunnel relied on 6to4, that may lead one to the impression that one should no longer use a tunnel broker like Hurricane Electric because of the statement that 6…

I've seen protocol 41 being blocked - literally transmitted packets from 
one host to another (with no NAT in between) where protocol 6 packets 
got through and protocol 41 packets didn't.   That breaks both 6to4 and 
6in4.  I've read accounts that indicate that other providers are also 
doing this.

One of the things I don't want is an RFC published that legitimizes this 
in any sense, even an oblique one.

> I saw 6rd was mentioned pretty well, but that's more of a temporary transitional solution for an organization like an ISP, should they decide to implement IPv6, which is what differentiates from co…
Yeah, 6rd isn't an alternative from the point of view of a user/customer 
needing a way to exchange IPv6 packets with hosts on other networks, and 
without v6 support from his ISP.

Keith

---

From: Ole Troan <[email-masked]>
Date: Fri, 31 Oct 2014 15:41:29 +0100

Lorenzo,

> One use that comes to mind is bringing IPv6 connectivity to machines inside a legacy IPv4-only datacenter where the network gear does not support IPv6.

but it wouldn't be IPv6 connectivity since you cannot reach the IPv6 Internet using 6to4 anymore.
would it be useful in that case to be able to build a topologically restricted IPv6 overlay network? e.g. for local IPv6 only applications in the data centre?
isn't that much more likely to lead to breakage?

cheers,
Ole

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 31 Oct 2014 23:43:39 +0900

> Internet using 6to4 anymore.

It would be local IPv6 connectivity. But the datacenter might not allow
direct access to the Internet anyway, even on IPv4, so that might not be a
problem.

> would it be useful in that case to be able to build a topologically
> restricted IPv6 overlay network? e.g. for local IPv6 only applications in
> the data centre?

6to4 *is* an overlay network.

---

From: Keith Moore <[email-masked]>
Date: Fri, 31 Oct 2014 10:45:02 -0400

On 10/31/2014 10:30 AM, Gert Doering wrote:
> that conclusion based on observable reality?
Measurements taken under different conditions will yield different 
results.  "observable reality" includes both kinds of results.

> Call me impressed.
Has it ever occurred to you that I've been using 6to4 since before the 
RFC was published and that I've seen a lot of different behaviors by 
now?   Has it ever occurred to you that I could pick ISPs on the basis 
of whether they were hostile to 6to4?

Of course I'm aware that relay routers can go away - that's why I have 
no problem (ok, not much problem) with deprecating RFC 3068. But in my 
case the relay router didn't go away - it appears that one of my ISPs 
(soon to be ex-ISP) started blocking it.  (because I'm getting ICMP net 
unreachables).

When to some degree the problems with 6to4 result from operator attacks 
on it, I don't think that's something that IETF should be supporting - I 
think IETF should be calling operators out on it.

> measurements and results)

Because you don't really care about measurements and results?

Keith

---

From: Gert Doering <[email-masked]>
Date: Fri, 31 Oct 2014 15:53:48 +0100

Hi,

> (soon to be ex-ISP) started blocking it.  (because I'm getting ICMP net 

So would you be fine with the document saying "3065 is good, 3068 should
be deprecated"?

From your e-mails it is still fully unclear to me whether you're talking
about peer-to-peer 6to4 or 6to4-to-native, and to which part you're 
objecting - and it has been said often enough that nobody will take 
away your peer-to-peer 6to4 (and the draft is actually fairly clear
about that).

> think IETF should be calling operators out on it.

The problem with 6to4-to-native isn't operators actively attacking relays,
more operators loosing interest in proper maintenance - as in "the person
who set this up left the company, nobody knows it's still there, the
router is overloaded and drops packets".

Since nobody is paying for it, and it's very hard to actually figure out
who to yell at in the generic relay case, this is just a model that is
not sustainable, without any malevolence involved - no matter how often 
you call it "attacking".

> Because you don't really care about measurements and results?

Oh, I do.  (And while I *do* maintain and monitor my relay, I have spent
enough time debugging 6to4 with "some other relay being used for the
return path" to understand that this is not the solution we're looking
for, no matter what the problem is)

Gert Doering
        -- NetMaster

---

From: "Metzler, Dan J" <[email-masked]>
Date: Fri, 31 Oct 2014 14:54:23 +0000

> From: Keith Moore [mailto:[email-masked]]
> Sent: Friday, October 31, 2014 9:37 AM
> To: Metzler, Dan J; Alexandru Petrescu; Brian E Carpenter; Owen DeLong
> Cc: [email-masked] WG
> > I agree with the statement regarding mentioning alternatives in the
> document, (perhaps in the introduction?), but I'd point out the tunneling
> protocol(s) that could be used as an alternative, and then if desired,
> optionally list some tunnel brokers along with that information.  Hurricane
> Electric is 6in4 or straight tunneling in protocol 41, which is not affected by
> this document.
> >
> > I wonder if perhaps some of the confusion from the discussion on this list
> is from a faulty assumption that this document might be getting rid of the
> protocols used by the tunnel brokers.
> > For example, if a Hurricane Electric tunnel relied on 6to4, that may lead
> one to the impression that one should no longer use a tunnel broker like
> Hurricane Electric because of the statement that 6to4 is deprecated.
> 
> I've seen protocol 41 being blocked - literally transmitted packets from one
> host to another (with no NAT in between) where protocol 6 packets
> 6in4.  I've read accounts that indicate that other providers are also doing
> this.
> 
> One of the things I don't want is an RFC published that legitimizes this in any
> sense, even an oblique one.
> 

I didn't see anything that implied support for blocking protocol 41 in this draft.
Adding language in support of 6in4 as an alternative would certainly not legitimize the blocking of protocol 41.
Am I missing something?

That said, if you already have native IPv6 available, I can see where a provider might want to block it.

---

From: Owen DeLong <[email-masked]>
Date: Fri, 31 Oct 2014 08:02:57 -0700

> I can find, and my D-Link box is old.)

Yes… Manually configured tunnels. Not sure which RFC, but if you look at the instructions available on http://tunnelbroker.net
you will find a great many examples for various routers, including for example, the Apple Airports complete with screenshots.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Fri, 31 Oct 2014 08:23:05 -0700

> On Oct 31, 2014, at 4:03 AM, Alexandru Petrescu <[email-masked]> wrote:
> 
> Hi Brian,
> 
> I take advantage of your invitation to suggest text changes although I am not sure it covers topics unrelated to the one discussed in that email.
> 
> I think the document should mention what are the recommended alternatives.  Until now we see recommendations of particular tunnel brokers such as Hurricane Electric's (is it really that company behind it or just a reuse from a distant past?) and SixXs or AYIYA, and also recommendations to move to native IPv6.
> 
> - tunnel broker should be considered as intermediate solution to native IPv6 and as such may incur additional renumbering efforts.
> - tunnel broker offers some advantages over 6to4, e.g. IPsec security is possible because it's not an anycast address.
> - tunnel broker creates new inconvenients, e.g. a new 'focal point' or single point of failure.

A tunnel broker is only a single point of failure if you use only one tunnel to one tunnel broker.

If you use diversity of tunnel brokers, and/or a tunnel broker and other transit, it is not a single point of failure at all.

Owen

---

From: Philip Homburg <[email-masked]>
Date: Fri, 31 Oct 2014 16:29:12 +0100

>measurements and results)

Random data point, a ping from all IPv6 capable probes on RIPE Atlas to one
target, gives:
(all probes)
 388 rcvd":0
   2 rcvd":1
   9 rcvd":2
2140 rcvd":3

(probes with a 6to4 address)
  12 rcvd":0
   1 rcvd":2
  36 rcvd":3

3 ICMP echo requests were sent, this is the number of probes that report a certain number of replies.

I'd say that based on these stats, 6to4 probes are not a lot worse than average.

---

From: Gert Doering <[email-masked]>
Date: Fri, 31 Oct 2014 16:31:53 +0100

Hi,

> I'd say that based on these stats, 6to4 probes are not a lot worse than average.

Is "send a one-way ping" a useful metric for "we have a problem with
return relays" or "the RTT increases in a way that this is way worse
than IPv4"?

But it's interesting how poor IPv6 reliability for "Atlas probes with
IPv6" is.

Gert Doering
        -- NetMaster

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 31 Oct 2014 15:39:03 +0000

> I'd say that based on these stats, 6to4 probes are not a lot worse than average.

100% packet loss reported by:

non 6to4 probes: (388-12)/(2140-36) = 17.8%
6to4 probes: 12/36 = 33.3%

So there's a substantial difference.  That said, it would be a mistake to
treat this as data - the low 6to4 sample size will not generate
statistically significant numbers.

Nick

---

From: Philip Homburg <[email-masked]>
Date: Fri, 31 Oct 2014 16:50:21 +0100

>statistically significant numbers.

I'm sort of surprised we are having this discussion. Assuming 6to4 users are just a
tiny fraction of all IPv6 users, and that there is way more brokenness than just 6to4,
what's the point of actively trying to kill 6to4?

Let the relays run on auto-pilot and die of old age. And let applications deal with
brokenness in general.

Note: lots of RIPE Atlas probes end up with ULA addresses even when there is fine IPv4
connectivity. To me that seems like a way more interesting failure mode than a few
broken 6to4 connections.

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 31 Oct 2014 16:00:25 +0000

> what's the point of actively trying to kill 6to4?

Nobody's trying to kill it.  The document is a statement from the IETF that
6to4 is moribund as a protocol and that future developments should steer
clear of it.

Right now there are two standards track RFCs which explicitly means that
6to4 is recommended for production use by the IETF.  The move to historic
status changes that status to: "no longer recommended for use".

There's more information on what historic status means here:

https://www.ietf.org/iesg/statement/designating-rfcs-as-historic.html

Nick

---

From: Ole Troan <[email-masked]>
Date: Fri, 31 Oct 2014 17:01:43 +0100

Keith,

> Any application that uses IPv6 and involves some hosts that don't have native (non-NATted) IPv4 access.

I was thinking of this in a post deprecated rfc3068 world. where 6to4 out of the box was less likely to give access to the IPv6 Internet. would then an isolated 6to4 overlay have value?

> There's nothing wrong with putting 6to4 addresses in DNS, just like there's nothing wrong with putting ULIAs in DNS.

sure, as long as all hosts/applications throw all the spaghetti on the wall that works.

> What do you mean by "address sharing"?   (If you mean the same v4 address is associated with multiple end sites using carrier-side NAT, I agree.)

or any of the umpteen other ways. MAP-E, MAP-T, 4rd, LW4over6, DS-lite, NAT444, +++. most of these apart from NAT444, would have native IPv6 though, and presumably updated gear where 6to4 code isn't there.

> No, it's because global v4 addresses are scarce and 6to4 provides a way around that.

6to4 doesn't really do that.

cheers,
Ole

---

From: Owen DeLong <[email-masked]>
Date: Fri, 31 Oct 2014 09:18:07 -0700

> That said, if you already have native IPv6 available, I can see where a provider might want to block it.

Observable reality is that AT&T is blocking protocol 41 where IPv6 is NOT available.

Owen

---

From: James Woodyatt <[email-masked]>
Date: Fri, 31 Oct 2014 09:55:35 -0700

On Fri, Oct 31, 2014 at 7:53 AM, Gert Doering <[email-masked]> wrote:

> > no problem (ok, not much problem) with deprecating RFC 3068. [...]
>

I'm just catching up to this discussion now, and I'd like to reaffirm my
support for moving RFC 3068 to historic, but I'd also like to express my
desire to hesitate with moving RFC 3065 to historic while IPv4 is still the
dominant version.

My concern is that moving RFC 3065 to Historic status and marking the
2002::/16 prefix as deprecated and recommending "no new implementations"
will send a message to the large enterprises currently maintaining the
dominant host operating system dual-stack IPv4/IPv6 implementations that
"removing from existing implementations" is also appropriate at this time.
I think the case for going beyond removing support for anycast 6to4 relay
routers to removing all support for host-to-host 6to4 is not very strong.

Elsewhere in this thread, Lorenzo offered one reason to keep from
instructing IANA to mark the 2002::/16 prefix as deprecated, and I
sympathize with his view.  I think it stands in contrast to the assertion
that usage of pure RFC 3065, i.e. without RFC 3068, can reasonably be
described as practically nil.  I could offer other similar reasons. Some
people are certainly using RFC 3065 (not RFC 3068) today to solve real
problems they are facing while IPv4 is still the dominant IP version in
deployed equipment.

It's my view that moving only RFC 3068 to Historic should have the
practical effect of making the 6to4 addresses into a special kind of unique
local address suitable for use in private where IPv4-only routes are still
operationally dominant.  While IPv4 is still in widespread use, I think
having a tunnel mechanism in most host operating systems, which is designed
to allow these unique-local global scope addresses to be useful on private
networks or between peers in bilateral agreement, is a good idea, and I
sort of wish this draft had been written expressly to communicate that
view.  I believe that telling OS engineers to remove all support for 6to4
now, which is how I think this current draft will be interpreted in
practice when published, will have the effect of taking away a useful tool
for IPv6 transition from people who are faced with real problems caused by
legacy deployments of IPv4-only network equipment that has not yet reached
its end of life.

I do understand [and sympathize to some extent] with those who would like
to burn 6to4 entirely to the ground and salt the earth where it once grew.
The damage attributable to RFC 3068 is considerable, and I can well
appreciate the urge to post giant warning signs around its perimeter at a
distance of several kilometers cautioning even the most skilled adventurers
of the grave risks of approaching it under any circumstances. Nevertheless,
I do feel like moving RFC 3065 to Historic at this time is premature.

Shorter james: I would prefer to move only RFC 3068 to Historic now, and
not to move RFC 3065 to Historic until IPv4 is no longer the dominant IP
version.

-- 
james woodyatt <[email-masked]>
Nest Labs, Communications Engineering

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 31 Oct 2014 17:02:12 +0000

> but I'd also like to express my desire to hesitate with moving RFC 3065 to historic

RFC 3065 is already obsoleted by RFC 5065.

Thanks - Fred
[email-masked]

---

From: James Woodyatt <[email-masked]>
Date: Fri, 31 Oct 2014 10:06:09 -0700

My mistake.  I meant RFC 3056.  I should have double-checked my memory of
the relevant RFC number.

On Fri, Oct 31, 2014 at 10:02 AM, Templin, Fred L <[email-masked]

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 31 Oct 2014 17:15:10 +0000

> My mistake.  I meant RFC 3056.  I should have double-checked my memory of the relevant RFC number.

No worries; I think I saw someone else juxtapose the 5 and 6 in an earlier message too.

While I have the floor, I know of at least one enterprise that uses public IPv4 addresses
internally. Some devices inside the enterprise see the public addresses and then assume
they can use 6to4. They then set up a 6to4 virtual interface with a 2002:* address assigned,
i.e., even though the enterprise has not deployed a 6to4 service.

What would deprecation mean to this class of devices?

Thanks - Fred

---

From: Jeroen Massar <[email-masked]>
Date: Fri, 31 Oct 2014 18:15:26 +0100

> I can find, and my D-Link box is old.)

Fritz!Box definitely has tunnel support.

Fritz!Box even has built-in SixXS tunnel support (proto-41 + heartbeat +
TIC for configuration. And there is even a node in New Zealand.

Greets,
 Jeroen

---

From: "Metzler, Dan J" <[email-masked]>
Date: Fri, 31 Oct 2014 18:15:04 +0000

> From: Owen DeLong [mailto:[email-masked]]
> Sent: Friday, October 31, 2014 11:18 AM
> To: Metzler, Dan J
> Cc: Keith Moore; Alexandru Petrescu; Brian E Carpenter; [email-masked] WG

I don't have any kind of business relationship with AT&T, but if I were a customer, I'd be asking them for my native IPv6 access at that point.  I don't pretend to suggest that there aren't people blocking protocol 41 for no reason other than fear, and I generally don't think it's good for a provider to block protocol 41 until they've provided some alternative.

Here's a conversation I had with someone from a somewhat small ISP downstream from a larger ISP.
Q: "So do you have any plans for deploying IPv6?"
A: "Not really.  We've got other projects we're working on, and our customers haven't really asked for it."
Q: "Well if you wait until your customers are demanding it, considering most of them are unaware of anything called IPv4, let alone IPv6, won't it be too late?"
A: "Well, we've been watching the traffic, and we just haven't seen any demand for it."
Q: "How would you recognize the demand?"
A: "Well, we haven't seen any tunneling, like Teredo or 6to4 traffic."

I've never forgotten that exchange because I think it is somewhat representative of the attitude of some ISPs in general, who are not simply running out of IPv4 address space because they obtained it long ago, and one benefit of tunneling like this, is just to show ISPs that there is demand.  For situations like that, an ISP can get rid of these tunnels by beginning an IPv6 implementation, which perhaps just starts as 6rd.

With regard to the document in question though, since it does not deprecate protocol 41 or even lobby against its use, I don't see how that particular issue is relevant.  We're just talking about 6to4, which is a layer above protocol 41.  The point is I'm in favor of providing reliable tunnel mechanisms to get IPv6 connectivity where network providers refuse to provide native IPv6, but 6to4 as implemented today, is probably not the best option for that.

- Dan Metzler

---

From: Ray Hunter <[email-masked]>
Date: Fri, 31 Oct 2014 19:55:15 +0100

> [email-masked]
I suspect very little will change in practice. My own experience is that 
6to4 was rarely turned on intentionally, but quite often 
unintentionally, causing harm. Turning it off unintentionally, or 
removing the feature completely, is more likely to be beneficial rather 
than harmful IMHO.

I'm not per se against retaining RFC3056 for use between consenting 
adults where it has been explicitly configured.

I certainly didn't like the implementation assumptions of it being 
enabled automatically (but that has already been fixed in 6343 Section 
4.1), and marking 6to4 preferable to pure or NATted IPv4 by default in 
3484 (which has also already been fixed in 6724 Section 10.7).

Your mileage may vary with currently deployed production code, and 
writing another IETF doc won't likely change that, whether it marks 6to4 
as historic or not. You might have to pay a higher maintenance fee 
though to retain this premium feature.

OTOH 3068 IMHO does need to be labelled harmful and historic.

-- 
Regards,
RayH

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 01 Nov 2014 08:41:03 +1300

> Observable reality is that AT&T is blocking protocol 41 where IPv6 is NOT available.

This illustrates rather neatly why in my opinion it would be a mistake
to start listing alternatives to 6to4 in *this* document. We have
been designing a ridiculously large number of coexistence techniques
since 1994, and look where it's got us. I don't object to adding a statement
that there are various tunneling mechanisms that do not have the same
problems as 6to4, but attempting to describe and pseudo-recommend them
would just start a non-convergent discussion. (Well, it's already started.)

Let's just whack one mole at a time.

  Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 01 Nov 2014 08:45:30 +1300

> BTW, adding 192.88.99.0/24 to the bogons will not really help in anyway as the client (the entry point in the 6to4 tunnel) will not be able to signal the IPv6 node of lack of IPv6 connectivity in m…

As discussed in RFC 6343, indeed. No news here. But if there is no route,
diagnostics should be easier.

   Brian

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 31 Oct 2014 20:28:26 +0000

> From: v6ops [mailto:[email-masked]] On Behalf Of Brian E Carpenter
> Sent: Friday, October 31, 2014 12:41 PM
> To: Owen DeLong
> Cc: Keith Moore; [email-masked] WG
> Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt - alternatives to 6to4
> 

Or, we could just say "use AERO" and be done with it. But, AERO is not a
coexistence technique - it is long-term evolution (to borrow an apt phrase).

Thanks - Fred

---

From: Gert Doering <[email-masked]>
Date: Fri, 31 Oct 2014 22:40:16 +0100

Hi,

> RFC 3065 is already obsoleted by RFC 5065.

James was quite obviously talking about 3056 (and 3068).

Gert Doering
        -- NetMaster

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 01 Nov 2014 13:07:40 +1300

Bundling up a few short points:

On 01/11/2014 03:17, Keith Moore wrote:
...
> The latter statement is simply false.

Well, the statement needs to be deconstructed.

1. 6to4-to-native, not using the anycast method, works if and
only if routing is carefully configured as described in RFC 3056.
It's critical, for example, that every native IPv6 host involved sees
a route to 2002::/16 that leads to a properly configured return relay.

2. 6to4-to-native using the anycast method fails in a quite high
proportion of cases because of all the issues descrived in RFC 6343.

> What would deprecation mean to this class of devices?

Until somebody upgrades the host software in a way that removes 6to4,
nothing, as far as I can see. It's just the same as p2p 6to4 on the
Internet, isn't it?

    Brian