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

[Joe Touch <[e-mail]>]

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

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