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 <fgont@xxxxxxxxxxxxxxx> wrote: > > On 02/08/2017 10:51 AM, otroan@xxxxxxxxxxxxx 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@xxxxxxxxxxxxxxx > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > >
Attachment:
signature.asc
Description: Message signed with OpenPGP