Re: Generic anycast addresses...

[Joel Jaeggli <[e-mail]>]

Sent from my iPhone

> On May 31, 2019, at 15:27, Mark Smith <[e-mail]> wrote:
> 
>> 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.

It has never been a requirement. 

RIRs will happily allocate GUA space which is  not intended to appear in the DFZ.

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