Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-ehs-packet-drops-00.txt

From: Brian E Carpenter <[email-masked]>
Date: Tue, 4 Aug 2020 13:22:43 +1200

I've tracked this draft since it started, so many of my previous comments have already been integrated. Now that it's a WG document, I've tried to read it again with fresh eyes.

General: I think this is a very useful document for the reason it gives:

>    o  Raise awareness about the operational and security implications of
>       IPv6 Extension Headers

I suggest ensuring that the OPSAWG and OPSEC WGs are made aware of this draft before it reaches WGLC.

Now a few detailed comments:

> 4.  Packet Forwarding Engine Constraints
...
>    One of the common
>    methods of handling next-hop lookup is to send a small portion of the
>    ingress packet to a lookup engine with specialised hardware (e.g.
>    ternary CAM or RLDRAM) to determine the packet's next-hop.

Am I correct in thinking that some implementations do this in parallel with receiving the rest of the packet, i.e. overlap the destination lookup with receiving the payload? If so, that seems worth mentioning, to underline the strong focus on line speed processing.

>    If a hardware forwarding engine on a modern router cannot make a
>    forwarding decision about a packet because critical information is
>    not sent to the look-up engine, then the router will normally drop
>    the packet.

I wonder if this is slightly misleading, because it also applies to middleboxes that are not strictly speaking routers.

>    NOTE:
> 
>       Section 5 discusses some of the reasons for which a modern router
>       might need to access layer-4 information to make a forwarding
>       decision.

It might be worth pointing out the obvious at the beginning of this NOTE: the destination address is always in the first 40 bytes, so the concern is about forwarding engines that do *not* forward based only on the DA.

> 5.1.  ECMP and Hash-based Load-Sharing
...
>    Clearly, widespread support of [RFC6437] would relieve middle-boxes
>    from having to process the entire IPv6 header chain, making Flow
>    Label-based ECMP and Hash-based Load-Sharing [RFC6438] feasible.

There's a slight confusion there. RFC6438 *does not* depend on the source setting the flow-label, because it's about setting the flow label for ECMP in foo-in-IPv6 tunnels, where it's the tunnel ingress that needs to follow RFC6437. There is a problem for non-tunneled packets, but that is not covered by RFC6438.

So my friendly rewrite is:

Clearly, widespread support of [RFC6437] would relieve middle-boxes
from having to process the entire IPv6 header chain, making Flow
Label-based ECMP and Hash-based Load-Sharing feasible. This can
be achieved for provider-based tunnels [RFC6438] and in principle
for server-farm load balancing [RFC7098]. However, this is not
true today for wide-area ECMP or load sharing.

> 6.1.  Inability to Find Layer-4 Information

It seems to me that a mention of how TLS also causes this is relevant. If TLS is in use, does it matter whether there are extension headers? There's some good recent analysis in https://tools.ietf.org/html/draft-ietf-opsec-ns-impact .

Regards
   Brian

On 01-Aug-20 07:31, [email-masked] wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the IPv6 Operations WG of the IETF.
> 
>         Title           : Operational Implications of IPv6 Packets with Extension Headers
>         Authors         : Fernando Gont
>                           Nick Hilliard
>                           Gert Doering
>                           Warren Kumari
>                           Geoff Huston
>                           Will (Shucheng) Liu
> 	Filename        : draft-ietf-v6ops-ipv6-ehs-packet-drops-00.txt
> 	Pages           : 16
> 	Date            : 2020-07-31
> 
> Abstract:
>    This document summarizes the operational implications of IPv6
>    extension headers, and attempts to analyze reasons why packets with
>    IPv6 extension headers may be dropped in the public Internet.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-ehs-packet-drops/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-v6ops-ipv6-ehs-packet-drops-00
> https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-ipv6-ehs-packet-drops-00
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>