On 17-Jun-26 19:16, Pinkert, Tjeerd wrote:
Dear Brian,
Broken on the internet does not mean broken on limited domains, as can be seen
by active IPv6 option development.
And broken on the internet seems to be mainly due to network providers (and
implementations?) not wanting to be standards compliant (for various reasons,
but not for reasons of standards compliance).
And yes, there are the security concerns for the older IP options, but security
can be addressed for new option proposals, or (partially) ignored for limited
domain use.
I strongly oppose to closing the IPv4 options registry without alternative
means of providing similar features on the network layer level (IP protocol).
As you know there have been several I-Ds the last years requesting IPv4 option
numbers, that were refuted/demoted “because IPv4 options are not an option”.
They weren't an option in 2005, as the reference shows,
I meant https://www2.eecs.berkeley.edu/Pubs/TechRpts/2005/EECS-2005-24.pdf
and they weren't an option in 1994 on the only occasion that I proposed one.
The Internet has been opaque to IPv4 options for more than 30 years and that
isn't going to change.
I read RFC 6274 differently. It says a few important things about the IP option
implementations:
But it's an informational document. The normative rules are elsewhere.
1. IP systems are required to ignore options they do not implement.
--> This can only be done fully appropriately when all options (except 0
and 1) are Case 2: type + length, alternatively processing is stopped when
encountering the first unknown option, which is always possible.
--> This also means that the internet is supposed to be be transparent to
IP options, and that this is not a security issue.
Well, a lot of people have ignored this since the 1990s. We have exactly the
same issue with IPv6 extension headers.
2. All current and future options except End of Option List (Type = 0) and No
Operation (Type = 1), are of Class 2.
--> this is problematic, while limiting the number space unnecessarily IMHO.
3. This format allows for the creation of new options for the extension of the Internet
Protocol (IP) and their transparent treatment on intermediate-systems that do not
"understand" them, under direction of the first three functional parts.
Number 3 explicitly leaves open the creation of new IP options under certain
conditions, so the reference explicitly *does* show they *are* an option.
Best regards,
Tjeerd
P.S. also my employer would like to use IP options, or keep the possibility for
new IP options open.
In that case, I hope they also want to use IPv6 extension headers, where the
considerations are very similar.
I would compare this issue to differentiated services and ECN, where we have
worked hard to keep everything the same in IPv4 and IPv6. But making this work
somewhat transparently across ISP boundaries has been very difficult, with
fallback to default behaviour being a very common result. For options and
extension headers, the result is often worse, i.e. packet drops.
Again, I am not against limited domain solutions, but the IETF as a whole
doesn't seem to like that. (In differentiated services, we do have a local use
range of code points. There is no local use range for IPv4 options.)
Regards
Brian
_______________________________________________
Int-area mailing list -- [email protected]
To unsubscribe send an email to [email protected]
