Re: Generic anycast addresses...

[Mark Smith <[e-mail]>]

On Sun., 2 Jun. 2019, 07:06 Brian E Carpenter, <[e-mail]>
wrote:

> On 02-Jun-19 02:05, Michael Richardson wrote:
> >
> > Mark Smith <[e-mail]> wrote:
> >     >> hop 1 is the router at home, and hope 2 is the access router at
> my ISP, and
> >     >> hop 3 is my ISP's core router connect to upstream peers.
> >     >>
> >     >> Should hop 1 (home router) or hop 2 (access node) were to
> blackhole route
> >     >> fc00::/6 (ULA-R and ULA-C), would that affect your use case?  Or
> could the
> >     >> anycast service possibly be at the ISP?
> >
> >     > I'm guessing you don't have internal ULA address space, which is
> why you're
> >     > more successful than if you did.
>
> For example:
>
> C:\WINDOWS\system32>tracert fd2e:82a1:f3c4::1
>
> Tracing route to fd2e:82a1:f3c4::1 over a maximum of 30 hops
>
>   1     2 ms     2 ms     2 ms  fritzy
> [fd63:45eb:dc14:0:be05:43ff:fe8e:ce39]
>   2  General failure.
>
> Trace complete.
>
> fritzy is my CPE, of course.
>


Likely implementing RFC 7084.

"In this role, the IPv6 CE router is responsible for ensuring that
   traffic using its ULA addressing does not go out the WAN interface
   and does not originate from the WAN interface."



> > I do have a lot of ULA, but I didn't try from within those segments,
> because I
> > was not at my office and I couldn't get there from the conference I was
> at.
> >
> >     >> Should home routers install routes to 2000::/3 when they see
> "default"
> >     >> rather
> >     >> than "::/0"?  I have made that argument, but I see the other
> point about
> >     >> how limiting it could be in the future.
> >
> >     > A ULA address at an ISP would only be reachable to customers who
> only have
> >     > GUA addresses.
> >
> >     > If a customer has ULA internally, a ULA source address would be
> preferred
> >     > over a GUA source to reach an ISP ULA (anycast) destination. That
> ULA
> >     > source address would cause the packet to be dropped by a BCP38
> filter at
> >     > the ISP access router, assuming they have them, as they should.
> >
> >     > Even if the ISP doesn't have BCP 38 filters, the ISP's routing is
> very
> >     > unlikely to have routes back to all customers' ULA address spaces.
> >
> > This is a good point you make.
> > So should home routers do BCP38 filtering on their external interface?
> > (Better to drop it early)
> >
> >     > So you need global scope anycast addresses for working source
> address
> >     > selection. Except that defeats the goal of having anycast destined
> packets'
> >     > travel being restricted to a domain smaller than global when that
> is
> >     > required or desirable.
> >
> > Do you think we need another scope of address?
>
> I think we need a better definition of scope boundaries, which clearly
> cannot be well defined just by bits in an address prefix.


That seems to have been adequate for multicast, and I think we're in a
similar problem space.

Multicast scopes are defining forwarding domains (replacing the use of the
TTL field) and are an input into source address selection. They don't
specify anything else. Things such as if the multicast group ID is IANA
defined or not is formally encoded somewhere else (T flag bit).


But I have a whole draft about that, and it's not particularly an IPv6
> problem.


I think your draft is covering the topic of network domains much more
broadly.

The forwarding domain of a packet is a specific example of the more general
idea of a network domain.

There are of course domain types that don't have much or anything to do
with a packet forwarding domain, such as a payload encryption domain.

Regards,
Mark.





>     Brian
>
>