Subject: RE: Extension header order in draft-leddy-6man-truncate-04

From: Ron Bonica <[email-masked]>
Date: Fri, 6 Jul 2018 19:27:27 +0000

Mike,

I’m not sure that I agree. Let’s think through all of the possible cases……

R = Routing Options header is present
A = Either Authentication header or ESP header is present

Case 1) !R and !A
The new truncation options appear in the one-and-only Destination Options header

Case 2) !R and A
The new truncation options appear in a Destination Options header before the Authentication / ESP header
Another Destination Options header may appear  after the Authentication / ESP header

Case 3) R and !A
The new truncation options appear in a Destination Options header after the Routing Options header
Another Destination Options header may appear before the Routing Options header

Case 4) R and A
The new truncation options appear in a Destination Options header before the Routing Options header
Another Destination Options header may appear after the Authentication / ESP header

I think that we are agreeing on cases 1,2 and 4. But we might disagree on case 3? Is this the case?

                                                                                     Ron

From: C. M. Heard <[email-masked]>
Sent: Saturday, June 30, 2018 4:08 PM
To: Ron Bonica <[email-masked]>
Cc: 6man <[email-masked]>
Subject: Extension header order in draft-leddy-6man-truncate-04

Hello Ron,

It occurs to me that the proper order of headers when the "Truncation Eligible" or "Truncated Packet" options appear should be:

      IPv6 header

      Hop-by-Hop Options header

      Destination Options header ("Truncation Eligible", "Truncated Packet" , or note 1)

      Routing header

      Authentication header (note 2)

      Encapsulating Security Payload header (note 2)

      Destination Options header (note 3)

      Upper-Layer header

      note 1: for options to be processed by the first destination that

              appears in the IPv6 Destination Address field plus

              subsequent destinations listed in the Routing header.

      note 2: additional recommendations regarding the relative order of

              the Authentication and Encapsulating Security Payload

              headers are given in [RFC4303<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc4303&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=KxRyHMsPmNs_kvEv0yopCbQV5aZpbkzTG9H6JXg4nfk&s=oLsNVjrXXwdW5tFsZ-9Lw-5kJqhFqyzrq0m84zbN1_8&e=>].

      note 3: for options other than "Truncated Packet" that are to be

              processed only by the final destination of the packet.

My reasoning is that (a) we want "Truncation Eligible" to be processed by the first destination if in the IPv6 header and subsequent destinations listed in the routing header and (b) we want Truncated Packet" to be processed before the Authentication Header (if one is present) at the final destination. Note that case (b) is necessary since the truncated packet will fail the AH integrity check. If AH were processed first, the destination node would not send the desired PTB message,

Do you agree?

Mike Heard

---

From: "C. M. Heard" <[email-masked]>
Date: Fri, 6 Jul 2018 15:40:37 -0700

Ron,

We definitely disagree about case 3 (but we agree about the others).

The way you have it is truncation option appears after RH, which means
either that:

(a) you do NOT want the intermediate hops singled out by the routing header
to process the truncation option, or

(b) you expect all truncation-capable intermediate routers to walk the
header chain past the routing header, possibly through a leading
destination options header, when the packet is too big to forward.

I can't see why either of those things is desirable. What am I missing?

Mike

P.S. I missed the possibility of a second destination options header
without the truncation option in cases 2-4. I would have noticed that had I
done my homework, since it is right there in the ESP discussion in the
draft.

On Fri, Jul 6, 2018 at 12:27 PM, Ron Bonica <[email-masked]> wrote:

> *From:* C. M. Heard <[email-masked]>
> *Sent:* Saturday, June 30, 2018 4:08 PM
> *To:* Ron Bonica <[email-masked]>
> *Cc:* 6man <[email-masked]>
> *Subject:* Extension header order in draft-leddy-6man-truncate-04
>
>
>
> Hello Ron,
>
>
>
> It occurs to me that the proper order of headers when the "Truncation
> Eligible" or "Truncated Packet" options appear should be:
>
>
>
>       IPv6 header
>
>               headers are given in [RFC4303 <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc4303&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=KxRyHMsPmNs_kvEv0yopCbQV5aZpbkzTG9H6JXg4nfk&s=oLsNVjrXXwdW5tFsZ-9Lw-5kJqhFqyzrq0m84zbN1_8&e=>].
>
>
>
> My reasoning is that (a) we want "Truncation Eligible" to be processed by
> the first destination if in the IPv6 header and subsequent destinations
> listed in the routing header and (b) we want Truncated Packet" to be
> processed before the Authentication Header (if one is present) at the final
> destination. Note that case (b) is necessary since the truncated packet
> will fail the AH integrity check. If AH were processed first, the
> destination node would not send the desired PTB message,
>
>
>
> Do you agree?
>
>
>
> Mike Heard
>

---

From: Ron Bonica <[email-masked]>
Date: Sat, 7 Jul 2018 10:56:28 +0000

Mike,

Having thought about it for a while, you may be right. I will post an updated to the draft as soon as the submission tool reopens.

                                                                                           Thanks,
                                                                                             Ron

From: C. M. Heard <[email-masked]>
Sent: Friday, July 6, 2018 6:41 PM
To: Ron Bonica <[email-masked]>
Cc: 6man <[email-masked]>
Subject: Re: Extension header order in draft-leddy-6man-truncate-04

Ron,

The way you have it is truncation option appears after RH, which means either that:

(a) you do NOT want the intermediate hops singled out by the routing header to process the truncation option, or

(b) you expect all truncation-capable intermediate routers to walk the header chain past the routing header, possibly through a leading destination options header, when the packet is too big to forward.

Mike

P.S. I missed the possibility of a second destination options header without the truncation option in cases 2-4. I would have noticed that had I done my homework, since it is right there in the ESP discussion in the draft.

On Fri, Jul 6, 2018 at 12:27 PM, Ron Bonica <[email-masked]<mailto:[email-masked]>> wrote:
Mike,

Case 1) !R and !A

Case 2) !R and A

Case 3) R and !A

Case 4) R and A

                                                                                     Ron

From: C. M. Heard <[email-masked]<mailto:[email-masked]>>
Sent: Saturday, June 30, 2018 4:08 PM
To: Ron Bonica <[email-masked]<mailto:[email-masked]>>
Cc: 6man <[email-masked]<mailto:[email-masked]>>
Subject: Extension header order in draft-leddy-6man-truncate-04

Hello Ron,

      IPv6 header

      Routing header

      Upper-Layer header

Do you agree?

Mike Heard

---

From: "C. M. Heard" <[email-masked]>
Date: Sat, 7 Jul 2018 09:04:23 -0700

Ron,

I thought of a couple of issues that arise when a "Truncation Eligible"
option appears before a Routing Header.

First, an intermediate hop in the source route will need to remember
whether it has seen the "Truncation Eligible" option in order to correctly
process the packet upon finding the Routing Header with an unexpired route,
so that it can truncate the packet and change the "Truncation Eligible"
option to "Truncated Packet" before forwarding. Prima facie this seems
straightforward, but I would not want to bet my life on that without
actually analyzing the interaction with each standardized type of Routing
Header.

Second, what happens at an intermediate hop in a source route if it
encounters the "Truncated Packet" option? Does it immediately send an ICMP
message? Or should it continue following the header chain to see if a
Routing Header is present, so that it can forward (and perhaps re-truncate)
the packet? The latter is what I had in mind, but it does seem to impose
complex processing requirements on nodes that can play the role of
intermediate hop in a source route. A node that can play the role of
endpoint only can safely ignore this subtlety.

I still don't think it's desirable to have the truncation option after the
routing header, but the question is clearly more complicated than I had at
first appreciated.

Mike Heard

On Sat, Jul 7, 2018 at 3:56 AM, Ron Bonica <[email-masked]> wrote:

> Mike,
>
>
>
> Having thought about it for a while, you may be right. I will post an
> updated to the draft as soon as the submission tool reopens.
>
>
>
>
>                                             Thanks,
>
>
>                                  Ron
>
>
>
>
>
> *Sent:* Friday, July 6, 2018 6:41 PM
> *Subject:* Re: Extension header order in draft-leddy-6man-truncate-04
>
>
>
> Ron,
>
>
>
> (a) you do NOT want the intermediate hops singled out by the routing
> header to process the truncation option, or
>
>
>

---

From: Ron Bonica <[email-masked]>
Date: Wed, 11 Jul 2018 20:06:07 +0000

Hi Mike,

Sorry for the slow response. See inline…..

                               Ron

From: C. M. Heard <[email-masked]>
Sent: Saturday, July 7, 2018 12:04 PM
To: Ron Bonica <[email-masked]>
Cc: 6man <[email-masked]>
Subject: Re: Extension header order in draft-leddy-6man-truncate-04

Ron,

I thought of a couple of issues that arise when a "Truncation Eligible" option appears before a Routing Header.

First, an intermediate hop in the source route will need to remember whether it has seen the "Truncation Eligible" option in order to correctly process the packet upon finding the Routing Header with an unexpired route, so that it can truncate the packet and change the "Truncation Eligible" option to "Truncated Packet" before forwarding. Prima facie this seems straightforward, but I would not want to bet my life on that without actually analyzing the interaction with each standardized type of Routing Header.

Second, what happens at an intermediate hop in a source route if it encounters the "Truncated Packet" option? Does it immediately send an ICMP message? Or should it continue following the header chain to see if a Routing Header is present, so that it can forward (and perhaps re-truncate) the packet?

The later

The latter is what I had in mind, but it does seem to impose complex processing requirements on nodes that can play the role of intermediate hop in a source route. A node that can play the role of endpoint only can safely ignore this subtlety.

Yeah, it does add a little complexity, but the benefits are worth it. The benefits are:

-          The ICMP PTB is sent from the ultimate destination. Therefore, it is more likely to make it to the source

-          If the packet needs to be truncated again, downstream, the source learns the PMTU in one RTT

I still don't think it's desirable to have the truncation option after the routing header, but the question is clearly more complicated than I had at first appreciated.

I still agree.

                  Ron

Mike Heard

On Sat, Jul 7, 2018 at 3:56 AM, Ron Bonica <[email-masked]<mailto:[email-masked]>> wrote:
Mike,

                                                                                           Thanks,
                                                                                             Ron

Ron,

Mike

Case 1) !R and !A

Case 2) !R and A

Case 3) R and !A

Case 4) R and A

                                                                                     Ron

Hello Ron,

      IPv6 header

      Routing header

      Upper-Layer header

Do you agree?

Mike Heard

---

From: Ron Bonica <[email-masked]>
Date: Wed, 11 Jul 2018 20:06:41 +0000

BTW, I will add this to the next version of the draft.

Ron,

Second, what happens at an intermediate hop in a source route if it encounters the "Truncated Packet" option? Does it immediately send an ICMP message? Or should it continue following the header chain to see if a Routing Header is present, so that it can forward (and perhaps re-truncate) the packet? The latter is what I had in mind, but it does seem to impose complex processing requirements on nodes that can play the role of intermediate hop in a source route. A node that can play the role of endpoint only can safely ignore this subtlety.

Mike Heard

                                                                                           Thanks,
                                                                                             Ron

Ron,

Mike

Case 1) !R and !A

Case 2) !R and A

Case 3) R and !A

Case 4) R and A

                                                                                     Ron

Hello Ron,

      IPv6 header

      Routing header

      Upper-Layer header

Do you agree?

Mike Heard