Re: Generic anycast addresses...

[Toerless Eckert <[e-mail]>]

On Sat, Jun 01, 2019 at 08:14:33AM +1000, Mark Smith wrote:
> > 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,
> 
> That's not how anycast works.
> 
> Only one of the two ISPs will receive the DNS query, and there will
> only be one answer.

Yes, for an individual query. I was referring to the case where i have
for example 8.8.8.8 as my DNS server, and depending on which ISP link
i use to reach that DNS anycast address, i can get a different answer.
Might involve more than one DNS resolution step of course.

> Using multicast for your DNS queries (assuming the multicast
> infrastructure exists) would cause the problems you describe.

Just talking normal unicast DNS request to anycast DNS server address.

Cheers
    Toerless

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

-- 
---
[e-mail]