Hi, * Arifumi Matsumoto
> But, your suggestion of Rule 4.5 does more than de-prioritization > of 6to4 prefix. It de-prioritizes 6to4 _routers_ - rule 6 is taking care of de-prioritizing the 6to4 prefix. All put together, this ensures the source address selection algorithm selects an address with a label that matches the destination (if available), and that the next-hop is appropriate for the selected next-hop. We do agree that getting the source and destination labels to match is a good thing, right? (For what it's worth, rule 6 already codifies it.) At least I have a hard time picturing a scenario where you would want to use non-matching labels if matching labels are available. As an added bonus, when Teredo and other non-native forms of connectivity is added to the policy table with different labels than native, you get the same de-prioritizing effect for them as well. > Great. I really appreciate we could have good discussion here. Likewise! :-) > Can I have your opinion about other remaining issues of this item ? > Such as The longest match rule in section B.4 ? Certainly: B.1: No strong opinion either way. B.2: We should go to great lengths to ensure that IPv4 (and native IPv6) is prioritized above transitional IPv6 like Teredo and especially 6to4. Overuse of transitional IPv6 is causing lots of problems and is _the_ reason why there's essentially no IPv6 content generally available on the internet today. There are three proposed changes that together accomplish this goal. In order of importance (in my opinion): 1) Changing RFC 1918 address scope to global: prevents transitional IPv6 from being used in preference to (NAT-ed) IPv4. 2) Your rule 5.5: prevents transitional IPv6 from being used in preference to IPv4 or native IPv6 in dual-stack situations. 3) My rule 4.5: prevents transitional IPv6 from being used in preference to native IPv6 in single-stack situations. B.3: IMHO, IPv6 isn't deployed enough that we need to go to great lengths to maintain backwards compatibility with outdated implementations. So I'd remove the outdated cruft. But I don't feel very strongly about it. B.4: My personal opinion of the longest match rule is that it should be scrapped. IPv6 isn't hierarchical anymore and the DNS round robin technique is as useful in IPv6 as in IPv4 - it's something worth not breaking. I can't say I like the idea of applying a limit on how many bits you will compare either as that's basically just making a guess on how operators will structure their networks. I suspect that providers that are interested in the functionality the longest match rule attempts to provide, will instead be using some kind of split-horizon DNS solution. 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 --------------------------------------------------------------------
