Re: [Spud] Putting Network-Layer Information in the Network Layer

[Tom Herbert <[e-mail]>]

On Fri, Jul 10, 2015 at 10:14 AM, Joe Touch <[e-mail]> wrote:
> Hi, Brian,
>
> On 7/10/2015 3:44 AM, Brian Trammell wrote:
>>
>>> On 09 Jul 2015, at 19:36, Joe Touch <[e-mail]> wrote:
> ...
>>> IPv4 options can be jumped over in one step using the IHL field.
>>
>> yes, |set| = 1.
>
> Well, it's actually also because the offset is in the default header and
> nowhere else. The number of options varies, as does the length of many
> options.
>
>>> There's
>>> no such field for IPv6 - routers have to walk the chain of headers one
>>> by one.
>>
>> Right. It seems to me the way out of this (which is not just a
>> problem for boxes that want to muck about in transport protocols, but
>> ones thatwant to properly process hop by hop options) would be to
>> define a new(small) set of IPv6 options headers that themselves would
>> (1) not be combinable and (2) have a fixed length, allowing the
>> next-header field to be _treated_ in constant time / with relatively
>> few gates as the IHL field.
>
> There are several hurdles, not the least of which is that the length of
> HBH options can change in transit.
>
> You don't really need a fixed length to solve this, or even a fixed set.
> The options can even be mutable.
>
> What you really need is a "jump to transport" header that comes before
> all the others, and that is maintained by any device that adds, deletes,
> or changes the length of an option.
>
> The real problem there isn't doing that; its knowing whether you've
> traversed a router that obeys those rules without dropping packets at
> routers that don't. That would kill IPv6.
>
>> I haven't followed 6man, though I presume this approach or
>> approaches like it have been discussed there ad nauseam.
>
> See above.
>
>> The fixed-lengthness of these new v6 options headers would make them
>> problematic for freely extensible options, though one could use these
>> to stick common fast path options in the "fixed" point of the header,
>> and otherwise point to space elsewhere in the packet for things that
>> can happen slowly. You eat the cost of following pointers and doing
>> the more expensive deframing only if you need to in this case.
>
> The real issue, AFIACT, is detecting the behavior of legacy devices that
> wouldn't know to follow these rules - without having them drop the
> packet because it is an unknown option (i.e., you can set "drop if
> unknown", but that would be bad; if you don't set that bit, then you
> can''t detect when changes occur easily).
>
Hi Joe,

Trying to bring up new protocols or features with legacy devices is a
problem that appears in several different contexts. For example we see
this when bringing up IPv6, using UDP on the Internet, running SCTP or
other protocols. In the absence of negotiation with all the relevant
devices or explicit knowledge that all the devices in the path support
the new feature, the typical solution is to try using the feature and
see what the effects are. If we see that packets are being dropped
(lack of acknowledgments) or error messages are seen, then we know
backoff to some "simpler" mode that is known to work. For instance,
use TCP instead of UDP when we see UDP is not making forward progress
for an application (Christian mentioned this in reference to Skype and
gaming protocols). This works as long as devices are dropping packets
because of things they don't understand. Presumably this method could
be employed for hosts to send IP options on the Internet, that is try
sending options and if there are problems stop sending them to that
destination (by definition, options should never required!).

Tom

>>>>> I suspect you'll find that IP options are basically a non-starter except
>>>>> for research purposes.
>>>>
>>>> For the story on the v4 side, do you know of anything newer than
>>>> Fonseca et al "IP Options are Not and Option" (tech report version at
>>>> http://www.eecs.berkeley.edu/Pubs/TechRpts/2005/EECS-2005-24.pdf)? It's
>>>> ten years old -- but given where the engineering effort has gone during
>>>> that decade, I doubt strongly much has changed here.
>>>
>>> Not much. Those old studies have been used in other WGs to drive
>>> documents (IMO, unfortunately).
>>
>> I've been thinking about whether it would be worth the effort to do
>> an updated IP options transparency study.
>
> The IETF has a persistent problem with extensibility. Vendors don't make
> money supporting capabilities not in current use, but that ossifies the
> protocols badly.
>
> Joe