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

[Ole Troan <[e-mail]>]

> 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.

Cheers 
Ole