|
Comments below. > When updating the draft, kindly describe DNA procedure, especially the > link identification mechanism, more thoroughly. From the previous > discussion with Bernard, I got the impression that there are a few > things in the current draft which no longer holds such as > > o All routers on the link advertise the same subnet prefixes. > > Also Bernard informed that 'NS/NA exchange with a router confirms only > the information from that router and does not guarantee the validity > of information from other routers'. I assume this is also missing in > the draft. I agree that the document needs to more clearly describe the simple DNA mechanism. > I think there should be a way to indicate a DNA link. One question for simple DNA is whether we are attempting to determine a "link" or just connectivity to a particular router interface. This is a subtle, but potentially important difference. My impression had been that the goal was the latter. > In a DNA link, a host should be informed that simple DNA is supported > in the link. If the goal is only to determine whether a given router interface is reachable, then I don't think this is needed. > Otherwise the host has no way to determine whether to use > simple DNA or ordinary ND. Given that NUD uses unicast packets, would there be situations in which "simple DNA" is not supported on a link, but "ordinary ND" is? One of the design principles of "simple DNA" is that it is never slower than normal IPv6 address acquisition process (e.g. RS./RA + DHCPv6 if necessary). If that is true, then should not be a need to make this determination. Simple DNA is attempted, and if it fails, it fails. > The simplest way may be `when advertising > an RA, a simple DNA router should indicate that the RA is from a > simple DNA router with, for example, a DNA bit' If we start with the assumption that simple DNA should work with existing routers, then modifications like this are precluded. |