Re: Generic anycast addresses...

[Toerless Eckert <[e-mail]>]

On Fri, May 31, 2019 at 12:25:03PM +1000, Mark Smith wrote:
> > On May 30, 2019, at 5:05 PM, Mark Smith <[e-mail]> wrote:
> > 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.

Consider you have a CDN RR www.example.com hosting video clips.
I look it up across my two ISP connections and get two different IP addrs,
each being the CDN instance supposed to be serving a specific area.
If i now attempt to access IP 2 via link 1, i may simply get service
denial on the basis of my source IP address because the whole setup
to provide different CDN server addresses is to manage bandwidth and
serve from each instance only client IP addresses that are in a part
of the Internet to which bandwidth and cost of that server are
considered optimum by example.com.

I could not find the section "how www.example.com will make more money
with this memo" in Marks draft. Would be interesting to understand
if/how he proposes to achieve this, because this is about the financially
biggest use case of "anycast DNS" in the Internet i can think of and
there is a whole industry building this and another to work around it.

The part of using one IP address learned across one (VPN tunnel) link to
access content you're not supposed to have across that second (native
ISP) link is of course one of the key examples of this. Because in
many CDN cases that denial-of-service based on originator IP address is
not implemented.

Cheers
    Toerless

> 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.
> >
> >
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

-- 
---
[e-mail]