Subject: Re: A long HBH Options question

From: "C. M. Heard" <[email-masked]>
Date: Tue, 21 Aug 2018 17:39:45 -0700

On Tue, 21 Aug 2018 19:16:55 +0000, Ron Bonica wrote:
> [ … ] let's assume that:
>
> - A packet contains an HBH option and the high-order bits of the HBH
>   Option type are "10" [could also be "01" or "11']
>
> - The packet traverses Router A and Router B on route to its
>   destination
>
> - Router A is not configured to process HBH options
>
> - Router B is configured to process HBH options
>
> - Neither Router A nor Router B recognize the HBH option contained by
>   the above-mentioned packet.
>
> I think that RFC 8200 requires the following behavior:
>
> - Router A forwards the packet to Router B, without examining the HBH
>   Options header
>
> - Router B discards the packet, because it doesn't recognize the
>   option.
>
> Is this the required behavior?

Yes.

> If so, does this behavior cause cognitive dissonance for anybody else?

It sure does.

> I am thinking that the "act" bits are meaningless in the HBH extension
> header. This discussion may also be applicable to
> draft-herbert-ipv6-update-dest-ops.

The "act" bits are not exactly meaningless, but only the encoding "00"
will elicit consistent behavior from nodes that  comply with RFC 8200
and don't recognize the option. To me, it would seem quite odd if the
designer of any new HbH option were to choose an encoding with
"act" bits other than "00". For already allocated options, any encoding
other than "00" will not have the results expected by those who
designed the options assuming that the rules in RFC 2460 would be
followed. Thus, that the maintainers of existing HbH options with the
"act" bits other than "00" should probably re-examine the option
encoding in light of the change wrought by RFC 8200. Here is the list:

0x63  RPL (RFC 6553, PS)
0x6D  MPL (RFC 7731, PS)
0xC2  Jumbo Payload (RFC 2675, PS)
0xEE  IP_DFF (RFC 6971, Experimental)

The ROLL WG has in fact taken this step with the RPL option, though for
reasons independent of the change made in RFC 8200. The thinking
behind the original design in RFC 6553 was that it was undesirable for
the RPL option to escape from the RPL domain in which it was originated,
so "act" was set to "01" to force nodes external to the domain to
silently discard escaped packets. That thinking has been revised, and
there is a document in last call that will deprecate the existing
code point and get a new one (probably 0x23) with "act" set to "00".

A re-examination of already allocated destination options would be
called for if the change proposed in draft-herbert-ipv6-update-dest-ops
were to be implemented. Here is that list:

0xC9  Home Address (RFC 6275, PS)
0x8A  Endpoint Identification (DEPRECATED)
0x8B  ILNP Nonce (RFC 6744, Experimental)
0x8C  Line-Identification (RFC 6788, PS)

The Home Address option would actually not be affected by the
proposed change in draft-herbert-ipv6-update-dest-ops since it
isn't allowed to appear appear before a Routing Header. I have
not examined the others, however.

Mike Heard

---

From: Ole Troan <[email-masked]>
Date: Wed, 22 Aug 2018 12:43:42 +0200

> 0xC2  Jumbo Payload (RFC 2675, PS)

You couldn’t possibly regard the jumbo payload option as optional.
You just wouldn’t get packets through non-supporting routers.
I am fine with regarding this as a configuration error.

Cheers,
Ole

---

From: "C. M. Heard" <[email-masked]>
Date: Wed, 22 Aug 2018 07:06:50 -0700

> > encoding in light of the change wrought by RFC 8200. Here is the list:
[ ... ]
> > 0xC2  Jumbo Payload (RFC 2675, PS)
[ ... ]
> I am fine with regarding this as a configuration error.

Agreed. Brian Carpenter has made the same point.

--cmh

---

From: Tom Herbert <[email-masked]>
Date: Wed, 22 Aug 2018 07:28:19 -0700

> 0x8C  Line-Identification (RFC 6788, PS)
Mike,

Thanks for looking into this.

Neither RFC6744 nor RFC6788 explicitly prohibit putting the option in
front of a routing header, but I don't think doing that would make
much sense in either case. In case of ILNP nonce, the option is used
to communicate to a peer node information about the reverse path so
it's really intended for the transport destination endpoint.
Line-Identification is only used in conjunction with a ND packet being
tunneled in the payload so only the ultimate destination should do
anything with the option. It would be a good idea if specifications
for new Destination Options explicitly said whether or not they can
appear before a Routing header.

Tom

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Ron Bonica <[email-masked]>
Date: Wed, 22 Aug 2018 16:43:19 +0000

Hi Tom,

Judging by the feedback, those experiencing cognitive dissonance constitute a small minority. Maybe our concerns are better addressed with medication than clarifications ;-)

However, if you want to reduce the number of pills that I take every day, you might add the following clarifications to your document:

- What do the "act" bits mean when they appear in an HBH option?
- What does the "chg" bit mean when it appears in an option where Opt Data Len is equal to 0.
- What does the "chg" bit mean when it appears in a Destination Options header precedes the Routing Options header.
- What does the "chg" bit mean when it appears in a Destination Options header follows the Routing Options header (or the packet does not contain a routing header).

                                                                              Ron

> -----Original Message-----
> From: Tom Herbert <[email-masked]>
> Sent: Wednesday, August 22, 2018 10:28 AM
> To: C. M. Heard <[email-masked]>
> Cc: Ron Bonica <[email-masked]>; 6man <[email-masked]>
> Subject: Re: A long HBH Options question
> 
> >> I am thinking that the "act" bits are meaningless in the HBH
> >> extension header. This discussion may also be applicable to
> > designer of any new HbH option were to choose an encoding with "act"
> > bits other than "00". For already allocated options, any encoding
> > The ROLL WG has in fact taken this step with the RPL option, though
> > for reasons independent of the change made in RFC 8200. The thinking
> > the RPL option to escape from the RPL domain in which it was
> > originated, so "act" was set to "01" to force nodes external to the
> > domain to silently discard escaped packets. That thinking has been
> > revised, and there is a document in last call that will deprecate the
> > existing code point and get a new one (probably 0x23) with "act" set to
> "00".
> >
> > 0x8A  Endpoint Identification (DEPRECATED) 0x8B  ILNP Nonce (RFC 6744,
> > Experimental) 0x8C  Line-Identification (RFC 6788, PS)
> >
> Mike,
> 
> Neither RFC6744 nor RFC6788 explicitly prohibit putting the option in front of
> a routing header, but I don't think doing that would make much sense in either
> case. In case of ILNP nonce, the option is used to communicate to a peer node
> information about the reverse path so it's really intended for the transport
> destination endpoint.
> Line-Identification is only used in conjunction with a ND packet being tunneled
> in the payload so only the ultimate destination should do anything with the
> option. It would be a good idea if specifications for new Destination Options
> explicitly said whether or not they can appear before a Routing header.
> 
> Tom
> 
> > The Home Address option would actually not be affected by the proposed
> > change in draft-herbert-ipv6-update-dest-ops since it isn't allowed to
> > appear appear before a Routing Header. I have not examined the others,
> > however.
> >
> > Mike Heard
> >
> > Administrative Requests:
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail
> > man_listinfo_ipv6&d=DwIFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzo
> > CI&r=Fch9FQ82sir-BoLx84hKuKwl-
> AWF2EfpHcAwrDThKP8&m=kq67Q11JdAIfRhVwF5c
> > N-DpFwRB9d3ip8DQlPOmzaII&s=UJLxrCn-N92TYQRkRq9QD_0-
> Du3MfKXlx3a1n1bVe7U
> > &e=

---

From: Tom Herbert <[email-masked]>
Date: Wed, 22 Aug 2018 10:16:55 -0700

> Hi Tom,

Hi Ron,

> - What do the "act" bits mean when they appear in an HBH option?

That would be a good clarification of HBH processing in RFC8200.

> - What does the "chg" bit mean when it appears in an option where Opt Data Len is equal to 0.

Okay.

> - What does the "chg" bit mean when it appears in a Destination Options header follows the Routing Options header (or the packet does not contain a routing header).

I think that's already covered in the draft (section 3). Please let me
know if it's not clear.

Tom

---

From: Ron Bonica <[email-masked]>
Date: Wed, 22 Aug 2018 18:30:02 +0000

Tom,

Fair enough. The first item is out of scope for your draft. The second will be included. The third and fourth are already in your draft.

                                                           Ron

> Sent: Wednesday, August 22, 2018 1:17 PM
> To: Ron Bonica <[email-masked]>
> Cc: C. M. Heard <[email-masked]>; 6man <[email-masked]>
> > Judging by the feedback, those experiencing cognitive dissonance
> > constitute a small minority. Maybe our concerns are better addressed
> > with medication than clarifications ;-)
> >
> > However, if you want to reduce the number of pills that I take every day,
> you might add the following clarifications to your document:
> >
> > - What does the "chg" bit mean when it appears in a Destination Options
> header precedes the Routing Options header.
> > - What does the "chg" bit mean when it appears in a Destination Options
> header follows the Routing Options header (or the packet does not contain a
> routing header).
> 
> I think that's already covered in the draft (section 3). Please let me know if it's
> not clear.
> 
> Tom
> 
> >
> >
> > Ron
> >
> >
> >> > will elicit consistent behavior from nodes that  comply with RFC
> >> > 8200 and don't recognize the option. To me, it would seem quite odd
> >> > if the designer of any new HbH option were to choose an encoding with
> "act"
> >> > followed. Thus, that the maintainers of existing HbH options with
> >> > the "act" bits other than "00" should probably re-examine the
> >> > option encoding in light of the change wrought by RFC 8200. Here is the
> list:
> >> >
> >> > 0x63  RPL (RFC 6553, PS)
> >> > 0x6D  MPL (RFC 7731, PS)
> >> > for reasons independent of the change made in RFC 8200. The
> >> > thinking behind the original design in RFC 6553 was that it was
> >> > undesirable for the RPL option to escape from the RPL domain in
> >> > which it was originated, so "act" was set to "01" to force nodes
> >> > external to the domain to silently discard escaped packets. That
> >> > thinking has been revised, and there is a document in last call
> >> > that will deprecate the existing code point and get a new one
> >> > (probably 0x23) with "act" set to
> >> "00".
> >> >
> >> Line-Identification is only used in conjunction with a ND packet
> >> being tunneled in the payload so only the ultimate destination should
> >> do anything with the option. It would be a good idea if
> >> specifications for new Destination Options explicitly said whether or not
> they can appear before a Routing header.
> >>
> >> Tom
> >>
> >> > isn't allowed to appear appear before a Routing Header. I have not
> >> > examined the others, however.
> >> >
> >> > Mike Heard
> >> >
> >> > -------------------------------------------------------------------
> >> > - IETF IPv6 working group mailing list [email-masked] Administrative
> >> > Requests:
> >> > https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_m
> >> > ail