> Mark Andrews <[EMAIL PROTECTED]> 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," especially with the growing
> |> uncertainty that there will ever be a _permanent_ centrally assigned flavo
> r
> |> of ULA available without recurring fees.
> |
> | Publishing AMBIGIOUS addresses in the GLOBAL DNS is WRONG.
>
> Wrong in what way? Morally? If you don't want to be troubled by the
> presence of locally assinged ULAs in my forward DNS, just don't request
> names from my forward DNS.
A host may have *both* a LOCALLY ASSIGNED ULA and a global
addresses. In fact this is highly likely. If I have a
machine withe the same ULA when I attempt to connect the
remote machine I will get my machine according to the address
selection rules.
> | If you need to publish them in the DNS you need to use a
> | split DNS configuration.
>
> No, that will not work if I want to use locally assigned ULA addresses for
> dynamic tunnels that anyone can access. And in any case, do you really want
> us to be in a position of mandating split DNS? I have no objection to folks
> running split DNS if they so desire, but I do not so desire and I certainly
> do not wish to force split DNS on anyone.
Then choose a centrally assigned ULA. The two types of ULA have
different usage patterns. Pick the correct one for the job.
> |This is no different to how we handle
> | RFS 1918 address.
>
> Umm, if locally assigned ULA addresses are going to have to be treated the
> same as RFC1918 addresses, why couldn't we have just kept site local addresse
> s?
Centrally assigned ULAs are globally unique. The restiction if
you read what was written above was on LOCALLY ASSIGNED ULAs.
There is a choice. You choose which set of tradeoffs to apply
when select your ULA. You could even have one of each type.
> |They don't get published in the GLOBAL DNS
> | because they are AMBIGIOUS.
>
> Merely repeating this assertion (even IN ALL CAPS) really isn't a useful
> argument. We have spent many months discussing ULAs as a solution to the
> ambiguity of site local addresses. This seems like a last minute attempt
> to cripple them.
No. It is a attempt to prevent harm from incorrect use.
> |> An important feature of even locally assigned ULAs is that they are global
> ly
> |> unique "enough" for many/most purposes that have been discussed. After mo
> nth
> |> s
> |> of analysis to that end, their lack of absolute uniqueness is insufficient
> to
> |> justify adding new prohibition on a particular range of uses at this late
> dat
> |> e.
> |
> | They are unique enough to link serveral hundred / thousand sites
> | *with minimal renumbering required*.
> |
> | They are not unique enough to link millions of sites where the
> | is no way of knowing that renumbering is required.
>
> Even if you are correct that they are not unique enough to link millions
> of sites (and I do not accept that you are correct--duplicates could be
> handled by cooperating sites by a de facto uniqueness mechanism outside
> the scope of this proposal) how does this justify restricting the utility
> of locally assigned ULAs in the several hundred/thousand sites case?
>
> How about a compromise? Let's first insure that centrally assigned ULAs
> are available for permanent assignment with no recurring fees (and at most
> a nominal initial fee). Once that is accomplished we would be in a better
> position to weigh the costs/benefits of recommending locally assigned ULAs
> in various contexts. Such recommendations could be in a document separate
> from the core ULA document. Restricting the use of locally assigned ULAs
> before we even know whether there will be an alternative seems a bit rash.
> After all, this topic has been under discussion for a very long time; what's
> the rush now?
It's not rash. They have limitations. The fact that you
don't like the limitatitions does not mean that they should
not be acknowledged and dealt with appropriately.
> Dan Lanciani
> [EMAIL PROTECTED]
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [EMAIL PROTECTED]
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
--
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
--------------------------------------------------------------------
