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

[Fernando Gont <[e-mail]>]

Gyan,

On 19/9/20 16:52, Gyan Mishra wrote:
[....]
>     In that sense, RFC6564 is unable to make any difference. Whether
> 
>     providing such feature (common EH format for all EHs, from now on)
>     would
> 
>     have made a difference, is hard to tell... But I'd argue it wouldn't.
> 
> 
>      So bottom line we don’t think there is any operational impact 
> related to eh drops due to operators filtering based on the catch-22 
> issue regarding hardware not being able to support the new EH TLV based 
> standard RFC 6584 to support “new extension headers” supporting new TLV 
> as we believe that new are maybe few and far between that bucket that 
> can impact fast path eh processing. 

I'm just saying that I don't think RFC6564 will have any sort of impact, 
for worse or better.



> Based on the above we believe that 
> we are in that same boat as with eh headers use the same protocol number 
> name space thus impossible to have a complete list so not being able to 
> be processed.

No.

I'm saying that you cannot parse something that you don't know what it 
is. RFC6564 does not change that in any way.



[...]
> 
> Also from that perspective as well is not a reason for operators to drop 
> ant eh and an idea is to maybe just explicitly permit all the original 
> RFC 8200 standard eh and new RFC 6584 eh headers as a recommendation to 
> not just drop hbh and other headers that could end up being processed in 
> the slow path.  So instead of doing a drop xyz header followed by a 
> permit any you explicitly permit all RFC 8200 and RFC 6584 headers If 
> your platform supports.

Please see draft-ietf-v6ops-ipv6-ehs-packet-drops. :-)

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