> Mark Andrews <[EMAIL PROTECTED]> wrote:
>
> |> Mark Andrews <[EMAIL PROTECTED]> wrote:
> |>
> |> |> Mark Andrews <[EMAIL PROTECTED]> wrote:
> |> |>
> |> |> |+ Advertising locally assigned ULA AAAA records in the global DNS i
> s
> |> |> |+ 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 grow
> ing
> |> |> uncertainty that there will ever be a _permanent_ centrally assigned fl
> avo
> |> 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.
>
> This may be true, but it is not responsive in spite of the tasteful use of
> ALL CAPS. You are starting with the premise that you are attempting to
> access my machines by looking up a name in my DNS. If you don't like the
> way I populate my DNS then you don't need to use my DNS.
If it in the global DNS is in NOT "your DNS". It is everybodies.
If you want to put it in your DNS then use split DNS. Stop
polluting the commons.
> |> | 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 wa
> nt
> |> us to be in a position of mandating split DNS? I have no objection to fol
> ks
> |> running split DNS if they so desire, but I do not so desire and I certainl
> y
> |> do not wish to force split DNS on anyone.
> |
> | Then choose a centrally assigned ULA.
>
> As I'm sure you are aware, centrally assigned ULAs are not currently availabl
> e
> and their future availability on the terms originally suggested is becoming
> increasingly unlikely.
Centrally assigned ULAs will appear.
> |The two types of ULA have
> | different usage patterns. Pick the correct one for the job.
>
> When the proposal to create ULAs was "split" in order to accommodate a longer
> process for the centrally assigned flavor (because of the supposed need for
> comments from the existing address registries) the locally assigned flavor
> had the necessary attributes to support a wide variety of usage patterns.
> You propose to restrict the usage of the locally assigned flavor in such a
> way that many interesting applications will demand the centrally assigned
> flavor. I propose that if we really want to do that then we should first
> insure that the centrally assigned flavor comes into existence on reasonable
> terms.
> |> |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 addre
> sse
> |> s?
> |
> | Centrally assigned ULAs are globally unique. The restiction if
> | you read what was written above was on LOCALLY ASSIGNED ULAs.
>
> And if you read what I wrote above you will see that I was indeed speaking
> of locally assigned ULAs, even though I didn't put it IN ALL CAPS.
>
> | There is a choice. You choose which set of tradeoffs to apply
> | when select your ULA. You could even have one of each type.
>
> This is a false choice. It is impossible to choose the set of tradeoffs
> because we have no idea what the attributes of centrally assigned ULAs (if
> they ever exist at all) will be. Basically, we copped out on mandating the
> critical attributes of centrally assigned ULAs (permanent assignment, low
> one-time fee) yet now you want to mandate restrictions on locally assigned
> ULAs that will force a requirement for the centrally assigned flavor.
You believe permanent assignment, low one-time fee was manditory.
I never did. The *only* thing critical about centrally assigned
addresses is that that are uniquely assigned within the specified
address range. The rest is just nice to have. If the registries
charge too much then people will move to locally assigned ULA and
live with the limitations imposed by those addresses.
> |> |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.
>
> Harm to whom?
Harm to users of the DNS. RFC 1535 was written in response to
resolvers return address which connected to the wrong machines
when putting in fully qualified addresses. You are asking
the WG to endore a similar policy because you believe centrally
assigned addresses will never occur.
> |> |> An important feature of even locally assigned ULAs is that they are glo
> bal
> |> 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 insuffici
> ent
> |> to
> |> |> justify adding new prohibition on a particular range of uses at this la
> te
> |> 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?
>
> I see that you declined to reply to my suggested compromise. How about we
> make centrally assigned ULAs work before we break locally assigned ULAs?
>
> | It's not rash. They have limitations.
>
> You are confusing architectural limitations with administrative restrictions.
> The architectural limitation of locally assigned ULAs is that there is some
> chance of duplication. This implies that exposure of such addresses outside
> of the realm in which their uniqueness can be guaranteed may lead to ambiguit
> y.
> This is true regardless of the mechanism used to expose those addresses: glob
> al
> DNS, some other name lookup system, or even the passing of a literal address
> in some random protocol.
>
> Your proposal to prohibit locally assigned ULAs from the global DNS is an
> administrative restriction--one which considerably devalues the addresses
> in question.
They were already devalued. It was inherent consequence of the
assignment technique. You must be the only one who thought that
publishing of locally assigned ULA in the global DNS was going to
occur. I know from the start as should have anyone who has
ever dealt with site locals / link local / RFC 1918 addresses that
there were never going to be published in the global DNS. They
were by ther very nature abmigious.
The fact that I said MUST NOT should not have come as suprise to
anyone here.
Sure the addresses will leak from time to time. You don't however
deliberately *publish* them however.
> |The fact that you
> | don't like the limitatitions does not mean that they should
> | not be acknowledged and dealt with appropriately.
>
> The limitations of locally assigned ULAs have been acknowledged and discussed
> extensively. Your proposal to create an administrative restriction does
> nothing to deal with the limitations; it merely forces the use of an as yet
> undefined alternative where locally assigned ULAs would have been sufficient.
> This is very reminiscent of the original site local debates.
Site local was much worse. Here you choose which type of address to
use.
One with may require a fee vs one that is free.
One which you can publish in the global dns vs one which you can't.
One that you should never have to renumber vs one which you may
have to renumber.
> 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
--------------------------------------------------------------------
