Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt> (Internet Protocol, Version 6 (IPv6) Specification) to Internet Standard

[Fernando Gont <[e-mail]>]

On 02/04/2017 05:32 AM, [e-mail] wrote:
> Thank you Pete! You are of course right.
> 
> Let me try to provide some background of the issue.
> 
> The contentious text is the following paragraph from 2460:
> 
> With one exception, extension headers are not examined or 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.
> 
> Essentially the question is: - Does the IPv6 architecture permit
> insertion of extension headers and/or header options by a node along
> the packet's delivery path?
> 
> This question came up triggered by discussions around some recent
> proposals: - draft-ietf-conex-destopt, - RFC4782 (does header
> deletion) - draft-ietf-6man-segment-routing-header -
> draft-brockners-inband-oam-transport
> 
> The IP architecture (IPv4 and IPv6) supports _modifying_ IP options
> in flight, but it is unclear if it could permit changing the IP
> datagram's size. 

The only case that can be made for that is that the spec doesn't say
"insertion of EHs is forbidden" -- but then, if you were to have to
write a spec explicitly noting everything that is forbidden, you
wouldn't be able to achive that in your lifetime.

Everyone has agreed (including the authors of RFC2460) that EH insertion
has never been allowed.



> Increasing a packets size in flight would break
> PMTUD (RFC1981), AH, and might results in other ICMP error messages
> being sent to an unsuspecting source.
> 
> There were three main positions argued in the working group.
> 
> 1) Ban header insertion outright. 2) Describe the problems with
> header insertion. 3) No changes to RFC2460 text.
> 
> Permitting header insertion in the sense of specifying how header
> insertion could possibly work is of course outside the scope of
> advancing RFC2460.

Explicitly allowing EH insertion would most likely be out of scope, too:
It completely changes a very basic aspect of IPv6.

FWIW, I think that publishing a spec with what some have considered to
be ambiguous text (subsequently leading to 600+ messages on the very
group that specifies the protocol) would be a lousy job on our side.
Either explicitly ban extension header insertion, or explicitly allow it.

Whether EH insertion is allowed (or not) seems to me like a very basic
question that the protocol spec should be able to answer -- particularly
since we're moving it to Standard.

Given that the question has been "raised", it deserves an answer in the
spec. Otherwise, when asked "Are intermediate systems allowed to mangle
with IPv6 packets as they please?", I guess we'd have to answer "We
don't know... but neither did the group that wrote the spec".

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492