(I'm trying to make quick comments since I'll be offline for the next 10-12 hours. I'd apologize in advance for any possible typos or unclear wording, etc).
Before going to the specific ones, I'd like to present the basic logic I'd (personally) envision in this discussion. (It's my personal opinion. I know opinions may vary on this.) The most important thing is to not cause disruption for non-optimistic nodes. If there is any possibility of disruption, I basically want to confirm consensus if it is acceptable for those who implemented (and/or are operating) the "standard" behavior and is not particularly interested in implementing/operating the optimistic behavior. The logic like "this only matters in corner cases so it should be acceptable" from the side that wants to introduce the optimistic behavior is not justified, IMO. Next, if a proposed change for the optimistic behavior is controversial, then the default policy should be conservative, as long as it is crucial to make the optimistic behavior work. Again, just because it is convenient for optimistic nodes and the change *seems" to introduce a mess only in some corner cases cannot be a convincing reason. >>>>> On Mon, 26 Jul 2004 09:51:16 +1000, >>>>> "Nick 'Sharkey' Moore" <[EMAIL PROTECTED]> said: >> 1. overall, this approach depends on reasonably small reachable time >> (per Section 4.2 of RFC2461). [...] > Okay, there are two cases: An Optimistic node tries to configure > an address by sending an NS from :: and it either collides or it doesn't. > If it doesn't, there isn't a problem ... lingering NC state is a > fact of normal DAD too. > The NS from :: will not create NC state in any of the neighbours, > but other traffic sent before the collision is detected (other > NSs, RSs, NA O=0s) may create an entry if there wasn't one already. > Correspondence with neighbours may moves these entries to REACHABLE. > However, when the collision is detected, the collidee will respond > with an NA O=1 to all nodes, which will override the NC entries > and reset them to STALE. This is not really correct because duplicate can also be detected when two (colliding) nodes simultaneously perform DAD. In this case, there will be no NA with O=1. This case requires further discussion, BTW; whether we allow the advantage in the simultaneous case. If we don't, this will become a real issue; if not, we won't have to worry about this case. Also, we could perhaps say the resulting disruption may not be so harmful, since no nodes will use the duplicate address in this case. >> 2. the optimistic behavior can cause (temporary) disruption when the >> optimistic address collides with an address available via proxy ND >> (as described in section 4.2). I think we need to make an explicit >> consensus on whether this is acceptable (rather than an implicit one >> like "no objections in the last call"). Perhaps the wg session in >> San Diego is a good chance for this. > I agree: this should be discussed. > Personally, I don't think it's a big issue. The collision will still be > detected and repaired, and the Optimistic Node _will not_ override > an NC entry, even a proxy ND NC entry. Different people may have different views on this, and that's why I want to see an explicit consensus. (See also the "basic logic" above). (For that matter, I personally can live with the delay in this case though). >> 4. the optimistic behavior basically assumes routers send RAs with >> SLLAO (e.g., the first sentence of section 2). But I'm not really >> sure what the node should do if this assumption does not hold > There's nothing much they can do: they can't reliably get a reply > from the router with an NS or RS. Their only option is to wait > until they have a Preferred Address to NS or RS from: eg: wait > out the DAD timer like a normal, RFC2462-abiding node. Okay. I'll be happy if this point is clearer in the document. >> 5. I'm still not really comfortable with unsolicited NAs at the >> beginning of the optimistic DAD procedure. This can increase the >> possibility of disruption at the non-optimistic side. Since the >> typical usage of the optimistic behavior assumes RAs with an SLLAO, >> we don't really need such NAs for optimistic nodes to operate. I'd >> rather prohibit these NAs. > The unsolicited NAs will only disrupt things in a couple of tiny > corner cases (eg: #2 above). First, I don't think the logic of "this only matters in corner cases" is not justified (see the "basic logic" above). > The first unsolicited NA (O=0) is allowed because there are cases > (think predictive handovers) where the router may be buffering > traffic for the MN, but it needs some signal from the MN to inform > it of its arrival (the NS doesnt' have enough information). > The NA O=0 will be enough to get this started. It's a MAY because > its only useful in this particular case. Does that make sense? I understand the motivation, but it is not convincing enough based on my "basic logic". Also, if the motivation to optimize roaming between a mobile node and a router that has the ability to support the MN, do we really need to realize that by overloading the existing protocol mechanism, with taking a risk to cause disruption? Can't we do that with, e.g., a new ND option that only works for nodes that understand it? > The second unsolicited NA (O=1) is allowed to let the MN trump > any stale NC entries which have been preventing it from communicating, > _after_ DAD has completed. It's allowed under unmodified DAD in any > case, so I'm happy to remove it. As I said in the comment, I don't care about the second NA (O=1). It's up to you whether and how you include it in the optimistic DAD document. >> 6. In section 2.2, the draft says: >> >> [RFC2462] introduces the concept of Tentative (in 5.4) and Deprecated >> (in 5.5.4) Addresses. Addresses which are neither are said to be >> Preferred. Tentative addresses may not be used for communication, >> and Deprecated addresses should not be used for new communications. >> These status flags may also be used by other standards documents, for >> example Default Address Selection [RFC3484] uses these flags. >> >> But at least RFC2462 does not define the notion of "Tentative" or >> "Deprecated" as "flags". (and RFC3484 does not contain a word >> "flag"). > Ugh. On the one hand, implementing OptiDAD for Linux has been a > great experience in that it's provided a reality check that OptiDAD > will actually do the right thing. On the other hand, it's loaded > a set of entirely alien terminology into my brain. I'll fix the > terminology to refer to 'states' as per the the RFCs. > | These address states may also be used by other standards documents, > | for example Default Address Selection [RFC3484] treats Tentative, > | Deprecated and Preferred addresses differently. > Would that be okay? Yes, except for one thing: RFC3484 does not mention tentative. (In fact, a "tentative address" should never been assigned in an interface in theory, so it cannot be a target in RFC3484 in the first place). Also, you might want to reconsider whether "Optimistic" should be defined as a "flag", too. (e.g., section 4.1 has this phrase: "...the address's Optimistic flag is cleared..."). >> 7. In section 2.2 >> >> Protocols which do not understand this state should >> treat it equivalently to 'Deprecated', to indicate that the address >> is available for use but should not be used if another suitable >> address is available. >> >> I don't really understand what "protocols which do not understand this >> state" actually means. > Okay, so I'm introducing a new state, Optimistic. Current protocols, > eg RFC3484 mentioned above, will tell you what to do for Tentative > addresses, what to do for Deprecated addresses, what to do for > Preferred addresses. What I'm saying is that if you've never heard > of the state 'Optimistic', you should treat it equivalently to > 'Deprecated'. I think this should work okay. Okay, then referring to RFC3484 as an example might help here (note, again, that RFC3484 does not talk about tentative addresses though). >> BTW, can an application (using the standard >> socket API) perform the bind(2) system call for an optimistic address? > I hope so! Can you bind(2) a deprecated address? I've been assuming > you can, but it seems that not everyone agrees: > http://www.atm.tut.fi/list-archive/ipng/msg05111.html > It's my intention to allow bind() on Optimistic addresses. If > that doesn't fit with the "treat equivalent to Deprecated" idea, > we'll need to think of something cleverer :-) We decided in rfc2462bis to allow applications binding a deprecated address (see the second paragraph of rfc2462bis-03 Section 5.5.4). I'm not sure if it requires a change in the optimistic DAD draft though. >> 8. In section 2.2, the draft says: >> >> When the DAD timer completes without incident, >> the address becomes a Preferred address. >> >> As far as I know, no RFCs define the notion of "DAD timer". Please be >> more accurate on this. (The same comment should apply to some other >> parts of the draft). > But you know what I mean, right? Yes, but I think it is generally not a good practice to introduce an unofficial technical term (or a phrase that looks like a technical term) without providing a clear definition. Assuming the correct guess at the reader's side is naive, IMO. > I couldn't find a name for it > anywhere. Does it have a name? No, but I don't see why we cannot simply say like "When DAD completes without incident" in this case. I believe similar wording can also apply to other occurrences of "DAD timer". >> 9. 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. >> >> "SHOULD" means there can be an exception, but in this case I don't see >> a possibility of exception: what can the node do if it does not >> perform ND or forward the packet to the router? Perhaps we can simply >> say "MUST" instead of "SHOULD" here. > It could drop it on the floor, or buffer it awaiting DAD completion: > neither seem like a useful behaviour to me, but I'd rather leave it > up to the implementor whether to implement the router-redirect feature. I see. Then I'd explicitly say it's an implementation's choice, but I can also live with the current wording. >> 10. In section 3.2 >> >> * (modifies 5.4.3) A node MUST reply to a Neighbour Solicitation for >> its address from the unspecified address with a Neighbour >> Advertisement to the All Nodes address. If the solicitation is >> for an Optimistic Address, the reply MUST have the Override flag >> cleared (O=0). >> >> Does the first sentence apply to all nodes including "Standard" ones, >> or is it limited to optimistic nodes? (I'd object to this >> modification in the first place, BTW - see comment 5). > You mean #3? Still thinking about it! Oops, yes, I meant #3. Sorry about the typo. >> * (modifies 5.4.3) A node MUST reply to a Neighbour Solicitation for >> an Optimstic Address from a unicast address, but the reply MUST >> have the Override flag cleared (O=0). >> >> Just a note: this may be a controversial change (see comment 2 above). > This one is essential to establish communication while Optimistic. > Imagine I'm sending from an Optimistic Address. I can send a packet > out via my my router, but it still won't know my LLAddr. When the > reply comes back, the router must NS for me, so it can pass on > the reply. If I don't NA in response, the reply will never get to me! Yeah, I understand that, perhaps I was not clear enough...my point is that this case may cause longer disruption with proxy ND, so we first need to have a clear consensus on whether we can accept that (that's why I said "controversial" referring to comment 2). >> 12. In section 3.2 >> >> * (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) >> >> Just a note: we are going to clarify this case in rfc2462bis. Not >> sure if it requires a change to the optimistic DAD draft though. > Yeah, that'd be great. If the 2462bis text makes this redundant, > I'll remove it. The original OptiDAD draft included quite a few > things which have been made redundant by 2461bis and 2462bis! As I commented on a previous version of the Optimistic DAD draft, rfc2462bis doesn't talk about regenerating address on duplication. But rfc2462bis-03 clarifies what "disabling interface" means and when the node should disable the interface. So, perhaps we can just refer to Section 5.4.5 of RFC2462 instead of the description about disabling interface: * (modifies 5.4.5) An Optimistic Address that is determined to be a duplicate MUST be deconfigured immediately, and the node takes the action described in Section 5.4.5 of RFC2462. If rfc2462bis becomes an RFC before optimistic DAD, then we'll simply be able to update the reference to the new RFC. Meanwhile, requiring to restart DAD with a new address with a SHOULD seems to me too strong in the context of the goal for optimistic DAD. I'd prefer to mention the possibility (referring to the appendix) without using any RFC2119 keyword. >> 13. In section 4 >> >> The ON will immediately send out a Neighbour Solicitation to >> determine if its new address is already in use, and a Neighbour >> Advertisement (with the Override flag cleared) for the address. This >> NA allows communication with neighbours to begin immediately. >> >> What does "immediately" mean? Are you saying a random delay before >> the first NS (in some situation) should be removed? The same comment >> should apply to NA, while I object to sending such NAs in the first >> place (see comment 5 above). > Good point. Any changes to these delays are beyond the scope of > OptiDAD ... there are other drafts addressing them. And then we should note that optimistic DAD will create another possibility of the "first packet" which may require a random delay. >> 15. this draft uses the term "Neighbour", but for this particular term, >> I guess we should stick to the US standard "Neighbor", because the >> base documents such as RFC2461 use the latter, and people may search >> for related documents with (e.g.) "grep -i neighbor rfc*.txt". > You've got a point there. I'm an Aussie, and out of long habit I > "egrep -i neighbou?r *.txt", but I'm happy to translate > to US English if that's desired. Not everyone has egrep handy, I > realize :-) Note: while I'd like to see consistent spelling for this particular term, I personally do not care much about the dialect issue, as I said in my response to Greg. I'm just providing a suggestion, and it's up to you whether to introduce the change. >> (In this sense, I don't care about "behaviour":-) > How about "Alumini?um"? Do I have to say it funny as well :-) :-) :-) Based on the rationale of the comment, I don't care:-) >> 16. the draft uses the term "suffix" to form an address with a prefix, >> but I think it should rather be "interface identifier" based on the >> formal definition used in other IPv6 related documents. > Yeah, but it's not always an interface identifier ... 3041 and SEND > and all that. I think 'suffix' is clearer. But as far as I can see, at least RFC3041 uses the term "interface identifier", not "suffix". JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. [EMAIL PROTECTED] -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
