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

[Gyan Mishra <[e-mail]>]

On Sat, Sep 19, 2020 at 6:37 AM Fernando Gont <[e-mail]> wrote:

> Hi, Ole,
>
>
>
> On 19/9/20 06:48, Ole Troan wrote:
>
> >> On 19 Sep 2020, at 09:19, Fernando Gont <[e-mail]> wrote:
>
> >>
>
> >> 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).
>
> >>
>
> >
>
> > Right, but only if the assumption that middleboxes would allow arbitrary
> headers in between network and transport is true.  That seems unlikely to
> me.
>
>
>
> I agree. I don't think they would allow arbitrary headers in between
>
> network and transport. That said, *if* they were meaning to, they
>
> wouldn't be able to handle "unknown EHs", anyway. i.e., RFC6564 does not
>
> really deliver what's probably implied by the document: parsing unknown
> EHs.
>
>
>
> 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. 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.

So net-net in theory does not really make a difference that the new RFC
6584 TLV style has made a difference in solving the problem and also maybe
be contributing to problem if old hardware does not support the new tlv
standard catch 22 issue.  Since tlv style is for new headers it helps new
headers being developed but you still have the gap with old headers using
protocol number name space and not documented or tracked anywhere for
support ability.

Here is an idea to help operators and overall eh processing issues from in
infrastructure ACL standpoint.

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.

>
>
> 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