On 02/04/2017 05:32 AM, otroan@xxxxxxxxxxxxx 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: fgont@xxxxxxxxxxxxxxx PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492