On Fri, Feb 3, 2017, at 1:37 AM, Brian E Carpenter wrote:
> In Section 4 ("IPv6 Extension Headers") the draft says:
>
>> With one exception, extension headers are not processed by any node
>> along a packet's delivery path, until the packet reaches the node (or
>> each of the set of nodes, in the case of multicast) identified in the
>> Destination Address field of the IPv6 header.
>
> (FYI, the exception is the hop-by-hop extension header.)
>
> I do not dispute that this sentence reached WG consensus. However, I want
> to ask if it has IETF consensus. In my opinion, this sentence should read
>
> With one exception, extension headers are not processed, inserted,
> deleted or modified by any node along a packet's delivery path, until
> the packet reaches the node (or each of the set of nodes, in the case
> of multicast) identified in the Destination Address field of the IPv6
> header.
>
> I believe this was always the intended meaning of the word "processed"
> from the earliest design phase of IPv6, but some people have read this
> text as allowing insertion, deletion or modification of headers. IMHO
> it needs to be clarified.
I, too, am of the opinion that the WG consensus on this point was wrong.
>From the outset it has been fundamental to the IPv6 architecture that
an ICMPv6 message triggered by a particular packet will be sent back to
the source of that packet. If an intermediate node inserts an extension
header or makes an alteration in one that triggers an ICMPv6 error
message -- for example, Packet Too Big or Parameter Problem -- that
error message will be sent back to the source of the packet, not to
the node responsible for inserting the offending header or alteration.
That is fundamentally broken.
On that basis, I don't think that there is any doubt that Brian's
construction of the intent of RFC 2460 is the correct one, and
the language of RFC 2460bis should unambiguously reflect that.
Mike Heard