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
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
