On 7/9/19 01:59, Tom Herbert wrote: > On Fri, Sep 6, 2019 at 3:11 PM Robert Raszuk <rob...@raszuk.net> wrote: >> >> Sander, >> >> But this is exactly what both chairs of 6man did with the help of AD long >> time back. You must have missed it ! >> >> And below is a link precisely written to address requirement of justifying >> deviation: >> >> https://tools.ietf.org/html/draft-voyer-6man-extension-header-insertion-06 >> > > Yes, and that draft was discussed in depth in 6man, a number of issues > were raised, and we haven't heard back from the authors. And this was > not just a case of saying it violates RFC8200, there were specific > reasons given why it isn't robust. So it's correct to say that current > consensus in 6man is that extension header insertion is disallowed.
Exactly. And the text in RFC8200 reflects that consensus. > I also have a nit about that draft. The very first line of the > abstract is "The network operator and vendor community has clearly > indicated that IPv6 header insertion is useful and required." I would be quite curious (but might be wrong) if the operator community cared about doing EH insertion. They are normally more interested about solving problems... and EH-insertion, per-se, has nothing to do with solving problems. The draft in question doesn't comment on the most basic question: why do you want to do EH-insertion as opposed to encap/decap into a new packet? I asked this question a number of times, and nobody answered. Rumor on the corridors had it that it had to do with one specific vendors having issues (of some sort) with implementing this with doing encap/decap. -- but that's the closest that I got to a rationale for the motivation of EH-insertion. Thanks, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
