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

[JinHyeock Choi <jinchoe@gmail.com>]

Dear Julien

About your concerns,
we don't have to worry about the first one, a false NCE creation.

In simple DNA, RS/ NS messages use a Tentative Option, instead of SLLAO.
So there would not happen a false NCE.

It's more complex for your second concern, non valid router address.

Simple DNA is not based on link identification anymore,
i.e. it doesn't determine whether a host remains at the same link or not.

Instead simple DNA just verifies the validity of an address (or addresses)
by confirming reachability with the routers which is associated with
the address.

It is still unclear how simple DNA verify other IP configuration parameters
such as router address, prefix or MTU.

Kindly find my inline comments.

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

However, in simple DNA, RS would contain Tentative option,
instead of 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?

No. Because the RS comes not with SLLAO but tentative option,
this would not happen.

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

this is a problem. Maybe we should recommend that

Upon every DNA operation,
a host should re-affirm it's default router address & perform DAD,
even it turns out that the host remains at the same link.

best regards

JinHyeock