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

[Joe Touch <[e-mail]>]

+1, for somewhat different reasons, notably the problem deploying new IP
options and layer separation.

This really hints that UDP isn't quite sufficient without its own
options. There seems only one place to do this - using the UDP length
field.

E.g., let's say you have a 1500B IP packet with a 20B IP header, leaving
1480 for UDP. But instead of saying that UDP's Length is 1280, we say
it's 1400; in that case, the last 80 bytes could be used as a 'trailer
option area'.

This is somewhat like UDP-lite, except that instead of declaring the
length to indicate "checksum coverage", it would just indicate the UDP
payload vs. extended header, and it would use the existing UDP protocol
number (17) rather than that of UDPlite (136).

---
The reason why this mechanism can use the current UDP protocol number is
that we're not changing the semantics of UDP or the length of the data
delivered to the application vs. the existing UDP length field.

Because we're still assuming that the UDP checksum covers only the
length indicated in the UDP header, there should be no inconsistency
with "mismatching pseudoheaders" - I think. I'll check with the UDPlite
crowd (unless any are already on this list - Gorry?)
---

I'm still not convinced it's safe, though. It would not be covered by
the UDP checksum. I have no idea whether existing stacks would handle it
correctly (i.e., ignoring the extra bytes) vs. shortening the IP packet
to make the lengths match.

NOTE: this appears valid per RFC1122 and RFC768, but I haven't tried it
to see whether it makes various OSes blow up yet...

Hmmm.

Joe

On 7/10/2015 1:45 PM, Toerless Eckert wrote:
> 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