Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers

[Fernando Gont <[e-mail]>]

Hello, Gyan,

On 19/9/20 01:06, Gyan Mishra wrote:
> 
> Hi Fernando
> 
> In this draft can we talk add point about the catch 22 situation 
> described in RFC 7045 excerpt below bottom of introduction:
> 
> I think this issue is critical to the overall issue with processing of 
> EHs and operators filtering EHs in some cases unnecessarily.

What, specifically, would you like us to say about it?

Note: RFC6564 has not (and will not) improve the situation in this 
respect. Since EHs share the same namespece as "upper layer protocols", 
then, in order for a middlebox to know it can parse a header as in the 
RFC6564 format, it has to now that the corresponding "protocol number" 
identifies an EH (as opposed to an upper layer protocol).

RFC6564 would have been useful only if we had closed the door to the 
definition of new EHs with a new "protocol number", and had specified 
that any new EHs would share the same protocol number ("XX", to have 
been assigned by IANA at the time RFC6564 was published).

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492