Re: Generic anycast addresses...

[Mark Smith <[e-mail]>]

On Fri, 31 May 2019 at 11:18, Ted Lemon <[e-mail]> wrote:
>
> On May 30, 2019, at 5:05 PM, Mark Smith <[e-mail]> wrote:
> > Adding, even if both upsream/parent NSPs are providing DNS resolver service with the same NSP scoped anycast address (because it will be a generic NSP scoped DNS resolver address), the downstream customers' routing will pick only one of them to use.
>
> This might be dysfunctional.  Sometimes if you query the DNS server for one upstream and then use the answer on the other upstream, the results will not be the same, and might be quite suboptimal.   That said, this isn’t likely a problem with the real point you are making, so I only mention it for completeness.
>

It's a fault you report to the ISP as they're not providing a properly
working DNS resolution service.


> > Similar to multicast, what I've proposed supports embedding a unicast /64 prefix. The all-zeros /64 is used as "unspecified".
> >
> > So in this scenario, both NSPs would advertising the same generic NSP scoped anycast DNS resolver address with an all zeros /64 part - and likely such a well-known anycast address that it could be a factory default for devices. They may also each advertise an NSP scoped anycast DNS address which embeds one of their GUA /64s.
> >
> > So a customer could leave the choice of which NSP's DNS resolver they use entirely up to their routing system by using the generic DNS anycast address, which would be the default, or they could prefer only one of their NSP's DNS anycast resolver services by configuring their hosts to use that NSP's specific anycast DNS address that includes the NSP's chosen GUA /64.
> >
> > They could go further and configure the second NSP's specific NSP scope anycast DNS resolver address as a second DNS entry on a host to get NSP independent DNS redundancy, if the first and preferred NSP's DNS anycast resolution service isn't considered reliable enough.
>
> This isn’t actually the use case that I’m talking about—I’m a bit puzzled.  Here you are configuring the anycast address just like a regular IP address.

Only if you want or need to.

>  The use case I need is for a well-defined anycast address that does not need to be discovered.   So while what you are doing may be useful, it doesn’t have anything to do with my use case.

https://tools.ietf.org/html/draft-smith-6man-form-func-anycast-addresses-00#section-5.1

5.1.  Features

   o  Provides separate globally well known and local network defined
      anycast function or service identifier spaces.  Globally well
      known identifiers can be encoded in applications during their
      development as constants, avoiding the need for them to be
      specified and configured during deployment of the application.

>  The reason I was pointing out that your scoping model didn’t work is that I didn’t understand that you intended to use different anycast addresses for different ISPs.

It's both.

There is a generic one that all are likely to ISPs would provide.

Using the draft's format (note there is an error with the scope
position in the draft, fixed in next revision),

- 0xaa - 8 bit Formal Anycast Prefix
- 0xb - 4 bit Vislble Scope: Network Service Provider
- 0x0 - 4 bit Anycast Identifier Format: Functional Anycast
- 0x:: - 64 bits Anycast Domain Prefix: 64 bits of all zeros,
indicating unspecified prefix
- 00b - 2 bits reserved, set to zero
- 00 0000b - Prefix-Length: 6 bit prefix length, all zeros having
special meaning of 64 bit prefix length
- 0000 0000b - Flags: 8 bit flags, 1 defined, T meaning Transient in
high order position i.e. non-IANA assigned (i.e. same as multicast
flag T meaning)
- 0x0 - Local Instance: 8 bit field available to local anycast domain
to allow instances or versions of the service to be included in the
address. zero by default. Can be used to extend following Anycast
Function Identifier to 32 bits in the anycast domain identified by the
Anycast Domain Prefix.
- 0x000053 - Anycast Function Identifier: 24 bit function identifier.
IANA assigned in this case because the T bit is not switched on.
Assume 53 (actually 83 in decimal).

Compressing all the zeros (common default values chosen to be zero for
that purpose), an ISPs would announce into their routing domain (and
to customers via eBGP):

aab0::53/128

This would be the default embedded in the code of DNS resolvers.
Following the formula, ISPs should all arrive at that value, however
there probably would be value in an IANA registry or similar
documenting it to minimise formula following errors.


The ISPs might also respectively provide their own unique Functional
Anycast addresses by embedding one of their GUA /64s as the Anycast
Domain prefix:

So ISP A also announces:

aab0:2001:db8:0:a::53/128


ISP B also announces:

aab0:2001:db8:0:b::53/128



With each of the following customers being multihomed to both ISP A and ISP B:

Customer A might be happy with the default, so they leave hosts' DNS
resolver clients address as the default of aab0::53. It's
plug-and-play, no configuration required.

Customer B might want to always use ISP A's DNS resolver, so they
replace the default of aab0::53 with aab0:2001:db8:0:a::53.

Customer C might want to use ISP B's DNS resolver, but fall back to
ISP A's if ISP B's fails, so they replace the default of aab0::53 with
two entries in order, aab0:2001:db8:0:b::53, aab0:2001:db8:0:a::53.


(Instead of announcing specific anycast /128s, an ISP could announce
an aggregate route for all of their specific anycast domain services
e.g. ISP A above would announce aab0:2001:db8:0:a::/80).

So ISPs announcing both the generic well-known DNS anycast address,
and their own specific versions, allows their customers to leave the
default in the DNS resolver client code, or override it to suit their
preferences as to who they get the anycast DNS service from.

Is that clearer?

Regards,
Mark.


> For that use case, there’s no need for a special scoped anycast address—each ISP can simply allocate an IP address or IP addresses and configure their routing to treat them as anycast addresses.   There are problems with this, but these problems are already discussed e.g. in RFC 7094.
>
>