I believe SHOULD NOT is sufficient as well for CA ULA. I believe there may be ligitimate cases when having CA ULA's in global DNS exist. Company A has a VPN tunnel to Company B, and they route ULA addressing through this tunnel. By advertising this addressing in the global DNS for AAAA records, it enables this to get done without Company A and Company B doing zone transfers to each other, and having to push some zones and limit others, or use split DNS, etc... I admit, this is what they *SHOULD* be doing, but I have yet to see a large company that isn't lazy when it comes to DNS...
For LA ULA's, I also agree that it SHOULD NOT is appropriate, since a central authority that doesn't have a recurring fee doesn't exist, and we should allow for that to be the case. Steve Dalberg Email: steve at sendithere dot com -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brian E Carpenter Sent: Tuesday, December 07, 2004 1:17 AM To: Daniel Senie Cc: [EMAIL PROTECTED] Subject: Re: I-D ACTION:draft-ietf-ipv6-unique-local-addr-08.txt Daniel Senie wrote: > At 04:31 AM 12/6/2004, Brian E Carpenter wrote: > >> Dan Lanciani wrote: >> >>> Mark Andrews <[EMAIL PROTECTED]> wrote: >>> |+ Advertising locally assigned ULA AAAA records in the global DNS is >>> |+ MUST NOT occur as they are not globally unique and will lead >>> |+ to unexpected connections. >>> I strongly object to making this a "MUST NOT," ... >> >> >> >> OK. Lot of shouting since this was sent but not much new text. >> >> How about >> >> Locally assigned ULA AAAA records MUST NOT appear in the global DNS, >> since there is an extremely small probability that the corresponding >> addresses are not unique. Even though these addresses will be >> unrouteable in the global Internet, their leakage via DNS is highly >> undesirable. Such AAAA records MAY appear in local regions of the DNS >> corresponding to their region of routeability. >> >> (And I would put an equivalent SHOULD NOT on centrally assigned >> ULAs.) > > > I disagree. SHOULD NOT is sufficient, as it was (is) for RFC 1918. I > also would remove the "highly" in "highly undesirable". The leak of > such an address is not serious. Though such leakage has occurred > occasionally with IPv4, the world has not ended. While I understand a > strong desire to "get it right this time with IPv6," I don't see this > particular issue as one where the result will be anything more than > annoying prospective adopters of IPv6 with no good reason. Personally, I could accept either MUST NOT or SHOULD NOT, and don't feel strongly about "highly." I hope the chairs can declare a consensus... Brian -------------------------------------------------------------------- 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 --------------------------------------------------------------------
