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

[[e-mail]]

Fernando,

Pete asked me to summarize the objections to option 1 - banning header insertion explicitly.
I responded with the set of objections I've heard for all options, as I couldn't see a straightforward way of only summarising for option 1.

I don't understand your message.
Do you disagree with the summary itself? Are there arguments missing?
Or is your grief that the I have distilled the arguments wrongly or put them in a bad light?

Or are you just rehashing your position on the issue?

cheers,
Ole


> On 8 Feb 2017, at 15:25, Fernando Gont <[e-mail]> wrote:
> 
> On 02/08/2017 10:51 AM, [e-mail] 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: [e-mail]
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
> 
> 
>