Hi, all. I'd like to start revision of RFC3484, because everybody knows it has some defects and I think this issue of address selection at end hosts is very important.
The points that I want to include in the revision of RFC3484 are follows: Essential points, * to remove site-local unicast address related statements. RFC3484 contains a few "site-local unicast" description. It's better to remove examples related to site-local unicast address, or change examples to use ULA. * to update default rule. The default rule today is: Prefix Precedence Label ::1/128 50 0 ::/0 40 1 2002::/16 30 2 ::/96 20 3 ::ffff:0:0/96 10 4 What we should consider now is, - IPv4-compatible IPv6 address is deprecated.(RFC4291) - Teredo is defined. (RFC4380) Teredo should have less priority than 6to4 and IPv4 considering its communication overhead and reliability ? Also, this value below conforms to Windows. - ULA should have less precedence than IPv4. As brought up by Pekka Savola, ULA is a possible cause of connection failure. It gets worse, as IPv6 deployment proceeds and more FQDNs have both A and AAAA records. As a few people already pointed out, I guess it's not so easy to solve the Pekka's ULA and IPv4 trouble other than to change policy table. While the problems caused by prioritizing ULA lower than IPv4 seem to be relatively easily solved. For example, by removing A record, using DNS zone-split, like that. Prefix Precedence Label ::1/128 50 0 ::/0 40 1 2002::/16 30 2 ::ffff:0:0/96 10 3 fc00::/7 8 4 2001::/32 5 5 Not essential but helpful, * To add ULA related considerations if any. For example, we have to pay attention to source address selection for a multicast packet. By default, ULA will be chosen for a multicast packet of any scope. * To define data type and length of each item in policy table hopefully. Though this issue maybe trivial, if a site administrator wants to set some policies to every hosts in his site and his site has every kind of operating systems, it causes difficulties for him to determine the site-wide policies. Also it has bad effects even for normal users when they try to set-up the policies that are putted on a how-to web-page for another operating system. Though these aren't direct interoperability issues, these indirect interoperability issues seems not negligible. * to add temporary address selection rule for policy table. As you know, temporary address has good and bad points. it's good to view web-pages or communicate with general public. it's bad for such a service that based on address based authentication. It's better if you can control on/off of temporary address. It's much better if you can control which address to use for which service. IMHO, Policy Table is the best place to implement this additional function. Prefix Precedence Label Temporary 2001:db8:/16 40 1 off ::/0 20 2 on In this simple case, you use temporary address for every site other than your corporate network(2001:db8::/16). You don't have to change the existing RFC3484 source address selection rules drastically, because temporary address related rules have less priority than policy table related rules. Any comments are welcome. Best regards, -- Arifumi Matsumoto Ubiquitous Computing Project NTT Information Sharing Platform Laboratories E-mail: [EMAIL PROTECTED] -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------