Hi, On 2010/01/19, at 10:26, Brian E Carpenter wrote:
> Rémi, > > On 2010-01-19 01:46, Rémi Denis-Courmont wrote: >> On Fri, 15 Jan 2010 20:13:16 +0900, Arifumi Matsumoto <[email protected]> >> wrote: >>> * Fred's proposal. >>> - A host tries each pair of src and dst addresses to establish >>> a connection in a short time period. >>> - A host can make use of ICMP error messages indicating that the >>> src address should be this, or the src address is simply wrong. >>> - A host can have cache for the reachability status, which stores >>> which src and dst pair should be used to reach a certain dst. >> >> This is awfully complicated. It might be implemented properly in some >> high-profile apps, but it will be implemented incorrectly in many apps, and >> it won't be implemented at all in others. > > It really doesn't belong in apps at all. It belongs in a shim common > to all transports. I would suggest giving serious consideration > to modifying the spec for the REAP component of SHIM6, which incidentally > doesn't rely on ICMP transparency. We can implement this try-and-error approach mechanism in several ways, and each of them has its own benefits and limitations. And as Brian suggested, we can learn from the past/ongoing activity like Windows APIs, SHIM6 and mptcp. > However, it seems evident to me that we have to both make > site-wide 3484 policy distribution work, and make rapid trial-and-error > work. Neither one alone meets the need. Same here. Kindest regards, > To this day, there are still >> applications that won't even try to fall-back from IPv6 to IPv4. Also, as >> you mention, this simply doesn't fly for connection-less protocols. So >> IMHO, source address selection should be hidden from apps into the >> operating system as much as possible. >> >> That of course does not preclude writing advices for robust applications on >> what intelligent things they can and can *not* do. That could definitely >> include trying all potential pairs in parallel instead of trying them >> sequentially, if the application-layer protocol would handle it properly >> anyway. >> > -- Arifumi Matsumoto Secure Communication Project NTT Information Sharing Platform Laboratories E-mail: [email protected] -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
