On 02/08/2017 10:51 AM, otroan(_at_)employees(_dot_)org wrote:
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.
What did you see as the objections to going with (1) (which I
presume to be the equivalent of Brian's proposed text)? Why was it
that people thought the protocol could not be clarified to say
that? And was your assessment that those arguments were correct, or
that they simply were not addressed by the WG? I've seen several
people argue on this list that (1) was always the intent of the
protocol, and that damage occurs if you don't follow that
directive. I haven't seen anyone here argue otherwise. Could you
summarize?
I can try. It has been difficult to distill the essence out of all
the mailing list discussions. This is _my_ take of the discussion and
arguments as I understood them. Please chime in with corrections.
The arguments of what would break are correct. The counter-arguments
given would be that this is done within a controlled domain and the
potential for damage could be controlled.
There need not be "counter arguments". It was clear to everyone that
IPv6 never allowed EH insertion. If you want to change that, you have to
update RFC2460 (and if you do it before rfc2460bis is published, good
luck with moving it to Standard).
OTOH, if the argument is that you want to break a protocol in your own
environment, in which you can "control the damage"... why do you need an
RFC for that? why should we rubberstamp it?
The discussion went something like (paraphrasing):
- Inserting headers will break Path MTU discovery, AH and may result
You miss the most important point: EH insertion was never allowed in
IPv6. Quite a lot of us find the argument that "we're doing EH
insertion because RFC2460 doesn't explicitly prohibit *insertion*" quite
funny.
I'm not against EH-insertion per se. I'm against what looks like a
procedural hack.
If people want EH insertion, fine: write a proposal that updates
RFC2460, and let's have the discussion. But please do not pretend that
RFC2460 allows EH insertion.
in unsuspecting hosts receiving ICMP error messages. - We will do
this in a controlled domain only. - Even if you can guarantee it will
not leak, it is not appropriate to specify that in the core IPv6
specification - We don't need that, we just need 2460 not to ban it.
IPv6 is used in many networks not only the capital I Internet.
There was also quite a bit of discussion on the intent of the
original authors. I don't know how much value it is correct to give
that argument. "This is what I intended, but not what I wrote...".
Given that this is in any case the output of the IETF and not two
individual authors.
1) Ban header insertion outright.
[...]
b) RFC2460 is already clear and no clarification is needed. No
interoperability issue has been shown caused by this perceived
ambiguity.
RFC2460 already bans EH insertion. Only when SR wa published people
started to argue otherwise.
Given that for some guys there was room for EH insertion, we clearly
need to make the point clear.
There was hard to find consensus on either of the alternatives. As
the poll shows there was a clear preference (if people couldn't get
their first choice) to describe the problem, over banning it, or over
saying nothing.
Based on the mailing-list discussion, it was quite clear that most of
the folks arguing in favor of "ambiguity" were from the same company
pushing a proposal with EH insertion. That's not a minor datapoint.
Besides, moving a document to Standard with "ambiguity" on an item that
led to 600+ messages discussion at the same group that specifies the
protocol would be really bad.
We're moving RFC2460 to standard. I think it should be able to answer
the very basic question "Is it possible to insert EHs in the middle of
the network?" -- or, framed in a different way: "is IPv6 and end-to-end
protocol?"
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fgont(_at_)si6networks(_dot_)com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492