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

From: "C. M. Heard" <[email-masked]>
Date: Sun, 6 May 2018 12:39:07 -0700

Ron,

I fail to see how this proposal will help with loss of PTB messages when
firewalls block them. That an ICMP message from a router would be blocked
but the same thing from a remote host would be permitted does not not seem
plausible. If that is wrong, elaboration (in the form of an explanation or
actual empirical evidence) would be in order.

Secondly, because the option is intended inspected, acted upon, and
potentially modified by intermediate routers, it should be a Hop-by-Hop
option. Yes, I know that stuff like CONEX (thankfully, experimental) relies
on inspection of destination options by intermediate nodes, but we should
never have consented to that. A router conforming to RFC 8200 won't modify
destination options and is not even required to have the capability to
inspect anything past the Hop-by-Hop options header.

Mike Heard

On Sun, May 6, 2018 at 12:12 PM, C. M. Heard <[email-masked]> wrote:

> Please review and comment
>
>                       Ron
>
>
> -----Original Message-----
> From: internet-drafts at ietf.org <internet-drafts at ietf.org>
> Sent: Friday, May 4, 2018 4:41 PM
> To: Ron Bonica <rbonica at juniper.net>; John Leddy <john_leddy at comcast.com>
> 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: Ron Bonica <[email-masked]>
Date: Mon, 7 May 2018 08:07:56 +0000

Hi Mike,

As always, you raise two good points.

Regarding the first point…….

If intermediate devices  block *all* ICMP PTB messages, PMTUD will break. The current draft will do nothing to fix that breakage.

However, there are many scenarios in which:

-          The network can deliver an ICMP PTB from the destination node to the source node

-          The network cannot deliver an ICMP PTB message from a transit node to the source node

The current draft is helpful in those scenarios.

The following are scenarios where the network can deliver ICMP PTBs from the destination node to the source node, but cannot deliver ICMP PTBs from the transit node to the source node:

-          When the transit node doesn’t have a viable route to the source

-          When the source address is anycast

-          When the source node filters all packets (including ICMP)  except for those from sources that it recognizes. (This is a configuration error, but a common one).

Maybe I should add some text regarding this point?

Regarding the second point…..

You begin with the assumption that “the option is intended to be inspected, acted upon, and potentially modified by intermediate routers”. This statement is neither entirely true nor entirely false.

The option is intended to be ignored by the vast majority of intermediate nodes that it traverses. An intermediate node only inspects the option *after* it has decided that the packet cannot be forwarded as is. That is, the option is only inspected in an exception case.

There is precedent intermediate routers examining destination options in exception cases. See Section 4.1.1 of RFC 2473.

                                     Ron

From: C. M. Heard <[email-masked]>
Sent: Sunday, May 6, 2018 3:39 PM
To: Ron Bonica <[email-masked]>
Cc: 6man <[email-masked]>
Subject: Re: New Version Notification for draft-leddy-6man-truncate-00.txt

Ron,

I fail to see how this proposal will help with loss of PTB messages when firewalls block them. That an ICMP message from a router would be blocked but the same thing from a remote host would be permitted does not not seem plausible. If that is wrong, elaboration (in the form of an explanation or actual empirical evidence) would be in order.

Secondly, because the option is intended inspected, acted upon, and potentially modified by intermediate routers, it should be a Hop-by-Hop option. Yes, I know that stuff like CONEX (thankfully, experimental) relies on inspection of destination options by intermediate nodes, but we should never have consented to that. A router conforming to RFC 8200 won't modify destination options and is not even required to have the capability to inspect anything past the Hop-by-Hop options header.

Mike Heard

On Sun, May 6, 2018 at 12:12 PM, C. M. Heard <[email-masked]<mailto:[email-masked]>> wrote:

                      Ron

-----Original Message-----

From: internet-drafts at ietf.org<https://urldefense.proofpoint.com/v2/url?u=http-3A__ietf.org&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=iym-D6Bsg8Z4vM3RiHEcZv6I6IP4jTQPCWtnWlVpyPo&s=hmqSmLLjWde6pjSHJsCItLb54Fn84J3uRinr-J_7cL0&e=> <internet-drafts at ietf.org<https://urldefense.proofpoint.com/v2/url?u=http-3A__ietf.org&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=iym-D6Bsg8Z4vM3RiHEcZv6I6IP4jTQPCWtnWlVpyPo&s=hmqSmLLjWde6pjSHJsCItLb54Fn84J3uRinr-J_7cL0&e=>>

To: Ron Bonica <rbonica at juniper.net<http://juniper.net>>; John Leddy <john_leddy at comcast.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__comcast.com&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=iym-D6Bsg8Z4vM3RiHEcZv6I6IP4jTQPCWtnWlVpyPo&s=XMHPP8qCqWw4Lyty4h5ohaJOpVqwQbxxxujH_OGJmKU&e=>>

Revision:    00

Pages:              11

URL:            https://tools.ietf.org/html/draft-leddy-6man-truncate-00<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dleddy-2D6man-2Dtruncate-2D00&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=iym-D6Bsg8Z4vM3RiHEcZv6I6IP4jTQPCWtnWlVpyPo&s=fIFEHtfFW6wcln8eByqK4TMXoO5KxudvgrC11u7XM-0&e=>

Status:         https://datatracker.ietf.org/doc/draft-leddy-6man-truncate/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dleddy-2D6man-2Dtruncate_&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=iym-D6Bsg8Z4vM3RiHEcZv6I6IP4jTQPCWtnWlVpyPo&s=PUxxG9guXt2eXDr5zeSOvFwbuVtDtI7VzIeNrEm6k8o&e=>

Htmlized:       https://tools.ietf.org/html/draft-leddy-6man-truncate-00<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dleddy-2D6man-2Dtruncate-2D00&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=iym-D6Bsg8Z4vM3RiHEcZv6I6IP4jTQPCWtnWlVpyPo&s=fIFEHtfFW6wcln8eByqK4TMXoO5KxudvgrC11u7XM-0&e=>

Htmlized:       https://datatracker.ietf.org/doc/html/draft-leddy-6man-truncate<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dleddy-2D6man-2Dtruncate&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=iym-D6Bsg8Z4vM3RiHEcZv6I6IP4jTQPCWtnWlVpyPo&s=7zxdgawY2cqrZt5TNFPllMRiRJPAkK8A_hpL5rLhdQA&e=>

Abstract:

   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<https://urldefense.proofpoint.com/v2/url?u=http-3A__tools.ietf.org&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=iym-D6Bsg8Z4vM3RiHEcZv6I6IP4jTQPCWtnWlVpyPo&s=TEHMji6HPlccCO53VbSYdheEUg8eSKT1IZUYQ2SBHSo&e=>.

The IETF Secretariat

---

From: "C. M. Heard" <[email-masked]>
Date: Mon, 7 May 2018 05:39:01 -0700

Hello Ron,

More explanation would indeed be helpful for the following use cases that
you mentioned:

   - Intermediate node has no route back to source: this implies asymmetric
   routing; is this common?
   - Source address is anycast: why won't the destination node have the
   same issue as an intermediate node, i.e., of delivery of PTB to the wrong
   instance?
   - Misconfigured source node: why isn't it easier to fix the node's
   configuration than to install new software to support this option in that
   node and deploy same in the internet?

Regarding the inspection of destination options in exception cases: the
precedent in RFC 2473 is worth mentioning. That RFC is very explicit
regarding how a tunnel encapsulator walks the header chain (see
https://tools.ietf.org/html/rfc2473#section-4.1.1), and that might be a
very good feature to emulate -- in particular, the instructions on when to
terminate the search for the truncation option.

That being said, allow me to point out that the situation with Hop-by-Hop
has changed since RFC 2473 was written. At that time, there was a
requirement for every intermediate node to examine every Hop-by-Hop options
header. With RFC 8200 that is no longer true; nodes are expected to examine
and process the Hop-by-Hop Options header only if explicitly configured to
do so.

Mike Heard

On Mon, May 7, 2018 at 1:07 AM, Ron Bonica <[email-masked]> wrote:

> If intermediate devices  block **all** ICMP PTB messages, PMTUD will
> break. The current draft will do nothing to fix that breakage.
>
>
>
> The following are scenarios where the network can deliver ICMP PTBs from
> the destination node to the source node, but cannot deliver ICMP PTBs from
> the transit node to the source node:
>
>
>
> -          When the source node filters all packets (including ICMP)
>  except for those from sources that it recognizes. (This is a configuration
> error, but a common one).
>
>
>
> You begin with the assumption that “the option is intended to be
> inspected, acted upon, and potentially modified by intermediate routers”.
> This statement is neither entirely true nor entirely false.
>
>
>
> The option is intended to be ignored by the vast majority of intermediate
> nodes that it traverses. An intermediate node only inspects the option *
> *after** it has decided that the packet cannot be forwarded as is. That
> is, the option is only inspected in an exception case.
>
>
>
> There is precedent intermediate routers examining destination options in
> exception cases. See Section 4.1.1 of RFC 2473.
>
>
>
>                                      Ron
>
>
>
> *From:* C. M. Heard <[email-masked]>
> *Sent:* Sunday, May 6, 2018 3:39 PM
> *To:* Ron Bonica <[email-masked]>
> *Cc:* 6man <[email-masked]>
> *Subject:* Re: New Version Notification for draft-leddy-6man-truncate-00.
> txt
>
>
>
> Ron,
>
>
>
> From: internet-drafts at ietf.org <https://urldefense.proofpoint.com/v2/url?u=http-3A__ietf.org&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=iym-D6Bsg8Z4vM3RiHEcZv6I6IP4jTQPCWtnWlVpyPo&s=hmqSmLLjWde6pjSHJsCItLb54Fn84J3uRinr-J_7cL0&e=> <internet-drafts at ietf.org <https://urldefense.proofpoint.com/v2/url?u=http-3A__ietf.org&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=iym-D6Bsg8Z4vM3RiHEcZv6I6IP4jTQPCWtnWlVpyPo&s=hmqSmLLjWde6pjSHJsCItLb54Fn84J3uRinr-J_7cL0&e=>>
>
> To: Ron Bonica <rbonica at juniper.net>; John Leddy <john_leddy at comcast.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__comcast.com&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=iym-D6Bsg8Z4vM3RiHEcZv6I6IP4jTQPCWtnWlVpyPo&s=XMHPP8qCqWw4Lyty4h5ohaJOpVqwQbxxxujH_OGJmKU&e=>>
>
> URL:            https://tools.ietf.org/html/draft-leddy-6man-truncate-00 <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dleddy-2D6man-2Dtruncate-2D00&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=iym-D6Bsg8Z4vM3RiHEcZv6I6IP4jTQPCWtnWlVpyPo&s=fIFEHtfFW6wcln8eByqK4TMXoO5KxudvgrC11u7XM-0&e=>
>
> Status:         https://datatracker.ietf.org/doc/draft-leddy-6man-truncate/ <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dleddy-2D6man-2Dtruncate_&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=iym-D6Bsg8Z4vM3RiHEcZv6I6IP4jTQPCWtnWlVpyPo&s=PUxxG9guXt2eXDr5zeSOvFwbuVtDtI7VzIeNrEm6k8o&e=>
>
> Htmlized:       https://tools.ietf.org/html/draft-leddy-6man-truncate-00 <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dleddy-2D6man-2Dtruncate-2D00&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=iym-D6Bsg8Z4vM3RiHEcZv6I6IP4jTQPCWtnWlVpyPo&s=fIFEHtfFW6wcln8eByqK4TMXoO5KxudvgrC11u7XM-0&e=>
>
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-leddy-6man-truncate <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dleddy-2D6man-2Dtruncate&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=iym-D6Bsg8Z4vM3RiHEcZv6I6IP4jTQPCWtnWlVpyPo&s=7zxdgawY2cqrZt5TNFPllMRiRJPAkK8A_hpL5rLhdQA&e=>
>
>
>
>
>
> Abstract:
>
> 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 <https://urldefense.proofpoint.com/v2/url?u=http-3A__tools.ietf.org&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=iym-D6Bsg8Z4vM3RiHEcZv6I6IP4jTQPCWtnWlVpyPo&s=TEHMji6HPlccCO53VbSYdheEUg8eSKT1IZUYQ2SBHSo&e=>.
>
>
>
> The IETF Secretariat
>
>
>
>
>