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.
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. Yours, Joel From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On Behalf Of Soheil Abbasloo Sent: Friday, June 30, 2017 2:09 PM To: Burt Silverman <bur...@gmail.com> Cc: vpp-dev <vpp-dev@lists.fd.io> Subject: Re: [vpp-dev] IPv4 Option field Thanks Burt, good hint. However, the problem they try to solve doesn't happen in all scenarios. Consider a simple case: Say we are Verzion and want to do some measurements in "our" owned network. Packets having IP-options can be dropped at the edge of the network to prevent security issues, "but" in our network we need the "Option" to configure routers/switches to inject desired options at desired points in the network. Basically, what all of these documents want to prevents is preventing the END-USER to do some scary jobs! So accepting option field in headers of packets (as an example) in our network which is controlled by US should be a simple available feature in software solutions. Thanks, Soheil On Fri, Jun 30, 2017 at 6:52 AM, Burt Silverman <bur...@gmail.com<mailto:bur...@gmail.com>> wrote: I discovered the "formal document" that addresses part of the situation: RFC 7126 Filtering of IP-Optioned Packets is a Best Current Practice, and it recommends that timestamp optioned IPv4 packets be dropped. They recognize that this breaks network troubleshooting techniques, but the feeling is that those are already broken, and there are security issues associated with the timestamp option. On the other hand, I believe there are options that they believe should be handled. So I am not sure that testing the header size byte for 0x45 is best practice, but I have not given RFC 7126 a thorough read through. Burt On Fri, Jun 30, 2017 at 4:05 AM, Andrew Yourtchenko <ayour...@gmail.com<mailto:ayour...@gmail.com>> wrote: Soheil, Quite some platforms switch the packets with up options in software. An example: http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst4500/12-2/31sga/configuration/guide/config/mcastmls.html#wp1082100 How do you plan to deal with this behavior in the network ? --a On 29 Jun 2017, at 20:00, Soheil Abbasloo <ab.soh...@gmail.com<mailto:ab.soh...@gmail.com>> wrote: Dave, That paper only shows that "in their experiments they saw that half of the routers in INTERNET drop the packets with IPv4-Option", but measurements targeted for the path of packets in internet is just a use case. Think about different third party NFV containers running on our private datacenter to process the incoming packets (even from internet or where ever!) and usage of VPP as software switch/router/processing-point under those containers. Now use of IPv4 iOAM to get some local performance measurements in this private network (which usually gets Ipv4 packets as input) makes sense. So IMO saying that half of "their" tested routers doesn't support ipv4 options doesn't seem a good reasoning for not supporting IPV4 option in VPP. Ole, It's not obsoleted. As Burt mentioned it's still part of the standard. Even recent ietf drafts are considering this feature. For instance look at https://tools.ietf.org/html/draft-brockners-inband-oam-data-04 VPP already supports iOAM for IPv6 which is I guess base on the available IOS solution for IPv6 from Cisco. We were going to add Ipv4 iAOM functionality to VPP; however, from what you're saying I feel there won't be support for accepting IPv4-Options in VPP in future, and it seems that there is no solid reasoning behind that decision, am I right? Thanks all, Soheil On Thu, Jun 29, 2017 at 11:24 AM, Dave Barach (dbarach) <dbar...@cisco.com<mailto:dbar...@cisco.com>> wrote: I agree with Ole. See https://www2.eecs.berkeley.edu/Pubs/TechRpts/2005/EECS-2005-24.pdf From: vpp-dev-boun...@lists.fd.io<mailto:vpp-dev-boun...@lists.fd.io> [mailto:vpp-dev-boun...@lists.fd.io<mailto:vpp-dev-boun...@lists.fd.io>] On Behalf Of Burt Silverman Sent: Thursday, June 29, 2017 12:49 PM To: Ole Troan <otr...@employees.org<mailto:otr...@employees.org>> Cc: Soheil Abbasloo <ab.soh...@gmail.com<mailto:ab.soh...@gmail.com>>; vpp-dev <vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>> Subject: Re: [vpp-dev] IPv4 Option field I believe the standards should be adhered to. RFC791 has not been obsoleted. One man's opinion (sentence 1). Burt On Thu, Jun 29, 2017 at 11:11 AM, Ole Troan <otr...@employees.org<mailto:otr...@employees.org>> wrote: Soheil, Others my correct me, but as far as I know IPv4 options are for all practical purposes deprecated. Lots of forwarding planes do a validation check of 0x45 on the first octet. Likewise for middleboxes (e.g. NAT). Have you tried if you can get these packets passed any routers / across the Internet? Not impossible to change the IP4 VPP path, although it would require fixing all code that finds the L4 header. But I think you would end up in horrific deployment issues... Cheers, Ole > On 29 Jun 2017, at 02:21, Soheil Abbasloo > <ab.soh...@gmail.com<mailto:ab.soh...@gmail.com>> wrote: > > Hi all, > > This is Soheil. We are working on a project involving the IPv4 In-Band OAM. > > I have tried to use VPP in a simple scenario (like the simple > switching/routing tutorial in fd.io<http://fd.io>) to pass IPv4-Options (in > out case TIMESTAMP option) between two containers. However, packets having > IP-Option field will be dropped by VPP due to the checksum error. > > I have checked the source code (17.04) and found that VPP only handles fixed > 20 Bytes IP headers (there is a header size check in ipv4-input node > {<>!=0x45}). Which might indicate that VPP doesn't handle IP-options; hence > the source of wrong checksum calculations in VPP. > > So is there any plan for support IPv4-Option fields in VPP? Is there any > reason for not supporting it?! Or maybe I'm doing something wrong, can you > please tell me what I have missed here? > > ( > Just a few things: > 1- I have checked checksum calculations in my server where I insert > IP-options and they are fine! > 2- When I don't insert options, everything is fine and packets can be > received at client > ) > > Thanks, > Soheil > _______________________________________________ > vpp-dev mailing list > vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> > https://lists.fd.io/mailman/listinfo/vpp-dev _______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> https://lists.fd.io/mailman/listinfo/vpp-dev _______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> https://lists.fd.io/mailman/listinfo/vpp-dev _______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> https://lists.fd.io/mailman/listinfo/vpp-dev
_______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
