Re: stable addressing

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

A "talk first, negotiate later" approach to multiaddress multihoming 
has important advantages, as it allows seamless backward compatibility. 
A weak point of this type of approach is that it doesn't lend itself to 
easy implementation in a middlebox, as compatibility with existing 
transports requires all possible addresses to be available on the 
multihomed host, and it possibly even requires cooperation from 
applications.

However, if we were to add a new "fool the transport" address, this 
problem would largely go away. The idea is that multihomed hosts would 
have stable addresses (presumably unique site locals). For incoming 
sessions, the stable address is advertised in the DNS as a new RR. The 
correspondent looks up both the stable address and the set of regular 
addresses, and proceeds to set up a transport session towards one of 
the regular addresses as per NOID et al. However, the transport 
protocol acts as if the session is towards the remote stable address. 
The middlebox at the receiving site terminates all multihoming 
negotitation. It also maps back and forth between any of the regular 
addresses and the stable address, with the result that the receiving 
host can just use its stable address without being aware of multihoming 
issues.

For outgoing sessions, the multihoming middlebox intercepts DNS 
requests by internal hosts. Rather than just send the AAAA records to 
the requesting hosts, it replies with an AAAA record that contains the 
"fool the transport" address for the remote host, and keeps an 
FTT->AAAA mapping in memory. Then, when the internal host tries to set 
up a session towards the remote FTT address, the middlebox performs the 
necessary multihoming negotiation with the host sitting at the AAAA 
address(es) associated with the FTT address in question and then 
proceeds to rewrite addresses as per the combined FTT->AAAA and 
multihoming state.

Since the FTT address only replaces the locator/identifier at the 
transport level, applications still get to see the addresses that are 
published as AAAA records, so security assumptions aren't broken. That 
is, unless a middlebox is used, but in that case presumably the 
middlebox will handle any address-based security as well as 
multihoming. Since FTT addresses aren't really visible anywhere, there 
is little to no need to authenticate them.

Note that this approach also allows for easier source address rewriting 
by routers.

Two problems remain: interaction between multihomed hosts behind a 
middlebox and legacy IPv6 hosts, and referrals. And one thing to think 
about: making the negotiation protocols such that two or more 
middleboxes can come to the same results independently, so they can 
provide failover for eachother without having to synchronize state 
between them.