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

From: [email-masked]
Date: Mon, 6 Dec 2004 12:18:15 -0800 (GMT-08:00)

-----Original Message-----

>> This is the harm that can be caused when you publish a
>> LA ULA.
>
>That is certainly a possible outcome if you happen to collide with someone, 
>that someone happens to be mixing PI/PA and LA ULA addresses for a given 
>hostname, and you happen to try to contact a host via that hostname.  Care 
>to calculate the odds that your scenario will happen?

As someone who will end up supporting installations or have to debug problems related to connectivity, the actual odds are not important. If the odds are greater than 0, it will happen. Whatever solution that is proposed here should keep that in mind. Also, any solution should keep in mind how to work around any such problems when it does happen. If addresses are in global DNS, does that make my life horrible when trying to create scenarios where I need to avoid parts of the DNS? Not sure thats an issue here, but I think it needs to be considered.

>However, there do exist cases where the behavior is well-defined and correct 
>even in the face of ambiguity.  Suppose you have:

The scenario you proposed can be done without using global DNS. I would almost argue that you would want to do it outside of the global DNS, since I do not need to advertise this part of my infrastructure to the world.

>Removing the LA ULA from DNS will not solve the ambiguity problem anyway, 
>nor does it mask the interaction with address selection rules.  The problem 
>still exists at the IP layer, and any application that supports IPv6 address 
>literals (i.e. nearly all of them) would see the exact same behavior if 
>users were to type in an ambiguous ULA literal instead of a hostname that 
>resolved to that ULA.  Should we also ban users from distributing LA ULAs 
>via smoke signals or avian carriers to keep from trying to use addresses 
>where they're not valid?

You are probably right here. But I think the standards should try and do what it can to protect unknowing entities from unwanted behaviour. As you stated later, you can't stop people from doing things, even with a MUST NOT in the document, but I do not think this is a good argument for NOT tightening up a document where the IETF feels certain behaviour should be restricted or isolated to local use only.

After following this thread for a bit, my outside opinion is that we should keep the global DNS as clean as possible, and allow internal organizations do what they need to without unknowingly mess up an innocent bystander who will not have any idea of whats going on or how to fix/work around problems.

--rich

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "Dalberg, Stevin J" <[email-masked]>
Date: Tue, 7 Dec 2004 10:29:29 -0800

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-masked] [mailto:[email-masked]] On Behalf Of
Brian E Carpenter
Sent: Tuesday, December 07, 2004 1:17 AM
To: Daniel Senie
Cc: [email-masked]
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-masked]> 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

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Tue, 7 Dec 2004 17:15:51 -0500

For what it's worth, having re-read the arguments pro and con, and the wording used in RFC 1918 with respect to routing outside the private net domain, I think that the -08 draft covers everything and word-smiths everything quite nicely.

Bert

> From: Bob Hinden [mailto:[email-masked]]
> Sent: Tuesday, December 07, 2004 4:23 PM
> To: [email-masked]
> Hi,
> >     Locally assigned ULA AAAA records MUST NOT appear in 
> the global DNS,
> >     unrouteable in the global Internet, their leakage via 
> DNS is highly
> >     undesirable. Such AAAA records MAY appear in local 
> regions of the DNS
> >(And I would put an equivalent SHOULD NOT on centrally 
> assigned ULAs.)
> 
> While I am sure everyone in this discussion has read the DNS 
> text in the 
> current draft, here it is just in case:
> 
>     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.
> 
>     For background on this recommendation, the concern about 
> adding AAAA
>     and PTR records to the global DNS for locally assigned local IPv6
>     addresses stems from the lack of complete assurance that 
> the prefixes
>     are unique.  There is a small possibility that the same PTR record
>     might be registered by two different organizations.  Due to this
>     concern, adding AAAA records is thought to be unwise 
> because matching
>     PTR records can not be registered.
> 
> This text (in my view) is more or less equivalent to what is proposed 
> above.  The text in the draft doesn't use the upper case MUST/SHOULD 
> language since this part of the document is operational 
> guidelines and that 
> language doesn't seem appropriate.  I suppose something with 
> lower case 
> must/should would work.
> 
> My personal view is that this is about all we can say now in this 
> document.  I continue to think that what is needed is a 
> separate draft that 
> discusses this topic in detail.  This document might even relax the 
> recommendation if warranted.  It would be a good place to describe 
> different approaches to the locally and centrally assigned 
> ULAs as well.
> 
> Chair hat on:
> 
> The -08 draft is currently in the IESG.  Almost all of the 
> Discuss votes 
> have been cleared.  If we can go with the current text it may 
> result in the 
> document being approved soon.  The more we try to fine tune 
> it there is a 
> risk of further delay.
> 
> It would be good if we could move forward on this document.
> 
> Bob