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

On Mon, Aug 20, 2018 at 12:00 PM, Fred Baker <fredbaker.ietf@gmail.com> wrote:
> From my perspective, a tunnel endpoint is a destination. If we want any given destination, an example of which is a tunnel endpoint, to not process some set of options, I would suggest that we simply don't put those options into the header. The question isn't whether the endpoint should process them; it's whether the option is appropriate and useful.
>
Fred,

The problem isn't that the endpoint doesn't handle any unknown options
that would otherwise be skipped, it's that endpoints are dropping
packets simply by virtue that a Destination Options header is present.
That behavior is not consistent with RFC8200 and is detrimental to our
ability to ever define and use useful options.

Tom

>> On Aug 20, 2018, at 9:07 AM, Joel M. Halpern <jmh@joelhalpern.com> wrote:
>>
>> 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
>>> --------------------------------------------------------------------
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>
> --------------------------------------------------------------------------------
> The fact that there is a highway to hell and a stairway to heaven is an interesting comment on projected traffic volume...
>