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

[Ron Bonica <[e-mail]>]

Hi Mike,

Sorry for the slow response. See inline…..

                               Ron


From: C. M. Heard <[e-mail]>
Sent: Saturday, July 7, 2018 12:04 PM
To: Ron Bonica <[e-mail]>
Cc: 6man <[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> 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


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

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 <[e-mail]<mailto:[e-mail]>> wrote:
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 <[e-mail]<mailto:[e-mail]>>
Sent: Saturday, June 30, 2018 4:08 PM
To: Ron Bonica <[e-mail]<mailto:[e-mail]>>
Cc: 6man <[e-mail]<mailto:[e-mail]>>
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