Ole, I was taking the permissive view, which has often been taken with IPv4. Your argument that the specs do not permit insertion even in v4 is quite defensible. My point was that even if it is permitted, it is such a bad idea that we do not want to go there.
Also, just for clarity, I agree with you that it is not permitted in v6. And I consider it a dangerous practice in both places. As you point out, the argument "my network, my rules" fails in the face of the repeated evidence that things will leak out of anyones network. Yours, Joel -----Original Message----- From: Ole Troan [mailto:otr...@employees.org] Sent: Friday, June 30, 2017 3:59 PM To: Joel Halpern <joel.halp...@ericsson.com> Cc: Soheil Abbasloo <ab.soh...@gmail.com>; Burt Silverman <bur...@gmail.com>; vpp-dev <vpp-dev@lists.fd.io> Subject: Re: [vpp-dev] IPv4 Option field Joel, At the risk of turning this into the IETF list. > The issue is that many existing routers will drop, or if you are very lucky > slow-path, and IP4 packets with options. > Yes, the specification allows such options. The IPv4 specs even allow adding > and removing such options. > However, because of issues like ECMP / LAG support, such options have been > observed not to work. We have been over this a few times with regards to the IPv6 header insertion proposals. I have seen no support for the statement "the IPv4 specs even allow adding and removing such options", if by that you mean adding or removing options by intermediate nodes along the packets forwarding path. What the IPv4 RFCs allow is changing options en-route (so does IPv6), but that requires the host to insert the scratch space, i.e. the option at source. Happy to be proven wrong, but Bob and I thought we went over the "history" here quite a few times... > Thus, while there may be some cases where they can be made useful, it > requires great care in many other aspects of the network. > Depending upon what measurements are needed, there are other ways to get the > needed information even in data centers. Best regards, Ole _______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
