Subject: Re: Modifiable Destination Options

From: "C. M. Heard" <[email-masked]>
Date: Fri, 29 Jun 2018 00:13:14 -0700

On Thu, 28 Jun 2018 15:09:05 -0700, Tom Herbert wrote:

> I have a question about modifiable Destination Options.
>
> RFC8200 states: "The third-highest-order bit of the Option Type
> specifies whether or not the Option Data of that option can change en
> route to the packet's final destination."
>
> I don't see that that setting this bit for a Destination Option is
> prohibited. So what is the effect of setting a Destination Option type
> to be modifiable en route? Is setting a Destination Option to be
> changeable en route valid? I suppose the text that extension headers
> except for HBH can't be processed in transit implies that a DO can
> never be modified en route and trumps the DO changeable bit, but are
> there case where it could be legitimately be changed, maybe the end
> host is allowed to modify the option before delivery to the
> application?
>
> Setting the third-highest-order bit of the Option Type in a Destination
Option indeed
does not make much sense, since intermediate nodes are not supposed to
modify
destination options. The purpose of this bit, if I correctly understood
what I have
read, is to allow an AH or ESP module to determine whether to include the
option
in the ICV calculation or replace it with zeroes. Whatever else happens
internal to
the source or destination node is, I think, out of scope for RFC 8200.

The IANA registry does not distinguish between HbH and Destination options,
but as it turns out, only PAD1, PADN, and the experimental types can appear
in either role, and no existing DO (other than the experimental types) has
the
third-highest-order bit set. One would hope that an attempt to make such any
assignment in the future would not survive the the review process.
Mike Heard

---

From: "C. M. Heard" <[email-masked]>
Date: Sat, 30 Jun 2018 12:30:06 -0700

> assignment in the future would not survive the the review process.

After having written this, I was reminded by the new version announcement
that
https://tools.ietf.org/html/draft-leddy-6man-truncate-04 defines a
destination
option that is intended to be inspected by an intermediate node but only if
the
packet that contains it is too big to be forwarded, and in that case that
destination option ("Truncation Eligible") is overwritten with another one
("Truncated Packet"). In both cases, however, there is no option data that
can change unpredictably in flight; hence it makes no difference whether
the third-highest-order bit ("chg bit") is set to 0 or 1, as is (correctly)
noted in the IANA considerations section of that document.

I must say that I'd prefer to see the chg bit set to 0 for all options that
have no
option data, irrespective of whether they are Destination options or HbH
options,
for the simple reason that the zero-length option data simply cannot change
in
flight and to say otherwise is counter-intuitive. I'd gladly waive that
preference
if we were running out of option codes, but that currently is not the case.

Mike Heard