On Tue, Aug 21, 2018 at 1:41 PM, Pablo Camarillo (pcamaril) <pcama...@cisco.com> wrote: > Tom, > > > > If a Destination Option appears before a Routing header, the Destination > Option header is ignored (packet is NOT dropped). > > If you think its relevant to implement the Destination Option header option > types 01, 10 and 11, please open a Jira ticket for it. [1] > Thanks for confirming that. I suspect that some other implementations do that as well which is why I submitted https://tools.ietf.org/html/draft-herbert-ipv6-update-dest-ops-00 to formally permit nodes to skip Destination Options before a routing header.
Other use cases of Destination Options that don't precede a Routing header present more of problem if they're not processed per RFC8200. Tom > > > Thanks, > > Pablo. > > > > [1] https://jira.fd.io/projects/VPP > > > > On 21/08/2018, 17:57, "vpp-dev@lists.fd.io on behalf of Tom Herbert" > <vpp-dev@lists.fd.io on behalf of t...@quantonium.net> wrote: > > > > Hello, > > > > I have some questions regarding Destination Options processing in VPP. > > Basically, I'd like to know they are properly supported per RFC8200. I > > not, then I'd like to request the VPP stack is fixed to be protocol > > compliant in this. > > > > This came up in regard to a discussion on IETF 6man list. It is a > > known problem on the Internet that many middlebox implementations > > don't support Destination Options. In the worst case, they arbitrarily > > drop packets based on the presence of a Destination Options header. > > This ossifies the feature and makes it unusable. The specific context > > is that segment routing header draft defines a new TLV mechanism in > > the routing header, we are suggesting that Destination Options before > > the Routing header be used. In order to do that we need proper support > > for Destination Options. > > > > The draft-ietf-6man-segment-routing-header-14 mentions that several > > implementation of segment routing, of these only Linux and FD.io VPP > > are easy to find open source. > > > > Linux properly supports Destination Options and Hop-by-Hop options, > > including processing limits introduce in RFC6434bis to keep things > > sane. The default number of options Linux will process is eight. > > > > I looked at the VPP code. AFAICT, Destination Options are not > > supported to any extent such that if the stack receives a packet with > > a Destination Option it drops it. Is this interpretation correct? > > > > If VPP does indeed drop packet like this, then I think that is a bug. > > Fixing it would entail implementing the the TLV loop. Even if VPP > > doesn't care about any particular options, this is still important > > since RFC8200 defines specific behaviors on what implementations > > should do if unknown options are received. > > > > Thanks, > > Tom > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#10250): https://lists.fd.io/g/vpp-dev/message/10250 Mute This Topic: https://lists.fd.io/mt/24877418/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
