Hi,
thank you for your reply.
Stig Venaas wrote:
Rémi Denis-Courmont wrote:
Hello,
Le Lundi 29 Mai 2006 13:23, Arifumi Matsumoto a écrit :
- 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.
I pretty much agree that Teredo should have a lower priority than
public IPv4 space, but it is not so obvious with regards to private or
link-local IPv4 addresses... in the client to server case were NAT are
a non-issue, using IPv4 is better anyway, but in other cases (e.g. SIP
calls, p2p...), it will probably be worse.
In RFC3484 Section 3.2, scope for IPv4 is already defined
just like you said.
So, public IPv4 address has a higher priority, and
private or link-local IPv4 address has a lower priority
than Teredo, because of dst rule 2, if you use the
Policy Table I proposed.
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
About SIP and P2P applications,
especially nowadays, they are already NAT-aware. So, it
doesn't cause big problem to treat a private IPv4 address
as a global address. How do you think about this ?
- 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.
As with Teredo, it should at least be safe to underprioritize ULAs
against public IPv4 space, but if I understand correctly, that implies
adding 4 extra IPv4 rules (3 for RFC1918, and one for 169.154/16).
And, yeah, I can't think of any safe choice in between private IPv4
and ULAs.
The same is true for ULA.
So, even when you use a private IPv4 address under NAT router,
ULA/Teredo will be chosen for www.kame.net(whcih has public A and AAAA)
because ULA and Teredo has global scope.
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.
Similarly, it might (?) be nice to have a (IPv4) NAT-friendly
application profile and a NAT-unfriendly one, though they might be
caveats that I've not thought of.
Yes, it sounds good if a host can detect NAT and use appropriate
address selection profile. But I guess the detection system will be
so complicated because the system has to be stateful and dynamic.
I think it's impossible to find defaults that fit all. We should have a
sensible default, and I think some minor changes should be made, but IMO
there may be many cases where this needs to be configured to match
individual site preferences.
Stig,
Yes, I absolutely agree that we cannot make perfect default rules.
But, at the same time, we should not leave a harmful default rule as it is.
We should make less harmful and more beneficial rules for more people.
After making the default rules and RFC up-to-date, I want to discuss
a mechanism to control/distribute site preferences.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
