Re: Transport multihoming

[Manuel Urueña Pascual <muruenya@it.uc3m.es>]

Hi,

I've been working in a protocol that seems very close to your reasoning.
Not really a new approach but catching some good ideas from SCTP and
Mobile-IP to exchange dynamic/multiple addresses between end-hosts with
legacy transport protocols.

http://www.it.uc3m.es/muruenya/draft-muruenya-epcp-00.txt

I think it may be applicable to the multihoming problem, but I'm seeking
some feedback from the MH people.

Thanks,
--Manuel

PD: I'm still trying to catch the mailing-list so maybe I've missed
something.

Peter Tattam wrote:
> As discussed at the Tokyo meeting, there are limitations in the TCP header size
> which may preclude this being done there.  Having it at the IP layer kind of
> makes sense, and having the gleaned information cached beyond the life of
> connections not only benefits multiple connections to the same host but should
> also aid connectionless protocols as well.
> 
> At Tokyo, I think Steve Deering made a suggestion that we make this an IP layer
> feature available to all protocols but it was so fresh in my mind that I had
> not thought through all the possibilities.
> 
> So my latest thought would be that we could do it at the IP layer in a similar
> way to that described in my preliminary draft.  
> 
> For TCP connections, the prefix/address set negotiation be done at syn/ack
> time, and for any other protocols that have the same syn/ack semantics. 
> 
> For connectionless protocols, the IP layer would need to rely on cached state
> to do its thing.  In such a scenario, it may be important to set an upper time
> limit on the cached information being valid, the information being updated by
> incoming traffic.  A nonce for the negotiation would have to be supplied by
> both ends in this case.
> 
> If a nonce were to be added to the IP MH options, this could be made larger
> than the TCP sequence number thereby increasing the security from seq number
> attacks.
> 
> Another possibility is that we define a MH connection protocol which
> establishes the MH characteristics of the connection between the two hosts. It
> would be analogous to a TCP session and would have the same degree of security
> as a TCP session.  It could be done directly at the IP layer or be an
> ancilliary protocol on top of IP.  It would imply that there would be host-host
> state information kept somewhere in the IP stack, but it is possible that this
> could distributed amongst the control blocks associated with each connection.