Re: Comments on draft-herbert-ipv6-update-dest-ops

[Tom Herbert <[e-mail]>]

On Mon, Aug 20, 2018 at 9:23 AM, Ole Troan <[e-mail]> wrote:
> Tom,
>
>>>> The negative converse also seems to be true. If an implementation does
>>>> not support parsing of Destantion Options before the Routing header,
>>>> then the node probably doesn't support parsing of any Destination
>>>> Options. This becomes an issue in router implementations that
>>>> terminate tunnels int the network with intent to and forward the
>>>> tunneled packets. For instance FD.io VPP supports VXLAN, LISP, SR-IPIP
>>>> among other encapsulations, AFAICT if the implementation receives an
>>>> encapsulated packet addressed to the node that has a Destination
>>>> Option (second type that follows any Routing header), either the
>>>> packet is either dropped or the Destination options are ignored.
>>>
>>> [wearing the VPP committer hat]
>>>
>>> VPP as a tunnel endpoint does not parse destination options. In fact at least for rfc2473 tunnels I believe it would drop packets containing one. I am not convinced you can use one implementation’s behavior to support your argument (or not). At least from a VPP perspective I would add destination option header support, as soon as there were any options that made sense to support. (And I am not convinced the tunnel encap limit option is one of them.). I certainly wouldn’t build an implementation that blindly processed destination options, if there were any to support.
>>>
>> Ole,
>>
>> What you're describing is the type of deadlock that has led to IPv6
>> options being ossified. On one side middelboxes are only going to
>> support them properly once there are "options that make sense" to
>> support, and on the other hand host developers don't want to work to
>> define ones that make sense to support since middleboxes don't support
>> options. In-situ OAM is a good example of this. The original idea was
>> to put OAM in every encapsulation protocol, however that would be much
>> better server in either Hop-by-Hop or Destination options and now at
>> least IPv6 options are being defined for that.
>>
>> Specifically in the case of VPP, I'm not sure why proper parsing of
>> Destination Options would be a be major effort. This is just software,
>> and probably just a few lines of implementation to implement the
>> parsing loop and then you'd be able to claim the VPP is protocol
>> compliant in this area. I think this will be a bigger issue for
>> hardware implementations.
>
> Absolutely. It’s quick to add. That’s the point. Which is why I’m not adding it until there is something to do with those options.
> Note in the example you cited we aren’t talking about a middlebox, but a tunnel endpoint.
> I’m not sure I can be bothered adding support for pad options.
> I don’t see the deadlock here.
>
Ole,

Consider the folling scenario:

Someone is developing a new Destination Option that might be of
interest for use with tunnels and might even become one of those
options "that makes sense to support" . Maybe it's an option for the
aforementioned insitu-OAM, or maybe a general packet CRC, etc. The
developer dutifully uses experimental option type 0x1e for the type
value of their option to test it. In particular, the action taken if
the option is unknown to a receiver is to skip over it. They made that
choice because that allows incremental deployment of the support for
the option in any combination supporting sending side or receivers. In
other words, they don't want a flag day for the option that requires
all nodes to support the new option.

Now they go to test backwards comapatbility of the option by sending
it to a node that hasn't been updated to receive it. If the receiving
node is a Linux system, then the option is ignored and the tunneled
packet is processed as before-- expected behavior per the spec.
However, if it's sent to a VPP node then the packet is dropped-- not
expected. Even if this doesn't lead to incorrectness, it does breaks
interoperability and violates "be liberal in what you receive". This
net effect is that this makes development, test, and pilot deployment
of new options really hard. Just implementing the TLV loop, even if
the implementation doesn't process any of them, would resolve this.

Tom

> Now, if you are talking about a router/middlebox not passing the options, that’s another thing.
>
> Cheers,
> Ole