Subject: Re: [tsv-area] [tae] Transport negotiation

From: Joe Touch <[email-masked]>
Date: Wed, 03 Dec 2008 14:35:02 -0800

Hi, all,

I agree with most of James' conclusions, with some caveats:

james woodyatt wrote:
> On Dec 3, 2008, at 13:07, Stuart Cheshire wrote:
>>
>> The problem is that what constitutes a "transport layer" is a bit
>> slippery.
> 
> I don't think it should be.  The "transport layer" is identified by the
> upper layer protocol header at the end of the extension header chain of
> the inner-most encapsulated IP packet.

I'd say a transport layer is defined as the first protocol header in the
payload of the network header addressed to the host. That is typically
the innermost IP packet, but not always.

>> In a text-based protocol that can use either UTF-8 or Latin-1, is the
>> UTF-8/Latin-1 choice a transport negotiation?  In a protocol that can
>> run over TCP or over TLS, is that a transport negotiation?  If a web
>> server can optionally gzip content to save bandwidth, is that a
>> transport negotiation? What about gzip'd UTF-8 vs. gzip'd Latin-1?
>> What about gzip'd UTF-8 over TLS? What about ASN.1 vs. XDR vs. XML?
> 
> Speaking as a participant in the now-defunct BEEP working group, which
> wrangled these issues to the ground a long time ago, the answer I would
> give to all these questions is, "No."  They are all application profile
> negotiations. 

These are all transparent to the transport protocol; I agree that they
are not transport issues.

...
>> The Application Protocol Name in the SRV record needs to be an opaque
>> identifier that denotes the entire top-to-bottom slice through the
>> protocol stack -- semantics, packet formats, encoding rules, transport
>> protocol. (Once the client has got a connection to the server,
>> negotiating things like optional compression at that layer is then
>> feasible and sensible.)
>>
>> Even having the _udp or _tcp is, IMO, a historical mistake. This is
>> what I say about it in draft-cheshire-dnsext-dns-sd-05.txt: [...]
> 
> I certainly agree with that, but I think SRV makes a number of mistakes
> and this is only one of them.  I would prefer a different definition
> where the record type is a union of different structure types
> discriminated by transport protocol identifier.
> 
> While I'm dreaming, I think I'd ask for two record types to be defined:
> one for IPv4 and the other for IPv6.  That way, the DNS-SD usage of PTR
> records could allow registrants to advertise things like "this service
> is available for IPv6 at TCP port A and for IPv4 at TCP port B (which
> I've got mapped at my NAT gateway to port A)."

I disagree; keep in mind that port number assignments aren't IP-version
specific, so if a service is assigned to port A, then it is assigned to
port A for IPv4 and IPv6. I see no reason why SRV records should either
support or encourage a network-protocol specific port number for a given
service.

Joe

---

From: Stuart Cheshire <[email-masked]>
Date: Wed, 3 Dec 2008 13:07:16 -0800

On 26 Nov, 2008, at 16:24, Joe Touch wrote:

> http:// doesn't "just work" - it specifically indicates "HTTP over  
> TCP"
> IMO. And http://10.0.0.1/ specifies "HTTP over TCP over IPv4".

I think Joe is right about this.

I think the whole notion of "transport negotiation" is flawed. It  
seems attractive to say, "DNS runs over both TCP and over UDP, so we  
should be able to dynamically negotiate which," but under scrutiny  
the idea falls apart.

In a text-based protocol that can use either UTF-8 or Latin-1, is the  
UTF-8/Latin-1 choice a transport negotiation?

In a protocol that can run over TCP or over TLS, is that a transport  
negotiation?

If a web server can optionally gzip content to save bandwidth, is  
that a transport negotiation?

What about gzip'd UTF-8 vs. gzip'd Latin-1? What about gzip'd UTF-8  
over TLS? What about ASN.1 vs. XDR vs. XML?

The combinatorial explosion gets out of control. The correct answer  
IMHO, is to not even try. The Application Protocol Name in the SRV  
record needs to be an opaque identifier that denotes the entire top- 
to-bottom slice through the protocol stack -- semantics, packet  
formats, encoding rules, transport protocol. (Once the client has got  
a connection to the server, negotiating things like optional  
compression at that layer is then feasible and sensible.)

Even having the _udp or _tcp is, IMO, a historical mistake. This is  
what I say about it in draft-cheshire-dnsext-dns-sd-05.txt:

7. Application Protocol Names

    The <Service> portion of a Service Instance Name consists of a pair
    of DNS labels, following the established convention for SRV records
    [RFC 2782], namely: the first label of the pair is an underscore
    character followed by the Application Protocol Name, and the second
    label is either "_tcp" or "_udp".

    Application Protocol Names may be no more than fourteen characters
    (not counting the mandatory underscore), conforming to normal DNS
    host name rules: Only lower-case letters, digits, and hyphens; must
    begin and end with lower-case letter or digit.

    Wise selection of an Application Protocol Name is very important,
    and the choice is not always as obvious as it may appear.

    In many cases, the Application Protocol Name merely names and refers
    to the on-the-wire message format and semantics being used. FTP is
    "ftp", IPP printing is "ipp", and so on.

    However, it is common to "borrow" an existing protocol and repurpose
    it for a new task. This is entirely sensible and sound engineering
    practice, but that doesn't mean that the new protocol is providing
    the same semantic service as the old one, even if it borrows the  
same
    message formats. For example, the local network music sharing
    protocol implemented by iTunes on Macintosh and Windows is little
    more than "HTTP GET" commands. However, that does *not* mean that it
    is sensible or useful to try to access one of these music servers by
    connecting to it with a standard web browser. Consequently, the
    DNS-SD service advertised (and browsed for) by iTunes is  
"_daap._tcp"
    (Digital Audio Access Protocol), not "_http._tcp". Advertising
    "_http._tcp" service would cause iTunes servers to show up in
    conventional web browsers (Safari, Camino, OmniWeb, Internet
    Explorer, Firefox, Chrome, etc.) which is of little use since it
    offers no pages containing human-readable content. Similarly, if
    iTunes were to browse for "_http._tcp" service, that would cause it
    to find generic web servers, such as the embedded web servers in
    devices like printers, which is of little use since printers
    generally don't have much music to offer.

    Similarly, NFS is built on top of SUN RPC, but that doesn't mean it
    makes sense for an NFS server to advertise that it provides "SUN  
RPC"
    service. Likewise, Microsoft SMB file service is built on top of
    Netbios running over IP, but that doesn't mean it makes sense for
    an SMB file server to advertise that it provides "Netbios-over-IP"
    service. The DNS-SD name of a service needs to encapsulate both the
    "what" (semantics) and the "how" (protocol implementation) of the
    service, since knowledge of both is necessary for a client to
    usefully use the service. Merely advertising that a service was
    built on top of SUN RPC is no use if the client has no idea what
    the service actually does.

    Another common question is to ask whether the service type  
advertised
    by iTunes should be "_daap._http._tcp." This would also be  
incorrect.
    Similarly, a protocol designer implementing a network service that
    happens to use Simple Object Access Protocol [SOAP] should not feel
    compelled to have "_soap" appear somewhere in the Application
    Protocol Name. Part of the confusion here is that the presence of
    "_tcp" or "_udp" in the <Service> portion of a Service Instance Name
    has led people to assume that the structure of a service name has to
    reflect the internal structure of how the protocol was implemented.
    This is not correct. All that is required is that the service be
    identified by a unique Application Protocol Name. Making the
    Application Protocol Name at least marginally descriptive of
    what the service does is desirable, though not essential.

    The "_tcp" or "_udp" should be regarded as little more than
    boilerplate text, and care should be taken not to attach too much
    importance to it. Some might argue that the "_tcp" or "_udp" should
    not be there at all, but this format is defined by RFC 2782, and
    this document does not propose to change that. In addition, the
    presence of "_tcp" has the useful side-effect that it provides a
    convenient delegation point to hand off responsibility for service
    discovery to a different DNS server, if so desired.

Stuart Cheshire <[email-masked]>
* Wizard Without Portfolio, Apple Inc.
* Internet Architecture Board
* www.stuartcheshire.org

---

From: james woodyatt <[email-masked]>
Date: Wed, 3 Dec 2008 13:57:24 -0800

> The problem is that what constitutes a "transport layer" is a bit  

I don't think it should be.  The "transport layer" is identified by  
the upper layer protocol header at the end of the extension header  
chain of the inner-most encapsulated IP packet.  I think it would be a  
lot simpler if we didn't succumb to the temptation to overload that  
concept with a lot of other ones that really belong in the layers  
above the transport layer.  For example...

> In a text-based protocol that can use either UTF-8 or Latin-1, is  
> the UTF-8/Latin-1 choice a transport negotiation?  In a protocol  
> that can run over TCP or over TLS, is that a transport negotiation?   
> that a transport negotiation? What about gzip'd UTF-8 vs. gzip'd  
> Latin-1? What about gzip'd UTF-8 over TLS? What about ASN.1 vs. XDR  
> vs. XML?

Speaking as a participant in the now-defunct BEEP working group, which  
wrangled these issues to the ground a long time ago, the answer I  
would give to all these questions is, "No."  They are all application  
profile negotiations.  Some of them happen to be profile negotiations  
designed to tune the application protocol for certain transport layer  
extensions, e.g. security, compression, etc., and others are purely  
application layer negotiations, but none of them are negotiations of  
which transport layer to use.

> IMHO, is to not even try.

And to say, "No, these are not transport layer negotiations; they're  
application profile negotiations."

> The Application Protocol Name in the SRV record needs to be an  
> opaque identifier that denotes the entire top-to-bottom slice  
> through the protocol stack -- semantics, packet formats, encoding  
> rules, transport protocol. (Once the client has got a connection to  
> the server, negotiating things like optional compression at that  
> layer is then feasible and sensible.)
>

I certainly agree with that, but I think SRV makes a number of  
mistakes and this is only one of them.  I would prefer a different  
definition where the record type is a union of different structure  
types discriminated by transport protocol identifier.

While I'm dreaming, I think I'd ask for two record types to be  
defined: one for IPv4 and the other for IPv6.  That way, the DNS-SD  
usage of PTR records could allow registrants to advertise things like  
"this service is available for IPv6 at TCP port A and for IPv4 at TCP  
port B (which I've got mapped at my NAT gateway to port A)."

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering

---

From: james woodyatt <[email-masked]>
Date: Wed, 3 Dec 2008 15:26:09 -0800

> the innermost IP packet, but not always.

Fair enough, I suppose.

> support or encourage a network-protocol specific port number for a  

Not all services need to be assigned port numbers by IANA.  It's  
perfectly reasonable to define a service name with no associated port  
number.  Servers can bind to temporary port numbers and register them  
in DNS with service records.  Sadly, dual-stack IPv4/IPv6 servers  
cannot always ensure availability over both IPv4 and IPv6 at the same  
temporary port.  For example, consider the case where the IPv4 side of  
the service is mapped through a NAT gateway, e.g. it's located on a  
residential network and advertising its availability with DNS-SD to  
the public Internet.

If you don't believe in such configurations and you want to discourage  
them, then keeping SRV unified for both IPv4 and IPv6 makes a lot of  
sense.  The net result, however, is that dual-stack servers likely  
will be advertised with DNS-SD for IPv4 only, i.e. not for IPv6, for  
the foreseeable future.  This is how Apple's implementation of DNS-SD  
works today, and the result is slower adoption of IPv6 as an  
alternative to IPv4/NAT.  Moreover, it's doubtful that anything can be  
done to remedy the problem without drawing the network protocol  
distinction between service records some other way-- a way that will  
probably be more evil than my previous idea.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 4 Dec 2008 10:29:10 +0100

On 3 dec 2008, at 22:57, james woodyatt wrote:

> usage of PTR records could allow registrants to advertise things  
> like "this service is available for IPv6 at TCP port A and for IPv4  
> at TCP port B (which I've got mapped at my NAT gateway to port A)."

You may want to tackle TCP vs SCTP (well, really "which *P", of  
course) while you're at it... And don't forget relative priorities so  
someone can say "try (my native, non-NAT) IPv4 first, then (6to4)  
IPv6" vs "try (native) IPv6 first, then (NATed) IPv4)". Or SCTP+TCP  
over v6, but my v4 NAT doesn't do SCTP so only TCP over v4.

---

From: james woodyatt <[email-masked]>
Date: Thu, 4 Dec 2008 09:08:52 -0800

On Dec 4, 2008, at 01:29, Iljitsch van Beijnum wrote:
> course) while you're at it... And don't forget relative priorities  
> so someone can say "try (my native, non-NAT) IPv4 first, then (6to4)  

I thought what I was dreaming about could already be made to do that.

---

From: Lloyd Wood <[email-masked]>
Date: Sun, 7 Dec 2008 00:49:17 +0000

On 3 Dec 2008, at 21:07, Stuart Cheshire wrote:
>
> I think the whole notion of "transport negotiation" is flawed.

agreed. And moving negotiation to 'asking DNS what to do' is just  
shifting the problem around.

At the least, it should be possible to explicitly say 'this is how I  
will send' and presume the other end is similarly explicitly  
configured. No negotiation, period.

(The environments I'm considering won't support DNS.)

DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/

<http://info.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

---

From: Joe Touch <[email-masked]>
Date: Sun, 07 Dec 2008 22:08:19 -0800

Lloyd Wood wrote:
> will send' and presume the other end is similarly explicitly configured.
> No negotiation, period.

Isn't that exactly what happens when I send a TCP over IPv4 SYN segment?
I'm saying "I want to use IPv4, using TCP, with the indicated options,
on the given port".

The trouble ensues when the initiator is ambiguous about what it wants -
for whatever reason (e.g., to enable alternates at differently-capable
receivers).

Joe

---

From: Lloyd Wood <[email-masked]>
Date: Mon, 8 Dec 2008 12:56:47 +0000

Joe,

I'm interested in a parseable way to pass that information down from a  
URI and the program handling the URI.

Right now, we can explicitly state 'http' or 'https'. These are  
presumed to live over TCP, and IP - whether to use v4 or v6 is usually  
determined directly by giving an address or by DNS. But, oddly enough,  
we can also explicitly specify the port number, which defaults to 80.  
So, even though http lives on port 80 (and https on 443), that can be  
overridden in the URI.

Similarly, though http is expected to live over TCP, being able to  
explicitly override it in the URI if desired has merit in some cases.  
That is, 'http' would be the same as writing 'http-tcp'. 'http-sctp',  
for the work outlined in:
http://tools.ietf.org/html/draft-natarajan-http-over-sctp
means use a different transport - SCTP instead of TCP.

Doesn't it strike you as odd that we can, at a high uri level, specify  
the low-level port number, but not the details of the layering to be  
used for that port? By adding explicit detail in the URI, we are  
removing ambiguity.

L.

---

From: Joe Touch <[email-masked]>
Date: Mon, 08 Dec 2008 07:14:44 -0800

> URI and the program handling the URI.

OK...

> Right now, we can explicitly state 'http' or 'https'. These are presumed
> to live over TCP, and IP - whether to use v4 or v6 is usually determined
> directly by giving an address or by DNS. But, oddly enough, we can also
> explicitly specify the port number, which defaults to 80. So, even
> though http lives on port 80 (and https on 443), that can be overridden
> in the URI.

Right. The port number is determined by the service name (which doubles
as the application protocol name) by default, but since that number is
solely determined by the endpoints anyway, there's an override.
ou w
> used for that port? By adding explicit detail in the URI, we are

The port number isn't low level; it's the highest level, at the same
level as the protocol name/service name (http, https). The address is
also application-layer (consider that http://www.a.com/ returns a
different result than http://www.b.com/ even if they resolve to the same
IP address, at least since HTTP 2.x AFAIR).

The fact that addresses have different formats (DNS name, IPv4 dotted,
IPv6 coloned) is the part you're trying to mimic, IMO, and the
implication that using an IPv4 dotted implies a particular network layer
(IPv4 packets). Right now, we can specify that only for numeric IP
addresses, not even for DNS names.

Note that we don't let that float, though - it isn't:

	http or https://www.a.com/

It's the floating part that doesn't make a lot of sense from a protocol
handshake viewpoint - regardless of the fact that it also doesn't map
well to existing protocol handshakes.

As to specifying the lower layers, that builds on the artifact of
numeric IP addresses implying network layer. I don't know if I think
this should be visible to the app layer (as the address necessarily is);
it seems to break a lot of the isolation that layering is intended to
provide.

- ----

If you're going to do this, though, I wonder if the syntax of that
shouldn't lie syntactically where it exists in layering:

i.e.:
	http://www.example.com/
would become, explicitly:
	http:80//tcp:nagle//www.example.com:v4/

I.e., tcp doesn't modify the http part; it modifies the service:port
*pair*, and isn't tied any more to that pair than it is to the DNS name.
The DNS name, further, requires a version as well. We could add explicit
options to TCP as shown above too.

The general form might thus be:

	protocol_ID[:defaut_override]*

And the general form of a URI would include:

	app proto_ID//[transport_proto_ID//]?net_proto_ID

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 08 Dec 2008 13:13:39 -0800

John Leslie wrote:
> Lloyd Wood <[email-masked]> wrote:
>> That is, 'http' would be the same as writing 'http-tcp'.
> 
>    Given that there's existing work for http over sctp, and that sometimes
> ambiguity is intentional and can be a good thing, I'd recommend that
> plain 'http' be allowed to continue whatever ambiguity it already has,

The ambiguity is that some people think "http" has ambiguity, and others
do not; it's insufficient to assume that there's agreement on this, thus
that it's clear exactly what needs a new name.

Sec 3.2.2 of RFC2616 appears to indicate that TCP is assumed, i.e., that
it's not up in the air. Elsewhere it's noted that HTTP can run over any
reliable transport, but 3.2.2 indicates fairly directly what http: means.

AFAICT, there *only* ambiguity in URIs is in the network protocol when
specified by a DNS name (and even that causes substantial grief).

Joe

---

From: Stuart Cheshire <[email-masked]>
Date: Tue, 9 Dec 2008 14:42:26 -0800

On 3 Dec, 2008, at 13:57, james woodyatt wrote:
> The "transport layer" is identified by the upper layer protocol  
> header at the end of the extension header chain of the inner-most  
> encapsulated IP packet.

This might be a fine answer to the question, "What is the transport  
layer?" on the mid-term exam for an introductory undergraduate  
networking class.

The notion of layers in networking is an artificial simplifying  
assumption introduced to help us think about software design (and to  
help ISO divide their people up into seven committees). Like all  
simplifying assumptions, there are cases where it is helpful, and  
cases where it is not. This is a case where religious adherence to  
apparent layer boundaries is not helpful.

Bryan Ford's excellent "Breaking Up the Transport Logjam"  
presentation pointed out that what we call the "transport layer"  
artificially takes three functions (demux, flow control, and  
operational abstraction) and lumps them together in what we  
traditionally call "transport layer", while leaving out other  
functions (session, presentation, etc.) and artificially deeming them  
to be "not transport layer". Such artificial distinctions do not help  
guide our networking design thought processes in useful ways.

For our purposes here, there are three relevant groupings:

C. Application/Presentation/Transport/etc.
B. IP
A. Datalink/Hardware/etc.

In group (A) there are differences due to inherent differences in the  
underlying hardware.
The purpose of IP (group B) is to homogenize away those hardware  
differences and present a uniform service model.
In group (C) there are intentional differences due to the different  
requirements of different applications.

The point is that the differences in group (C) are *intentional*.  
Different applications have different requirements. The whole *point*  
of having different transport protocols is that they offer different  
operating semantics -- e.g. UDP preserves message boundaries; TCP  
does not.

I think that when we denote a certain application protocol using a  
name like "foobar", that name has to encompass the complete package  
of everything the application uses, requires, and assumes, from the  
IP layer up. Tempting as it is to think of networking as a set of  
tinker-toy components that can be just plugged together in whatever  
order we feel like, in the real world software is a lot more brittle  
than that. I'm all in favour of applications negotiating capabilities  
and requirements, but that has to be done by the applications, and  
done carefully, with thorough testing. Thinking that we can solve  
this problem by just enumerating all the permutations in the DNS  
seems naive to me.

---

From: Joe Touch <[email-masked]>
Date: Tue, 09 Dec 2008 16:34:09 -0800

Stuart (et al.),

Stuart Cheshire wrote:
>> The "transport layer" is identified by the upper layer protocol header
>> at the end of the extension header chain of the inner-most
>> encapsulated IP packet.
> 
> 
> help ISO divide their people up into seven committees).

That's one perspective; I have another, e.g.:
http://www.isi.edu/rna/

This is somewhat similar to John Day's view on layering.

...
> Bryan Ford's excellent "Breaking Up the Transport Logjam" presentation
> pointed out that what we call the "transport layer" artificially takes
> three functions (demux, flow control, and operational abstraction) and
> lumps them together in what we traditionally call "transport layer",
> while leaving out other functions (session, presentation, etc.) and
> artificially deeming them to be "not transport layer". 

His approach doesn't consider that these features exist at other layers.
All layers are capable of:
	state coordination (soft, hard, etc.)
	flow control
	error recovery
	order restoration
	multiplexing/demultiplexing
	framing
	security
	etc.

What distinguishes layers, IMO, is scope and the relation to the
services it requires a-priori. I don't consider the above the unique
purvue of the transport layer, to be sure.

Joe

---

From: james woodyatt <[email-masked]>
Date: Tue, 9 Dec 2008 19:01:55 -0800

On Dec 9, 2008, at 16:34, Joe Touch wrote:
> [...]

 From where I stand, i.e. smack in the middle of your transport-aware  
packet-forwarding plane-- where, as Stuart so kindly reminded us in a  
previous message, I am using the word "transport" to talk about my  
naïve and misguided notions concerning what identifies the layer above  
the one currently subject to forwarding-- the upper layers look  
altogether like a stack of transports with the one at the top being  
designated an application by virtue of the magical fact that it isn't  
being used to transport anything else, and the one at the bottom  
being-- hopefully-- the *only* one the transport-aware forwarding  
plane has to care about (but, of course, hopes are always dashed on  
the Rock Of Exceptions).

It so happens that I would dearly love to see the Internet packet- 
forwarding planes simplified to make them not have to care *at* *all*  
about what I'm calling "transports" here, but it seems like every time  
I've tried to help that along, I've ended up getting punched in the  
neck by reality.  So, I'm pretty well sold on the RNA idea: if you ask  
me, we may as well regard the architecture as "transports" from top to  
bottom, from XML schema all the way down to the 802.11 PHY layer.  I'm  
totally game for this.

Looking at Bryan Ford's "Breaking Up The Transport Logjam" paper, I  
can imagine defining an Endpoint Identity extension header that  
comprises the source and destination service identifiers, independent  
of what we might traditionally regard as the transport layer, for any  
given IP packet.  I can also imagine defining separate flow and  
ordering control, rate control, congestion avoidance, and connection  
maintenance extension headers, all of which are independent of the  
transport layer.  There might not be anything left of the traditional  
"transport" layer when we get done, but I suppose that could be  
regarded as a feature: the objective being to split the existing  
transport layers up into a toolkit of combinatory extension headers.

But is it a good idea to do it this way?  It doesn't seem likely when  
I think about it.  Why not just define a single layer that unifies all  
the various E2E tools in one conceptual model?  (I'm now remembering  
an esoteric transport protocol called XTP that purported to attempt  
this.  <sardonic>I wonder whatever happened to it.</sardonic>)

I think I must be missing something important about this transport  
logjam problem or making some unwarranted assumptions related to it.   
Hopefully, the others here will set me straight.  I'm looking forward  
to it.

---

From: Joe Touch <[email-masked]>
Date: Tue, 09 Dec 2008 21:09:15 -0800

james woodyatt wrote:
...
> But is it a good idea to do it this way?  It doesn't seem likely when I
> think about it.  Why not just define a single layer that unifies all the
> various E2E tools in one conceptual model?  (I'm now remembering an
> esoteric transport protocol called XTP that purported to attempt this. 
> <sardonic>I wonder whatever happened to it.</sardonic>)

TP++ as well, FWIW. There's a difference between trying to unify the
functions of the layers (as with XTP and TP++) and declaring that this
means only a single layer is sufficient. RNA argues (and Day's book also
suggests) that the layering itself provides utility in limiting scope,
and in abstracting services for layers above (and from layers below).

Joe

---

From: Stuart Cheshire <[email-masked]>
Date: Wed, 10 Dec 2008 09:46:08 -0800

On 9 Dec, 2008, at 19:01, james woodyatt wrote:

> From where I stand, i.e. smack in the middle of your transport- 
> aware packet-forwarding plane

Why do we want a transport-aware packet-forwarding plane?

The primary reason NAT gateways need to peek into the transport  
header is to get at the ports for receiver demultiplexing. It's  
purely a historical mistake that we forgot to put the demultiplexing  
identifiers into the IP-layer header like other protocols do, which  
is why every IP-based transport layer has to duplicate that  
functionality, which is why NAT gateways need to peek into those  
transport headers.

It's too late to fix the IPv6 header format, but if we regard UDP/ 
IPv6 as our new combined datagram header, the way Bryan Ford  
proposes, then a whole bunch of problems go away. It's not a  
deficiency of NAT gateways that they need to understand every  
transport header (and thereby impede adoption of transports they  
don't understand); it's a deficiency of our transport headers that  
they include demultiplexing identifiers that they should not.

It's a testament to the IETF's extreme antipathy to NAT that we  
refused to layer new transport protocols like SCTP and DCCP over UDP,  
as if we imagined that creating new protocols that didn't work with  
NAT would be the thing to convince the rest of the world that NAT was  
evil. It was as if we imagined that in the resulting battle for  
consumer mindshare our new transports would win and NAT would lose.  
We sacrificed SCTP and DCCP on the altar of anti-NAT fanaticism.

If SCTP and DCCP were just user-level library code that any  
application writer could use freely, without waiting for support from  
the OS vendor, NAT gateways, or network, they'd be much more widely  
used today. This strange notion that layering transport protocols  
over UDP is a gross hack has got to go.

Layering new transport protocols over UDP is not a hack. It's  
actually the right architecture AND (because of that) it also happens  
to work though NAT gateways too.

---

From: Joe Touch <[email-masked]>
Date: Wed, 10 Dec 2008 09:55:55 -0800

Stuart Cheshire wrote:
>> packet-forwarding plane
> The primary reason NAT gateways need to peek into the transport header
> is to get at the ports for receiver demultiplexing. 

The IP header has exactly what a NAT needs for receiver demultiplexing -
the IP address.

> It's purely a
> historical mistake that we forgot to put the demultiplexing identifiers
> into the IP-layer header like other protocols do, which is why every
> IP-based transport layer has to duplicate that functionality, which is
> why NAT gateways need to peek into those transport headers.

Ports are intended for demultiplexing within a host. The fact that a NAT
masks multiple hosts breaks port demultiplexing *by design*; NATs are
intended to hide the fact that there are multiple hosts.

> It's too late to fix the IPv6 header format, but if we regard UDP/IPv6
> as our new combined datagram header, the way Bryan Ford proposes, then a
> whole bunch of problems go away. It's not a deficiency of NAT gateways
> that they need to understand every transport header (and thereby impede
> adoption of transports they don't understand); it's a deficiency of our
> transport headers that they include demultiplexing identifiers that they
> should not.

IMO, NATs need to understand the demultiplexing that is designed to be
internal to a host exactly because of what a NAT is and what it does. It
doesn't make sense to be to bemoan that fact.

Joe

---

From: Stuart Cheshire <[email-masked]>
Date: Wed, 10 Dec 2008 10:02:32 -0800

> doesn't make sense to be to bemoan that fact.

I can't tell which side you are arguing. Do you believe that:

(a) demultiplexing (i.e. port numbers) should be duplicated by every  
transport layer, or
(b) demultiplexing (i.e. port numbers) should be done once, at a  
shared lower layer?

---

From: james woodyatt <[email-masked]>
Date: Wed, 10 Dec 2008 11:45:25 -0800

On Dec 10, 2008, at 09:46, Stuart Cheshire wrote:
> The primary reason NAT gateways need [...]

I'm not talking about NAT gateways, especially given that I'm not sure  
I believe that NAT66 will require port multiplexing (though, I think  
it might).  I'm only talking about stateful filtering IPv6 routers.

Do we *not* want stateful filtering routers anymore?  Please please  
please... someone tell my managers and marketing people!  I want to  
believe.  I really do.  Would you like to see my scars again?  I could  
post the GIFs.  (NSFW)

> actually the right architecture AND (because of that) it also  
> happens to work though NAT gateways too.

I'm not in agreement with that.  I still think "layering new  
transports on UDP" is a kludge.  There's a lot of "transportly stuff"  
that needs to be negotiated on a node-to-node basis, and only  
sometimes (not always) on a user-endpoint-to-user-endpoint basis, e.g.  
congestion avoidance, mobility, etc.

I'm starting to come around to liking the idea of a toolkit of  
combinatory extension headers the more I mull over Joe's earlier  
comments.  To that end, I regard the UDP header as a conflation of two  
unrelated concepts: A) service multiplexing on node-to-node  
associations and B) datagram payload integrity checking.  Also, while  
I think UDP does a passing job on the former, it does a really lousy  
job on the latter, and I'd rather see those bytes used for extension  
header chaining than for checksum and length.

Alas, we have stateful filtering routers today (I have several on my  
desk right now!) and these are only aware of the transport protocols  
in existence presently (minus SCTP and DCCP).  One of them is UDP, but  
it's not the *only* available option for traversing filters.  I don't  
think it's the best one, either.  There are too many optional  
misbehaviors of stateful filtering routers with regard to UDP  
forwarding to make it optimally useful as a foundation for new  
transports.

In my view, if we're looking for ways to make new IPv6 transports  
capable of traversing stateful filters, we should instead consider  
layering them over IPsec AH or ESP, each of which is treated today  
under much more sensible rules: either they pass through filters  
unmolested or they get through not at all.  I like that much better  
than the crazy weirdness you get with UDP filtering, where passing in  
one direction between endpoint A and endpoint B is no guarantee that  
any related communications will pass through the filter in the other  
direction or even between either endpoints A and B and another  
endpoint C.

Sadly, I'm not sure we really want to be looking for ways to make  
transports capable of traversing stateful filters.  I think IETF  
enjoys finding new and interesting ways for routers to decide when not  
to forward as a matter of network policy.  I wish to be proven wrong  
about that, but I doubt it will happen.  In that light, I think the  
combinatory extension headers idea has a lot of merit.

---

From: Joe Touch <[email-masked]>
Date: Wed, 10 Dec 2008 14:12:00 -0800

Stuart Cheshire wrote:
> (b) demultiplexing (i.e. port numbers) should be done once, at a shared
> lower layer?

Regarding NATs, I think that demultiplexing of port numbers should be
done inside the end host, and that NATs necessarily need to peek at
these numbers in 'layer violating ways'.

The question you're asking is clearer now - i.e., what is the demux order:

	1) IPaddr, transportproto, port

	2) IPaddr, port, transportproto

AFAICT, the demultiplexing is really:

	3) IPaddr, [transportproto, port]

I.e., the second demuxing (after IP address) includes both the transport
protocol and the port as a pair - whether done in a NAT or in the end
system. I understand that you want to decouple the two, but port numbers
aren't defined independently of transport protocol. Regardless of what
order you do them in, whatever does one needs to do both AFAICT.

Joe

---

From: james woodyatt <[email-masked]>
Date: Wed, 10 Dec 2008 15:17:30 -0800

> 	3) IPaddr, [transportproto, port]

Actually, the rules a port-muxing NAT must enforce at demuxing time  
are always dependent first on the transport protocol.  After that, the  
rules get murky.

For example, in the case of TCP, the translated destination is a  
function of the entire 4-tuple of remaining address parameters, i.e.  
source address, source port, destination address, destination port.

On the other hand, in the case of UDP, the translated destination can  
be the result of any of three different functions involving the 2- 
tuple of the destination address and destination port, the source  
address and the source port, according to the UDP endpoint mapping  
behavior of the NAT function in play.  (Incidentally, a similar  
explosion of possibility arises for TCP when considering unsolicited  
inbound SYN packets received at destination address and destination  
port pairs already in use by another connection state, i.e. it's  
according to the TCP endpoint mapping behavior of the NAT function.)

Likewise, other transport protocols, e.g. IPsec ESP, don't even have  
source and destination ports, and also some, e.g. SCTP, use an  
association identifier with the destination address and they don't  
translate the source or destination ports at all.

It's messy, but if we're going to end our anti-NAT jihad, then I'm  
looking forward to seeing proposals for ways we can simplify all  
this.  Hopefully, those proposals will be ones that won't get shot to  
pieces in the everlasting battles over security vs. transparency for  
which IETF has been the battleground since forever.

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 11 Dec 2008 08:26:42 +0000

> On 9 Dec, 2008, at 19:01, james woodyatt wrote:

<snip>

> It's a testament to the IETF's extreme antipathy to NAT that we refused 
> to layer new transport protocols like SCTP and DCCP over UDP, as if we 
> imagined that creating new protocols that didn't work with NAT would be 
> the thing to convince the rest of the world that NAT was evil. It was as 
> if we imagined that in the resulting battle for consumer mindshare our 
> new transports would win and NAT would lose. We sacrificed SCTP and DCCP 
> on the altar of anti-NAT fanaticism.
> 
Not so. At least for DCCP, this seems to be re-writing history:

DCCP made a design decision (in an IETF design review, I think, on the 
basis of NAT experience) to not use a stronger checksum and to position 
the 16-bit DCCP checksum and port fields in places where they would 
EXACTLY match those of UDP.

The decision to use the UDP checksum algorithm was largely motivated by 
the desire to allow incremental header checksum update.

SCTP made different design choices, but at least for DCCP, the 
NAT-traversal is not much different to those protocols that already 
traverse NATs.

> If SCTP and DCCP were just user-level library code that any application 
> writer could use freely, without waiting for support from the OS vendor, 
> NAT gateways, or network, they'd be much more widely used today. This 
> strange notion that layering transport protocols over UDP is a gross 
> hack has got to go.
> 
I disagree. This was a conscious decision, see DCCP problem statement 
(RFC4336).

> Layering new transport protocols over UDP is not a hack. It's actually 
> the right architecture AND (because of that) it also happens to work 
> though NAT gateways too.
> 
I am not convinced this is a good long-term decision.

> _______________________________________________
> tae mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tae
> 
Gorry Fairhurst

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 11 Dec 2008 11:00:15 +0100

On 10 dec 2008, at 20:45, james woodyatt wrote:

> I'm not talking about NAT gateways, especially given that I'm not  
> sure I believe that NAT66 will require port multiplexing (though, I  
> think it might).

Yes, why would we demux on the 128 bits that are there in clear sight,  
doing it on 16 others that may or may not be present elsewhere in an  
unpredictable place makes much more sense. </sarcasm>

> I'm only talking about stateful filtering IPv6 routers.

We "need" port numbers for stateful filters today (well, in the past,  
really) because someone may be running a vulnerable service on another  
port.

However, for non-TCP, non-UDP protocols we can assume that the hosts  
running those are keeping up with the times and don't run DCCP, SCTP  
or ???P services on certain ports so we should just allow these  
protocols without looking deeper inside them. We only need the old  
crap for TCP and UDP in case someone is running Windows 98 or XP  
without a service pack, anyway.

> Do we *not* want stateful filtering routers anymore?

I don't.

> Please please please... someone tell my managers and marketing  
> people!  I want to believe.  I really do.

We had this dicussion last year in the CPE context. You said you  
couldn't sell to those people letting through ANY unsolicited packets.

> I still think "layering new transports on UDP" is a kludge.

I tend to agree but even I can be pragmatic from time to time.

But this is really a pointless discussion except when inventing new  
transports, because all the other ones except RTP already exist and  
DON'T run on top of UDP so changing this to running ove UDP requires  
new hacks. Inventing new hacks because we don't like the old hacks  
doesn't seem like a very good use of our time.

Back to the transport negotiation issue: the whole idea of specifying  
TCP vs SCTP etc in URLs is nonsense, because the whole issue is that  
we don't know whether a client can support the new protocol. Feeding a  
client a URL it won't be able to parse just pushes the problem to the  
layer where URLs are created.

IPv6 got this part right: the URLs are the same but consenting clients  
and servers can discover that they share IPv6 capability and use it  
while oblivious servers and/or clients can remain oblivious. We could  
do transport negotiation in the same way (through the DNS) although  
this requires even more DNS lookups for clients that know the new  
protocols, which isn't great especially if the new stuff is rarely used.

Another option that wasn't really possible with the IP version  
negitiation is doing the negotiation in-band through test packets or  
options. However, test packets are also problematic when they are  
common while the things they are test for are uncommon. And some  
middleboxes barf on options...

> capable of traversing stateful filters

Isn't that backwards? Shouldn't we adapt filters to our new protocols  
rather than the other way around? Especially with IPv6, where we can  
assume that there is no ossified legacy deployment, i.e., everything  
that runs IPv6 can assumed to be at least minimally upgradable.

But if we really want this we should probably come up with a "UDP  
ultralight" which would probably be ports and payload type, with  
possibly some SYN/FIN style bits to make statefulness workable. Bonus  
credit for putting this in a fixed place in the packet. We may also  
want to forbid the payload protocols from looking at the addresses for  
their checksum.

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 11 Dec 2008 10:51:46 +0000

<snip>
> credit for putting this in a fixed place in the packet. We may also want 
> to forbid the payload protocols from looking at the addresses for their 
> checksum.
 >
We would still need a way for transport end points to know that they had 
indeed got a packet that was MEANT to be sent to them. That was one of 
the roles of the UDP/DCCP/SCTP/UDP-L/ICMP etc checksum for IPv6:-)

Gorry

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 11 Dec 2008 12:01:47 +0100

On 11 dec 2008, at 11:51, Gorry Fairhurst wrote:

> We would still need a way for transport end points to know that they  
> had indeed got a packet that was MEANT to be sent to them. That was  
> one of the roles of the UDP/DCCP/SCTP/UDP-L/ICMP etc checksum for  
> IPv6:-)

The chance of hitting a live IPv6 address when one or more random  
address bits are flipped is very low. (With IPv4 the header checksum  
protects us from this.) The chance of then also hitting a live session  
and being in-window is _extremely_ small. Do we really care about this  
corner case? And that's for link layers without their own CRCs.

It's not like the current checksum is bullet proof the way things are,  
you can easily end up with corrupt data in the payload for long flows  
if there is some level of errors not caught by lower layers, with two  
flipped bits you can have the same checksum as the original packet so  
this would happen at the order of about once every million packets  
with two flipped bits.

---

From: Lloyd Wood <[email-masked]>
Date: Thu, 11 Dec 2008 12:09:30 +0000

On 11 Dec 2008, at 10:00, Iljitsch van Beijnum wrote:
>
> Back to the transport negotiation issue: the whole idea of  
> specifying TCP vs SCTP etc in URLs is nonsense, because the whole  
> issue is that we don't know whether a client can support the new  
> protocol. Feeding a client a URL it won't be able to parse just  
> pushes the problem to the layer where URLs are created.

The URI is rejected locally, and it becomes a scripting problem for  
the script that deliberately specified 'use that transport' - and the  
script can fall back to a different transport if it so chooses.

This is all local in the box.

Negotiation at a high level is something that can be sorted out once  
the capability to specify transports at a high level exists.

L.

---

From: Lloyd Wood <[email-masked]>
Date: Thu, 11 Dec 2008 12:12:58 +0000

Placing the requirement for insertion of the pseudo-header checksum  
and protection of network headers on the transport layer was a mistake  
in IPv6, IMO. That mistake is fixed by using UDPv6 or UDP-Litev6 to  
provide demultiplexing and in interface to the transport layer.

UDPv6 and UDP-Litev6 are pretty much the minimum for transports, and a  
good starting point.

On 11 Dec 2008, at 10:51, Gorry Fairhurst wrote:

>> possibly some SYN/FIN style bits to make statefulness workable.  
>> Bonus credit for putting this in a fixed place in the packet. We  
>> may also want to forbid the payload protocols from looking at the  
>> addresses for their checksum.
> >

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 11 Dec 2008 12:35:10 +0000

Iljitsch van Beijnum wrote:
>> one of the roles of the UDP/DCCP/SCTP/UDP-L/ICMP etc checksum for IPv6:-)
> 
Does anyone have recent results/experience for router/switch/middlebox 
corruption? - I think links should have CRC/FEC (covering at least of 
the header), so I wouldn't design transport to fix link errors - this 
design doesn't mean the network is corruption free... there's more to 
the network path than the physical links.

> you can easily end up with corrupt data in the payload for long flows if 
> there is some level of errors not caught by lower layers, with two 
> this would happen at the order of about once every million packets with 
> two flipped bits.
> 
Yes, right so *do* check the complete object transfered over the transport
connection (that's always been good advice  - but I like the idea of a 
check that lowers the error rate at
the input to my protocol state machine (i.e. tries to check headers relate
to the payload they carry and the endpoint where they were directed).

Gorry

---

From: "Phelan, Tom" <[email-masked]>
Date: Thu, 11 Dec 2008 09:48:48 -0500

> > It's a testament to the IETF's extreme antipathy to NAT that we
refused
> EXACTLY match those of UDP.

[Tom P] I think we should question the wisdom of that decision.
Basically, it was decided to do 67% of what was necessary for NAT
traversal -- put the ports and checksum in the same place as UDP -- but
not the remaining 33% -- we put DCCP in the protocol field instead of
UDP.  My opinion is that the end effect of this is largely what Stuart
says above.

> NAT-traversal is not much different to those protocols that already

[Tom P] DCCP is not much different, but is some different, and that some
different is enough to make the not different parts not matter.

> > If SCTP and DCCP were just user-level library code that any
application
> I disagree. This was a conscious decision, see DCCP problem statement

[Tom P] This is really not an over-UDP issue, although over-UDP is the
easiest way to solve the issue.  This is really about the thinking that
transport protocols MUST be implemented in the kernel.  That thinking
makes Microsoft the gatekeeper for any widespread deployment of a new
transport protocol, which eliminates the possibility of grass-roots
deployments of new transports.

By the way, my thinking behind doing the dccp-tp implementation is to
enable these grass-roots deployments.

> > Layering new transport protocols over UDP is not a hack. It's
actually

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 11 Dec 2008 16:05:50 +0100

On 11 dec 2008, at 15:48, Phelan, Tom wrote:

> This is really about the thinking that

No it doesn't. Nobody is stopping you from implementing a new protocol  
and sending/receiving packets from user space using that protocol with  
raw sockets.

Of course in that case there's no demultiplexing between several user  
space programs using the protocol in question.

So your real complaint is that you can't come up with a new protocol  
in user space but still have the kernel demultiplex.

The logical conclusion of this train of thought is that the IP header  
should gain port numbers but lose the protocol number, which is then  
completely superfluous. (Currently its only real function is to allow  
for ICMP responses to arbitrary packets although it is widely abused  
in filtering.)

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 11 Dec 2008 10:12:10 -0500

On Dec 11, 2008, at 10:05 AM, Iljitsch van Beijnum wrote:

> No it doesn't. Nobody is stopping you from implementing a new  
> protocol and sending/receiving packets from user space using that  
> protocol with raw sockets.
>
> Of course in that case there's no demultiplexing between several  
> user space programs using the protocol in question.
>
> The logical conclusion of this train of thought is that the IP  
> header should gain port numbers but lose the protocol number, which  
> is then completely superfluous. (Currently its only real function is  
> to allow for ICMP responses to arbitrary packets although it is  
> widely abused in filtering.)

OK, I will bite. How can you tell a UDP packet from a TCP packet using  
only port numbers ?

Regards
Marshall

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 11 Dec 2008 16:17:55 +0100

On 11 dec 2008, at 16:12, Marshall Eubanks wrote:

> OK, I will bite. How can you tell a UDP packet from a TCP packet  
> using only port numbers ?

You don't, just like you don't know whether port 12345 runs HTTP,  
SMTP, IRC or whathever protocol. If you can find out the application  
protocol out of band, then finding out the transport protocol as well  
is not much extra work, no need to include this information in every  
packet.

---

From: "Phelan, Tom" <[email-masked]>
Date: Thu, 11 Dec 2008 10:22:14 -0500

> space programs using the protocol in question.

[Tom P] Well, you clipped the part that said over-UDP was the easiest
way, which implies that it isn't the only way.  Raw sockets are tougher
-- the application needs superuser or equivalent privileges in most
cases, and, as you said, demultiplexing can be a problem.  These
problems are often enough to stop an implementation.

---

From: james woodyatt <[email-masked]>
Date: Thu, 11 Dec 2008 09:23:25 -0800

On Dec 11, 2008, at 02:00, Iljitsch van Beijnum wrote:
> Yes, why would we demux on the 128 bits that are there in clear  
> sight, doing it on 16 others that may or may not be present  
> elsewhere in an unpredictable place makes much more sense. </sarcasm>

Are you sure the word "demux" is appropriate in your context?  It  
doesn't seem so.

> couldn't sell to those people letting through ANY unsolicited packets.

The devil, as I recall trying to make clear at the time, was in the  
precise technical meaning of the word "unsolicited" in such contexts.

Nevertheless, if we're talking [inappropriately] about marketing  
considerations, then yes, my marketing people still don't think they  
can sell CPE routers unless they filter out unsolicited inbound flows  
by default.  In response to the usual technical arguments about why  
such filters are bad bad bad, they can [and cheerfully do] point to  
IETF's best current practices as documented in RFC 4864.

Is RFC 4864 wrong?  I certainly don't have the clout to say so  
convincingly, and the people who might conceivably have such clout all  
say otherwise when they're in the same room with the decision makers.   
And, this is why my forwarding plane must be aware of transport  
protocols, and it's also why I get a little testy when IETF people who  
ought to know better tell me that it shouldn't be.  Grrr.

> I tend to agree but even I can be pragmatic from time to time.

Sometimes, a kludge is the pragmatic alternative to a prohibitively  
expensive architecture.

However, my quote comes from a context where our esteemed participant  
wearing the IAB hat expressed the view that "layering new transports  
on UDP" is not only optimally pragmatic, which is debatable, but "the  
right architecture" too.  It's going to be a lot more difficult to  
convince me of this latter proposition, but that's not really an  
important consideration, is it?  I'm not an architect.

---

From: Stuart Cheshire <[email-masked]>
Date: Thu, 11 Dec 2008 09:24:36 -0800

On 10 Dec, 2008, at 14:12, Joe Touch wrote:

> I think that demultiplexing of port numbers should be done inside  
> the end host

In my view this is (no offense intended) merely religious dogma, not  
some inherent property of good networking design. IP was designed  
that way. That doesn't make it the only way to design networking, or  
even a good way to design networking.

And, even if the demultiplexing should be done inside the end host  
(which is usually is) that doesn't mean the bits need to go somewhere  
else in the packet.

I view addressing/demultiplexing as a continuum.

Consider the address: 17.206.42.11:22

17 gets the packet to Apple
206 gets the packet to building 6
42 gets it to my floor
11 gets it to my machine
22 gets it to the sshd process running on my machine.

Why should the last element of that chain have be special, and  
fundamentally different to the preceding steps, with its data stored  
somewhere else in the packet?

AppleTalk had demultiplexing data all the way to the ultimate  
software endpoint stored in the datagram header, and in Minneapolis  
people pointed out that other protocols did too.

IP's strange design also causes problems for multicast. If a host  
joins multicast group X and listens on UDP port Y, and a sender sends  
multicast packets to X:Z, then the network's multicast infrastructure  
does all the work to deliver the packets to the host, which then  
promptly throws them away because it has no listener on UDP Z. The  
whole point of multicast is that receivers indicate their interest in  
traffic by joining groups and sending IGMP messages, so that the  
network's multicast infrastructure can deliver packets only to  
receivers that have indicated an interest. The problem is that  
receipt of a multicast packet depends on the destination address  
being X:Y, but only X is communicated in IGMP packets to the  
network's multicast infrastructure. Again, those hidden extra  
addressing/demultiplexing bits mess us up.

On 11 Dec, 2008, at 07:05, Iljitsch van Beijnum wrote:

> So your real complaint is that you can't come up with a new  
> protocol in user space but still have the kernel demultiplex.
>
> is then completely superfluous.

EXACTLY. (I.e., what AppleTalk and other protocols did.)

> using only port numbers ?

You don't. It's none of your business.

How can you tell UTF-8 from Latin-1 using only port numbers?

How can you tell sshd listening on port 123 from httpd listening on  
port 123, using only port numbers?

You don't have to. The sender sending to port 123 sends ssh-format  
data or http-format data depending on what it's connecting to. As  
long as the two peers agree on what protocol/framing/encoding they're  
using (which they have to anyway, to do anything useful) then no one  
else needs to know.

Again, this is exactly how AppleTalk worked. When listening on a port  
for incoming packets, you could either elect to get all those  
datagrams directly yourself (which would be like opening a UDP socket  
in IP programming), or you could ask the networking stack to hand  
those packets to some other library routine, like the ADSP packet  
handler (AppleTalk's equivalent of TCP). The packets don't have to  
say what the transport protocol is, because the sender and receiver  
already know.

---

From: Joe Touch <[email-masked]>
Date: Thu, 11 Dec 2008 09:35:19 -0800

Stuart Cheshire wrote:
>> I think that demultiplexing of port numbers should be done inside the
>> end host
> 
> some inherent property of good networking design. IP was designed that
> way. That doesn't make it the only way to design networking, or even a
> good way to design networking.
> 

That number has multiple meanings:

	- indicate a service
	- demuux to the service (in conjunction with the source port)

Further, that number is interpreted in the context of the transport
protocol, so really you have the following (if you really want to talk
about full demuxing):

	IPv4:10.0.0.1:TCP:22

I completely agree that this isn't the only way to design networking,
but it is how the Internet is *defined*. Let's say we define a new
system for demuxing - then we could define the boundaries in different
places, or let them be endpoint specific. Either way, as you go left to
right, presumably you get more specific (though the IP address is
written backwards if you peek inside it).

A key part of that observation is that:

	in order to understand how to demux a label, the
	receiver needs to know the context of the label

i.e., IPv4 is the context of the IP address.

TCP is the context of the port number.

That's why they *must* come in the order they do. If you want a
'metalayer' so you can demux after IP before TCP, then you need another
layer there:

	IPv4:10.0.0.1:MPL:456:TCP:22

Note that the MPL is the protocol that lets you demux and/or handshake
coordination before you get to TCP. Regardless of how this is done, note
that "22" necessarily comes after TCP. You can't simply swap the order
of the labels willy-nilly ;-)

Joe

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 11 Dec 2008 20:42:06 +0100

On 11 dec 2008, at 18:23, james woodyatt wrote:

>>> sure I believe that NAT66 will require port multiplexing (though,  
>>> I think it might).

> Are you sure the word "demux" is appropriate in your context?  It  

On rereading it does look a bit strange, but what I mean is demux  
incoming packets that are the responses to outgoing NATed packets back  
to the sources of those original packets.

With NAT44 this happens on the port numbers, but with NAT66 there are  
two additional reasons that this isn't necessary/desirable apaort from  
the reasons that are also true in IPv4: it's not necessary because  
there are enough IPv6 addresses, and finding the port numbers is  
harder because they don't occur at a fixed place in the packet.

> convincingly, and the people who might conceivably have such clout  
> all say otherwise when they're in the same room with the decision  
> makers.  And, this is why my forwarding plane must be aware of  
> transport protocols, and it's also why I get a little testy when  
> IETF people who ought to know better tell me that it shouldn't be.   
> Grrr.

I guess we lost as far as TCP and UDP are concerned. Maybe we can  
sneak in allowing other protocols based on addresses and the protocol  
number without looking at ports, if any.

> However, my quote comes from a context where our esteemed  
> participant wearing the IAB hat expressed the view that "layering  
> new transports on UDP" is not only optimally pragmatic, which is  
> debatable, but "the right architecture" too.  It's going to be a lot  
> more difficult to convince me of this latter proposition, but that's  
> not really an important consideration, is it?  I'm not an architect.

Well when we create a new transport we can have the UDP fight again.  
But for the existing ones, running them on top of UDP creates as many  
problems as it solves, while making firewalls aware of them is  
certainly doable without creating new issues. And apparently you can  
even NAT SCTP and DCCP...

---

From: Bryan Ford <[email-masked]>
Date: Sun, 14 Dec 2008 21:30:54 +0100

On Dec 8, 2008, at 1:56 PM, Lloyd Wood wrote:
> I'm interested in a parseable way to pass that information down from  
> a URI and the program handling the URI.
>
> presumed to live over TCP, and IP - whether to use v4 or v6 is  
> usually determined directly by giving an address or by DNS. But,  
> oddly enough, we can also explicitly specify the port number, which  
> defaults to 80. So, even though http lives on port 80 (and https on  
> 443), that can be overridden in the URI.
>
> explicitly override it in the URI if desired has merit in some  
> cases. That is, 'http' would be the same as writing 'http-tcp'.  
> 'http-sctp', for the work outlined in:

I don't think transport protocol names belong in URLs, because  
transports are ultimately just tools that application protocols use to  
get stuff from point A to point B; the user doesn't usually and  
shouldn't have to care which tools the application uses to get its job  
done.  Why should the user care whether his web browser is downloading  
his web page via HTTP-over-TCP or HTTP-over-SCTP?  If the point of  
using SCTP is that it makes the parallel HTTP transfers go faster,  
then the behavior you want is that the client and server use SCTP  
whenever both client and server support it, and fall back to TCP  
otherwise.  That behavior should be completely transparent to the end  
user - just like the negotiation of HTTP 1.0 versus HTTP 1.1 is - and  
should have no bearing on what an object is named.  If you start  
encoding SCTP into URLs in web pages, then (as Iljitsch pointed out)  
things quickly start breaking as soon as the "http-over-sctp" URL  
reaches a client that doesn't support SCTP.

While I'm not sure I would necessarly defend the "http" versus "https"  
distinction on architectural grounds, at least that distinction does  
have a direct bearing on the user - i.e., users often do care whether  
they're accessing a particular web site over a "secure" connection or  
not, and the "https" gives them a nice bit of warm fuzzy reassurance  
that they are.  We might have already outgrown this approach, however,  
given that modern web browsers now much more loudly proclaim the  
secure/insecure status of web connections by changing the color of the  
URL bar and adding other fancy ornamentation; they could certainly  
still do those other things to tell the user whether the connection is  
secure or not, even if HTTP and HTTP-over-TLS actually shared the same  
URL scheme name and just negotiated security purely dynamically.

> Doesn't it strike you as odd that we can, at a high uri level,  
> specify the low-level port number, but not the details of the  
> layering to be used for that port? By adding explicit detail in the  
> URI, we are removing ambiguity.

This fact makes perverse sense when we keep in mind the historical  
reality that, as Joe Touch pointed out, the "http" scheme always in  
practice meant specifically "HTTP-(over-no-TLS-because-TLS-wasn't- 
there-yet)-over-TCP" - then it's clear what the port number means.   
But that doesn't mean we necessarily have to accept this state of  
affairs as the architectural Ten Commandments to apply for all time.   
If we try to move forward toward an architectural viewpoint where the  
"http:" scheme name means "HTTP-over-some-unknown-dynamically- 
negotiated-protocol-stack", it indeed becomes a little less obvious  
what exactly the attached "port number" field should mean.   But we  
could envision generalizing it to be a transport-independent "service  
number" of some kind - or even, dare I say, a "service name"?

Cheers,
Bryan

---

From: Bryan Ford <[email-masked]>
Date: Sun, 14 Dec 2008 22:20:45 +0100

On Dec 10, 2008, at 1:34 AM, Joe Touch wrote:
>>> header

I really like the generic "recursive building block" approach you seem  
to be proposing, at least as far as it can be reasonably pushed - how  
far that is, is not entirely clear yet at least to me.  (In general,  
I'm a big fan of "recursive" just-about-anything; see for example my  
work on microkernels and recursive virtual machines, (recursive) CPU  
inheritance scheduling, and "structured" (read: recursive) streams. :) )

But as I see it, using a single, configurable metaprotocol to stamp  
out implementations of all of the specific layers we need in practice,  
is an implementation strategy: a particular approach to implementing  
those layer instances we decide we need - though perhaps a  
particularly good approach.  We still at some point need to figure out  
what specific layer instances we need for a given purpose at a given  
point in time, given the properties and constraints of the network and  
the demands of applications.  Our "logjam" paper's focus is on  
identifying what specific layer instances we need with what (minimum)  
bits of functionality at each layer, not on how those bits of  
functionality are implemented.  If for implementation purposes we can  
instantiate a single metaprotocol in different configurations to  
produce the Endpoint, Flow, and Semantic layers, then I'd be extremely  
happy.

I feel like we're just blind men feeling different parts of the same  
elephant.

Cheers,
Bryan

---

From: Bryan Ford <[email-masked]>
Date: Sun, 14 Dec 2008 22:54:00 +0100

On Dec 10, 2008, at 8:45 PM, james woodyatt wrote:
> transports on UDP" is a kludge.  There's a lot of "transportly  
> stuff" that needs to be negotiated on a node-to-node basis, and only  
> sometimes (not always) on a user-endpoint-to-user-endpoint basis,  
> e.g. congestion avoidance, mobility, etc.

If full endpoint identification is available in some packet header  
(e.g., an Endpoint Layer header) that is below and independent of any  
transport semantics-specific header, then you can still negotiate  
whatever "transporty stuff" you want to either on a node-to-node or  
endpoint-to-endpoint basis, as desired.  All the information is there;  
it's your choice how to use it.  If you want to store state or  
negotiate something at a granularity coarser than individual  
endpoints, then just mask off the low bits of the endpoint address -  
e.g., those "low bits" that happen to represent the port number - much  
the same way as IP routers mask off the low bits of an IP address to  
match routing table entries that have a granularity coarser than a  
single host.

But if all the endpoint information _isn't_ there in a generic header,  
as it isn't in the current world, then anything in the middle of the  
network that need to the endpoint-granularity information is always  
forced to dig into the transport-specific part of the headers.  That's  
where the problem lies, and that's why I think the architecture needs  
to be defined in such a way that full endpoint-to-endpoint information  
is at least _available_ in a generic form, regardless of whether and  
in what way that information is used (e.g., how many address bits get  
used to index into a particular state table).

Speaking of host versus endpoint granularity, can you point out some  
specific examples of "transporty stuff" that you think really needs to  
be negotiated at a host granularity rather than an endpoint  
granularity?  The whole notion of "host granularity" is a pretty  
slippery concept in the Internet as it stands, and I've been wondering  
lately just how well _any_ mechanism that makes assumptions about what  
"host granularity" is will hold up as the Internet evolves...

I actually wrote a short response to Dave Thaler and the IAB about  
Dave's IETF plenary talk, on precisely this topic.  Here's a repost,  
FWIW...

---

Hi Dave,

I highly enjoyed your presentation in the plenary and very much  
appreciate the IAB's work on the IP model evolution document.  I would  
like to suggest for your and the IAB's consideration another  
traditional assumption that I believe is important, often and  
increasingly untrue, and not yet covered in the document.  (Also, can  
you suggest the most appropriate mailing list for me to post this  
message to for public discussion?)

Assumption:  Hosts/nodes are atomic entities reliably distinguishable  
from networks in the Internet's taxonomy.

This "host atomicity" or "host granularity" assumption pervades the  
design of many basic Internet protocols, the most important being the  
use of different mechanisms for "inter-host routing" (IP addresses and  
layer 2 routing) versus "intra-host routing" (transport layer port  
numbers).  While it may have been true at first that a "host" always  
corresponded directly to a physical machine, this correspondence has  
progressively eroded as the Internet has grown due to scaling and  
network management challenges.

For example, DHCP was designed to give each client "host" one and only  
one IP address.  ISPs readily adopted DHCP because it eliminated the  
need for their home users to enter IP addresses manually, but as soon  
as home users started wanting to attach multiple physical hosts to the  
same ISP uplink, the fact that each host only gets one IP address  
created an artifical IP address space shortage for "hosts"  
representing a private home network: the DHCP-configured gateway  
"host" can't hand out global IP addresses to the private network if it  
wasn't given any addresses other than one for itself.  This artificial  
IP address space shortage was probably instrumental in fueling NAT  
deployment long before any "real" IPv4 address shortage set in.   
Similarly, even within a single physical host, it is increasingly  
common for users to run multiple virtual machines within that host via  
software such as VMware; the Internet architecture's assumption that  
the "outer" (physical) host is an atomic entity again makes it  
difficult for the "inner" (virtual) hosts to obtain usable addresses  
without the use of NAT (or difficult and fragile layer 2 bridging  
hacks).  Although DNS is a little better in this fashion in that  
domain names are in theory arbitrarily composable - if a physical host  
is named "foo.bar" then there could be virtual hosts "a.foo.bar",  
"b.foo.bar", etc. - its current design does not make it easy for hosts  
to take advantage of this theoretical composability without lots of  
manual setup (e.g., a Dynamic DNS mechanism by which the host can  
install virtual "sub-host" records into its authoritative DNS server's  
database).

There are other examples of issues resulting from this decreasingly- 
true "host atomicity" assumption.  SCTP assumes that the redundant  
transport endpoints of a multihomed "host" differ only in IP address  
and not in port number, making it impossible for NATs to support SCTP  
in the traditional way (see draft-ietf-behave-sctpnat).  This  
difficulty could have been avoided easily in the design of SCTP simply  
by treating all the redundant transport endpoints as completely  
independent (IP address, port number) pairs, effectively removing any  
dependence on the granularity of a "host."  RTP/RTCP similarly assumes  
traditionally that a single host (IP address) has complete control  
over a given port space ("intra-host address") and can easily and  
deterministically allocate two consecutive UDP port numbers to the  
same application, an assumption that has similarly proven troublesome.

If I was to suggest some form of concrete guidance regarding this  
assumption, it would be that we look very, very closely at any part of  
a protocol design that seems to depend on "host granularity" in some  
way, and see if that dependency can easily be avoided.  For example,  
in any protocol above IP, if a message carries an IP address but not a  
corresponding port number, we need to look very closely at why it does  
not need to carry an associated port number (i.e., a complete endpoint  
as a single information unit), and whether any assumption the protocol  
is thereby making about "host granularity" is really valid given the  
reality of today's Internet.  Similarly, for any protocol message that  
carries a port number but no corresponding IP address for some reason  
(or the IP address is conveyed elsewhere or in a different fashion and  
associated later), we need to look very closely at why these pieces of  
information are separated and how that might affect or limit the  
protocol.  Finally, if a protocol for some reason thinks it needs to  
talk about a an aggregated multiplicity of endpoints - e.g., "all the  
ports at a given IP address" - we need to think very carefully about  
why, given the fuzziness of "host granularity" in today's networks,  
the protocol should not in fact also be able to talk about arbitrary  
subnet prefixes (i.e., a range of host IP addresses with all their  
respective ports), and/or be able to talk about smaller "port ranges"  
within one particular IP address (as various DHCP and IPv4-to-v6  
extensions currently being debated increasingly do).

Thanks,
Bryan

---

From: <[email-masked]>
Date: Mon, 15 Dec 2008 15:11:59 -0000

Bryan,

I've written up
http://www.ietf.org/internet-drafts/draft-wood-tae-specifying-uri-transports-00.txt
which should answer your "why should the user care?" question below.

cheers,

L.

<http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

-----Original Message-----
From: Bryan Ford [mailto:[email-masked]]
Sent: Sun 2008-12-14 20:30
To: Wood L Dr (Electronic Eng)
Cc: Joe Touch; [email-masked]; [email-masked]
Subject: Re: [tae] [tsv-area] Transport negotiation

Cheers,
Bryan

---

From: Joe Touch <[email-masked]>
Date: Mon, 15 Dec 2008 19:55:39 -0800

Bryan Ford wrote:
...
> far that is, is not entirely clear yet at least to me.  (In general, I'm
> a big fan of "recursive" just-about-anything; see for example my work on
> microkernels and recursive virtual machines, (recursive) CPU inheritance
> scheduling, and "structured" (read: recursive) streams. :) )
> 
> But as I see it, using a single, configurable metaprotocol to stamp out
> implementations of all of the specific layers we need in practice, is an
> implementation strategy: a particular approach to implementing those
> layer instances we decide we need - though perhaps a particularly good
> approach.  We still at some point need to figure out what specific layer
> instances we need for a given purpose at a given point in time, given
> the properties and constraints of the network and the demands of
> applications. Our "logjam" paper's focus is on identifying what
> specific layer instances we need with what (minimum) bits of
> functionality at each layer, not on how those bits of functionality are
> implemented.  If for implementation purposes we can instantiate a single
> metaprotocol in different configurations to produce the Endpoint, Flow,
> and Semantic layers, then I'd be extremely happy.

The purpose of RNA is to recognize that any function can be useful at
any - or every - layer, regardless of implementation. Yes, there's a
distinct problem of deciding what version of a function is useful at a
given layer - some of which depends on the functions required at the
upper layer, some of which depends on the scope of the layer, and some
depend on what's feasible at the lower layers. There are other groups
working on this part of that problem.

This presumes, however, that the uppermost layer "knows what it wants",
but it allows the binding of which layer solves a given function to vary
dynamically as needed. A function is bound to a variation and a layer
only as needed.

That means that you don't say "HTTP over TCP over IP" or "HTTP over SCTP
over IP"; you say "HTTP over reliable, inorder delivery" and let the
next layer down figure out what that means. AFAICT this is consistent
with what you want to do - but maybe your examples describe how to do it??

Joe