Re: [Errata Rejected] RFC8200 (6003)

[Erik Kline <[e-mail]>]

[ moved IESG and RFC Editor to bcc ]

> 1) Is the current state of the IPv6 standard that nodes listed in a
> Routing Header can insert, remove, process, or (more generally) mangle
> with the packet structure?

I think the text is pretty clear that the extent of the
"mangle-ability" is limited to HbHs and DOs between the IPv6 header
and the RH.

> 2) If that's the assumption, how does IPv6 operate with respect to
> AH, PMTUD, and error reporting?  Allowing intermmediate nodes (such as
> those listed in a RH) can certainly break AH, PMTUD, and (ICMPv6) error
> reporting.   Whereas nono of these core functionalities break if
> EH-mangling on the delivery path is forbidden -- as I personally think
> it is.

[AH]

If a router in the dest addr field attempted to alter a packet with an
AH, the implementation would be faced with a choice:

  (a) break things such that AH validation detects the tampering (AH
is "working as intended"),

  (b) only tamper with things that AH does not cover,

  (c) don't tamper at all, or

  (d) other: e.g., discard, punt to an SDN controller, phone a friend, ...

(b) and (c) would probably be better than (a).  But there might be
uses for (a) and (d).

By analogy, perhaps we could consider the choice faced by by a NAT'ing
router implementation that receives an IPv4 packet with AH (though
perhaps there is specific guidance in a document somewhere for this
case -- I don't know).  Regardless of behaviour in the presence of an
AH, "NAT's gonna NAT" when an AH is absent.

[ PMTUD ]

Header removal does not cause a PMTUD problem.

Header "swap", such that the IPv6 Payload Length remains unmodified,
does not cause a PMTUD problem.

Header insertion could cause a PMTUD, but there are some circumstances
where it also might not, i.e. if the router doing the insertion were
also the router forwarding onto a link where the MTU would be
exceeded: it could instead generate a PTB.

[ ICMPv6 error reporting ]

I called out this case in particular because I also think it could
complicate a sending node's implementation.  However:

  (a) the additional processing complexity is only incurred by sending
nodes that insert RHs ("no Routing Header, no cry"),

  (b) if the ICMPv6 error originator filled the packet out to 1280
bytes per RFC 4443 S2.4 (c) then it seems possible that things could
all still work, and

  (b) even RFC 4443 acknowledges that sometimes ICMPv6 error messages
just can't be properly processed; the 2nd paragraph of RFC 4443 S2.4
(d) is a partial list of when a node invokes the "shrug emoji handling
routine".

> 3) RFC8200 also contains the following text, as one of the intended
> clarifications:
>
>     o  Clarified that extension headers (except for the Hop-by-Hop
>        Options header) are not processed, inserted, or deleted by any
>        node along a packet's delivery path.
> ?
>
> If the argument is that nodes listed in a RH can mangle with EHs, then,
> in order for this sentence to make any sense, is your interpretation
> that the noes listed in a RH are not part of the packet delivery path?

This text you've excerpted is from Appendix B that summarizes changes
from RFC 2460.  Its brevity elides *all* the truly relevant details in
the rest of the document and I fail to see how it can be used to
supersede the real, detailed text.

> 4) The very RH is specified as:
>    4.4.  Routing Header
>
>       The Routing header is used by an IPv6 source to list one or more
>       intermediate nodes to be "visited" on the way to a packet's
>       destination.
>
> Where there's no use of destination vs final destination -- indeed, this
> text implies that the "destination" is the final destination of the
> packet. In that light, why would one specific interpretation of one part
> of the current standard (RFC8200) be considered to override or take
> precedence over other parts of the standard?  And, in particular, when
> one of such parts and interpretations break several protocol mechanisms,
> and the other doesn't?

Because, as has been stated, the text in Section 3 goes out of its way
to identify when the Destination Address field may not be that of the
ultimate destination, and Section 4 defines the node in the
Destination Address field as the one able to modify headers.

> 5) Based on a literal reading of RFC8200, the processing of a
> Destinations OPtions Header preceding a RH is not allowed. As such,
> should we also consider that nodes must ignore the DOH preceding a RH in
> IPv6 packets?

I'm afraid I don't quite follow you here.  Section 4.1 discusses this
in detail, and note 1 identifies this use case explicitly.

Cheers,
-ek