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> 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> 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 > > 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] *On >> Behalf Of *Burt Silverman >> *Sent:* Thursday, June 29, 2017 12:49 PM >> *To:* Ole Troan <otr...@employees.org> >> *Cc:* Soheil Abbasloo <ab.soh...@gmail.com>; vpp-dev <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> 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> 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) 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 >> > 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 >> >> >> > > _______________________________________________ > vpp-dev mailing list > 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 >
_______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
