Dear Brian, Eric, @Eric, I propose to delete the closing of the IP options register from the I-D for the following reasons.
>> 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 Ah, yes, that was, of course, one of the documents we also had a look at before starting work on the IP measurement option. We did not think it relevant for our use cases. Neither will it be relevant for many other real world networked application settings where IPv4 is used in limited domains where IP options could be exploited. For our use cases in the railway industry, the following system properties are of importance: 1. In particular, hard real time, safety critical (SIL 4) protocols according to EN 50159 are used (e.g., RaSTA, DIN VDE V 0831-200:2015). 2. We typically have limited domains due to the criticality of the railway infrastructure. 3. Then we have long lived components, and due to backward compatibility it is not always possible to replace IPv4 yet. Just to get an impression, components typically have an MTBF > 30 years, and then remain in operation (much) longer. Notably, in Germany there are still mechanical interlocking types of the first generation (1873) in active operation, and relay interlockings (Sp. Dr. 60, developed in 1960) easily reach 50+ years of operation. This may also be expected for electronic and digital interlockings, that typically have parts using network technology based on IPv4, and are in use from about 1990 on. 4. From the perspective of backward compatibility, it would be good to have migration paths from IPv4, which active developments still include, to IPv6. 5. On the other hand, the possibility to backport functionality from IPv6 to IPv4 should be given, when needed in the future. 6. This also holds for IP options, where options for IPv4 and IPv6 serving the same purpose should be definable. That is why we think the IP options table should stay open for definition of new IP options. We also know that some of the points above hold for other industrial applications in limited domains, SCADA applications to name one. The discussion about IP options for limited domains seems to be still relevant (and it seems, not only from my side). There are two reserved IP option classes, one of which could be reassigned for private use in limited domains and one for transparent / passive end-to-end options over the public internet. In my opinion, this should be discussed as a separate topic / in a separate I-D. It could liberate the IP options technology for wider use and more experimentation. (This could also be considered for the IPv6 protocol?) Some more freely related answers to Brian below. >> 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. Hmmm, not easily, which is unfortunate (and unnecessary for transparent end-to-end options), but that is not so much of an issue for limited domains that are usual in our industry. It is up to the network equipment manufacturers to enable internet (backbone) providers to enable/ensure, e.g., end-to-end transparency for IP options. >> 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. Best current practices touching on IP options contains the list of normative references: * BCP 186: RFC 7126 This also seems to be one of the reasons for the opaqueness of the internet to IP options. It contains lines like (section 4.3.5): The default setting for this knob SHOULD be "drop", and the default setting MUST be documented. Only for a minority of the IP options the advice is not to drop. >> 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. Unfortunately... Although the use on limited domains seems to be unhampered, e.g., given the ongoing IOAM developments in the ippm group. >> 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. That is certainly the case. > 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. Yes, I already noted that while reading up on DS, the DSCP definitions and the transport profiles defined, as well as the recent developments on L4S. That is a Hercules job to do. > 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.) Maybe the question should not be one of "taste", but one that regards the broader scope in which internet protocols are currently used as standard network technology. Ubiquity, and dealing fairly with that broadness, is the other side of the coin of having defined, I would say, one of the most successful, long lived and popular network protocols. Looking again at RFC 791: There are two reserved IPv4 option classes (1,3 reserved for future use)..., one of them could be declared for private use, and that would enable users of limited domains quite some freedom in the use of IP options. Reading RFC 791, it appears to me that option class as well as option numbers were both to be used to distinguish IPv4 options in type. I took that up in the remarks above (thank you for the hint, the idea had not yet occurred to me in this shape). Best regards, Tjeerd _______________________________________________ Int-area mailing list -- [email protected] To unsubscribe send an email to [email protected]
