[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: I-D ACTION:draft-ietf-ipv6-unique-local-addr-08.txt

 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: ipv6-bounces@xxxxxxxx [mailto:ipv6-bounces@xxxxxxxx] On Behalf Of
Brian E Carpenter
Sent: Tuesday, December 07, 2004 1:17 AM
To: Daniel Senie
Cc: ipv6@xxxxxxxx
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 <Mark_Andrews@xxxxxxx> 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
>>     since there is an extremely small probability that the
>>     addresses are not unique. Even though these addresses will be
>>     unrouteable in the global Internet, their leakage via DNS is
>>     undesirable. Such AAAA records MAY appear in local regions of the
>>     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...


IETF IPv6 working group mailing list
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6

IETF IPv6 working group mailing list
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6