Re: Generic anycast addresses...

[Mark Smith <[e-mail]>]

On Thu, 30 May 2019 at 11:05, Toerless Eckert <[e-mail]> wrote:
>
> On Thu, May 30, 2019 at 10:59:04AM +1000, Mark Smith wrote:
> > Having deployed anycast DNS service in the past, being a reviewer of
> > RFC 7094, and having thought about this sort of problem space for a
> > while, I came to the conclusion that there should be a formal class of
> > IPv6 anycast addresses that include fine grained scopes. A separate
> > class of addresses is also what the authors of  RFC 1546 suggested as
> > an option for anycast support.
> >
> > "IPv6 Formal Anycast Addresses and Functional Anycast Addresses"
> > https://tools.ietf.org/html/draft-smith-6man-form-func-anycast-addresses-00
>
> Anycast is not the issue.

Ted asked for a scoped anycast solution.

> Scoping unicast is the issue. When you manage
> to work that out, you can get scoped anycast for free. But scoped
> unicast failed and was removed, except for ULA AFAIK. Go figure.
>

No need to "go figure", explained why in RFC 3879.

The problem with the Site-Local unicast address space is that multiple
nodes holding the same unicast address (as in, meant to permanently
and exclusively identify one and only one node - "uni") is a fault.
The Site-Local unicast address space inadvertently created a potential
fault condition by design because it created unicast address
ambiguity.

Multiple nodes intentionally holding the same anycast address (as in,
not permanently exclusive to one and only one node) is not a fault and
is expected.

One operational problem with anycast address today is that you can't
look at the address and determine if it is intended to be an anycast
address or not, meaning you can determine if a duplicate address is a
fault or not. That is because they're assigned from within the unicast
address space, rather than from a specific formal anycast address
space. Contrast that with multicast addresses, which are assigned from
within their own formal address space.

> I think the pragmatic way is to actually continue to build successful
> experiments with the existing ULA definitions we have.
>

ULAs don't meet the requirements. If a ULA address is globally
assigned by IANA and well known, and possibly used in multiple
different networks, it is not Unique and it is not Local anymore.

Regards,
Mark.




> > Regards,
> > Mark.
> >
> >
> > > Bob
> > >
> > >
> > >
> > >
> > > --------------------------------------------------------------------
> > > IETF IPv6 working group mailing list
> > > [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
> > --------------------------------------------------------------------
>
> --
> ---
> [e-mail]