rewriting draft, next round

[Iljitsch van Beijnum <iljitsch@muada.com>]

Ok, I've written some text for the draft based on GSE/8+8 I was talking 
about. For anyone interested in following my progress:

http://www.muada.com/drafts/draft-van-beijnum-multi-rewrite-00.txt

(Please no spelling or style comments just yet, this is work in 
progress.)

I've done away with the 64 bits + 64 bits thing on the grounds that it 
is insecure and breaks transport protocols and autoconfiguation. 
Instead, there is a mapping between the identifier address and the 
locator addresses and back, so the locators essentially retain the 
identifying function.

Next order of business: the mapping function. I'm thinking:

- use a simple packet format with information that announces 
capabilities and preferences (not specifying the format, though: too 
much detail at this stage)
- both hosts should then be able to determine from their own 
information and that of the correspondent how they're going to 
communicate without the need for additional round trips (similar to TCP 
options in the SYN packets)
- getting this mapping mechanism exactly right the first time is going 
to be close to impossible and take a lot of time, so why even try, but 
rather: do something simple now but provide hooks for upgrading later
- so each host must support:
  1. doing this inband in an IP option in the first packet for a session
  2. find this information in the DNS
  3. request the information from some central host that presumably 
implements a smarter mapping discovery/negotiation mechanism

I'm also considering a "delayed negotation" mechanism where hosts only 
use an IP or TCP option to deliver a cookie that makes it possible to 
negotiate multihoming later when it turns out that the session is 
long-lived. (We do NOT want to go through all of this for each 
individual TCP session towards a webserver.)

Comments welcome.

Iljitsch