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

[Ole Troan <[e-mail]>]

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.

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

Cheers,
Ole