Re: Usable extension headers [Re: New Version Notification for draft-voyer-6man-extension-header-insertion-08.txt]

[Ole Troan <[e-mail]>]

Brian,

> On 28 Nov 2019, at 23:06, Brian E Carpenter <[e-mail]> wrote:
> 
> On 29-Nov-19 00:03, Ole Troan wrote:
> ...> RFC7872 was (IMNSHO) based on the flawed belief that any end-host/service end-point should accept arbitrary extension headers.
> 
> I don't think so. The extension header mechanism was designed on a "consenting adults" model where all that matters is that both end points support a particular header type. (With two exceptions: the fragment header and the hop-by-hop options header, which are both significant en route. The routing header is *not* an exception to that model.) RFC7872 might be construed as testing whether that model is viable, but it doesn't imply any particular belief about end systems afaik.

The belief in the document is that what you get from Alexa's list of web sites will give you an address of a fully compliant IPv6 system. And that it will support:

   o IPv6 packets with a Destination Options header of 8 bytes;

   o  IPv6 packets resulting in two IPv6 fragments of 512 bytes each
      (approximately); and

   o  IPv6 packets with a Hop-by-Hop Options header of 8 bytes.

The IP address you get back from an AAAA query of the Alexa list is rarely an IPv6 host. The IP address represents an abstract service point.
There is a fairly complicated set of infrastructure behind that IP addresss. Load balancers, NATs, NAT64s etc.
But the point is that the service profile is known in the infrastructure.

And if there are no valid use case for any packet with a DH, FH or HBH. Why would you think that an operator of such a service should not drop those packets on the floor?
That's the flawed assumption in this document.

HBH is different, as a router punt flag. RFC7872 essentially asks "if we ever came up with a useful HBH option, how would it fare in the Internet?". One would expect numbers to be skewed since no Internet deployable HBH option existed at the point of measurement.
There are improvements in RFC8200 and I'd believe most old boxes that had serious problems with HBH are largely phased out. And we for the first time have an Internet wide HBH option defined (PMTUD). Gorry et al is running measurements of that now. And I believe he has already found some ASs that block HBH.

Cheers,
Ole