On Dec 8, 2004, at 6:27 AM, Brian Haberman wrote:
This is unfortunately not the only concern. Actually, i would even say this is
a somehow minor issue, as the risk of collision is small.
The real concern is similar to what is explain in the v6ops IPv6onbydefault draft.
Say that a well know host publish 2 AAAA in the global DNS, a 'regular' one
and a ULA one, apparently to make local things works better.
What is going to happen is that remote hosts have statistically 50% chance
to try the ULA first. Then, if TCP is in used, an application will
have to wait up to 3 minutes (according to present TCP specs) before
it can safely fall back to the 2nd address. Note that some implementations
I know have lowered this timeout, but this is still a critical issue.
In other words, the concern is not so much with publishing local addresses
in a local branch of the DNS, but to publish both local and global
data for the same name.
I don't see this as being specific to ULAs. As the above referenced
draft points out, this can happen with a mix of IPv4 and IPv6 addresses.
It happens today with a mix of global IPv4 addresses and net 10 addresses
being associated with the same name.
I agree that it is a problem, but not one specific to ULAs.
Now, the ULA draft tries to mitigate the issue by recommending that ULAs not be put in the global view DNS. I don't think we can do much more than that. What people do with their local DNS is their business.
Brian,
I'm of the opinion that those are important issues but it is unlikely they will be resolved in this wg.
The problem I have with the current text is that it somehow goes too far. It provides
a rationale why ULA SHOULD not be published that is not correct and would inevitably lead to
confusion.
I'd suggest to not publish any rationale and simply say something like:
4.4 DNS Issues
At the present time AAAA and PTR records for locally assigned local IPv6 addresses are not recommended to be installed in the global DNS. The operational issues relating to this are beyond the scope of this document and are discussed in the dnsop working group.
Note: I do not think you need another last call, this can be simply fixed
in the RFC 48h.
- Alain.
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
