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

[Tom Herbert <[e-mail]>]

On Mon, Aug 20, 2018 at 8:40 AM, Ole Troan <[e-mail]> wrote:
>
>
>> On 20 Aug 2018, at 17:05, Tom Herbert <[e-mail]> wrote:
>>
>> 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.

Tom

> Cheers
> Ole