Re: [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)

[Tom Herbert <[e-mail]>]

On Thu, Feb 27, 2020 at 2:52 PM Joe Touch <[e-mail]> wrote:
>
> FWIW - there are separable issues here:
>
> - whether an IP header (or parts thereof) should be changed in transit
>
> AFAICT, the answer has always been yes, but limited to the hopcount/ttl in the base header and hop-by-hop options in the options/extension headers.
>
> - whether an IP header length can change in transit
>
> I see no reason why it can't become smaller, but if it can become larger then PMTUD and PLPMTUD don't work.
>
> So the question isn't just what is wanted, it's what is feasible.
>
Joe,

Per the problem about making packets larger in the network, I'd point
out that this is already common due to in-network tunneling. In any
case, it's really the only interesting case here (as opposed to making
packets smaller).

Tom

> Joe
>
>
>
>
> On 2020-02-27 14:07, Tom Herbert wrote:
>
> Fernando,
>
> I think we need to be careful that IETF is labeled as a collection of
> inflexible architectural purists. We know that standards conformance
> is voluntary and we haven't seen the last time that someone, possibly
> even a major vendor, will circumvent the system for their own
> purposes. IMO extension header insertion is a great example of that.
> On one hand we have people quoting IPv6 saying that it isn't allowed
> per RFC8200-- period! And on other side there are proponents that see
> a real need for it and believe they have clear use case-- at one
> presentation in IETF a proponent bluntly stated that regardless of any
> discussion in IETF they're going to do it! IMO, what we haven't seen,
> was a real attempt to resolve and work out the engineering issues.
> That's not for lack of trying-- for instance I proposed a direction to
> try for an engineering compromise in draft-herbert-6man-eh-attrib-00,
> but saw little discussion on that.
>
> Tom
>
> On Thu, Feb 27, 2020 at 1:43 PM Fernando Gont <[e-mail]> wrote:
>
>
> Folks,
>
> If you haven't been following recent developments in the Spring WG, you
> may be surprised about some of the work that is being pursued (or was
> being pursued)-
>
> Such work has included proposing that some IPv6 routers insert and
> remove routing headers en-route to the final destination.
>
> After many very heated and lengthy debates, some of this work was
> dropped, but other remains (e.g. routers removing IPv6 EHs from packets
> en-route to their final destination, part of what they call "PSP"). For
> the most part, the proponents have argued that "we have implemented it,
> and the industry wants it" -- as if we just have to rubberstamp what
> they have done.
>
> On the technical side, the proponents have argued that:
>
>      If a packet employs source routing (and hence its Destination
>      Address is modified en-route to direct the packet through each
>      of these "waypoints"), then any of such "waypoint" routers are
>      free to add or remove IPv6 extension headers at will. (No, not
>      encap/decap, but rather add/remove EHs from the IPv6 header
>      chain).
>
> That seems to me like a very major deviation from what's supposed to be
> our current "architecture", where IPv6 is an end to end protocol.
> Besides, it should be obvious that removal/insertion of EHs en-route
> error reporting (since host typically check that the ICMP errors they
> receive correspond to something that they actually sent).
>
>
> A number of us have raised this a number of times, and at least some of
> us feel that our concerns are being ignored.
>
> It would seem to me that these documents and decisions have a concrete
> impact on our architecture, and that they are being pursued without any
> proper oversight. There is also a widespread feeling that having one or
> a few big vendors pushing these ideas might be playing a role here.
>
> (See, for instance:
>
> * https://mailarchive.ietf.org/arch/msg/ipv6/Er7LR_VrsJLko_QnqEKTXvPcpj4/
>
> * https://mailarchive.ietf.org/arch/msg/ipv6/gG7Fbz0R030g55oW1mvckj0THwc/
> )
>
> What I would expect is that all thes major changes to our existing
> architecture and protocols would only done by formally updating existing
> standards *if* deemed appropriate, as opposed to just trying to sneak
> changes "when nobody is watching", or by having very curious
> interpretations of our protocols and standards.
>
> I've raised the topic to our AD (Suresh), to the IAB, and on the arch-d
> list before, but so far haven't been lucky or seen anything meaningful
> happen in this area.
>
> I have also submitted an errata to make RFC8200 even more clear on the
> topic, but it remains unprocessed.
>
> So my questions are:
>
> * On the technical area:
>
>   + Is IPv6 an End To End protocol?  Or is the IETF's stance that
> routers are free to mangle with the packet structure as they please?
>
>   + Was IPv6 designed that way? And if it wasn't, when/how was the
> architecture changed?
>
>
> * On the procedural area:
>
>    + Where/how should IETF WGs seek for architecture-related advice?
>
>    + What do do in situations like the above?  Wait and see how things
>      evolve, and upon any formal decisions, just submit formal Appeals
>      if deemed necessary?  (and after way too much energy consumed from
>      everyone)
>
>      I would have expected that as soon as these issues were raised,
>      the offending text would be removed rightaway. But that wasn't
>      the case. And when the changes did happen, it wasn't without
>      an extraordinary waste of time and energy from all of us.
>      For instance, any work on IPv6 header insertion/deletion wouldn't
>      seem to fit within the charters of the 6man or spring wgs.
>
>
>      FWIW, this is not the first instance of issues surrounding the same
>      topic. It goes back to the rfc2460bis effort, when a similar set of
>      folks (too many from one big vendor) got to have 6man ship
>      what became RFC8200 with a noted "ambiguity", just to be able
>      to have some playground for EH insertion/deletion. And we only got
>      to improve on that during IETF LC:
>
>     (see:
> https://mailarchive.ietf.org/arch/msg/ipv6/Kp76SONpyqWneNgvtc8sh-fGAu0/)
>
>
> Thoughts or advice on the technical and/or procedural aspects will be
> appreciated.
>
> Thanks!
>
> Cheers,
> Fernando
>
>
>
>
> -------- Forwarded Message --------
> Subject: Errata #5933 for RFC8200
> Date: Thu, 27 Feb 2020 17:07:36 -0300
> From: Fernando Gont <[e-mail]>
> To: Suresh Krishnan <[e-mail]>
> CC: [e-mail] <[e-mail]>
>
> Suresh,
>
> Two months ago I filled an errata on RFC8200 regarding the processing of
> IPv6 extension headers. The errata is available here:
> https://www.rfc-editor.org/errata/eid5933
>
> While I believe that folks with a knowledge of Internet Protocols would
> be able to interpret what is in RFC8200, given recent discussions on the
> topic, and upon a re-read of the text, I believe a clarification is
> warranted, such that we allow all sorts of curious interpretations of
> the text.
>
> I send a heads-up on the 6man mailing list
> (https://mailarchive.ietf.org/arch/msg/ipv6/6MPs25WvSMD6vVT0ekaMYjAwM6c/),
> and the proposed text received the review of at least Brian Carpenter,
> Ron Bonica, and Mark Smith. Their reviews are available on such thread.
>
> In the light that some folks seem to be pretending to leverage "the lack
> of clarify" in RFC8200 (an Internet Standard) to violate it, I'd
> appreciate that the reported errata be processed.
>
> Processing the aforementioned errata is key to many of the discussions
> this and other WGs are having.
>
> Thanks,
> --
> Fernando Gont
> SI6 Networks
> e-mail: [e-mail]
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
>
> _______________________________________________
> Int-area mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/int-area
>
>
> _______________________________________________
> Int-area mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/int-area