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

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.

https://tools.ietf.org/html/rfc7045

   A contributory factor to this problem is that because extension
   headers are numbered out of the existing IP Protocol Number space,
   there is no collected list of them.  For this reason, it is hard for
   an implementor to quickly identify the full set of standard extension
   headers.  An implementor who consults only RFC 2460
<https://tools.ietf.org/html/rfc2460> will miss all
   extension headers defined subsequently.

   This combination of circumstances creates a "Catch-22" situation
   [Heller <https://tools.ietf.org/html/rfc7045#ref-Heller>] for the
deployment of any newly standardised extension
   header except for local use.  It cannot be widely deployed because
   existing middleboxes will drop it on many paths through the Internet.
   However, most middleboxes will not be updated to allow the new header
   to pass until it has been proved safe and useful on the open
   Internet, which is impossible until the middleboxes have been
   updated.

The uniform TLV format now defined for extension headers [RFC6564
<https://tools.ietf.org/html/rfc6564>]
   will improve the situation, but only for future extensions.  Some
   tricky and potentially malicious cases will be avoided by forbidding
   very long chains of extension headers that need to be fragmented
   [HEADER-CHAIN
<https://tools.ietf.org/html/rfc7045#ref-HEADER-CHAIN>].  This will
alleviate concerns that stateless
   firewalls cannot locate a complete header chain as required by the
   present document.

   However, these changes are insufficient to correct the underlying
   problem.  The present document clarifies that the above requirement
   from RFC 2460 <https://tools.ietf.org/html/rfc2460> applies to all
types of nodes that forward IPv6 packets
   and to all extension headers standardised now and in the future.  It
   also requests that IANA create a subsidiary registry that clearly
   identifies extension header types and updates RFC 2780
<https://tools.ietf.org/html/rfc2780> accordingly.
   Fundamental changes to the IPv6 extension header architecture are out
   of scope for this document.

On Wed, Sep 16, 2020 at 5:44 AM Fernando Gont <fgont@si6networks.com> wrote:

> Hi, Tom,
>
>
>
> On 15/9/20 13:08, tom petch wrote:
>
> > From: Fernando Gont <fgont@si6networks.com> Sent: 15 September 2020
>
> > 12:24
>
> >
>
> > Hi, Tom,
>
> >
>
> > On 15/9/20 06:05, tom petch wrote: [...]
>
> >>
>
> >> I wouldn't mind writing a Section that sits between the current
>
> >> Sections 2 and 3 with more background on extension headers, if you
>
> >> think that would be of value.
>
> >>
>
> >> <tp> Yes please.  One page or two pages max, summarising why they
>
> >> were thought a good idea, the different types and their uses, how
>
> >> widely used they are  and with references;  RFC8200 may be
>
> >> Normative but it takes a while to appear and that after RFC2460!
>
>
>
> Ok.  I will craft text and send it to the list for review before
>
> incorporating it.
>
>
>
>
>
>
>
> > An intro to EHs -- and e.g., how the structure compares to the IPv4
>
> > packet structure is simply and doable. OTOH, what you suggest might
>
> > now. :-)
>
> >
>
> > e.g.,Not sure one can tell how widely used they are. Also, getting
>
> > into enumerating EHs will result in the relevant section becoming
>
> > stale soon, since there seems to be quite a bit of development in
>
> > this area.
>
> >
>
> > <tp> My sense is of the middle part of the I-D, the technical detail,
>
> > is floating in mid-air, lacking an introduction, lacking a
>
> > conclusion. and as such will only convince those who are already
>
> > convinced.
>
>
>
> FWIW, at lesast from my pov, we don't really want to convince people (of
>
> doing this or that), but rather want to document the reasons for which
>
> people may drop packets with EHs. i.e. documenting that such packets may
>
> be dropped for very valid rational reasons.
>
>
>
>
>
> > I have to read between the lines to divine that there is a connection
>
> > between fragmentation and EH, between length of packet header and EH,
>
> > between security and EH and so on.  By not making the connection
>
> > explicit, I think that you will lose your target audience.
>
>
>
> Fair enough. I'm always keen to improving the document, so thanks for
>
> the suggestion!
>
>
>
> Regards,
>
> --
>
> Fernando Gont
>
> SI6 Networks
>
> e-mail: fgont@si6networks.com
>
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
>
>
>
>
>
>
> _______________________________________________
>
> v6ops mailing list
>
> v6ops@ietf.org
>
> https://www.ietf.org/mailman/listinfo/v6ops
>
> --

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

*Gyan Mishra*

*Network Solutions A**rchitect *

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