On 2004-08-03, Erik Nordmark wrote: > > Overlall this is a good and important document which I'd like to > see standardized.
Thanks. I think it's getting there! > Applicability question: > I think we understand the implications of having a host use an optimistic > address. But do we know what happens should a router use an optimistic > address (to start forming neighbour adjacencies using a routing protocol) > and then discovers that the address is a duplicate? > Should we limit the applicability to hosts, or explicitly say that > routing protocols should not use optimistic addresses? I've got to admit, the thought had never even crossed my mind. Sending RAs from an Optimistic Address would definitely have bad consequences in the case of a collision ... there's no Override bit or equivalent mechanism available. Additionally, a collision could potentially redirect a whole lot of traffic to the collidee if the collider nominates it as a default router! I think we should limit the applicability to hosts, and if NEMO WG needs a router equivalent let them develop it :-) Comments anyone? > Section 2.2 says: > When the DAD timer completes without incident, > the address becomes a Preferred address. > > This isn't correct. Whether the address becomes preferred or deprecated > is a function of the preferred and deprecated lifetimes. If the preferred > lifetime is zero it will become deprecated after the DAD completes. Yeah, I changed that text at the last minute and didn't really think it through *hangs head in shame*. It's in 3.2 as well. Oh, you mention that below too ... > How about saying > When the DAD timer completes without incident, > the address becomes a Preferred or a Deprecated address based on its > preferred lifetime. OK. Jinmei was unhappy with 'DAD Timer', too ... any suggestions of how I can unambiguously explain what I mean? I don't like "when DAD completes", because I don't think it's clear enough either ... > As I pointed out elsewhere, I think we should drop section 2.4. > If some predictive scheme needs this it can be specified in the future. > This effects the text in section 4. OK. > Note that I don't see a need to prohibit unsolicited NAs with O=0, > thus the text in section 3.1 regarding them is ok. > I just don't see them as useful hence we shouldn't recommend that they be > sent. Yep, they're only useful in a particular circumstance, and that puts them fairly thoroughly beyond the scope of OptiDAD. I'd like to keep the rules about the O flag in 3.1, just to keep anyone who does implement this honest. Jinmei, would you be happy with this? > Section 2.5 says: > When the ON wants to contact another neighbour, but it cannot because > the neighbour is not in its NC, it should instead forward the packet > to the router, relying on the router to forward the packet. > > This begs the question "instead of what". Also, the ON might have other > non-optimistic addresses it can use to send a NS. > I suggest rephrasing it as > When the ON wants to contact another neighbour, but it cannot because > the neighbour is not in its NC and it has only optimistic address(es) > assigned > to the interface, then it can not send a Neighbour Solicitation message. > Instead it should send the packet > to the router, relying on the router to forward the packet. OK, good. Will do. > Section 2.6 doesn't say anything useful for an implementor. > Do we want to say that optimistic nodes should retransmit the DAD probe 3 > times? This wouldn't have much of a performance effect and it would improve > detection in the presence of packet loss. Given that optimstic support > might be common on nodes with wireless interfaces (which have higher packet > loss in many cases) this might be a reasonable improvement. Would seem okay to me ... should that be a SHOULD? > In section 3.1: > * (modifies 7.2.2) When a node has a unicast packet to send from an > Optimistic Address to a neighbour, but does not know the > neighbour's link-layer address, it MUST NOT perform Neighbour > Discovery but instead SHOULD forward the packet to the router of > that network. > > Note that the procedure of sending a NS and getting a NA is called "address > resultion" in RFC 2461. Also, since the host might have other addresses it > can use for the NS. > > I'd suggest: > * (modifies 7.2.2) When a node has a unicast packet to send from an > Optimistic Address to a neighbour, does not know the > neighbour's link-layer address, and only has optimistic addresses > assigned to the interface, it MUST NOT perform Address > Resolution by sending a Neighbour Solicitation message, > but instead SHOULD forward the packet to a default router on the link. OK, that sounds fine. > Section 3.1 says: > * When the DAD timer expires on an Optimistic Address, the > 'Optimistic' flag MUST be cleared, and the address becomes a > Preferred Address. > I suggest: > * When the DAD timer expires on an Optimistic Address, the > 'Optimistic' flag MUST be cleared, and the address becomes a > Preferred or Deprecated Address based on its preferred lifetime. Ditto. > Section 3.1 says: > * (modifies 5.4.5) An Optimistic Address that is determined to be a > duplicate MUST be deconfigured immediately. If the address is a > link-local address formed from an interface identifier based on > the hardware address (e.g. EUI-64), the interface SHOULD be > disabled. Otherwise, if the address was automatically > configured, DAD SHOULD be restarted with a new address. > (Appendix A suggests methods for generating a new address) > Since the text in RFC 2462bis is being revised, how about referring to > that document instead of duplicating a probably stale snapshot of the behavior > in this document. > > We could simply say: > * (modifies 5.4.5) An Optimistic Address that is determined to be a > duplicate MUST be deconfigured immediately, the same way > a tentative address is deconfigured when found to be a duplicate. > Further implications of an address being found a duplicate are > specified in [RFC 2462]. > (Appendix A suggests methods for generating a new address) OK. It seems like OptiDAD is actually getting _smaller_, which to my way of thinking is a good thing! > Section 4 has: > , and a Neighbour > Advertisement (with the Override flag cleared) for the address. This > NA allows communication with neighbours to begin immediately. > > I think this should be dropped if we agree that section 2.4 should be dropped. > The ON can communicate with neighbors by sending packets via a default router, > and neighbors can reach the ON my sending a NS and getting a NA with O=0. Yeah, it was intended to be a quickstart mechanism for when using predicitive handovers (circa Yokohama) and shouldn't be in here any more really. My Fast Handovers work has gone pretty thoroughly non-predictive in the meantime anyway :-) > Section 4.1: > After the appropriate DAD delay, the address's Optimistic flag is > cleared and another NA is sent, this time with O=1. This will ensure > that all Neighbour Caches are up-to-date. > > I don't see this solving any problem. If the NCEs have stale information > (for whatever reason) NUD will take care of that. And there is nothing > in the operation of optimistic DAD which will create stale information > when there is no duplicate. > Thus sending unsoliciated NAs doesn't seem to help when there is no duplicate. It was basically there because if there _is_ a stale entry hanging about, nothing the node sent while Optimistic will remove it. But there's no need for OptiDAD to specify it anyway, since it's allowed by RFC 2461 7.2.6 anyway. > Section 4.3: > In contrast, > if a node attempts to configure an Optimistic Node's Optimistic > Address, the Optimistic Node will not deconfigure the address, and > instead defend with a Neighbour Advertisement, causing the newcomer > to reconfigure. This gives the Optimistic Node a slight advantage > over Standard nodes, however this is justified since the Optimistic > node may have already established connections to Optimistic > Addresses. > > I didn't find the details of how this defense works; in fact it seems > inconsistent with the text that says when the address is found to be a > duplicate it must be deconfigured. The same way as a node would normally defend itself: with an NA for that address (which, of course, I should have said explicitly) > In any case, I think trying to defend the address to control who wins is > complex; the risk is that multiple ONs would keep on responding with NAs at > each other to try to win. So simply having the first entity winning (i.e. > reception of a NS/NA when not in tentative or optimistic doesn't make the > address a duplicate, but reception of a NS/NA in those states forces > the address to be unconfigured) should be sufficient. Yeah, this has proved rather unpopular. Originally, it was to address the concern that the ON may have invested in its new address (sending Binding Updates, that kind of thing) and so it would be better for the newcomer to change rather than the established ON. A standard node will discard a Tentative address if it gets an NA for that address OR an NS for that address from ::. Thus, in a collision between two Tentative nodes, both will discard the address. In the current OptiDAD rules, an Optimistic Address will only be discarded if an NA is received for it. If an NS from :: is received, the ON will defend the address with an NA, causing the newcomer to go away. This reflects the 'semi tentative' status of an Optimistic Address ... On the other hand, this is such a vanishingly unlikely situation (~ N/2^62, where N is the number of nodes moving into the network in DupAddrTransmits * RETRANS_TIMER) that I'm happy to remove it simply because it's unnecessary! (of course, the ON will not reconfigure an Optimistic Address if it receives an NS from a unicast address for it ... but then, either will a standard Node according to 2462. Unlike a standard node, the ON will respond to the NS with an NA O=0 rather than silently ignoring it ...) > Section 4.4: > and if two nodes configure simultaneously, they may each miss > the other's NS. > > I don't see how this can happen in standard DAD when there is no > packet loss. Well, yeah, L2 should sort them out so they can hear each other :-) > Thus I think standard DAD has problems when > - there is packet loss > - when nodes has intermittent connectivity to the link (which could > be viewed as a form of packet loss) > - then the link is partitioned (and later heals) since the DAD > process is only > run when the addresses are configured and not continiously I suspect > optiDAD has the same limitations. OptiDAD has all the limitations of Standard DAD ... it's just a bit quicker. If I was planning on reinventing this particular wheel I'd probably look at a continuous process ... but I'm sure that has its own problems, and its a quite well established wheel already :-) -----Nick -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
