Re: Generic anycast addresses...

[Mark Smith <[e-mail]>]

On Thu, 30 May 2019 at 17:14, JORDI PALET MARTINEZ
<[e-mail]> wrote:
>
> 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.

I don't really see how ULA central solves a scoped well known anycast
address problem that would support multiple forwarding domain scopes.

ULAs only have a single scope, and that is global per RFC 4193 and
https://tools.ietf.org/html/draft-carpenter-6man-whats-global-00.

However, in terms of reachability or forwarding domain scope, ULAs
effectively have an administrative scope by default, due to this text
in RFC 4193:

"The default behavior of exterior routing protocol sessions between
   administrative routing regions must be to ignore receipt of and not
   advertise prefixes in the FC00::/7 block.  A network operator may
   specifically configure prefixes longer than FC00::/7 for inter-site
   communication."

So if somebody wants to have a anycast address, well known or not,
that has a limited forwarding domain that is smaller or larger than
administrative, such as one of these,

Interface-Local scope
Link-Local scope
Realm-Local scope
Site-Local scope
Organization-Local scope
Network Service Provider scope
Global scope

ULA isn't going to suit.

A Link-Local anycast address or a GUA anycast address ticks off two of
the above, however there are no other unicast address scopes that
could suit any of the remaining ones. (That's the multicast address
scope list with the addition of a Network Service Provider scope that
would encompass its downstream customers' networks.)

Regards,
Mark.


>
> 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" <[e-mail] en nombre de [e-mail]> 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 <[e-mail]> wrote:
>     >
>     > On Thu, 30 May 2019 at 10:58, Toerless Eckert <[e-mail]> 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.
>     > >
>     > > --
>     > > ---
>     > > [e-mail]
>     > >
>     > > --------------------------------------------------------------------
>     > > IETF IPv6 working group mailing list
>     > > [e-mail]
>     > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>     > > --------------------------------------------------------------------
>     >
>     > --------------------------------------------------------------------
>     > IETF IPv6 working group mailing list
>     > [e-mail]
>     > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>     > --------------------------------------------------------------------
>
>     --------------------------------------------------------------------
>     IETF IPv6 working group mailing list
>     [e-mail]
>     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.
>
>
>