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> 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> > 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/catalyst45 >> 00/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
