On 5 February 2017 at 06:06, Enno Rey <erey(_at_)ernw(_dot_)de> 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.