Re: Generic anycast addresses...

[Mark Smith <[e-mail]>]

On Sat, 1 Jun 2019 at 02:35, joel jaeggli <[e-mail]> wrote:
>
> On 5/30/19 16:21, Mark Smith wrote:
> >
> >
> > On Fri., 31 May 2019, 08:54 Sander Steffann, <[e-mail]
> > <mailto:[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.
>
>  It is straight forward enough to use a gua prefix which you do not
> announce to the internet as a whole. we do this with internal
> anycast(s), address space used for point-to-point links management
> networks and so forth.
>

Sounds like it isn't a requirement to advertise RIR space globally
anymore so that RIRs can check if you're using it.

However, this is just one example of how a scoped formal anycast
address space could be used. There are others I'm working on in the
draft.

>
> > 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.
>
> We have really bad historical experiences with attempts to define scopes.
>

Can you elaborate?

Multicast scopes don't seem to have caused any issues, and I think it
is because they're much more fine grained than the total of 3 coarse
unicast ones. Multicast scopes better fit the domains people want.

> > 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] <mailto:[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
> > --------------------------------------------------------------------
> >
>
>