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

I can see two sides to this.  On the one hand, we want tunnel 
termination logic to be fast and effecient.  Requiring that it have only 
the necessary information, and not other random things, is part of our 
tool kit for achieving that.

On the other hand, the outer IP header, in the case of v6, is clearly 
destined for the tunnel terminator.  And the IPv6 spec is very clear 
that certain kinds of processing for IPv6 destination options are 
mandatory at such a destination.  For example, retunring an error if 
ther eia an unknown IPv6 destination option with the bit set to force 
errors.

Clearly, doing the checks for that is more expensive.  Equally, it seems 
to be clearly required by our current specs.

Yours,
Joel

On 8/20/18 11:40 AM, Ole Troan wrote:
> 
> 
>> On 20 Aug 2018, at 17:05, Tom Herbert <tom@herbertland.com> 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
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 