Re: Generic anycast addresses...

[Toerless Eckert <[e-mail]>]

On Thu, May 30, 2019 at 03:05:24PM +1000, Mark Smith wrote:
> > Anycast is not the issue.
> Ted asked for a scoped anycast solution.

My point was that scoped anycast would operate on top of
scoped unicast which we deprecated.

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

Right. I know. Back when this was happening i felt this was somewhat
ridiculous because scoped multicast addresses where not deprecated and
those scoped multicast addresses where/are even worse than scoped
unicast in the way they are defined in the IPv6 architecture. 

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

"Fault" is your assesment, its not rfc3879 language. For me its really
hard to agree fully with rfc3879 because it draws a lot of justification
from comparison with rfc1918, yet rfc1918 was back in 2004 and likely is
still today the address space with the most number of host on the planet.
How bad is something you call a fault if the mayority of the planet runs 
on it ?  IMHO, the IPv6 architecture addition of (arbitrarily) locally
numbered zones was the ambitious but insufficient fail, not the concept of
scoped adresses itself. The scoped addresses where just counterintuitive
to the global peer-to-peer connectivity vision of IPv6.

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

Dedicated anycast address space would IMHO not help to magically
make network layer deployment easier or more broadly deployable than
it is today. The only benefit would be to transport layer, and i think
by now we worked out how to deal with anycast in transport or other
higher layer protocols without dedicated anycast 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.

Agreed, but that was not the proposal. 

Cheers
    Toerless

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