|
> 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. [BA] I think that makes sense. > 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. [BA] This is wrong. Previous configuration should only be reused if the RA originates from a router corresponding to a valid address. An RA originating from another router should be processed normally. > 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. [BA] I agree that something along these lines should be included in the Simple DNA spec. I would also suggest that a router responding to a unicast NS be marked as REACHABLE. > > 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? [BA] I think it would be possible (and desirable). |