In your letter dated Wed, 2 Jun 2010 13:30:40 +0900 you wrote: >I think it is chicken-and-egg. >Right now, the multi-prefix does not work nicely because of the >lacking mechanisms documented in this draft. And IMO, those people >will lead to invention of NAT for IPv6.
In Section 4.2 "Next-hop selection", the draft says: "Scenario 1: "Host" needs to support the solution for this problem" This is not quite true. I'm running some code at home where when the host selects a source address and uses a next hop that is incompatible with the prefix, the router will send a redirect to the right router. Routers use an extension to RIPng to inform each other about source prefixes, and which routers support them. (For optimal performance, the host's destination cache should be changed, but it also works with stock IPv6 stacks). This solves that case where you have redundant connections through differnt ISPs. I didn't experiment with this yet, but I assume that longest prefix matching in source address select may even provide a primitive kind of load balancing. I guess that in a walled guarden, if the source prefix is within the same (shorter) prefix as all destinations, then this may also solve that problem. -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
