Subject: Re: [Errata Rejected] RFC6564 (4423)

From: "C. M. Heard" <[email-masked]>
Date: Thu, 17 Sep 2015 05:43:54 -0700

John Leslie <john at jlc.net> wrote:
> Fernando Gont <fgont at si6networks.com> wrote:
> > On 09/16/2015 05:07 AM, Ole Troan wrote:
> >>...
> >> with the HBH container, DestOpt container and the RH container
> >> haven?t we covered pretty much all the bases already?
>
>    No. We haven't.
>
>    Consider ConEx (congestion exposure):
>
>    It wants to be accessed by the uplink ISP router in _both_ directions,
> and by various monitoring points, mostly at AS boundaries. It _can_ be
> ignored by every router along the way. We ended up calling it a destination
> option; but that's a bad fit.

Name aside, I would be curious to know why it is a bad fit.  In this message

http://www.ietf.org/mail-archive/web/ipv6/current/msg20215.html

I acted on Brian Carpenter's suggestion to examine whether any of
the existing extension headers could not have been equally well
implemented by one of the following:

- hop-by-hop option
- destination option
- upper-layer header

My conclusion -- subject to provisos that the Destination Options
header be allowed to appear more than twice and that constraints be
allowed regarding the order in which destination options could
appear -- was that the only extension headers that had really good
reasons for being extension headers rather than one of the above
were the Fragment Header and the Authentication Header, and AH was
so classified only because it is shared with IPv4, which has no
analog to the Destination Options header.

>    There are certainly other cases of monitoring along the way which
> absolutely _don't_ want to involve every router (and very likely don't
> want to involve the destination).

Fair enough, but can you make the case that an extension header
(with or without the proposed Universal Extension Header (UEH))
would ever work better for that purpose than a destination option?

> > Who knows...
>
>    Exactly! We can't know all the uses to which IPv6 may be put in the
> future; and we really should cure ourselves of pretending we can.
>
> > In any case, right now RFC6564 not only does not really help (*), but is
> > misleading: I was tricked myself when I was working on RFC7610 that a
> > middle-box could parse past unknown EHs. So even if one didn't want to
> > address this problem (which I think would be a bad idea), at the very
> > least one shouldn't leave RFC6564 "as is".
> >
> > (*) I must say that I was surprised when Erik reminded me some time ago
> > that they tried to push a similar idea at the time... i.e., not sure why
> > *that* didn't become RFC6564.
>
>    Perhaps someone remembers?

See Suresh Krishnan's message

http://www.ietf.org/mail-archive/web/ipv6/current/msg20168.html

wherein he said

  "Yes we wanted to do this as well, but the WG didn't want to waste
   a protocol number for something that may never be used"

where "this" means something along the lines of the proposed UEH.

Mike Heard