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

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 1 Nov 2014 18:50:10 +0900

On Fri, Oct 31, 2014 at 9:12 AM, Brian E Carpenter <
[email-masked]> wrote:

> Anyway, please suggest text changes.
>

So, the problem is not peer-to-peer 6to4 or even relayed 6to4. Both of
these work fine, if the clients, the relay routers, and the native nodes
are in the same administrative domain. The problem is attempting to run an
service where:

   1. Users and servers may be anywhere on the Internet.
   2. No single entity is responsible for the relay router functionality.
   3. The reverse path is essentially random.
   4. Implementations use the service by default.

Note that neither #1 or #2 apply to successful anycast services like the
root servers, because a) there is always a single entity responsible for
each anycasted root server prefix, and b) the return path is via standard
unicast.

I think we all agree that there is ample evidence that this operational
model does not work on the Internet. But it can be made to work in limited
domains, e.g., inside one network, or between two or more parties that all
maintain and support a 6to4 relay router (and that for some reason cannot
use native IPv6). Therefore, I think the document should say:

   1. Experience with RFC3068-style anycast 6to4 relay routers on the
   Internet shows that service is often slow and unreliable, because <whatever
   reasons we can get consensus on; either the ones above, or whatever others>.
   2. Pointing a default route at a relay router is NOT RECOMMENDED.
   3. Implementations of 6to4 MAY allow configuring the IPv4 address of a
   relay router, but MUST NOT use a 6to4 relay router by default.
   4. Using the 192.88.99.1 anycast address is NOT RECOMMENDED.

Thoughts?

Cheers,
Lorenzo

---

From: Tim Chown <[email-masked]>
Date: Sat, 1 Nov 2014 10:35:23 +0000

On 30 Oct 2014, at 23:06, Owen DeLong <[email-masked]> wrote:
>> 
>> 
>>> On 31/10/2014 06:06, Antonio Querubin wrote:.
>>> 
>>> 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?
> 
> 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
> 
> There’s even help for exactly how to configure a variety of systems and routers.

Exactly. This works.

It's conceptually/practically as easy to use as a VPN service. 

Tim

---

From: "Templin, Fred L" <[email-masked]>
Date: Sat, 1 Nov 2014 15:34:12 +0000

Hi Brian,

> -----Original Message-----
> From: v6ops [mailto:[email-masked]] On Behalf Of Brian E Carpenter
> Sent: Friday, October 31, 2014 5:08 PM
> To: Keith Moore
> Cc: [email-masked]
> Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt
> 
> Bundling up a few short points:
> 
> On 01/11/2014 03:17, Keith Moore wrote:
> ...
> >> 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
> >
> > 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.
> 
> On 01/11/2014 06:15, Templin, Fred L wrote:
> 
> > 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?
> 
> 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?

Can I read this as: "Why fix what a'int broken"?

Thanks - Fred
[email-masked]

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

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 02 Nov 2014 08:16:17 +1300

> It's conceptually/practically as easy to use as a VPN service. 

Which means that it's not zerotouch. It is not fixed by "Did you try
switching it off and on again?" The problem with anycast 6to4 is that
it was a failed attempt at zerotouch IPv6, and that's what we're
really trying to get away from.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 02 Nov 2014 08:23:28 +1300

Lorenzo,

>    reasons we can get consensus on; either the ones above, or whatever others>.

Actually we've been there and done that: RFC 6343 gives details. No need
to rehash it IMHO.

>    2. Pointing a default route at a relay router is NOT RECOMMENDED.

Hang on, which default route do you mean?

>    relay router, but MUST NOT use a 6to4 relay router by default.

The new point here is the MAY. The rest is already stated, in different
words.

>    4. Using the 192.88.99.1 anycast address is NOT RECOMMENDED.

Sure. But again, I think that is a restatement of what the draft
already says.

Anyway: I'm taking this as a hands up for deprecate 3068, leave 3056
alone.

---

From: Owen DeLong <[email-masked]>
Date: Sat, 1 Nov 2014 19:01:45 -0700

> 
> 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.

Many have tried. Unfortunately, attempts to put pressure on AT&T by consumers are roughly equivalant to attempting to use one's thumb to compress a marshmallow into submission. Your thumb gets messy, but the marshmallow doesn't care.

In this regard, think of AT&T as a giant death-star shaped marshmallow only more bitter than sweet.

> 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.

Yep.

> 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.

I agree. However, I'm not quite to the point of saying it should certainly be declared deprecated as yet.

Owen

---

From: "Metzler, Dan J" <[email-masked]>
Date: Sun, 2 Nov 2014 13:37:10 +0000

> From: Owen DeLong [mailto:[email-masked]]
> Sent: Saturday, November 1, 2014 9:02 PM
> To: Metzler, Dan J
> Cc: Keith Moore; Alexandru Petrescu; Brian E Carpenter; [email-masked] WG
> Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt -
> alternatives to 6to4
> 
> >
> > 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.
> 
> Many have tried. Unfortunately, attempts to put pressure on AT&T by
> consumers are roughly equivalant to attempting to use one's thumb to
> compress a marshmallow into submission. Your thumb gets messy, but the
> marshmallow doesn't care.
> 

While I understand that there is a large degree of truth to this, I disagree with regard to the notion that any real attempts have been made to put pressure on AT&T or similar ISPs.  To put it in a less confrontational way, I don't think there have been attempts to provide ISPs with the necessary guidance or tools to know what the correct behavior is.  For example how about an RFC that defines standards of acceptable ISP behavior and provides a grading system.  This is something that customers can use when shopping for ISPs.  We could give classifications based on certain standards.
For example from an IPv6 perspective:
"A" - ISP implements Native IPv6 and/or 6rd
"D" - ISP implements no Native IPv6, and provides no 6rd, but ISP does not block any traffic including that which might allow a customer to implement IPv6.
"F" - ISP blocks traffic according to its own policies without customer endorsement. (Not the function of an ISP.)

Something like this would allow for a meaningful conversation with ISPs like AT&T, and provide context for rating ISPs in terms of brokenness of their implementations, and a basis for publishing that information.  Of course these categories would not just be limited to the context of IPv6 adoption, would have to be maintained as technologies come and go, and would provide a more general measure for reliability and basic functionality.

ISPs that claim grade A according to RFC #### could advertise that, and customers could be assured by sticking with grade A ISPs, they can accomplish anything they need to in terms of standard internet functionality.  A simple Wiki could be maintained by communities regarding what the grades or for various ISPs.  

In any case, my point is, while individuals may have complained to somebody working at AT&T, at various times, no real pressure has been put on AT&T or any other ISP, even to adopt IPv6 or to allow for customers to do so.  No incentives have been provided either.  We've thus far relied only on the notion that they will work toward the goal as they see an impact from lack of IPv4 addresses.  The idea that I would, as a customer ask, "where is my native IPv6", was less about applying pressure, and more about starting the conversation about what they could provide me as a customer.

---

From: Lorenzo Colitti <[email-masked]>
Date: Sun, 2 Nov 2014 23:56:25 +0900

You are aware that fully 25% of AT&T's users do have IPv6, right?
On 2 Nov 2014 10:37 pm, "Metzler, Dan J" <[email-masked]> wrote:

> > Subject: Re: [v6ops] I-D Action:
> draft-ietf-v6ops-6to4-to-historic-06.txt -
> > alternatives to 6to4
> >
> > >
> > In this regard, think of AT&T as a giant death-star shaped marshmallow
> only
> > more bitter than sweet.
> >
>
> While I understand that there is a large degree of truth to this, I
> disagree with regard to the notion that any real attempts have been made to
> put pressure on AT&T or similar ISPs.  To put it in a less confrontational
> way, I don't think there have been attempts to provide ISPs with the
> necessary guidance or tools to know what the correct behavior is.  For
> example how about an RFC that defines standards of acceptable ISP behavior
> and provides a grading system.  This is something that customers can use
> when shopping for ISPs.  We could give classifications based on certain
> standards.
> "D" - ISP implements no Native IPv6, and provides no 6rd, but ISP does not
> block any traffic including that which might allow a customer to implement
> IPv6.
> "F" - ISP blocks traffic according to its own policies without customer
> endorsement. (Not the function of an ISP.)
>
> Something like this would allow for a meaningful conversation with ISPs
> like AT&T, and provide context for rating ISPs in terms of brokenness of
> their implementations, and a basis for publishing that information.  Of
> course these categories would not just be limited to the context of IPv6
> adoption, would have to be maintained as technologies come and go, and
> would provide a more general measure for reliability and basic
> functionality.
>
> ISPs that claim grade A according to RFC #### could advertise that, and
> customers could be assured by sticking with grade A ISPs, they can
> accomplish anything they need to in terms of standard internet
> functionality.  A simple Wiki could be maintained by communities regarding
> what the grades or for various ISPs.
>
> In any case, my point is, while individuals may have complained to
> somebody working at AT&T, at various times, no real pressure has been put
> on AT&T or any other ISP, even to adopt IPv6 or to allow for customers to
> do so.  No incentives have been provided either.  We've thus far relied
> only on the notion that they will work toward the goal as they see an
> impact from lack of IPv4 addresses.  The idea that I would, as a customer
> ask, "where is my native IPv6", was less about applying pressure, and more
> about starting the conversation about what they could provide me as a
> customer.
>

---

From: "Metzler, Dan J" <[email-masked]>
Date: Sun, 2 Nov 2014 16:35:38 +0000

No.  (Thanks for pointing that out.)  And I didn’t necessarily mean to single out AT&T beyond responding to the earlier comment that did.  (As I said I have no business relationship with AT&T, nor any past experience with them.)

That said, back to the original discussion, involving protocol 41, if AT&T is truly blocking protocol 41 because they provide IPv6 native support across the board already, that seems a lot less unreasonable.  And, if I as a customer then go ask for my native IPv6 connections, then the answer will be, “certainly, here you go.”

Thanks,

-        Dan

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: Sunday, November 2, 2014 8:56 AM
To: Metzler, Dan J
Cc: Keith Moore; Owen DeLong; [email-masked] WG
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt - alternatives to 6to4

You are aware that fully 25% of AT&T's users do have IPv6, right?
On 2 Nov 2014 10:37 pm, "Metzler, Dan J" <[email-masked]<mailto:[email-masked]>> wrote:

> From: Owen DeLong [mailto:[email-masked]<mailto:[email-masked]>]
> Cc: Keith Moore; Alexandru Petrescu; Brian E Carpenter; [email-masked]<mailto:[email-masked]> WG

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

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 03 Nov 2014 08:40:21 +1300

Dan,

There was an attempt to define what Internet service means in a broader
sense, some years ago: RFC 4084 (aka BCP 104).

However, it isn't at all clear that the IETF is the right vehicle
for such an effort, except for providing technical definitions.

    Brian

On 03/11/2014 02:37, Metzler, Dan J wrote:
> .

---

From: Keith Moore <[email-masked]>
Date: Mon, 03 Nov 2014 00:09:59 -0500

On 11/02/2014 11:35 AM, Metzler, Dan J wrote:
> That said, back to the original discussion, involving protocol 41, if 
> AT&T is truly blocking protocol 41 because they provide IPv6 native 
> support across the board already, that seems a lot less unreasonable.
protocol 41 isn't just IPv6 over IPv4.

Keith

---

From: Jeroen Massar <[email-masked]>
Date: Mon, 03 Nov 2014 07:34:41 +0100

> protocol 41 isn't just IPv6 over IPv4.

What "else" is it then? :)

Yes, 6in4 (as in tunnelbrokers), 6rd, 6to4 and some others use it.

But blocking proto-41 blocks in essence anything that is transmitting
proto-41 packets and thus "IPv6 over IPv4".

The problem here is a ISP policy decision though; AT&T should not be
blocking things in the first place. Contact AT&T to resolve that matter,
nothing the IETF can do about (except suggesting alternative protocols
to circumvent such a block).

Greets,
 Jeroen

---

From: Jeroen Massar <[email-masked]>
Date: Mon, 03 Nov 2014 08:13:16 +0100

On 2014-11-03 07:56, Erik Kline wrote:
> Yes, clearly we're going need IPv4(TCP(TLS(HTTP(IPv6))))).

Already exists in a variety of ways ;)

One extreme method of circumvention:

OpenVPN in TCP mode using SOCKS over StegoTorus[1] with the help of
JumpBox[2] to make sure it really looks like a normal web browser.

Though AYIYA "circumvents" AT&T and even the real Great Big Firewall
quite well actually... as they do not know that they can block it.

Greets,
 Jeroen

[1] https://github.com/SRI-CSL/stegotorus
    http://freehaven.net/anonbib/cache/ccs2012-stegotorus.pdf

[2] https://github.com/SRI-CSL/jumpbox
    http://jeroen.massar.ch/publications/files/SECURECOMM2014-JumpBox.pdf

http://jeroen.massar.ch/presentations/files/SECURECOMM2014-JumpBox-pres.pdf

---

From: "Metzler, Dan J" <[email-masked]>
Date: Mon, 3 Nov 2014 11:44:22 +0000

“protocol 41 isn't just IPv6 over IPv4”
In IPv4, isn’t it?  It’s pretty much designated for IPv6 encapsulation.  There are a variety of protocols that accomplish the same goal, IPv6 encapsulation, using that port, but all to carry IPv6 over IPv4 in some manner.
I still don’t think it is an ISP’s job to block any one protocol, including 41, but if they provide native IPv6, it is less unreasonable because at least they already provide native IPv6 connectivity.  Once your providers provide native IPv6, why would we even need IPv4 protocol 41?  At that point it’s silly to tunnel v6 in v4 when you can just be more efficient with dual stack, right?
(The reason it is just “less unreasonable” is because the blocking ISP <AT&T in this case> may be serving other providers who haven’t provided native IPv6, and those providers may need access to tunnel to their tunnel endpoints or brokers.)

From: Keith Moore [mailto:[email-masked]]
Sent: Sunday, November 2, 2014 11:10 PM
To: Metzler, Dan J; Lorenzo Colitti
Cc: Owen DeLong; [email-masked] WG
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt - alternatives to 6to4

On 11/02/2014 11:35 AM, Metzler, Dan J wrote:
That said, back to the original discussion, involving protocol 41, if AT&T is truly blocking protocol 41 because they provide IPv6 native support across the board already, that seems a lot less unreasonable.
protocol 41 isn't just IPv6 over IPv4.

Keith

---

From: James Woodyatt <[email-masked]>
Date: Mon, 3 Nov 2014 10:57:37 -0800

> nothing, as far as I can see. It's just the same as p2p 6to4 on the

I think moving RFC 3068 to Historic while keeping RFC 3056 on the Standards
Track should be sufficient to keep devices like that from being
deprecated.  As long as they're not self-assigning an IPv6 default route,
and they're only giving themselves a local 2002::/16 route to the 6to4
tunnel, everything should be fine.  Moving RFC 3068 to History should be
sufficient to communicate to the maintainers of the software for those
devices that acquiring an IPv6 default route for traffic originating at
their 6to4 sources addresses entails some kind of manual or locally
automated configuration.

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

---

From: Owen DeLong <[email-masked]>
Date: Mon, 3 Nov 2014 13:19:41 -0800

I would argue that 6rd, CGN, or NAT64 should move you into a “B” at best for starters.

Further, I don’t think that making market judgments of particular carriers is within the charter of the IETF. This moves out of the realm of technical standards into product comparison and I would expect substantial backlash against the IETF attempting to take on that role.

It might be something NANOG or IOL or ISOC or some other group could take on, but I can’t see this fitting in the IETF charter.

Owen

> On Nov 2, 2014, at 5:37 AM, Metzler, Dan J <[email-masked]> wrote:
> 
> 
>

---

From: Mark Andrews <[email-masked]>
Date: Tue, 04 Nov 2014 09:52:18 +1100

In message <[email-masked]>, 
"Metzler, Dan J" writes:
> protocol 41 isn't just IPv6 over IPv4
> In IPv4, isnt it?  Its pretty much designated for IPv6 encapsulation.  
> There are a variety of protocols that accomplish the same goal, IPv6 
> encapsulation, using that port, but all to carry IPv6 over IPv4 in some 
> manner.
> I still dont think it is an ISPs job to block any one protocol, including 
> 41, but if they provide native IPv6, it is less unreasonable because at 
> least they already provide native IPv6 connectivity.  Once your providers 
> provide native IPv6, why would we even need IPv4 protocol 41?

Why do you need vpn's?  Why do you need IPv4 in IPv4 tunnels.  Why
do you need GRE tunnels.  Why do you need IPv6 in IPv6 tunnels?

It is not the ISP's job to filter traffic.  As long as it is being
source with a legitimate address the ISP should just pass the packet
along.  If the ISP's routers can't pass the packet they should be
replaced.  This include routers that can't pass fragmented packets.

You pay the ISP to deliver packets.

> At that 
> point its silly to tunnel v6 in v4 when you can just be more efficient 
> with dual stack, right?
> (The reason it is just less unreasonable is because the blocking ISP 
> <AT&T in this case> may be serving other providers who havent provided 
> native IPv6, and those providers may need access to tunnel to their 
> tunnel endpoints or brokers.)
> 
> 
> From: Keith Moore mailto:[email-masked]
> Subject: Re: v6ops I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt - 
> alternatives to 6to4
> 

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

---

From: Owen DeLong <[email-masked]>
Date: Mon, 3 Nov 2014 15:53:10 -0800

> On Nov 2, 2014, at 9:09 PM, Keith Moore <[email-masked]> wrote:
> 

What else is it? GRE is Protocol 47.

To the best of my knowledge, 41 is only used for 6in4 and 6to4.

However, AT&T isn’t just blocking 41 for users that they provide 6rd for. They are also blocking it for virtually all of their users that don’t have IPv6 access.

Owen

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 4 Nov 2014 00:03:21 +0000

ip-proto-41 is also for 6in6 (RFC2473).

Thanks – Fred

From: v6ops [mailto:[email-masked]] On Behalf Of Owen DeLong
Sent: Monday, November 03, 2014 3:53 PM
To: Keith Moore
Cc: [email-masked] WG
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt - alternatives to 6to4

On Nov 2, 2014, at 9:09 PM, Keith Moore <[email-masked]<mailto:[email-masked]>> wrote:

Keith

Owen

---

From: Keith Moore <[email-masked]>
Date: Mon, 03 Nov 2014 19:12:23 -0500

On 11/03/2014 06:53 PM, Owen DeLong wrote:
>
>> On Nov 2, 2014, at 9:09 PM, Keith Moore <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>>> That said, back to the original discussion, involving protocol 41, 
>>> if AT&T is truly blocking protocol 41 because they provide IPv6 
>>> native support across the board already, that seems a lot less 
>>> unreasonable.

I thought protocol 41 was generally used for IP (of whatever version) 
encapsulated in IP (of whatever version).  IANA's protocol number 
registry seems to cite RFC 2473, which is about encapsulating various 
kinds of things in IPv6  (though admittedly the distinction between the 
different registries isn't very clear).  Of course 6to4, 6over4, 6in4 
all use protocol 41 and all encapsulate things over IPv4.   What I 
haven't found is a use of protocol number 41 to encapsulate IPv4 in 
something else, so I might have been mistaken about that.

Keith

---

From: Jeroen Massar <[email-masked]>
Date: Tue, 04 Nov 2014 01:26:57 +0100

On 2014-11-04 01:12, Keith Moore wrote:
> encapsulated in IP (of whatever version).

No. If you see a value of '41' in a "protocol" or "next header" field
then it means the next header/protocol is IPv6.

For IPv4 in IPv6(or something else) you would use a next header of 4.

eg 4in4 would be [IPv4, protocol = 4][IPv4, protocol = TCP/UDP/etc]
eg 6in4 would be [IPv4, protocol = 41][IPv6, next header = TCP/...]
eg 6in6 would be [IPv6, next header = 41][IPv6, next header = TCP/...]
eg 4in6 would be [IPv6, next header = 4]][IPv4, protocol = TCP/...]
etc

> IANA's protocol number
> different registries isn't very clear).

Nack. 2743 is effectively about 6in6.

If you peek at:
https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml

You'll see it points at the similar number 2473.

Note that the middle two digits are swapped with the previous one, which
is likely where you got that honest mistake from.

And as most people call 6in4/tsp/ayiya/etc "IPv6 tunnels" 2743 does not
make this terminology much easier either ;)

> Of course 6to4, 6over4, 6in4
> all use protocol 41 and all encapsulate things over IPv4.

Don't forget about 6rd and all other protocols, eg AYIYA who indicate a
'next header' field of 41 to indicate IPv6 packets following there.

> What I

Because 41 is not meant for that. You need '4' for that (RFC2003).

Fun point there is that there is also 94 aka "ipip" but that is a
completely different beast again that is afaik nwhere to be found how it
is actually used.

Oh, yes all of this is fun and confusing ;)

(Not even going to GRE which uses the 802.11 'next header' numbers...)

Greets,
 Jeroen

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 4 Nov 2014 10:32:24 +0900

> Hang on, which default route do you mean?

There's only one default route.

> Sure. But again, I think that is a restatement of what the draft

The key point is that what I'm suggesting says LESS than the draft
currently says, which will hopefully help escape the dozens of messages of
arguments we're currently mired in.

---

From: Keith Moore <[email-masked]>
Date: Mon, 03 Nov 2014 21:46:24 -0500

> support across the board already, that seems a lot less unreasonable.
Disagree.   There are valid reasons for customers to be using protocol 
41 even if they also have native IPv6 access.   They might need to 
reliably reach 6to4 sites (i.e. without relying on someone else's relay 
routers), or they might need private 6in4 tunnels to other sites that 
don't yet have native v6 access.

Carriers should forward packets, not decide what protocols their 
customers are supposed to use or second-guess what their customers need.

Keith

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 04 Nov 2014 16:16:10 +1300

> There's only one default route.

Well yes, but I can't think of a scenario where your advice makes
sense. If you have an IPv4-only provider and your IPv6 connectivity
is 6to4, all IPv6 packets are encapsulated in IPv4 anyway, so you
aren't running any v6 routing at all. If you have an IPv6 provider,
you may or may not see a route to 2002::/16; if you don't, traffic
to 6to4 nodes will be sent on the IPv6 default route, and somebody
downstream may or may not deliver your packets to a reverse relay.

> arguments we're currently mired in.

If you're repeating your view that we should only deprecate 3068
and not 3056, yes, that is the question on the table, but it's
not my call, so I'm waiting to see if we can hum on this next week.

    Brian

---

From: "Metzler, Dan J" <[email-masked]>
Date: Tue, 4 Nov 2014 12:49:18 +0000

Well, I don't want to spend too much time sidetracked on this issue, but...

> Sent: Monday, November 3, 2014 3:20 PM
> To: Metzler, Dan J

Well, maybe, but only if some kind of standard is defined for "Level B Internet Access" and a "Level A Internet Access", which could at some time be obsoleted by a new set of standards for internet access down the road.  Right now the statement is just meaningless because IETF isn't defining those service architectures.

> 
> Further, I don’t think that making market judgments of particular carriers is
> within the charter of the IETF. This moves out of the realm of technical
> standards into product comparison and I would expect substantial backlash
> against the IETF attempting to take on that role.

I absolutely 100% agree that making market judgments of particular carriers is not something for IETF to get into.  However, to be fair, defining standards for basic service levels is not a market judgment, nor is it a product comparison.  

It's simply laying out a set of standards for classes of service.  No mention or judgment of any specific company would be involved.  If a company wants to offer a class of service such as Full Internet Access at "Level A", or whatever it's called, at some point, that has to include some form of IPv6 access; whether it be 6rd or native IPv6.  Today that may be Level A.  Tomorrow a new standard may mean that 6rd is Level B Internet Access, and Level A requires native IPv6.  Whatever they choose to implement, the company can advertise the type of service they offer.
No company is required to implement Level A functionality, but at least they would know what is required to achieve it.
No customer is required to buy Level A functionality, but at least they would know what to expect from Level C if they buy that instead.

> 
> It might be something NANOG or IOL or ISOC or some other group could take
> on, but I can’t see this fitting in the IETF charter.

Well, I have a different opinion, but that's ok.  IETF is responsible for IPv4 and IPv6.  It makes sense that they should also be responsible for describing the contexts under which those are designed be used, and the same goes for the various transitional mechanisms that can help one get from IPv4 to IPv6.

I realize mine is not the prevailing opinion, or we wouldn't be where we are today.  If IETF doesn't do this, it is left up to marketing types and individual personal experiences as it is today.  There likely isn't a community better suited to defining how all the disparate technologies and standards should fit together to form a service than IETF, and it really does fit the mission of IETF.  However, I'm going to let this branch of the conversation die, and move back to the discussion of the issue at hand, involving the trading of personal opinions on whether 6to4 is still provides a service, or is just broken. ;-)

- Dan

---

From: Keith Moore <[email-masked]>
Date: Tue, 04 Nov 2014 08:21:22 -0500

> Well, I have a different opinion, but that's ok.  IETF is responsible for IPv4 and IPv6.  It makes sense that they should also be responsible for describing the contexts under which those are desig…
+1

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 4 Nov 2014 13:29:09 +0000

On Nov 4, 2014, at 3:46 AM, Keith Moore <[email-masked]> wrote:

> Carriers should forward packets, not decide what protocols their customers are supposed to use or second-guess what their customers need.

Should they decide what service models their services will support? The discussion here isn’t about what packets they will carry, it’s about whether they will implement relays and anycast addresses.

---

From: Keith Moore <[email-masked]>
Date: Tue, 04 Nov 2014 08:37:46 -0500

On 11/04/2014 08:29 AM, Fred Baker (fred) wrote:
>
> On Nov 4, 2014, at 3:46 AM, Keith Moore <[email-masked] 
> Should they decide what service models their services will support? 
> The discussion here isn’t about what packets they will carry, it’s 
> about whether they will implement relays and anycast addresses.

The original context was about whether carriers should filter protocol 
41, to which the answer should be an emphatic "no".

I don't think anyone has claimed that they "should" implement relays.   
As for anycast addresses, that's just not filtering a BGP prefix 
advertisement, right?   So the carrier's default behavior should work, 
though it's certainly possible that I misunderstand something.

There is a wrinkle in that public-facing carriers are often expected 
(for some reason) to be the first line of support when a customer's app 
breaks, which provides incentive for them to "fix" problems like 6to4 
not working that might not actually be problems with their networks.   I 
actually think that this is indicative of a fundamental and serious flaw 
in the Internet architecture:  when something doesn't work, the Internet 
doesn't really provide any good indication of what the problem is, and 
what facility is responsible, to the host, application, or user.   Some 
applications and operating systems have tried to remedy this, but it 
tends to be done on an ad hoc basis rather than being a general facility.

Keith

---

From: Erik Kline <[email-masked]>
Date: Mon, 03 Nov 2014 06:56:53 +0000

/me ducks

---

From: Jared Mauch <[email-masked]>
Date: Tue, 11 Nov 2014 11:58:38 -0500

You left out GRE or a MPLS label, as well as NVGRE/VXLAN.

- Jared

> On Nov 3, 2014, at 1:56 AM, Erik Kline <[email-masked]> wrote:
>