To summarise, read:
http://www.ietf.org/internet-drafts/draft-ohta-multi6-8plus8-00.txt
which describes a end2end scalable 8+8 id/loc proposal, a lot different from Mike O'dell's version of 8+8.
Also, since the transport is maintaining per path information, it is in
the best decision to decide which path to use.
*nod*.
Correctly speaking, the transport or the application layer is the only place to decide which pasth to use, since the IP layer can not maintain timeout.
Attempt to imitate it by IP layer results in NAT, where connection will be terminated if there is no packets flow for a timeout period incorrectly guessed by the IP layer. At the upper layers, it is often perfectly leagal if there is no traffic for 1 hour over a live connection. But, NAT behaves badly for such connections.
It is the main reason why multi addressing is the only architectural possibility to do a scalable MH. The problem with
the remaining solutions (at shim/new identity/network layer) is that they hide the redundancy factor (multiple address -MA) from
the users. Given the current state (failures, misconfigurations
and rate limitations,) e2e check (by measurements) is the only option to check path availability. The MA feature gives user a chance to make a choice based on e2e reachability checks.
Right.
I dont know why people get suprised by explicit announcement of MA. we have been doing this kind of explicit announcement both in DNS ( multiple NX records) and SMTP ( multiple MX records.) So, in a way SMTP reliability is due to explicit announcement of multiple MX records.
That is an argument I made several years ago.
id/loc split proposals are cool. But, without modifying the routing
architecture, they can never provide a e2e reliability or explicit user control feature.
Wrong.
8+8 addressing (ID locator separation) works just fine to support multiple addresses of a host. Note that Mike O'dell made a poor proposal of an 8+8 variant does not mean others does not work.
With 8+8 addressing, IP layer needs no modification and routing architecture works as is.
With 8+8 addressing, all the addresses are passed to the upper layers and controlled there.
Because IPv6 addressing space was designed to leave a group bit of 8 byte MAC for 8+8 addressing, transport layers, including TCP, can check the bit to see whethere a host support end to end multihoming.
That is, API of TCP with 8+8 addressing needs no modificaiton and the existing code, including Mozilla, works as is without even a line of modificaiton.
OTOH, I don't forsee any routing change at *architectural* level in the near future.
It is time to think on why id/loc split proposals without routing architecture change kill the e2e control/reliability options and are architecturally incomplete.
There has been a lot of 8+8 id/loc split proposal, most of which does not change routing architecture.
It is granted that Mike O'dell's GSE was a poor id/loc proposal.
But, it is a problem of GSE, not 8+8 nor id/loc separation.
So, it is clear that a combination/subset of host-centric MH, transport MA and BGP MH (if there exists a solution which doesn't bloat routing table) is the ONLY possibility to do a scalable MHv6.
Read:
http://www.ietf.org/internet-drafts/draft-ohta-multi6-8plus8-00.txt
though it does not use BGP in a way you might be thinking, which is why it does not bloat the routing table.
Masataka Ohta