Subject: Re: [v6ops] 6to4-historic summary point: 2. "protocol 41"

From: Ole Troan <[email-masked]>
Date: Sun, 1 May 2011 11:35:27 +0200

Dmitry,

>>> Does the working group agree with the summarization of the concern? 
> 
> I agree with the summarization of the concern.
> 
>>> Do we agree with the proposed (in)action?
> 
> I disagree with the proposed action. I suggest to either remove the problem from the list of 6to4 problems, since as currently worded this is not a 6to4 problem, but protocol 41 problem, and this draft, in its current form, doesn't seem to have any intentions to deal with general protocol 41, or to add text illustrating why this problem is 6to4 specific and other uses of protocol 41 on the Internet do not have this problem or how that problem is/can be mitigated for them.

there are aspects of this that are unique to 6to4 (as an unmanaged tunnel mechanisms). e.g. a bi-directional configured tunnel between two nodes within a single network is quite different from a unmanaged tunnel spanning the Internet.

other uses of protocol 41 (including the managed one in 3056) does have mechanisms to detect black holes (routing protocol running on top of the tunnel).

> Also, if it is shown how this problem is 6to4 specific, RFC 3484bis recommendation would mitigate the problem and hence, in my opinion, this problem cannot be used as a justification for declaring RFC 3056 historic - in that case I suggest to remove the "historic" recommendation and instead add a reference to RFC 3484bis.

while rfc3484bis may mitigate the problem, it only does so by making sure 6to4 isn't used.

we have empirical evidence that 6to4 has problems with filters/firewalls. I haven't seen similar evidence for other mechanisms using protocol 41. doesn't mean they don't have the same issue obviously, but I don't think that's a good argument for not including this text about 6to4.

   o  6to4 has no specified mechanism to handle the case where the
      protocol (41) is blocked in intermediate firewalls.  It can not be
      expected that path MTU discovery across the Internet works
      reliably; ICMP messages may be blocked and in any case an IPv4
      ICMP message rarely has enough of the original packet in it to be
      useful to proxy back to the IPv6 sender.

on reflection I do agree with part of the objection. the current text implies that any overlay protocol should be able to bypass firewalls. what about something like:

   o  6to4 may black hole traffic in the case where
      protocol (41) is blocked in intermediate firewalls. Even if the firewall sent an ICMP message unreachable
      back, an IPv4 ICMP message rarely contains enough of the original IPv6 packet so that it can be relayed
      back to the IPv6 sender. That makes this problem hard to detect and react upon by the
      sender of the packet.

   o  It can not be expected that path MTU discovery across the Internet works
      reliably; ICMP messages may be blocked and in any case an IPv4
      ICMP message rarely has enough of the original packet in it to be
      useful to proxy back to the IPv6 sender.

cheers,
Ole

> 
> 
> ________________________________________
> From: [email-masked] [[email-masked]] On Behalf Of Fred Baker [[email-masked]]
> Sent: Wednesday, April 27, 2011 1:17 PM
> To: [email-masked] WG
> Subject: [v6ops] 6to4-historic summary point: 2. "protocol 41"
> 
>> 2. "protocol 41"
>> ----------------
>>  - Specifically, the issue (A) states that "6to4 has no specified mechanism to handle the case where
>>    protocol 41 is blocked...". Do other tunneling mechanisms using protocol 41 have such mechanism?
>>    If they don't, then should usage of protocol 41 be moved to historic, because the stated filtering/PMTUD
>>    problems are then not specific to RFC 3056? If they do, then having a brief overview of those and how/why
>>    they don't apply to 6to4 would help to strengthen the statement.
>> 
>> Action: None
> 
> Does the working group agree with the summarization of the concern? Do we agree with the proposed (in)action?
> 
> Reply if the answer is "no", and give a better suggestion.
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Mark Andrews <[email-masked]>
Date: Mon, 02 May 2011 09:20:49 +1000

In message <[email-masked]>, Ole Troan writ
es:
> > I disagree with the proposed action. I suggest to either remove the problem
>  from the list of 6to4 problems, since as currently worded this is not a 6to4
>  problem, but protocol 41 problem, and this draft, in its current form, doesn
> 't seem to have any intentions to deal with general protocol 41, or to add te
> xt illustrating why this problem is 6to4 specific and other uses of protocol 
> 41 on the Internet do not have this problem or how that problem is/can be mit
> igated for them.
> 
> there are aspects of this that are unique to 6to4 (as an unmanaged tunnel mec
> hanisms). e.g. a bi-directional configured tunnel between two nodes within a 
> single network is quite different from a unmanaged tunnel spanning the Intern
> et.
> 
> other uses of protocol 41 (including the managed one in 3056) does have mecha
> nisms to detect black holes (routing protocol running on top of the tunnel).
> 
> > Also, if it is shown how this problem is 6to4 specific, RFC 3484bis recomme
> ndation would mitigate the problem and hence, in my opinion, this problem can
> not be used as a justification for declaring RFC 3056 historic - in that case
>  I suggest to remove the "historic" recommendation and instead add a referenc
> e to RFC 3484bis.
> 
> we have empirical evidence that 6to4 has problems with filters/firewalls. I h
> aven't seen similar evidence for other mechanisms using protocol 41. doesn't 
> mean they don't have the same issue obviously, but I don't think that's a goo
> d argument for not including this text about 6to4.
> 
> 
 
PMTUD should be *off* on the encapsulating packets.  PMTUD should
only be enabled for TCP by default.  Unfortunately Linux and Solaris
boxes get this wrong and turn it on for all protocols.  Oracle/Sun
have acknowledged this is a bug with their stack.  This misbehaviour
causes problems for DNS/UDP.

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

---

From: "George, Wes E [NTK]" <[email-masked]>
Date: Mon, 2 May 2011 17:06:34 +0000

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dmitry Anipko
Sent: Saturday, April 30, 2011 8:37 PM
To: Fred Baker; [email-masked] WG
Subject: Re: [v6ops] 6to4-historic summary point: 2. "protocol 41"

>>Do we agree with the proposed (in)action?

I disagree with the proposed action. I suggest to either remove the problem from the list of 6to4 problems, since as currently
worded this is not a 6to4 problem, but protocol 41 problem, and this draft, in its current form, doesn't seem to have any intentions
to deal with general protocol 41, or to add text illustrating why this problem is 6to4 specific and other uses of protocol 41 on the
Internet do not have this problem or how that problem is/can be mitigated for them.
_________
[WEG] I think you're conflating two issues similar to previous objector, who said basically, "if we deprecate 6to4 because it
doesn't work, we have a lot of other tunneling and IPv6 transition protocols to deprecate too" and the line of logic that followed
that assertion was that we therefore shouldn't deprecate any of them.
IMO, there's nothing wrong with the assertion that 6to4 should be deprecated because of problems with protocol 41. The notion that
we should either ignore this issue because it's not specific to 6to4 or dramatically widen the scope of what is a fairly targeted
document about 6to4 to now include other implementations that use protocol 41 seems very odd to me. We want this draft to be as
complete as possible when documenting our rationale for saying, "well, that's not gone well at all..." rather than picking and
choosing the brokenness to only reflect the few things that are 100% specific to the implementation that we're deprecating.
You're right that protocol 41 problems are not all specific to 6to4. That doesn't make 6to4 any less broken when considering the
effects of protocol 41 filtering and other problems. 
Folks on this list have said more than once that it might make sense for there to be a companion document for Teredo, using some of
the same justifications. If there are other implementations using Protocol 41 that may be similarly affected, it'd be worth
evaluating their usefulness vs problems and pervasiveness of implementation as well. But we have to start somewhere, and we're
unlikely to gain consensus on deprecating all of them at once, so we're breaking it into pieces.

Wes George

---

From: "John Mann (ITS)" <[email-masked]>
Date: Tue, 3 May 2011 09:50:19 +1000

Hi,

On 3 May 2011 03:06, George, Wes E [NTK] <[email-masked]> wrote:

> from the list of 6to4 problems, since as currently
> worded this is not a 6to4 problem, but protocol 41 problem, and this draft,
> in its current form, doesn't seem to have any intentions
> to deal with general protocol 41, or to add text illustrating why this
> problem is 6to4 specific and other uses of protocol 41 on the
> [WEG] I think you're conflating two issues similar to previous objector,
> who said basically, "if we deprecate 6to4 because it
> doesn't work, we have a lot of other tunneling and IPv6 transition
> protocols to deprecate too" and the line of logic that followed
> IMO, there's nothing wrong with the assertion that 6to4 should be
> deprecated because of problems with protocol 41. The notion that
> we should either ignore this issue because it's not specific to 6to4 or
> dramatically widen the scope of what is a fairly targeted
> document about 6to4 to now include other implementations that use protocol
> 41 seems very odd to me. We want this draft to be as
> complete as possible when documenting our rationale for saying, "well,
> that's not gone well at all..." rather than picking and
> choosing the brokenness to only reflect the few things that are 100%
> specific to the implementation that we're deprecating.
> You're right that protocol 41 problems are not all specific to 6to4. That
> doesn't make 6to4 any less broken when considering the
> Folks on this list have said more than once that it might make sense for
> there to be a companion document for Teredo, using some of
> the same justifications. If there are other implementations using Protocol
> 41 that may be similarly affected, it'd be worth
> evaluating their usefulness vs problems and pervasiveness of implementation
> as well. But we have to start somewhere, and we're

+1  [ And the text has been changed already. ]

Anyway, what _are_ the other protocol-41 tunnel mechanisms that people are
concerned about?

ISATAP http://tools.ietf.org/html/rfc5214
- requires RS / RA packet exchange tunneled in protocol-41 before the node
knows its IPv6 prefix and default router.
Single endpoint-only protocol -- there are no other downstream devices that
could be impacted by a protocol-41 failure.
Tunnel reliability also improved by:
7.2. Handling ICMPv4 Errors
8.4. Neighbor Unreachability Detection
ISATAP is also likely to be implemented as a "managed" service by/inside an
enterprise,
which should improve its tunnel reliability.
Also an ISATAP subnet is likely to be "inside" an enterprise and so should
not / must not cross the enterprise border firewall - blocking protocol-41
is a feature, not a failing!

6rd http://tools.ietf.org/html/rfc5969
Increased reliability because "managed" by the ISP.
Has some stuff like
5.  Troubleshooting and Traceability
8.  Neighbor Unreachability Detection
[ I am no expert on 6rd. ]

http://tools.ietf.org/html/rfc4213
? is this "6over4" ?
"Configured Tunneling" is "managed" with explicit configuration at each end.
Also
3.8.  Neighbor Discovery over Tunnels
- NUD -  use an alternate path
- routing protocol running over the tunnel

Teredo http://tools.ietf.org/html/rfc4380
"Teredo: Tunneling IPv6 over UDP through Network Address Translations
(NATs)"
Uses UDP encapsulation, not protocol-41.

GRE tunnels
not protocol-41

VPNs or various flavours
not protocol-41

Anything else?

Thanks,
    John

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 03 May 2011 12:29:37 +1200

John,

On 2011-05-03 11:50, John Mann (ITS) wrote:
...
> http://tools.ietf.org/html/rfc4213

No. 6over4 is RFC 2529 and not really an active solution today.

> "Configured Tunneling" is "managed" with explicit configuration at each end.

Exactly. In widespread use until we get native everywhere, and the main
reason that a blanket policy for Protocol 41 isn't a good idea.

   Brian