Re: Generic anycast addresses...

In fact, I tried to rescue ULA-central by means of having the support in RIR policies (see pointers below). It didn't reached consensus at that time, but new arguments, new experience may change the situation (it happened already several times with other policy proposals).

After we get that, we can advance draft-ietf-ipv6-ula-central.

If we think this is a possible path, I'm happy to work again in the ULA-Central policy proposals in the 5 RIRs.

https://www.ripe.net/participate/policies/proposals/2007-05
https://www.apnic.net/community/policy/proposals/prop-048/
https://afrinic.net/policy/archive/proposal-for-ipv6-ula-central-afpub-2007-v6-003
https://www.lacnic.net/innovaportal/file/556/1/lac-2007-06-sp.pdf

I can't find the ARIN one, not sure if I presented it there as well.

Regards,
Jordi

El 30/5/19 3:13, "ipv6 en nombre de George Michaelson" <ipv6-bounces@ietf.org en nombre de ggm@algebras.org> escribió:

    point of information. the RIR system exists, and in the ULA
    discussions it was understood that globally unique assigned address
    processes were RFC bound in RFC2050 and subsequently RFC7020.

    If it becomes necessary to implement the service, the RIRs already
    indicated they understood how to manage ULA distribution with
    uniqueness, and mechanisms to apply normal address services like
    WHOIS.

    I guess I'm saying "just because we don't, doesn't mean we can't"

    -G

    On Thu, May 30, 2019 at 11:08 AM Mark Smith <markzzzsmith@gmail.com> wrote:
    >
    > On Thu, 30 May 2019 at 10:58, Toerless Eckert <tte@cs.fau.de> wrote:
    > >
    > > I cant brainstorm a lot more without more details of what you're
    > > trying to achieve, and  therefore what the constraints are.
    > >
    > > Worst case, you float the idea to a single ULA prefix defined
    > > by your RFCs mecanism and see how reviewers like this. At least its
    > > a lot better than trying to define a "well known" rfc1918
    > > anycast address - because your application defined ULA
    > > prefix has a very low probability of colliding with somebodies
    > > actually used ULA prefix.
    >
    > Per RFC4193 4.1 and the route propagation constraint, ULAs effectively
    > have an organisation scope by default. That may be too small or too
    > large for other anycast use cases.
    >
    > If there is a reserved well-known ULA prefix, then RFC 4193 would have
    > to be updated to exclude that value from the algorithm. We also don't
    > know if the chosen well-known ULA prefix is already in use somewhere.
    >
    > I think a better idea is a formal class of anycast addresses with fine
    > grained scopes that match (or are) the multicast address scopes.
    >
    > "IPv6 Formal Anycast Addresses and Functional Anycast Addresses"
    > https://tools.ietf.org/html/draft-smith-6man-form-func-anycast-addresses-00
    >
    >
    > > On Wed, May 29, 2019 at 05:41:04PM -0700, Ted Lemon wrote:
    > > > Indeed, the propagation pattern of a ULA would work nicely for this, but there???s no way to do this automatically.   I might have (and indeed unfortunately it???s common to have) more than one ULA on a constrained network.   How do I pick?   :)
    > > >
    > > > So what I really want is indeed something that is treated like a ULA, but that can be a constant, and not something that has to be derived.
    > >
    > > --
    > > ---
    > > tte@cs.fau.de
    > >
    > > --------------------------------------------------------------------
    > > IETF IPv6 working group mailing list
    > > ipv6@ietf.org
    > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    > > --------------------------------------------------------------------
    >
    > --------------------------------------------------------------------
    > IETF IPv6 working group mailing list
    > ipv6@ietf.org
    > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    > --------------------------------------------------------------------

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

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.