Re: [Tsv-art] [v6ops] [Last-Call] Tsvart last call review of draft-ietf-v6ops-ipv6-ehs-packet-drops-05

[Tom Herbert <[e-mail]>]

On Wed, Apr 7, 2021 at 7:22 AM Rob Wilton (rwilton) <[e-mail]> wrote:
>
> Hi Tom, Fernando,
>
> I would like to send this document to the IESG.
>
> Have we managed to reach a conclusion on this issue?
>
> Tom, my reading of this draft is as Fernando describes, in that it
> only intends to describe the implications and avoids making any
> recommendations.
>
> I was going to suggest that a sentence be added to the introduction to
> make this clear, but on checking again I see that the document
> already contains a pretty clear disclaimer in section 2.
>
> 2.  Disclaimer
>
>    This document analyzes the operational challenges represented by
>    packets that employ IPv6 Extension Headers, and documents some of the
>    operational reasons why these packets are often dropped in the public
>    Internet.  This document is not a recommendation to drop such
>    packets, but rather an analysis of why they are dropped.
>
> Is this sufficient?
>
> I guess that the authors could consider adding a sentence that it also doesn't provide any recommendation on how end hosts make use of extension headers, but that might be a bit incongruous in the sense that the document doesn't appear to talk about end host behaviour at all ...

Rob,

Given that hosts are the ones creating extensions headers and other
packet formats, hosts have a vested interest in how routers are
dealing with their packets. Even before this document was created, we
have long known that extensions headers might be dropped and have been
working on mitigations to reduce the number of drops which are already
addressing some of the reasons that packets with EH. For instance,
consider draft-hinden-6man-hbh-processing-00; this is a proposal to
limit the number of HBH options to exactly one. The idea is that
routers will make it feasible for routers packets that have HBH
options, with the trade off of specifically limiting the extensibility
of the protocol. The problem is there is no data that indicates this
proposal would have the desired effect; we don't if routers would
start accepting packets that are limited to one HBH option.

So my fundamental concern with this draft is that it is an entirely
qualitative description of a well known problem, however a qualitative
analysis is insufficient input for moving extension headers forward.
In the draft, there are several reasons suggested as to why routers
might drop packets, however there is no indication of the relative
occurrence frequency of these. Also, there are parameterizations
mentioned such as in the state that routers might drop if the chain is
"too long", there is no analysis on exactly what "too long" commonly
is (a couple of sizes for parsing buffers are mentioned but without
reference which is another frustration of mine with this draft). A
quantified analysis of the problem would delve into implementations
and deployment thereby providing actionable data. Note this is not the
same as making recommendations, I am just asking for the operational
data as part of the analysis from which we could derive guidance or
new protocol requirements.

Tom


Tom

>
> Regards,
> Rob
>
>
> > -----Original Message-----
> > From: v6ops <[e-mail]> On Behalf Of Tom Herbert
> > Sent: 10 March 2021 02:03
> > To: Fernando Gont <[e-mail]>
> > Cc: Gorry Fairhurst <[e-mail]>; IPv6 Operations
> > <[e-mail]>; [e-mail];
> > [e-mail]; [e-mail]
> > Subject: Re: [v6ops] [Last-Call] Tsvart last call review of draft-ietf-
> > v6ops-ipv6-ehs-packet-drops-05
> >
> > On Tue, Mar 9, 2021 at 4:03 PM Fernando Gont <[e-mail]>
> > wrote:
> > >
> > > On 9/3/21 19:07, Tom Herbert wrote:
> > > [...]
> > > >
> > > > Yes, ACLs on transport layer ports are common requirements, however
> > > > the problem arises from related requirements that arise due to the
> > > > limitations of routers to be able to locate the transport layer
> > > > information in a packet. An example of such an implied requirement
> > > > from this draft is "don't send packets with IPv6 header chains that
> > > > are too long because some routers can't parse deep enough into packets
> > > > to find the transport layer ports due to implementation constraints
> > > > (like limited size parsing buffer)".
> > >
> > > You seem to be reading more from the document than what we actually said
> > > in the document.
> > >
> > > There are no requirements in this document. We simply explain things
> > > operators need to do, what are the associated limitations in real-world
> > > devices, and what's the likely outcome.
> > >
> > > That's not an implied requirement, but simply a description of facts.
> > >
> > It's obvious that the implied or at least inferred requirement is that
> > if a host wants to increase the probability of packets making it to
> > the destination then they should not make header chains too long. This
> > would also be an obvious interoperability requirement, i.e. if I make
> > my header chains too long then packets will be dropped and my host
> > stack is not interoperable with some elements in the network.
> >
> > >
> > >
> > > > While the rationale for the
> > > > requirement may make sense, the problem, at least from the host stack
> > > > perspective of trying to send packets with low probability they'll be
> > > > dropped, is that a requirement that "don't IPv6 header chains that are
> > > > too long" is is useless without any quantification as exactly to what
> > > > "too long" might be.
> > >
> > > "too long" for the processing device(s). You don't know what devices
> > > will process your packets, hence cannot even guess what "too long" might
> > > mean.
> > >
> > > What you know for sure is that the longer the chain, the lower the
> > > chances of your packets surviving -- as per RFC7872.
> > >
> > That seems to me more like an assumption than a proven fact. To prove
> > it we'd need the data that correlates the length of the chain with
> > probability of drop, or alternatively, one could survey common router
> > implementations' capabilities and similarly extrapolate the
> > correlation. If we had this data then we could derive a meaningful
> > quantified requirement for both what routers are expected to process
> > and what hosts can expect. RFC7872 doesn't really have sufficient data
> > to make this correlation, and besides that it is not current.
> >
> > In any case, this draft qualitatively describes why routers are
> > droppings. Which I suppose is good, but, given that information, I
> > don't see much that helps host developers that are sending packets in
> > the network and are trying to go beyond sending packets that conform
> > to the least common denominator of plain TCP/IP.
> >
> > Tom
> >
> > > Thanks,
> > > --
> > > Fernando Gont
> > > SI6 Networks
> > > e-mail: [e-mail]
> > > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
> > >
> > >
> > >
> > >
> >
> > _______________________________________________
> > v6ops mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/v6ops