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,

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

Reply via email to