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 (#10241): https://lists.fd.io/g/vpp-dev/message/10241 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] -=-=-=-=-=-=-=-=-=-=-=-
