Subject: Unicast to routers was mark's [Thoughts and comments on draft-linkova-6man-grand-01]

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 10 Mar 2020 09:46:32 +0000

Hello Mark and Jen
 
> > As the number of routers on a link is likely and usually small, the node
> could perform the multicast packet replication itself for each router and then
> link-layer unicast the unsolicited NA to each router, per RFC6086, "Address
> Mapping of IPv6 Multicast Packets on Ethernet".
> >I think this should probably be a recommendation way to send these
> >gratuitous ND NAs, as it not only avoids link-layer multicasts entirely
> >for these gratuitous NAs, it also mitigates the security issue
> >described in the Security Considerations 3rd paragraph regarding hosts
> >announcing their new addresses. It's a better mitigation than MLD
> >snooping because that's a capability that needs to be available and
> >switched on, where as link-layer unicast is of course inherent. (It's
> >not a perfect prevention though because of the possibility of
> >link-layer Unknown DA frame flooding.)
> 
> Interesting idea. I've updated the section 2.1. However I'm not sure it should
> be the recommended approach as it relies on the fact that the host has the
> full list of routes.

I believe that this one is worth digging. 

Maybe the node cannot know the list of all routers, but the routers should be able to know each other. 
They could share the state intelligently, e.g., store it primarily on the access routers, couple it with load balancing or what-else, up to the routers.

The NA could be sent unicast to the router that advertised the PIO; in a simple scenario with a single router that's enough. In a more complex scenarios, up to the routers to share.
The NA could also be sent to a link-local "any router that does this new thing" anycast address, there are similarities with RFC 6275. I do not see why we could not make it work as well.

In this process the interesting piece is for the routers to discover each other and share capabilities and information such as NCEs. Hello?

All the best;

Pascal

---

From: Jen Linkova <[email-masked]>
Date: Thu, 12 Mar 2020 14:41:45 +1100

> They could share the state intelligently, e.g., store it primarily on the access routers, couple it with load balancing or what-else, up to the routers.

Oh. Adding more state on routers? If it's just to solve the problem
described in the draft it looks like an overkill to me. If all
first-hop routers are expected to sync the state with neighbors,
then I'd rather suggest that "the first packet received from a
SLAAC-enabled interface or from a subnet the router sends PIO for
triggers an ND for its source address if the address is not in the
cache already, and then the state is synchronized with other routers".
(draft-ietf-v6ops-nd-cache-init-02 will have more text on cons and
pros of that approach).

> The NA could be sent unicast to the router that advertised the PIO; in a simple scenario with a single router that's enough.

That would requite router <> PIO information on hosts - that (and Rule
5.5 of the default address selection support) would be great, but it's
not happening ;(

>In a more complex scenarios, up to the routers to share.

It sounds like what you are suggesting is to develop a standard
protocol to sync state between routers. It's not like I'm against it,
I just think it's a much bugger scope of work.
If that protocol exists I agree it should be enough to send a NA to a
single router.

-- 
SY, Jen Linkova aka Furry