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

On Wed, Dec 6, 2023 at 6:35 AM Eric Vyncke (evyncke)
<evyncke=40cisco.com@dmarc.ietf.org> 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 <ipv6-bounces@ietf.org> on behalf of Tim Chown <Tim.Chown=40jisc.ac.uk@dmarc.ietf.org>
> Date: Wednesday, 6 December 2023 at 15:02
> To: Geoff Huston <gih@apnic.net>
> Cc: 6man <ipv6@ietf.org>
> 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
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------