I guess you are right, there was a misunderstanding, though in both cases lack of support from the router will lead to the same result, drop of packets! The guys who argue that it is not a good idea might say that from routers point of view generally there would be no difference between the case that the insertion of Option has been done by its previous router or by the source of the packet.
However, if we are managing our network, the idea of having an option in routers to select between processing or not processing the packets with IP-option still makes sense, because you can dictate which routers should expect IP-options and which ones should not. That is all about how you are going to manage them, and the amount of flexibility that you have. Let's not forget that the IP layer was not intended to be an end-to-end layer. Even for L4 which was primarily defined to be an end-to-end Layer, the trend in today's networks is to violate that end-to-end nature for the sake of performance (as an example look at the usage of DCTCP in Microsoft, Google and other datacenters which violates the end-to-end nature of TCP and marks L4 headers in the network by switches). Unfortunately (or fortunately) VPP is just a tool and its marketing concerns gets higher priority. ;) Thanks Soheil On Fri, Jun 30, 2017 at 3:37 PM, Burt Silverman <bur...@gmail.com> wrote: > Just to be clear, Soheil, are you fine with the idea that the options like > timestamp are only added at the origination node? Your use of the word > "inject" made some people believe that you expected intermediate nodes to > add an option, based on the replies I see on this list. Perhaps, by > "inject" you just meant that you can get a set of routers/switches, > including VPP, that process the option and forward the packet, as opposed > to dropping the packet. That would be nice, being that Joel and Ole pointed > out that the other choice is not supported by the standards. > > Happy prototyping -- or whatever comes to pass. > > Burt > > > <https://www.avast.com/lp-safe-emailing-3177-a?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=oa-3177-a> > Virus-free. > www.avast.com > <https://www.avast.com/lp-safe-emailing-3177-a?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=oa-3177-a> > <#m_3541350063443403557_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> > > On Fri, Jun 30, 2017 at 2:08 PM, Soheil Abbasloo <ab.soh...@gmail.com> > wrote: > >> 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-bounces@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
