|
> Link identification mechanism is mostly described in Sec 3.5 but it only listed the cases when > 1) a solicited NA from a known test node arrives, > 2) a solicited RA with a known prefix arrives > (it's not clear whether the RA should come from a known router or not) [BA] I think it need not come from a known router. > 3) a solicited RA without a known prefix from a known router arrives. > > I can't find the paragraphs for the case > when a solicited RA without a known prefix from unknown router arrives > (which may occur the most in link change case.) [BA] I think that the case of an solicited (or unsolicited) RA coming from an unknown router needs to be discussed (whether it has a known prefix or not). My assumption is that this will result in additional addresses being configured in addition to any known addresses that may be confirmed in the simple DNA exchange. > 3. Little improvement in case of link change. > > Simple DNA optimization is mostly based on NS/NA exchange but > I am afraid that won't help for the case of link change, > i.e. when a host actually moves to a new link. [BA] I would say "not previously visited link". > IMO, DNA optimization is needed the most for such link change case, > because then the host no longer has a valid IP address and > should configure a new address as soon as possible > lest there should be communication disruption. [BA] Agreed. > According to Simple DNA, when a host moves to a new link, > it would receive no solicited NA and > should rely on a solicited RA which will arrive after random delay. > > So if the host has an on-going session, that would likely > to be disrupted. unless, by chance, > 1) the host happens to visit the currently attached link some time ago, > 2) has kept the link's information even after it detached from it and > 3) sends a NS to one of its routers with the preserved information. [BA] Steps 1-3 are at the core of DNAv4, in which the host may probe for any valid address. This approach was based on the observation that most mobile hosts move between a stable set of links over the course of the day, which often they have previously visited. As a result, they often have a valid address, yet existing TCP/IP stacks discard this address as soon as the host leaves the link. Since additional unicast NS/NA exchanges are inexpensive, DNAv4 does not restrict the host to only probing for 2 networks, because we found that it is often common for a host to have 3 or more valid addresses on various links (e.g. home, work, hotspot). > I think DNA optimization should provide some improvement > for the case of link change. From that viewpoint, I am not sure of > the suitability of NS/ NA based improvement. [BA] I would agree that Simple DNA should handle common link change cases at least as well as DNAv4 does. Overall, I think that this issue points out the need for an "Applicability" section in the Simple DNA specification, similar to that in DNAv4 Section 1.1, in order to point out exactly what the goals of Simple DNA are, and which cases it can handle. > 4. Router Modification > > The draft says that simple DNA assumes no router change. Is it > necessary? Previously router modification had been allowed. [BA] Within DNAv4, the goal was first to "do no harm" -- no degradation if the router did not support unicast ARP. The second goal was to "optimize for the common case" of a host moving between a common set of links. So my opinion would be that Simple DNA should have a similar goal: never worse than today, and better in the common case (common router behavior). > Moreover simple DNA draft mandates that routers MUST support Tentative > Option and mentions token bucket control. Isn't it a router change? [BA] I don't understand why "token bucket" control is necessary. I think the draft needs more discussion of the potential address duplication issues, so that we can understand the importance of Tentative Option support. In Simple DNA, only a valid address can be reconfirmed, so that DAD had previously completed. However, there may be circumstances in which another host had taken the address and completed DAD while the mobile host was away or asleep. This could, for example, happen in the case of privacy addresses. DNAv4 specification also mentions the case of a non-conformant DHCP server (Section 2). I would suggest a section on Duplicate Address Detection be added to go over this. One other thing. DNAv4 talks about confirmation of manually assigned addresses. Is this not also possible in Simple DNA? |