Re: Generic anycast addresses...

[Mark Smith <[e-mail]>]

On Thu, 30 May 2019 at 15:49, George Michaelson <[e-mail]> wrote:
>
> 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.
>

Yes, IANA would be the authority for global Well-Known service or
function Anycast Function Identifiers.

Also similar to multicast, a local domain can define its own local
service AFIs, with a flag encoding that choice.

The idea of a reserved part of the number space for anycast addresses
is not new.

For example, 131 888 is the phone number for one of the closest local
pizza delivery services here in Melbourne, and in Adelaide, and in
Perth etc., where the 13 prefix (and 1800 or 1300 prefixes) indicate
anycast phone numbers. I assume similar prefixes in other countries
are different, so 13, 1800 and 1300 could be considered to have
"country scope".


> 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.
>

If you're referring to the eBGP example, "5.7.3. Automatic eBGP
Session Establishment", I've realised that it probably isn't that
clear that I was more imagining private ASNs or the single ASN that an
ISP uses for its customers, both connected to a single ISP. That is,
not a globally unique ASN for a properly multi-ISP multihomed router.

Perhaps that could be possible with the use of an initial well-known
default ASN used to bootstrap the connection to the point where the
router can then somehow then acquire the globally unique ASN that it
switches to using. Out of scope for this ID I think.


> 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.
>

Thanks very much for your comments.

Regards,
Mark.

> -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
> > > > --------------------------------------------------------------------