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

[Joe Touch <[e-mail]>]

On 7/10/2015 3:19 PM, Tom Herbert wrote:
> On Fri, Jul 10, 2015 at 2:44 PM, Joe Touch <[e-mail]> wrote:
>> +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'.
>>
> You get UDP data on a UDP socket, so 1400 bytes is returned.

Sure - to the user.

> Returning
> the extra bytes would be a simple kernel and API change (at least in
> Linux).

You'd keep that within "UDP". If you want to get at that portion, it'd
be like accessing a raw IP socket.

> Besides that, I imagine that HW vendors probably want the
> options to be in the headers due to the HW limitations of packet
> processing.

They just want a quick way to find them. ;-)

> 
>> 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?)
>> ---
> 
> IIRC there was a proposal to contort the UDP checksum to become
> something closer to a UDP-lite checksum. The idea was to indicate this
> mode by setting a UDP length less than 8, and inferring the actual
> length of the UDP payload from the IP total length. Conceptually, this
> same hack could be used to add options to UDP.

Yes, that's what I am proposing. The difference with UDP-lite is that I
would not be returning the extra UDP header option space to the user;
UDP-lite treats that space as "not covered by the checksum" but also
returned to the user.

Joe

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