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

From: Ron Bonica <[email-masked]>
Date: Mon, 11 Jun 2018 17:17:21 +0000

Please review and comment.

                                 Ron

-----Original Message-----
From: [email-masked] <[email-masked]> 
Sent: Monday, June 11, 2018 12:32 PM
To: Ron Bonica <[email-masked]>; John Leddy <[email-masked]>
Subject: New Version Notification for draft-leddy-6man-truncate-03.txt

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

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

Status:  https://datatracker.ietf.org/doc/draft-leddy-6man-truncate/
Htmlized:  https://tools.ietf.org/html/draft-leddy-6man-truncate-03
Htmlized:  https://datatracker.ietf.org/doc/html/draft-leddy-6man-truncate    

Diff:       https://www.ietf.org/rfcdiff?url2=draft-leddy-6man-truncate-03    

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 also examines the new Destination option to
   determine whether it should discard the truncated packet or deliver
   it to an upper-layer protocol.

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: Tom Herbert <[email-masked]>
Date: Tue, 12 Jun 2018 08:03:59 -0700

Hi Ron,

>From the draft:

"This document defines procedures that enhance PMTUD, so that it no
longer relies on the network's ability to deliver an ICMP PTB message
from a downstream router to an IPv6 source node... When the
destination node receives a packet that has been truncated, it sends
an ICMP PTB message to the source node."

Why is sending the ICMP error from the destination more reliable than
sending from an intermediate node? Seems like both cases depending on
the network to forward the ICMP error back to the destination, but in
the case of sending ICMP from the destination there are potentially
more nodes in the path that need to forward ICMP correctly.

Also, this proposal depends on two facilities that are known to be
fragile on the Internet (ICMP and EH). In lieu of using ICMP from
destination, could a destination option be used with some sort of
reply packets to provide the PTB information to the sender?

Tom

On Mon, Jun 11, 2018 at 10:17 AM, Ron Bonica <[email-masked]> wrote:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Ole Troan <[email-masked]>
Date: Tue, 12 Jun 2018 23:01:09 +0200

> On 12 Jun 2018, at 17:03, Tom Herbert <[email-masked]> wrote:
> 
> Hi Ron,
> 
>> From the draft:
> 

If we're allowed to redesign PMTUD from scratch, then I agree that we shouldn't necessarily limit ourselves to the proposed solution.

PMTU is something we have not been successful at in the Internet layer.
I think the transport layer has to be involved.

I do like the truncate idea. E.g. for TCP the sending host could send a SYN packet padded out to the outgoing interface MTU.
Intermediate routers truncate the packet, and set a 'truncated' bit in the IP header.
The receiving host knows the senders MTU by the length of the received packet. In it's syn+ack it includes the sender's MTU in a TCP option and pads out the packet to it's own outgoing interface MTU.
Which is reported back in the final ack.

Subsequently PLMTUD style probing could be done.

Cheers,
Ole

---

From: Michael Richardson <[email-masked]>
Date: Tue, 12 Jun 2018 17:44:17 -0400

Ole Troan <[email-masked]> wrote:
    > I do like the truncate idea. E.g. for TCP the sending host could send a
    > SYN packet padded out to the outgoing interface MTU.  Intermediate
    > routers truncate the packet, and set a 'truncated' bit in the IP
    > header.  The receiving host knows the senders MTU by the length of the
    > received packet. In it's syn+ack it includes the sender's MTU in a TCP
    > option and pads out the packet to it's own outgoing interface MTU.

so, we are gonna let intermediate nodes truncate IPv6 packets?
[Can they truncate it in such a way that they remove specific Extensions Headers? :-)]

    > Subsequently PLMTUD style probing could be done.

Seems like we should just do PLMTUD already.
It works really well if you turn it on.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Ron Bonica <[email-masked]>
Date: Wed, 13 Jun 2018 15:45:08 +0000

Hi Tom,

Thanks for the review. Comments inline.....

                                           Ron

> From: Tom Herbert <[email-masked]>
> Sent: Tuesday, June 12, 2018 11:04 AM
> To: Ron Bonica <[email-masked]>
> Cc: IPv6 IPv6 List <[email-masked]>
> Subject: Re: FW: New Version Notification for draft-leddy-6man-truncate-
> 03.txt
> 
> Hi Ron,
> 
> From the draft:
> 
> longer relies on the network's ability to deliver an ICMP PTB message from a
> downstream router to an IPv6 source node... When the destination node
> receives a packet that has been truncated, it sends an ICMP PTB message to
> the source node."
> 
> 
> the network to forward the ICMP error back to the destination, but in the
> case of sending ICMP from the destination there are potentially more nodes
> in the path that need to forward ICMP correctly.
> 

I know of two common scenarios in which the network will not deliver an ICMP PTB from a downstream router to the source, but will deliver and ICMP PTB from destination to the source. See the following URLs for details:

- https://tools.ietf.org/html/draft-bonica-intarea-frag-fragile-02#section-4.5.2
- https://tools.ietf.org/html/draft-bonica-intarea-frag-fragile-02#section-4.5.3

Do you think that it would be helpful to import this text into the truncation document?

> Also, this proposal depends on two facilities that are known to be fragile on
> the Internet (ICMP and EH).

This was the motivation for https://tools.ietf.org/html/draft-bonica-6man-unrecognized-opt-01. Before using the truncation option, the upper-layer protocol executes the procedure described in https://tools.ietf.org/html/draft-bonica-6man-unrecognized-opt-01#section-4. 

 In lieu of using ICMP from destination, could a
> destination option be used with some sort of reply packets to provide the
> PTB information to the sender?
> 

It is conceivable that we might replace the ICMP PTB message with some other message. But if we did that:

- we would still have to solve the problem of networks that drop packets containing destination options
- we would have to change PMTUD.

Am I missing something?

                                    Ron

> > A new version of I-D, draft-leddy-6man-truncate-03.txt has been
> successfully submitted by Ron Bonica and posted to the IETF repository.
> >
> > URL:       https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__tools.ietf.org_html_draft-2Dleddy-2D6man-2Dtruncate-
> 2D03&d=DwIBaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-
> AWF2EfpHcAwrDThKP8&m=HRvtHKT92LiFOb1zU1bDEJwWpPTzNDmaN1-
> PrwCi_YI&s=FPdU9LiCjHlAdmD8woQhcPYeFuu-z0fTEU0w_DSuRGw&e=
> >
> > Status:
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.
> > org_doc_draft-2Dleddy-2D6man-
> 2Dtruncate_&d=DwIBaQ&c=HAkYuh63rsuhr6Scbf
> > h0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-
> AWF2EfpHcAwrDThKP
> > 8&m=HRvtHKT92LiFOb1zU1bDEJwWpPTzNDmaN1-PrwCi_YI&s=-
> dbepkoEzytdwtzOGd8W
> > w-MJYV6A34wZk_vatX1XvZY&e=
> > Htmlized:
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_ht
> > ml_draft-2Dleddy-2D6man-2Dtruncate-
> 2D03&d=DwIBaQ&c=HAkYuh63rsuhr6Scbfh
> > 0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-
> AWF2EfpHcAwrDThKP8
> > &m=HRvtHKT92LiFOb1zU1bDEJwWpPTzNDmaN1-
> PrwCi_YI&s=FPdU9LiCjHlAdmD8woQhc
> > PYeFuu-z0fTEU0w_DSuRGw&e=
> > Htmlized:
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.
> > org_doc_html_draft-2Dleddy-2D6man-
> 2Dtruncate&d=DwIBaQ&c=HAkYuh63rsuhr6
> > Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-
> AWF2EfpHcAwrD
> > ThKP8&m=HRvtHKT92LiFOb1zU1bDEJwWpPTzNDmaN1-
> PrwCi_YI&s=xFAJheLOIGkCkvOc
> > 3iZeYlSzPsoXKbtZDRbqNtOlzQY&e=
> >
> > Diff:       https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dleddy-2D6man-2Dtruncate-
> 2D03&d=DwIBaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-
> AWF2EfpHcAwrDThKP8&m=HRvtHKT92LiFOb1zU1bDEJwWpPTzNDmaN1-
> PrwCi_YI&s=YMIlb_8Fvwc1kn7QlKWuW5uD7SZoujrDK4T3MjYBHVM&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.
> >
> > The IETF Secretariat
> >
> > Administrative Requests:
> > https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mail
> > man_listinfo_ipv6&d=DwIBaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzo
> > CI&r=Fch9FQ82sir-BoLx84hKuKwl-
> AWF2EfpHcAwrDThKP8&m=HRvtHKT92LiFOb1zU1b
> > DEJwWpPTzNDmaN1-PrwCi_YI&s=1u-zLai3GKpg7eoX2upZ-
> czs7vVbqfDWu1zEz5QjQCM
> > &e=