Subject: [v6ops] Erik Kline's Yes on draft-ietf-v6ops-ipv6-ehs-packet-drops-06: (with COMMENT)

From: Erik Kline via Datatracker <[email-masked]>
Date: Tue, 20 Apr 2021 17:54:31 -0700

Erik Kline has entered the following ballot position for
draft-ietf-v6ops-ipv6-ehs-packet-drops-06: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-ehs-packet-drops/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

[[ comments ]]

[ section 7.1 ]

* It seems to me that this also applies to IP fragments of any family,
  particularly if the first fragment is delayed or lost.

  I can't tell from the text whether handling fragments (even in IPv4)
  is considered "process[ing] the packet outside the normal forwarding path"
  or not.

[[ nits ]]

[ section 3 ]

* s/IPv6 IPv6/IPv6/?

[ section 6.1 ]

* "the router on the sending side of the link needs to..."?

  This phrasing seems a little odd to me.  How about just
  "the (or a) forwarding router needs to...", since the rest of the sentence
  does make the described situation clear?

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 22 Apr 2021 17:59:31 +0100

Hi Erik,

>    particularly if the first fragment is delayed or lost.

dissecting this: first, how does a router handle an ipv6 packet with 
more EHs than it was designed to handle? And secondly: what of fragments?

The document is clear that fragments can only be handled by a 
intermediate system if there is stateful reassembly, and it reiterates 
that only the first fragment can contain ipv6 EHs and upper layer 
headers. So second-and-subsequent fragments will have neither EHs nor L4 
info, which means that they are not relevant to 7.1, and in fact also 
out of scope for the entire document

Otherwise the first fragment will be subject to 7.1: if the EH chain is 
longer than the device can handle, then the device will not be able to 
determine layer 4 information.

>    is considered "process[ing] the packet outside the normal forwarding path"

The first fragment is all that's relevant here, because 8200 specifies 
that the EHs and upper layer headers must be contained in the first 
fragment.

This is already mentioned in section 3, so it would probably be better 
not to repeat in section 7.

IPv4 and IPv4 options are well out of scope :-)  In fact, they're 
completely unusable on the internet - there's a lot of kit out there 
which will silently drop packets with ipv4 options set.

> * s/IPv6 IPv6/IPv6/?

er, oops.

>    does make the described situation clear?

good idea.

Nick