Re: New Version Notification for draft-hinden-6man-hbh-processing-01.txt

[Fernando Gont <[e-mail]>]

Tom,

On Fri, 2021-06-11 at 11:55 -0700, Tom Herbert wrote:
> 
> 
> It really depends on what you mean by "activate anything from EHs".
> There are at least two possible interpretations: 1) Process the EHs
> like HBH 2) Forward packets containing EHs without doing anything
> with
> them. For the viability of EHs, including future use cases, we mostly
> care about interpretation #2. This really just means we want nodes to
> ignore packets with extension headers instead of dropping them.
> According to the data in RFC7872 that mostly is already happening
> (e.g. 90% of packets with Destination Options we're being
> successfully
> delivered at least five years ago). 

RFC7872 doesn't convey everything that we measured: the number get
uglier as you increase the size of EHs (DO8 vs DO16 vs DO32 vs DO64,
etc.).




> RFC8200 has already relaxed the
> requirement that all nodes in the path need to process HBH, so so
> aside from an explicit policy, the biggest impediment is in
> implementation for those intermediate nodes that need to access the
> transport layer and if the necessary headers don't fit in the parsing
> buffer they may drop the packet. The solution to that, I believe, is
> to set a requirement specifying the maximum length IP header chain
> (e.g. 104 bytes including IPv6 header) that nodes must support if
> they are accessing the transport layer.

This is indeed as much as we (6man( can probably do.


For the amusement of participants, almost ten years ago I proposed to
limit the IPv6 header chain to 1280 bytes, and the idea didn't fly (
https://datatracker.ietf.org/doc/html/draft-gont-6man-oversized-header-chain-00
). :-)

Thanks,
-- 
Fernando Gont
Director of Information Security
EdgeUno, Inc.
PGP Fingerprint: DFBD 63E3 B248 AE79 C598 AF23 EBAE DA03 0644 1531