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

From: "C. M. Heard" <[email-masked]>
Date: Fri, 3 Feb 2017 09:20:28 -0800

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

---

From: Enno Rey <[email-masked]>
Date: Sat, 4 Feb 2017 20:06:35 +0100

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. Before I comment on this in a bit more detail, let me add two disclaimers:

Disclaimer (1): in the following rant on how certain things are happening at the IETF I can only speak for IPv6-related stuff. 
Disclaimer (2): addressing such a rant in direct to an IETF mailing list means I will tap on the feet of many people. Feel free to personally let me know your strong opinion or just ignore me/stare into another direction from now on when we meet. There's only a small chance this will happen at an IETF meeting anyway, for reasons laid out below. 

Let's look at how the actual discussion (and subsequent specification) work is done at the IETF, similar to other voluntary organizations: on mailing lists and in (f2f) meetings. As we all know, these meetings take place three times a year, each on a different continent (yes, I'm aware of remote participation, but let's be honest: at the end of the day how much impact on specification did this have this in past, in particular in heavily old boys' clubs dominated WGs like 6man?).

Further fact is: if you look at the lists of participants of the meetings, the vast majority of it is vendor personnel. This is not surprising when reflecting on the incentives different parties may have to send people to IETF meetings. How would, say, an enterprise person argue in front of her boss to attend the 51st (!) IETF meeting since the publication of RFC 2460 (especially considerung the ongoing [non-]state of deployment in large parts of that space. it's up to the reader to connect that state with the things I describe here...)?

But it's not like vendor people don't have to justify these nice trips to their bosses. Of course they have to. 
Here's two prevalent strategies:
- "we have that new feature. let's try to push it into an RFC, as this strengthens our market position (in general and for selling the specific thing)"
- "you know, there's this future thing called IPv6. I'm in one of the working groups where we come up with lots of creative ideas how to even make it better. my name is on one of the draft documents so I'll have to be there, at the next meeting (and we, as a vendor, demonstrated our contribution also)".

For quite some of the stakeholders (namely both the vendor in question and the respective participant[s]) these are not only legitimate but fully understandable. It's just: does this drive things in the right direction of the greater good & community? Me seems we have a classic tragedy of the commons here...

I'm in the very privileged position that my employer would (and did so several times in the past) actually pay for week-long trips to nice cities and expensive hotels (and release me from other tasks contributing to short-term productivity, let alone revenue) three times per year. Still I do know many people *very* unhappy with the current state of IPv6 specs - and scratching their heads in light of the present discussion - who are not.
We/you guys don't have to care about the esteem of IPv6 community (at least the part I myself can speak for) and you might even feel obliged to ignore it ("we know better what's good for them").
But we should at least be honest as for the obvious agenda quite some vendor guys are pushing as for EH insertion (I don't have to mention SR, do I?) and you Ole, as a 6man chair, have probably noticed that there's not much support for the idea from anybody outside Cisco space (yes, I'm aware of the poll. but I followed the mailing list discussions as well).

There you have it. I don't even think that this was anything new for most of you. Still at times it helps to name the obvious.
If any socio anthropologist wanted to find a textbook example for "how voluntary bodies claiming to be open for anyone get compromised over time by vested interests" the EH insertion thing would be one.

best

Enno

For the protocol: given the fundamental role of RFC 2460 I, too, think that an implementor must be able to get a clear answer to the question "is EH insertion allowed or not?" during its lecture, without going through 600+ e-mails in an archive (just to find out that "even the experts didn't agree on that, at the time"). So I support Fernando's request of 
> Either explicitly ban extension header insertion, or explicitly allow it.

-- 
Enno Rey

ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de
Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 

Handelsregister Mannheim: HRB 337135
Geschaeftsfuehrer: Enno Rey

=======================================================
Blog: www.insinuator.net || Conference: www.troopers.de
Twitter: @Enno_Insinuator
=======================================================