At 05:45 PM 12/4/2004, Mark Andrews wrote:
If ISC was to publish in the DNS
www.isc.org. 10M IN AAAA 2001:4f8:0:2::d ; exists today
www.isc.org. 10M IN AAAA FC01:4f8:0:2::d
and you happened to have a machine with local addresses FC01:4f8:0:2::d.
You would be unable to reach www.isc.org from any machine receiving your ULA prefix as a consequence of the address selection rules.
Come on. This is NOT a real-world example.
Today, I publish domains of the style example.com for production (public) use. I also publish NS records for zones of the style local.example.com for addresses on local (i.e. PRIVATE) networks that are not reachable from outside. Why do I do this? It simplifies getting around on private networks that allow servers to communicate for private matters (backups, for example). The servers are multihomed, with a public facing interface that is used for public things and a private-facing interface that's used for private things.
There's no interference with public operations. If you try to ping a host on .local.amaranth.net, you may get unexpected results since there are many RFC1918 addresses there. Did this harm anything? No. Could I use views in BIND to block your being able to query there? Sure.
People can and will publish zones for private use. Using a third level, such as local.example.com, is a GOOD way to do this.
If you're concerned about people screwing up in the form you show above, then make a statement to that effect, rather than insisting on a MUST NOT that covers reasonable, and non-interfering usage such as folks have been using for years in IPv4. There's no Commons involved here.
This is the harm that can be caused when you publish a LA ULA.
If you don't have MUST NOT you don't have a way to point blame when things go wrong. With MUST NOT you can say please remove the address you are in violation of RFC XXXX.
That's worked exceptionally well for folks leaking bogus-sourced packets (RFC 2827/BCP38). The IETF doesn't have a very good police force. If your goal is to enforce this by making DNS server products refuse to load zone data containing ULAs, I suspect that will fail as well, as the marketplace will insist such be allowed, and some vendor(s) will ignore claims to the contrary in the RFC.
2001:4f8:0:2::d is assigned by forcing the LL address then using auto assignment to get the other prefixes. It is done this way so it won't change with hardware changes.
I expect other sites will do similar things to provide stable addressing to their external machines. Collisions in addresses get much more probable when you start assigning the local parts by hand.
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
