Re: I-D Action: draft-han-6man-in-band-signaling-for-transport-qos-00.txt

[Tom Herbert <[e-mail]>]

On Tue, Oct 17, 2017 at 11:16 AM, Toerless Eckert <[e-mail]> wrote:
> As mentioned in my prior mail: RSVP-IP deployments got killed by SPs that filtered
> packets with router-alert because common network devices punted packets because of
> the presence of router-alert. Instead of punting them because of presence of
> RSVP-router-alert option. And of course you can blame IP multicast: every router
> started to punt router-alert because of MLD (and of course us multicast folks
> missed the chance to fix this in MLDv2 because it only tried to duplicate IGMPv3),
> but no RFC told developers to punt because of router-alert + value in the router alert.
> AFAIK, the same applies to hop-by-hop option in general. Alas, even rfc7045 did not discuss
> this issue.
>
> IMHO we need a mechanism that specifies: devices MUST NOT punt/slow down packets
> because of the presence of this mechanism, but only because of presence of
> (mechanism,value) where value is intended to be supported by device. If the device
> can not do this, then it MUST IGNORE this mechanism and forward packets with the mechanism
> as if the option was not present.
>
> One simple way to do this is to define hop-by-hop-fixed that does say exactly this
> and then hopefully allow all existing hop-by-hop TLV to live underneath that
> fixed hop-by-hop-fixed option. But i would certainly suggest to review processing
> complexity and extensibility before such a conclusion.
>
> Personally i prefer inband UDP layer signaling, not because i do not like IPv6
> option headers but because there is just no ubiquitous API to allow apps
> independent of OS enhancements to set arbitrary options headers, especially ones

The API does exist. OSes like Linux have implemented APIs described in
RFC2292 and other common APIs.

> that are not yet defined (allow apps to fully defined the whole header bit by bit).
> Lets say from a javascript app in a browser. And i am more interested in ease of
> adoption than in architectural cleanlyness. But of course its perfectly valid to
> do the architectural clean appraoch and then prove me wrong and get that option
> adopted more ;-))

It's not just about architectural cleanliness, it's about correctness.
In the case that an intermediate node parses a UDP payload it is
likely doing this based on the some common destination port number.
Port numbers don't have global and persistent meaning (e.g. TCP port
80 does not always have to be HTTP) so this leads to the possibility
of misinterpretation as described in RFC7605. If the node improperly
writes data into the UDP payload and updates the checksum, then this
becomes silent data corruption. Extension headers do not have this
possibility of misinterpretation in the network.

This potential misinterpretation of UDP ports and many other issues
with trying to turn UDP into a network layer protocol were brought up
in the SPUD/PLUS discussions.

Tom