Hi Tore, On 2010/11/07, at 19:56, Tore Anderson wrote:
> * Arifumi Matsumoto > >> As I said, prioritization between IPv4 and IPv6 is a matter of >> destination address selection, which my suggestion does not have any >> effect on. Usually, native IPv6 is preferred over IPv4 in a >> environment that you assume here. >> >> In a situation where IPv6 is preferred over IPv4, my suggestion makes >> the 6to4 address will be chosen for the 6to4 next-hop, and native >> IPv6 address will be chosen for the native IPv6 next-hop. That's >> all. > > Hi again, > > upon re-reading 3484 I agree I'm mistaken in thinking this will have any > effect on IPv4 vs IPv6 being used. My apologies. No problem. I'm really glad that you got what I meant. > > There's one situation that I'm still not entirely sure about though. > Imagine a host with two IPv6 addresses (and only one network interface): > > SA) 2002:f00::1/64 > SB) 2001:db8::1/64 > > It has two default routes, same RA router preference, next-hops are: > > R1) fe80::bad <-- a 6to4 rogue router, assigned us SA > R2) fe80::1 <-- a "proper" router, assigned us SB > > The destination address D is a native IPv6 address - say > 2001:db8:1234::1. Single-stack IPv6 only so the destination address > selection doesn't come into play. > > My understanding of the current RFC 3484 source address selection, rule > 5 would be a tie (as there's only one interface on the host), and rule 6 > would ensure SB would be the chosen as Label(SB) = Label(D). > > However, this does not in any way preclude the host from transmitting > the packet (with src=2001:db8::1 and dst=2001:db8:1234::1) to R1, the > 6to4 router. That will break. I have recent real-world experience > where it seems very likely that this is the cause of a large amount of > dualstack brokenness. (See the ipv6-ops mailing list in case you're > interested in that story.) > > Your proposal, the way I understand it, will add a rule 5.5 that would > ensure that in the above case, since the next-hop used is R1, the > selected source address is SA. That means preferring 6to4 to native > IPv6, something which will also break. > > Please let me know if I've misunderstood something here. Correct. But, I think the latter case is less problematic, in that it avoids avoidable troubles. IMO, it's a matter of local network policy whether fe80::bad is really good or bad. > Note that I'm not saying that the new rule makes the algorithm any worse > than it already is. I just think it could go further; I would like to > see the algorithm ensure that both SB and R2 are selected. Since we're > already revising RFC 3484 anyway, it would be a shame to not use the > opportunity to also fix this properly, in my opinion. > > Perhaps something along the lines of (note: in addition to your rule > 5.5, not replacing it): > > Rule 4.5: Avoid next-hops that have assigned candidate source > addresses whose labels do not match Label(D). > > But perhaps interfering with next-hop selection is outside the scope of > RFC 3484? Thank you for providing a constructive suggestion. As you mention it, I think the simplicity came from modularization of destination address selection, route (next-hop) selection, and source address selection, brings much benefits to implementing and understanding the protocol stack. So, if you break it, we really have to be careful about its benefits and side effects. > BTW: With your new rule active, and if the destination in my example > situation above is dual-stacked, do I understand correctly that if the > selected source address for the IPv6 destination address ends up being > the 6to4 one (SA, in my example above), then IPv4 will be preferred, > thanks to rule 5 of the destination address selection algorithm? > > If that is the case would be a great help with dual-stack brokenness. > Even though preferring IPv4 where native IPv6 is available isn't > optimal, it's much better than accidentally preferring 6to4 (either > source address or next-hop) to, well, pretty much anything else. I think it is correct, as far as the IPv4 address is global, or IPv4 private address scope is changed to global as proposed in my draft. And, I think this should be a reasonable compromise for this specific case. Best regards, Arifumi Matsumoto -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
