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

[Tom Herbert <[e-mail]>]

On Wed, Nov 27, 2019 at 8:28 PM Brian E Carpenter
<[e-mail]> wrote:
>
> Hi Bert,
> On 28-Nov-19 16:34, Manfredi (US), Albert E wrote:
> > -----Original Message-----
> > From: ipv6 <[e-mail]> On Behalf Of Brian E Carpenter
> >
> >> As I experienced years ago when my Ph.D. student was making real-world experiments with SHIM6, and as RFC7872 reported too, it's an observed fact that the Internet isn't transparent to packets with extension headers, not even to currently standardised ones. The same appears to have been true for IPv4 Options for at least 25 years. So, to be honest, I have no idea how to change that for the open Internet. We seem to be stuck with a lowest common denominator network layer.
> >
> > Isn't the problem that routers must mostly not mess with these extension headers?
>
> "Mostly" isn't good enough. It needs to be 100%. It only takes one router or middlebox on the path to be allergic to extension headers, and that's what we see in practice.

Brian,

That is the crux of the problem: if deployment of some protocol
requires 100% compatibility with every node the network, then it's
impossible to ever deploy any new protocols. There is no such thing as
100% support for pretty much anything other then maybe TCP/IPv4
without IP options. This is true on the Internet, but also true in
even moderately large closed networks. For instance, a sprawling
closed network like Google or Facebook doesn't have "flag days" to
push new support for new protocols to all nodes. IPv6 had to be rolled
out incrementally for example.

So the problem is how do we deploy protocols that aren't necessarily
supported across all possible paths. I think the answer is already
known: if we have a priori knowledge that some path supports a
protocol then use the protocol, if the particular path doesn't support
a protocol then don't use it and fall back to a degenerative protocol
more likely to be palatable. There are several examples of this
technique: Happy Eyeballs for IPv6, QUIC fallback to TCP, UDP DNS
fallback to TCP DNS, etc.

So then the question becomes how does a source node determine the
protocols supported for the destination it wants to reach? This can be
done with probing, configuration, or maybe a mashup map (if you want
to say that the set of ad hoc destinations that support a particular
protocol form a "limited domain" then sure). The map idea is
compelling, for instance if the data from RFC7872 was published as the
list destinations that are known to properly handle EH instead of just
rolled up statistics, then a node wishing to us EH could query the
database to see if a desired destination is usable for EH. Of course,
for that model to be practical we'd want the map to be updated in real
time based user experience hence the mashup attribute. The map of the
Internet would have the added benefit of providing a public report of
what difference service providers are supporting and hence users can
make informed decisions when choosing a provider (i.e. incentive for
providers to keep up with conformant protocol support).

Tom

>
>    Brian
>
> > Even hop-by-hop headers can be ignored by routers (unless specifically configured not to ignore)?
> >
> > So, you have a layer 3 extension option, but the boxes which do the heavy lifting at layer 3 must never mess with. On the other hand, end systems, which can play with IP extension headers, have virtually no knowledge of the network topology details.
> >
> > Router manufacturers seem to prefer the simplest possible routing mechanization. Hosts don't typically have a clue how best to use the knob. My impression has always been that people are as discouraged to use layer 3 extension headers, as they are to use packet fragmentation. One of those things you want to avoid, unless you're a glutton for punishment? Not so?
> >
> > Happy Thanksgiving, for those to whom this applies.
> >
> > Bert
> >
> >
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------