On Sun, May 5, 2019 at 12:45 AM David Miller <da...@davemloft.net> wrote: > > From: Tom Herbert <t...@herbertland.com> > Date: Mon, 29 Apr 2019 16:15:11 -0700 > > > Extension headers are the mechanism of extensibility for the IPv6 > > protocol, however to date they have only seen limited deployment. > > The reasons for that are because intermediate devices don't handle > > them well, and there haven't really be any useful extension headers > > defined. In particular, Destination and Hop-by-Hop options have > > not been deployed to any extent. > > > > The landscape may be changing as there are now a number of serious > > efforts to define and deploy extension headers. In particular, a number > > of uses for Hop-by-Hop Options are currently being proposed, Some of > > these are from router vendors so there is hope that they might start > > start to fix their brokenness. These proposals include IOAM, Path MTU, > > Firewall and Service Tickets, SRv6, CRH, etc. > > > > Assuming that IPv6 extension headers gain traction, that leaves a > > noticeable gap in IPv4 support. IPv4 options have long been considered a > > non-starter for deployment. An alternative being proposed is to enable > > use of IPv6 options with IPv4 (draft-herbert-ipv4-eh-00). > > "Assuming ipv6 extension headers gain traction, my patch set is useful." > > Well, when they gain traction you can propose this stuff. > > Until then, it's a facility implemented based upon wishful thinking. > Hi Dave,
"Assuming" was probably the wrong word here :-). They are gaining traction. A specific example is In-situ OAM (IOAM) which is being heavily pushed by Cisco (draft-brockners-inband-oam-data-07). This requires host to network signalling in data packets which goes far beyond what information the IP header contains. Their first inclination was to hack up UDP encapsulation protocols like Geneve, but that fundamentally doesn't work for various reasons. We were able to convince them that Hop-by-Hop Options is the correct mechanism so they are pursuing that in draft-ioametal-ippm-6man-ioam-ipv6-options-00. Naturally, they want to support both IPv6 and IPv4 for their products, but there is no usable mechanism in IPv4 (IP options are effectively obsoleted)-- hence the motivation for back porting extension headers to IPv4. In short, we're at a crossroads. Extension headers are "use it or lose it". If we don't figure out how to make these usable and useful soon, that may never happen and they'll be relegated to a historical footnote just like IP options. IMO, it would be a shame if that happens since we'd be surrendering a valuable feature. Tom > Sorry Tom, I kept pushing back using trivial coding style feedback > because I simply can't justify applying this. >
