[DNA] Sending RS probe after link-change in simple DNA

[Julien Laganier <julien.IETF@laposte.net>]

Folks,

I see two problems with the current behavior when sending RS probe with 
simple DNA.

1. Router creating a NCE for a global address belonging to a different 
subnet:

Let's suppose the host change from link1 to link2 which have 
respectively prefixes prefix1 and prefix2 announced by router1 and 
router2. Let's suppose the RS probe sent by the host is sourced from a 
global unicast address under the prefix prefix1 obtained from the 
previous router router1, e.g. prefix1::iid.

According to RFC4861 the RS should contain a SLLAO:

>    A host sends Router Solicitations to the all-routers multicast
> address.  The IP source address is set to either one of the
> interface's unicast addresses or the unspecified address.  The
> Source Link-Layer Address option SHOULD be set to the host's
> link-layer address, if the IP source address is not the unspecified
> address.

When the router receives the RS with the SLLAO, the following happens 
according to RFC4861:

>    Router Solicitations in which the Source Address is the
> unspecified address MUST NOT update the router's Neighbor Cache;
> solicitations with a proper source address update the Neighbor Cache
> as follows. If the router already has a Neighbor Cache entry for the
> solicitation's sender, the solicitation contains a Source
> Link-Layer Address option, and the received link-layer address
> differs from that already in the cache, then the link-layer address
> SHOULD be updated in the appropriate Neighbor Cache entry, and its
> reachability state MUST also be set to STALE.  If there is no
> existing Neighbor Cache entry for the solicitation's sender, the
> router creates one, installs the link- layer address and sets its
> reachability state to STALE as specified in Section 7.3.3.

Thus since a SLLAO is present but router2 has no existing NCE for the 
host, router 2 will create a NCE for the global unicast address 
prefix1::iid although prefix1 is not on-link and not advertized on 
link2 by router2.

Isn't that a problem?

If it is that could be avoided by specifying that a simple DNA host MUST 
source its RS probes from one of its link-local addresses.

2. Problem of default router selection when moving in a NETLMM domain.

As you might know, when a host moves within a NETLMM domain, although it 
may change attachment link, it will consistently receive the same 
router advertisement in RAs sent by the NETLMM MAGs acting as default 
router.

Let's suppose a host change from link1 to link2 served by MAG1 and MAG2. 
With the currently specified behavior of a simple DNA host, if the 
prefix is the same then the host should conclude it hasn't changed 
link:

>   On reception of a Router Advertisement which contains prefixes which
> intersect with those previously advertised by a known router, the
> host utilizes the configuration associated with the detected network.

Thus after the link change the host will continue to use the 
configuration valid on link1 where the default router is MAG1. However, 
it is now attached to link2, where MAG2 should be the default router. 
Since MAG2 and MAG1 might well have different link-local addresses and 
MAC addresses. Thus, MAG2 will be added to the default router list but 
won't be selected as default router instead of MAG1. This is going to 
be a problem since host won't be able to send packets to its default 
router MAG1. Thus connectivity for the host will be disabled until NUD 
concludes MAG1 isn't reachable causing MAG2 to be selected as a new 
default router.

The DNAv6 protocol had the following provision in section 
5.2.6.3 "Router Reachability Detection and Default Router Selection" to 
make it work well with NETLMM:

>    Prior to sending a DNA RS in response to an indication of link
> change, the host SHOULD set all Neighbor Cache entries for routers
> on its Default Router List to STALE.  When the host receives an RA in
> reply to the RS, the host SHOULD mark that router's Neighbor Cache
> Entry [3] as REACHABLE, or add a Neighbor Cache Entry in the
> REACHABLE state if one does not currently exist.
>
>    The host SHOULD also update its Default Router List in the
> following fashion.  If any of the routers returning RAs are already
> on the default router list, the host SHOULD use the information in
> the RA to update the Default Route List entry with the new
> information.  The host SHOULD add entries to the Default Router List
> for any routers returning RAs that are not on the list.  The host
> SHOULD confine selection of a router from the Default Router List to
> those routers whose Neighbor Cache entries are in the REACHABLE
> state.  Note that the Default Router List SHOULD be updated as
> described here regardless of whether the RA indicates that the host
> has changed to a new IP link, since changes in router reachability
> are possible on some link types even if the host remains on the same
> IP link.

Would it be possible to adopt a similar behavior for simple DNA?

Thanks.

--julien