Re: Generic anycast addresses...

[joel jaeggli <[e-mail]>]

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.


> 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.

> 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
> --------------------------------------------------------------------
>