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
