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

[Brian Trammell <[e-mail]>]

> On 09 Jul 2015, at 19:36, Joe Touch <[e-mail]> wrote:
> 
> 
> 
> On 7/8/2015 10:23 PM, Brian Trammell wrote:
>> hi Joe, all,
> ...
>>> One challenge is that IPv6 options are processed differently than IPv4 -
>>> there's no way to "jump" straight into the transport header to find
>>> ports (for port-based load balancing, e.g.).
>> 
>> Yep. If the option chain had a small and
>> easily-hardware-determinable
>> set of possible lengths -- which is the case for v4 options -- this
>> would be easier (but still harder to handle on the fast path than the
>> arrangements we're proposing here).
> 
> IPv4 options can be jumped over in one step using the IHL field.

yes, |set| = 1.

> 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 that want 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.

I haven't followed 6man, though I presume this approach or approaches like it have been discussed there ad nauseam.

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.


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

We revisited the safety of ECN in part because there were plausible processes for the situation to have changed -- the biggest problems that caused the Internet to be ECN-unsafe involved what were basically single-packet exploits against routers, and needed to be fixed for reasons *other* than making the feature work. (ECN *support* is another question, the answer to which is less cheerful.)

I can't think of a comparable process making new/experimental options support less linked to connectivity risk in edge networks -- if nobody uses them (because they don't work) then if you try to use them and they don't work, it's your fault. That would unfortunately seem to be a rather stable state.

Coming back to the layering question:

It does seem to me that what we're (the we that wrote the two documents starting this thread) trying to do is explicitly reinforce the boundary between the network layer and the transport layer, where this is defined as "things the path needs to see versus things only endpoints need to see". Asking nicely (i.e., publishing RFCs) did not work in this case: the transport ports are de facto part of the network layer now, and short of blowing the Internet up and starting over I can't see a way to get them back. So now we are left with enforcing the boundary cryptographically, leaving some space in the "new network layer" (in this case, IP + UDP (for ports) + SPUD) for those things now commonly done within the network.

If we can do this in the _current_ network layer (IPv6 (with options) with some alternate way to handle NAT + DTLS, or we find a portal to an alternate universe where end-to-end IPsec is widely deployable and manageable), then great, let's do that. I'm pessimistic enough to believe that that hasn't been a realistic prospect at any time during this century, though.

Cheers,

Brian

> Joe
> 
> _______________________________________________
> Spud mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spud