Re: Generic anycast addresses...

[Mark Smith <[e-mail]>]

On Fri., 31 May 2019, 08:54 Sander Steffann, <[e-mail]> wrote:

> Hi Ted,
>
> >> To me, a non-fuzzy boundary is one where you do something like ACL on
> >> a set of links completely isolating some area of the network. Fuzzy
> >> could vbe absence of default route causing ULA to stop. Not sure if
> >> these are good examples of any actual definition, but both ae possible
> with
> >> ULA.
> >>
> >> I'd mostly be concerned about non-fuzzy boundaries wrt. security,
> >> so not sure if i'd always want to avoid non-fuzzy boundaries.
> >
> > The question is, what’s different about the proposed application versus
> typical ULA usage?
>
> I like the scope aspect of Mark's draft. ULA is always organisation or
> site scoped, and should be filtered as such. Anycast that have a different
> scope should have different boundaries. Anycast addresses that have ISP
> scope can cross from the customer's network to the ISP's network, while
> there should be a boundary between that customer's ULA addresses and that
> ISP's ULA addresses (let's assume they both use ULA for this example).
>

An example use case for a Network Service Provider scope is anycast DNS
resolvers.

You can't use ULA because customers don't send their ULA prefixes to you,
and you don't really want them to, as that makes your ISP network part of
their network.

Ideally you don't want to use GUA DNS resolver anycast addresses because
that makes the DNS resolver vulnerable to DoS attacks from the Internet.

When I first ran up anycast DNS resolvers, I ideally wanted to use IPv4
addresses that had these property of globally unique, not globally
reachable, yet reachable from all customers' networks. Internet DoS attacks
on DNS resolvers were common at the time.

RFC1918 didn't suit, nor did normal RIR public address space, because APNIC
expected it to be globally reachable. IX space suites, but we weren't an
IX. We could have probably lobbied harder for it, however we needed to get
them going.


This is also part of my realisation that the forwarding scopes of our
unicast address spaces are quite coarse - global (GUA), organisation (ULA)
and link (Link-Local), and that's it.

The much more fine grained multicast scopes used with anycast addresses
would be much more flexible for anycast scenarios.

I think reintroducing the Site-Locals as a unicast address space, just to
create Site-Local scope anycast addresses, isn't really properly solving
the problem in a general enough way.

People will also use them for unicast addressing because they're more
similar to RFC1918s that ULAs - and we also have problems with people not
making ULA unique, despite the word Unique in the name.


No mention of generating unique ULAs, so people are being trained to use
ULAs that are not unique:

https://github.com/leblancd/kube-v6/blob/master/README.md#set-up-node-ip-addresses

A CPE vendor got this wrong too in the past:

Residential IPv6 CPE - What Not To Do and Other Observations
https://www.ausnog.net/sites/default/files/ausnog-05/presentations/ausnog-05-d02p02-mark-smith.pdf


Regards,
Mark.


> Cheers,
> Sander
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>