Re: Generic anycast addresses...

[George Michaelson <[e-mail]>]

yes, if you couch it like that, its not a unique assignment, its a WKS
type centrally managed. Its not global unicast, there is no single
entity which asserts control.

Thats an IANA function as I see it.

The BGP implications for this address would be interesting because the
origin-AS would vary a lot. If nobody has it, nobody can ROA it or
route: object it, but that is probably handled in other ways in route
filtering.

btw I'm not an address policy person, I only work in RIRland, so this
isn't a binding commitment statement, its just how I think.

-G

On Thu, May 30, 2019 at 3:14 PM Mark Smith <[e-mail]> wrote:
>
> On Thu, 30 May 2019 at 11:12, George Michaelson <[e-mail]> wrote:
> >
> > 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"
> >
>
> I think the multicast well-known group address model applies here,
> because anycast addresses typically represent functions or services
> rather than actual nodes, so IANA would be the likely registration
> authority.
>
> Anycast services and functions are quite similar to multicast groups
> representing services. From that perspective, the only fundamental
> difference between anycast and multicast is that a packet sent to an
> anycast service or function is only delivered to one of the set of
> anycast nodes, where as a packet sent to a multicast service or
> function is delivered to all of the set of multicast nodes.
>
> IANA have already assigned some global anycast addresses:
>
> RFC7723] reserves the IPv6 address 2001:1::1/128 for the use as the
>    Port Control Protocol Anycast address.
>
>    [RFC8155] reserves the IPv6 address 2001:1::2/128 for the use as the
>    Traversal Using Relays around NAT Anycast address.
>
> We're already down the path of formally defining global-scope
> individual anycast addresses, so organising anycast addresses into
> their own address class with fine grained scopes that are the same as
> multicast scopes, and including other information (which is also
> already similarly recorded in multicast addresses) could be more
> useful than just individual global scope /128s in a number of
> scenarios. I've suggested some example use cases in the draft.
>
> Regards,
> Mark.
>
>
>
>
> > -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
> > > --------------------------------------------------------------------