|
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
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 < fgont@xxxxxxxxxxxxxxx> 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 <fgont@xxxxxxxxxxxxxxx>
To: Suresh Krishnan <suresh.krishnan@xxxxxxxxx>
CC: 6man@xxxxxxxx <6man@xxxxxxxx>
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: fgont@xxxxxxxxxxxxxxx
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
_______________________________________________
Int-area mailing list
Int-area@xxxxxxxx
https://www.ietf.org/mailman/listinfo/int-area
_______________________________________________ Int-area mailing list Int-area@xxxxxxxxhttps://www.ietf.org/mailman/listinfo/int-area
|
