Hello again, * Arifumi Matsumoto
> Correct. But, I think the latter case is less problematic, in that > it avoids avoidable troubles. Agreed. While it does not avoid all potential troubles, it does seem likely that it will cause less problems overall than the current algorithm. > IMO, it's a matter of local network policy whether fe80::bad is > really good or bad. RFC 3484 with the default policy table already considers 6to4 source addresses worse than native addresses. I don't think it is controversial to similarly consider 6to4 routers as worse than native routers by default. Besides, a large majority of the 6to4 routers on the internet today are indeed unwanted and cause very bad results for people like me that want to deploy IPv6 services in a reliable manner. > 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. I can see that. There's in my opinion a clear benefit to making sure that both 1) the best available source address is selected, and 2) the next-hop used is appropriate for the source address used. (Your new rule sacrifices #1 to achieve #2 the way I see it.) Since next-hop selection is so tightly coupled with source address selection I think it makes lots of sense to handle both in RFC 3484. >> 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. Good. I support adding your new rule. It's a step forward compared to RFC 3484, even though it doesn't get us all the way. And it won't prevent us from adding the final piece of the puzzle (i.e. next-hop selection logic) later. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
