Subject: FW: New Version Notification for draft-leddy-6man-truncate-00.txt

From: Ron Bonica <[email-masked]>
Date: Sun, 6 May 2018 13:45:06 +0000

Please review and comment

                      Ron

-----Original Message-----
From: [email-masked] <[email-masked]> 
Sent: Friday, May 4, 2018 4:41 PM
To: Ron Bonica <[email-masked]>; John Leddy <[email-masked]>
Subject: New Version Notification for draft-leddy-6man-truncate-00.txt

A new version of I-D, draft-leddy-6man-truncate-00.txt has been successfully submitted by Ron Bonica and posted to the IETF repository.

Name:		draft-leddy-6man-truncate
Revision:	00
Title:		Destination Originates Internet Control Message Protocol (ICMP) Packet Too Big (PTB) Messages
Document date:	2018-05-04
Group:		Individual Submission
Pages:		11
URL:            https://tools.ietf.org/html/draft-leddy-6man-truncate-00
Status:         https://datatracker.ietf.org/doc/draft-leddy-6man-truncate/
Htmlized:       https://tools.ietf.org/html/draft-leddy-6man-truncate-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-leddy-6man-truncate

Abstract:
   This document defines procedures that enhance Path MTU Discovery
   (PMTUD), so that it no longer relies on the network's ability to
   deliver an ICMP Packet Too Big (PTB) message from a downstream router
   to an IPv6 source node.  According to these procedures, selected
   packets carry a new IPv6 Destination option.  When a downstream
   router cannot forward one of these packets because of MTU issues, it
   truncates the packet, marks it to indicate that it has been
   truncated, and forwards it towards the destination node.

   When the destination node receives a packet that has been truncated,
   it sends an ICMP PTB message to the source node.  The source node
   uses MTU information contained by the ICMP PTB message to update its
   PMTU estimate.  The destination node does not deliver the truncated
   packet to upper layer protocols unless specifically requested to do
   so by the upper layer protocol.

   The procedures described herein rely on the network's ability to
   deliver an ICMP PTB message from the packet's destination to the
   packet's source.

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.

The IETF Secretariat

---

From: 神明達哉 <[email-masked]>
Date: Tue, 08 May 2018 18:33:31 +0000

At Sun, 6 May 2018 13:45:06 +0000,

> Please review and comment

I've read the draft.  I share the concerns raised by Mike Heard:
https://www.ietf.org/mail-archive/web/ipv6/current/msg30190.html
I noticed exactly the same points before reading his review, so I
guess many others would have the same concerns.

Regarding the effectiveness of the proposal that still relies on the
delivery of ICMPv6 PTB: I thought the dominant cause of PMTU failure
is stupidity of middle boxes that filter out ICMPv6 messages
unconditionally (and they are placed so they would drop ICMPv6
messages from the destination node as well as from intermediate
routers).  If this is really the case, addressing other minor causes
doesn't seem to make much sense to me, especially when it involves a
new protocol feature (rather than operational practices).

I also wonder how much we can rely on the delivery of packets
containing a destination options header.  Maybe less likely than the
ICMPv6, but when such a stupid middle box makes PMTU fail, I guess
it's quite possible that this same box stupidly drops packets
containing a destination option.

On the other hand, if we can reasonably assume a destination option
can be used safely, I also wonder whether we might also use it to
signal the source instead of using ICMPv6 message.  Of course, it may
not always be feasible - for example, it's less likely to be
applicable to UDP "responses".  But I suspect it's not so unreasonable
to apply it to TCP.

Some other comments on the draft:
- The semantics of R-bit isn't clear enough to me.  At least Section 4
   should explain it in more detail.  Also, if this bit is mainly for a
   hypothetical use in future transport protocol as hinted in Section
   8, we might rather not introduce it unless we clearly see the need
   for it with a specific future transport protocol.  Underspecified
   protocol feature defined "just in case" tends to cause various
   troubles from more implementation bugs to security vulnerabilities.
- The draft hardcodes "1280" for the IPv6 minimum link MTU in several
   places.  I suggest calling it just "IPv6 minimum link MTU" (with a
   reference to RFC8200) instead of hardcoding a particular magic
   number.  Then (although quite unlikely) even
   if we ever update the minimum MTU value this document won't have to
   be updated except the reference to the "deprecated" RFC.

--
JINMEI, Tatuya

---

From: joel jaeggli <[email-masked]>
Date: Thu, 10 May 2018 00:38:36 +0900

> new protocol feature (rather than operational practices).

In my environments the dominant cause of ICMP PMTUD failure is the fact
that the IP packet gets hashed by an ECMP function and lands on a
different machine then the flow associated with the packet. In some
cases, you can actually fix that with a middlebox. In others (for
example the general  internet anycast case, you cannot).

It's a sufficiently important case that we got RFC 7690 to describe it.

> ICMPv6, but when such a stupid middle box makes PMTU fail, I gues
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: 神明達哉 <[email-masked]>
Date: Fri, 11 May 2018 11:34:48 -0700

At Thu, 10 May 2018 00:38:36 +0900,

> It's a sufficiently important case that we got RFC 7690 to describe it.

Ah, okay.  I wonder, however, whether draft-leddy-6man-truncate can be
effective mitigation in this case, since it still relies on an ICMPv6
message and the upper layer information that would be necessary to
identify the original flow is still encapsulated.  (On the other hand,
my "strawman" idea of using the destination option with the 'return'
packet would be effective in this case).

In any case, it would be good if draft-leddy-6man-truncate referred to
RFC7690 with related applicability considerations.

--
JINMEI, Tatuya

---

From: Ron Bonica <[email-masked]>
Date: Fri, 11 May 2018 19:00:44 +0000

Jinmei,

Thanks for your careful review and comments. In the next few days, I will submit an updated draft version addressing them all, and in particular, the ICMP PTB comment.

                                                                                            Ron

> From: 神明達哉 <[email-masked]>
> Sent: Tuesday, May 8, 2018 2:34 PM
> To: Ron Bonica <[email-masked]>
> Cc: IPv6 IPv6 List <[email-masked]>
> Subject: Re: FW: New Version Notification for draft-leddy-6man-truncate-
> 00.txt
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-
> 2Darchive_web_ipv6_current_msg30190.html&d=DwIBaQ&c=HAkYuh63rsuh
> r6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-
> AWF2EfpHcAwrDThKP8&m=Gyn1sb0eSSc7iwQnz5_AIwHTUsFSU1DlS9jaDNZ
> mXwk&s=StLf-moeiN2vuCLLGibvjshqjDrF6oEOMDKh_nGvayY&e=
> I noticed exactly the same points before reading his review, so I guess many
> others would have the same concerns.
> 
> Regarding the effectiveness of the proposal that still relies on the delivery of
> ICMPv6 PTB: I thought the dominant cause of PMTU failure is stupidity of
> middle boxes that filter out ICMPv6 messages unconditionally (and they are
> placed so they would drop ICMPv6 messages from the destination node as
> well as from intermediate routers).  If this is really the case, addressing other
> minor causes doesn't seem to make much sense to me, especially when it
> involves a new protocol feature (rather than operational practices).
> 
> I also wonder how much we can rely on the delivery of packets containing a
> destination options header.  Maybe less likely than the ICMPv6, but when
> such a stupid middle box makes PMTU fail, I guess it's quite possible that this
> same box stupidly drops packets containing a destination option.
> 
> On the other hand, if we can reasonably assume a destination option can be
> used safely, I also wonder whether we might also use it to signal the source
> instead of using ICMPv6 message.  Of course, it may not always be feasible -
> for example, it's less likely to be applicable to UDP "responses".  But I suspect
> it's not so unreasonable to apply it to TCP.
>