Hi William,
If you're feeling ambitious, change "two" to "many" and modify TCP so that during the SYN+SYN/ACK, both sides can exchange cryptographically signed connection IDs. The presence of these two IDs with a correct signature identifies subsequent packets associated with the connection, regardless of the source and destination addresses.
Interesting. This sounds pretty much like HIP base exchange...
Any such "TCP" packets can also contain an "address update" option which offers the other side a fresh list of addresses at which it can be reached as well as hints about priority and load balancing.
... and this like HIP mobility & multi-homing.
Among other nifty things, this would allow you to completely dispense with the source port. If you wanted to, you could also change the destination port to a destination service name, since it need only appear in the original SYN packet.
And this somewhat (but not quite) like id delegation in HIP.
I suppose if you want to retain backwards compatibility, you would at least include the source and destination port numbers in the SYN packet and drop them later if the options returned in the SYN/ACK agreed to use your new TCP.
And this like the hack (so far unspecified) to carry HIP I1 as TCP options.
If you're feeling *really* ambitious, exchange the hostname during the connection setup as well so that if all the connection's IP addresses change while the connection is idle, the next transmitter can find the other side by refreshing the address list with a DNS lookup. Require the DNS server to allow it's clients to update their hostname's list of IP addresses.
If you replace DNS with a rendezvous server, your hit again at HIP :-) <snip>
If you do all of these and then succeed in deprecating old-style source port/dest port connections, this has some interesting implications for route aggregation. You'll find it becomes possible to create a fully automatic system to resize and reassign IP addresses at need which in turn allows the Internet as a whole to automatically achieve something near the optimum achievable aggregation through the kind of "emergent behavior" you talk about.
That was realised in the HIP community some 6-7 years ago, and I guess in the Nimrod and some other communities even earlier.
Say, that's pretty neat. I had considered most of these ideas before, but it didn't occur to me to use a TCP protocol addition as the starting point so that deployment could be incremental and fully backwards compatible. If you don't write something up, maybe I will.
The biggest differences between your thinking and HIP seems to be that HIP is implemented below TCP, so that it works also for UDP. I think it matches better with the IP semantics, as a single IP address is (today) typically associated with a number of co-located TCP and UDP end-points.
Then there is also work specific to TCP, e.g Christian Huitema's eTCP (or whatever it was called).
I'm glad to see that more people come to the roughly same conclusions, independently. :-)
--Pekka Nikander -- to unsubscribe send a message to [EMAIL PROTECTED] with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
