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

[Gyan Mishra <[e-mail]>]

On Mon, Sep 21, 2020 at 6:53 PM Fernando Gont <[e-mail]> wrote:

> 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.
>
> Gyan>. I think we are saying the same thing related to unknown eh headers
> using either protocol number name space and RFC 6564 does not improve or
> make it worse.  Can we add a normative reference to RFC 7045 related to eh
> processing issues with unknown headers types in protocol number name space
> and that RFC 6564 does not improve the situation.
>
>
>
>
>
> [...]
>
> >
>
> > 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. :-)


   Gyan> ok

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

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *



*M 301 502-134713101 Columbia Pike *Silver Spring, MD