Re: [IPv6] Data for EH drops (was Re: Comments on draft-ietf-6man-hbh-processing-12)

[Tom Herbert <[e-mail]>]

On Wed, Dec 6, 2023 at 8:52 AM Eric Vyncke (evyncke)
<evyncke=[e-mail]> wrote:
>
> Tom
>
>
>
> All the previous research papers (including draft-vyncke-james) indeed seem to *indicate* a HW limitation, but I have yet to see a lab tested measurement for the top 95% routers used in the global Internet.
>
>
>
> This is the part where I am hugely interested: actual data about devices (even if working for one such vendor)

Eric,

We have seen anecdotal data on this over the years, but I'm not sure
if there's ever been an accurate survey on vendor capabilities. I
believe the trend is newer devices are going to 256 or even 384 byte
parsing buffers, but of course we should expect a lot of variance with
legacy devices still in operation. I still belive that IETF should at
least set a feasible minimum requirement.

Tom

>
>
>
> -éric
>
>
>
> From: Tom Herbert <tom=[e-mail]>
> Date: Wednesday, 6 December 2023 at 17:38
> To: Eric Vyncke (evyncke) <[e-mail]>
> Cc: Tim Chown <[e-mail]>, Geoff Huston <[e-mail]>, 6man <[e-mail]>
> Subject: Data for EH drops (was Re: [IPv6] Comments on draft-ietf-6man-hbh-processing-12)
>
> On Wed, Dec 6, 2023 at 6:35 AM Eric Vyncke (evyncke)
> <evyncke=[e-mail]> wrote:
> >
> > Tim,
> >
> >
> >
> > *Very* interesting return of information as R&E networks are probably easier to approach with a “research” topic such as EH drops.
> >
> >
> >
> > If the R&E networks drops are not by policy, then I am afraid that either the policy is not correctly applied or there is a platform limitation (e.g., applying a L4 ACL forces line cards to parse the EH chain until either the L4 header is found or max size of EH is reached).
>
> Eric,
>
> The latter is parsing buffer limitation in hardware devices. The
> marker for this is when we see packets with small DestOpts are good,
> but larger ones are dropped.
>
> The APNIC data has numbers for the drop rates of different size
> DestOpts (https://blog.apnic.net/2022/10/13/ipv6-extension-headers-revisited/).
> Looking at the APNIC data the drop rates of DestOpts for different
> sizes are reported as 8,16 bytes->30%, 32 bytes->32%, 64 bytes->39%,
> 128->86%. Assuming that drops in the 8 byte case are because of
> policy, we can normalize to the drop rates for those devices that
> don't drop all EH by policy: 8 bytes->0%, 16 byte->3%, 64 bytes->13%,
> 128 bytes->80%. Success with 8 and 16 bytes imply at least a 96 byte
> parsing buffer, success of 16 bytes implies at least 128 byte parsing
> buffer, and 128 bytes implies a 192 byte or larger parsing buffer.
>
> Based on this analysis, the requirement specified in the
> draft-ietf-6man-eh-limits-11 draft is:
>
> "If a router needs to parse the transport layer, for instance to
> deduce the transport layer port numbers, it MUST be able to correctly
> forward packets that contain an IPv6 header chain of 104 or fewer
> bytes, or equivalently, a router MUST be able to process a packet with
> an aggregate length of extension headers less than or equal to 64
> bytes."
>
> IMO, the APNIC data implies that a 128 byte parsing buffer is
> reasonably common in deployment to justify this requirement is
> feasible. It's true that smaller parsing buffers are a bit more
> common, however a 32 byte chain length is going to be less useful than
> 64 bytes for EH.
>
> Tom
>
> >>
> >
> > -éric
> >
> >
> >
> > From: ipv6 <[e-mail]> on behalf of Tim Chown <Tim.Chown=[e-mail]>
> > Date: Wednesday, 6 December 2023 at 15:02
> > To: Geoff Huston <[e-mail]>
> > Cc: 6man <[e-mail]>
> > Subject: Re: [IPv6] Comments on draft-ietf-6man-hbh-processing-12
> >
> > Hi,
> >
> > > In the first part of this yer, with the assistance from Gorry Fairhust and Anna Costura ot the Univ of Aberdeen we conducted a related experiment using a server located at that institution (which does NOT drop EH packets,) connected to JANET (which also  does not drop EH packets). However, we found that the major transit providers in the UK DO drop EH packets, including BT, BSKYB, Level 3, H3GUK, EE and ZEN. So we found it hard to see further afield.
> >
> > As someone who works for Jisc, who operate Janet, we noted from Gorry’s experiment that there was indeed at least one upstream transit provider we use to commercial networks who dropped packets with EHs. On contacting one they denied that such drops were configured or deliberate, despite the evidence being presented by Anna.  We found no way forward from there to determine the underlying cause.
> >
> > > Within the UK the result we found was that most transit paths encounter EH dropping at some point, and that means we can't "leap over" these obstruction points and look behind them. So I'm unable to device a broad scale  measurement that measures EH drop rates in the larger Internet.
> >
> > It would be interesting to determine the drop rates in the R&E networks. Our R&E connectivity is almost exclusively via GÉANT, who connect the European NREN backbones, save for a direct path to HEAnet in Ireland. We *think* that R&E networks don’t drop, but as yet have no evidence. I suppose you could tag the R&E networks as “limited domain” in that the new alt-mark and min mtu discovery RFCs published last year might be supported there.
> >
> > Tim
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [e-mail]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [e-mail]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------