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

[Mark Smith <[e-mail]>]

On 5 February 2017 at 06:06, Enno Rey <[e-mail]> wrote:
> Hi,
>
> On Sat, Feb 04, 2017 at 09:32:37AM +0100, Fernando Gont wrote:
>
>
>> Everyone has agreed (including the authors of RFC2460) that EH insertion
>> has never been allowed.
>> [...]
>> > 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.
>>
>
> The first talk I gave about IPv6 was in 1999 (with an experimental IPv6 stack of Windows NT and being connected to the 6Bone). I don't remember much of it but I'm pretty sure I explained that the desire to restore the pre-middlebox, pre-NAT end-to-end character of the Internet was one of the main design drivers of IPv6 (hint: you may also look at the "Acknowledgments" section of RFC 2460).
> Quite a few IPv6 books of the time (we still have them in the library, feel free to reach out for examples) explicitly mentioned end-to-end as a major property of IPv6 and many guys giving IPv6 talks & trainings since 15+ years now have it on their introductory slides. Furthermore several adjustments of the main IPv6 header (e.g. removing the checksum) and barring fragmentation performed by intermediate points clearly indicate the message: "in general we don't want devices to mangle with packets in transit".
> So, from my personal perspective, it's painfully obvious that there was never any intent to allow the modification of IPv6 packets in transit (besides very specific exceptions which were clearly described), and this has been an undisputed principle of IPv6 for a long time.
>
> So one may be tempted to ask: why do we have this discussion at all?
> Well I think the answer is quite simple: as so often in life, it's about agendas and politics.

I think it is much simpler than that.

People have put quite a lot of work into EH insertion and they don't
want to throw it away. That is entirely understandable, however the
specification is clear.

"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."

"The exception referred to in the preceding paragraph is the Hop-by-
   Hop Options header, which carries information that must be examined
   and processed by every node along a packet's delivery path, including
   the source and destination nodes.  The Hop-by-Hop Options header,
   when present, must immediately follow the IPv6 header."

The only modifications of an IPv6 packet in flight allowed are:

- decrement the Hop Limit
- change the Traffic Class
- change the Flow Label if the value is zero
- Hop-by-Hop EH processing.

In none of these cases is new information added to the packet,
changing the size of the packet. In all of these the negative
consequences of a failed update are the packet gets dropped, gets
lower priority per-hop handling, or is delivered to the incorrect
destination. These types of failures do not conflict with any
semantics that other protocols rely on, specifically that the source
address identifies the originator of the entire structure and initial
contents of the packet, with the possible and permitted in-flight
changes in packet contents values being explicitly identified in
RFC2460 and published updates to it.

Claiming the spec is ambiguous is trying to create a loophole that
permits the violation of the specification. That is probably viewed as
having lower cost, if successful, than redoing the work to use
encapsulation to add information to packet while also preserving the
packet's original semantics.

I think claiming "not examined or processed by any node along a
packet's delivery path" is ambiguous is pretending to know less about
something than one really does.

Regards,
Mark.