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

[Toerless Eckert <[e-mail]>]

IMHO, IP options do not get us anywhere.

I want a solution that works against the lowest common denominator
of APIs for applications that i have across not only platfornms,
but also application development environments. I have UDP APIs on
a lot more SDKs that UDP + IP options. I bet if i looked, i wouldn't
find IP optoins in a lot of interpreted language SDKs.

Even if supported by language SDK, its an OS issue whether IP optoins
are supported. I remember that some investigation for a project we did
2? years back now resulted in us finding that at C level system APIs,
android for example was not supporting IP router alert for a UDP socket
for IPv6, even though it supported it for IPv4 (i hope i remember these
details correctly). And its just one example.

If all of this stuff is fine, i am totally not persuaded that IP
options are going to be accepted by network operators. There is no
way to guarantee to a network operator that packets with IP options are
NOT punted and cause performance impacts.

We went through this exercise with ECN, and still haven't moved ahead.
After 10 years or so. Where is the stealth data-collection facility in
eg: firefox that tries randomn ECN flows not only to see whether they
pass through, but also checking latency & jitter to validate that
these ECN packets where not punted in routers when they did pass through ?

I am not saying we shouldn't have a glorified plan for STUN that ALSO
includes the architecture for doing it correctly for the
1980's Internet architecture, but please lets not make this plan A.

The Internet architecture has evolved on so many fronts. Can we not
learn in the network/transport layer structure too how to get the
best solutions for reality ?

Just saying.

Toerless

On Fri, Jul 10, 2015 at 10:14:59AM -0700, Joe Touch 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).
> 
> >>>> 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
> 
> _______________________________________________
> Spud mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spud