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

[Ron Bonica <[e-mail]>]

Hi Tom,

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

                                           Ron


> -----Original Message-----
> From: Tom Herbert <[e-mail]>
> Sent: Tuesday, June 12, 2018 11:04 AM
> To: Ron Bonica <[e-mail]>
> Cc: IPv6 IPv6 List <[e-mail]>
> Subject: Re: FW: New Version Notification for draft-leddy-6man-truncate-
> 03.txt
> 
> 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.
> 

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

> Tom
> 
> 
> 
> On Mon, Jun 11, 2018 at 10:17 AM, Ron Bonica <[e-mail]> wrote:
> > Please review and comment.
> >
> >                                  Ron
> >
> >
> > -----Original Message-----
> > From: [e-mail] <[e-mail]>
> > Sent: Monday, June 11, 2018 12:32 PM
> > To: Ron Bonica <[e-mail]>; John Leddy
> > <[e-mail]>
> > 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://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:
> >    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
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [e-mail]
> > 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=
> > --------------------------------------------------------------------