Optimistic DAD Issues List 2004-08-05

(I haven't included grammatical nits and tweaks, only issues which require some thought or discussion. Thanks for all the grammatical fixes though!)

Approximate color code:
NEW Fixed Fixed, I think Made changes, but still open

# Issue Solution

04-1 Jinmei Tatuya:I don't see the strong need for the unsolicited neighbour advertisements described in Section 3.1 [...] In particular, I don't understand why we SHOULD send the unsolicited NA in the latter case. SHOULD downgraded to a MAY. Explanatory text is in (new in -01) section 2.4.
04-2 Jinmei Tatuya & Pascal Thubert Definition of Well-Distributed Address is problematic. (see 00-4)
04-3 Section 3.4 has been considered in RFC2462bis. Removed from Opti DAD.
04-4 Pascal Thubert: P11 4.4 last paragraph: routers SHOULD behave this way. I believe you should accept that you're modifying the router behaviour and word it. This is tricky. An Optimistic DAD node is still compatible with a Standard router whether or not the router includes a SLLAO in an RS, it just doesn't get a major benefit if the router doesn't include an SLLAO. [RFC2461 6.2.3] says "This option MAY be omitted to facilitate in-bound load balancing over replicated interfaces".
I've made a small update to the explanatory text to clarify this.
00-1 Pekka Savola: The draft specifies that instead of using a tentative address as the source address for RS, another address or the unspecified address should be used instead. To me, using the unspecified address would seem shortsighted, so I'd like to disallow its use in this context. (This might cause a problem, though, because I don't think the nodes typically have an another address they can use...) Use of unspecified address as source in these circumstances is default behaviour [RFC-2461 6.3.7] so this is not a problem.

00-2 Pekka Savola: I don't think the memo is clear enough how a Tentative address on an ON compares to the tentative address on a standard node? I mean, if the communication can proceed immediately, this would imply that the address should be flagged as non-tentative, or as "permanent-optimistic" (which would be seen as non-tentative outside of Neighbor Discovery). The point is, how are these addresses to be handled at RFC3484 and other documents which reference tentative vs non-tentative? The term "Optimistic Address" added to draft -01 and explained rather more thoroughly. This point actually makes implementation a whole lot easier. Section 2 revised while I'm at it.
NEW TEXT 2.2 This draft introduces a new address state, 'Optimistic', which is used to mark an address which is available for use but which has not completed DAD. 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.

00-3 Pekka Savola: IMHO, section 3.3 on Address Generation is largely redundant or downright inappropriate. It describes a few useful things, but also goes on to specify how to regenerate the addresses if a conflict is found. This is IMHO very much out of scope for oDAD. At the very least, it should be moved to an appendix, but I'd vote for removal completely. A fair bit of thought has gone into this section, but it isn't an essential requirement. I've moved it to Appendix A.

00-4 Pekka Savola: What might be useful is specifying with which kind of addresses oDAD should be assumed: e.g., those addresses with the universal bit on are a prime target. Also those addresses which are randomly generated (RFC3041 or SEND) should be OK. Manual addresses or DHCPv6 in particular should be disallowed.
Erik Nordmark: I can understand manual addresses having a higher collision probability than universal-bit autoconfigured ones (due to human error). [...] But is also isn't clear to me that the probability, even in the manual case, is high enough to warrant pessimistic mode.
Nick Moore: I (personally) tend to agree, but I (editorially) am trying to steer a course between paranoia and recklessness :-)
Erik Nordmark: Is this an implementation concern i.e. that the code which decides whether to do optimistic DAD might not know whether the address was assigned by the DHCP client or manually by an administrator?
Pekka Savola: This can be fixed by the implementation, of course, by appropriate flags for adding new addresses. A question is should this feature be spelled out if it's required by oDAD.
Ralph Droms: Doesn't seem necessary - the draft text is "Optimistic algorithm SHOULD NOT be used on manually configured addresses," which seems sufficient without telling the implementor that some method to differentiate "manually configured addresses" is required.

I have removed this requirement from the 'rules' of the draft, but retained it in the explanatory text (eg: Appendix A).

00-5 Update of boilerplate to RFC3668 etc, and move ref to 2119 out of status of this memo. Done. Seems to be correct boilerplate, and 2119 ref now in 1.3 Definitions.
00-6 An address collision with a router may cause neighbouring routers's IsRouter flags for that address to be cleared. NEW TEXT IN 2.3 An address collision with a router may cause neighbouring router's IsRouter flags for that address to be cleared. However, routers do not appear to use the IsRouter flag for anything, and the NA sent in response to the collision will reassert the IsRouter flag.

01-1 Jinmei Tatuya: A Target Link Layer Address Option is also used in an NA. Even though the document concentrates on the use for redirects, the [section 1.4] description seems a bit confusing for me. New text:
TLLAO - Target Link Layer Address Option - an option to ICMP redirect messages and Neighbour Advertisements. See [RFC2461] sections 4.4, 4.5 and 4.6.1.

01-2 Jinmei Tatuya: I'd like to see informed concent and clear consensus on the (relatively longer) possible disruption when a different node already uses the address as a proxy-ND node. To discuss at IETF-60
01-3 Jinmei Tatuya: I'd like to remove unsolicited NAs at the beginning of optimistic DAD session. (I guess we've agreed on this)
Erik Nordmark: 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. 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.
2.4 to be removed, 3.1 to be retained. Predictive handover protocols which want to send these can specify that themselves.
01-4 Jinmei Tatuya: I'd like to remove the advantage given to the optimistic node in Section 4.3. As I already pointed out, allowing the advantage can leave a hard-to-diagnose problem if the collision reason is the collision of hardware addresses (see Section 5.4.5 of draft-ietf-ipv6-rfc2462bis-03.txt). And, practically speaking, removing the advantage is not really a severe disadvantage for the optimistic node, since the collision should be rare (again, as I pointed out, I'd use the low odds of collision this way, rather than justifying further easy optimization for optimistic nodes). this is such a vanishingly unlikely situation that I'm happy to remove it simply because it's unnecessary!
01-5 Erik Nordmark: 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. Erik Nordmark: When the DAD timer completes without incident, the address becomes a Preferred or a Deprecated address based on its preferred lifetime.
01-6 Erik Nordmark: 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. ?

#	Issue	Solution
04-1	Jinmei Tatuya:I don't see the strong need for the unsolicited neighbour advertisements described in Section 3.1 [...] In particular, I don't understand why we SHOULD send the unsolicited NA in the latter case.	SHOULD downgraded to a MAY. Explanatory text is in (new in -01) section 2.4.
04-2	Jinmei Tatuya & Pascal Thubert Definition of Well-Distributed Address is problematic.	(see 00-4)
04-3	Section 3.4 has been considered in RFC2462bis.	Removed from Opti DAD.
04-4	Pascal Thubert: P11 4.4 last paragraph: routers SHOULD behave this way. I believe you should accept that you're modifying the router behaviour and word it.	This is tricky. An Optimistic DAD node is still compatible with a Standard router whether or not the router includes a SLLAO in an RS, it just doesn't get a major benefit if the router doesn't include an SLLAO. [RFC2461 6.2.3] says "This option MAY be omitted to facilitate in-bound load balancing over replicated interfaces". I've made a small update to the explanatory text to clarify this.
00-1	Pekka Savola: The draft specifies that instead of using a tentative address as the source address for RS, another address or the unspecified address should be used instead. To me, using the unspecified address would seem shortsighted, so I'd like to disallow its use in this context. (This might cause a problem, though, because I don't think the nodes typically have an another address they can use...)	Use of unspecified address as source in these circumstances is default behaviour [RFC-2461 6.3.7] so this is not a problem.
00-2	Pekka Savola: I don't think the memo is clear enough how a Tentative address on an ON compares to the tentative address on a standard node? I mean, if the communication can proceed immediately, this would imply that the address should be flagged as non-tentative, or as "permanent-optimistic" (which would be seen as non-tentative outside of Neighbor Discovery). The point is, how are these addresses to be handled at RFC3484 and other documents which reference tentative vs non-tentative?	The term "Optimistic Address" added to draft -01 and explained rather more thoroughly. This point actually makes implementation a whole lot easier. Section 2 revised while I'm at it. NEW TEXT 2.2 This draft introduces a new address state, 'Optimistic', which is used to mark an address which is available for use but which has not completed DAD. 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.
00-3	Pekka Savola: IMHO, section 3.3 on Address Generation is largely redundant or downright inappropriate. It describes a few useful things, but also goes on to specify how to regenerate the addresses if a conflict is found. This is IMHO very much out of scope for oDAD. At the very least, it should be moved to an appendix, but I'd vote for removal completely.	A fair bit of thought has gone into this section, but it isn't an essential requirement. I've moved it to Appendix A.
00-4	Pekka Savola: What might be useful is specifying with which kind of addresses oDAD should be assumed: e.g., those addresses with the universal bit on are a prime target. Also those addresses which are randomly generated (RFC3041 or SEND) should be OK. Manual addresses or DHCPv6 in particular should be disallowed. Erik Nordmark: I can understand manual addresses having a higher collision probability than universal-bit autoconfigured ones (due to human error). [...] But is also isn't clear to me that the probability, even in the manual case, is high enough to warrant pessimistic mode. Nick Moore: I (personally) tend to agree, but I (editorially) am trying to steer a course between paranoia and recklessness :-) Erik Nordmark: Is this an implementation concern i.e. that the code which decides whether to do optimistic DAD might not know whether the address was assigned by the DHCP client or manually by an administrator? Pekka Savola: This can be fixed by the implementation, of course, by appropriate flags for adding new addresses. A question is should this feature be spelled out if it's required by oDAD. Ralph Droms: Doesn't seem necessary - the draft text is "Optimistic algorithm SHOULD NOT be used on manually configured addresses," which seems sufficient without telling the implementor that some method to differentiate "manually configured addresses" is required.	I have removed this requirement from the 'rules' of the draft, but retained it in the explanatory text (eg: Appendix A).
00-5	Update of boilerplate to RFC3668 etc, and move ref to 2119 out of status of this memo.	Done. Seems to be correct boilerplate, and 2119 ref now in 1.3 Definitions.
00-6	An address collision with a router may cause neighbouring routers's IsRouter flags for that address to be cleared.	NEW TEXT IN 2.3 An address collision with a router may cause neighbouring router's IsRouter flags for that address to be cleared. However, routers do not appear to use the IsRouter flag for anything, and the NA sent in response to the collision will reassert the IsRouter flag.
01-1	Jinmei Tatuya: A Target Link Layer Address Option is also used in an NA. Even though the document concentrates on the use for redirects, the [section 1.4] description seems a bit confusing for me.	New text: TLLAO - Target Link Layer Address Option - an option to ICMP redirect messages and Neighbour Advertisements. See [RFC2461] sections 4.4, 4.5 and 4.6.1.
01-2	Jinmei Tatuya: I'd like to see informed concent and clear consensus on the (relatively longer) possible disruption when a different node already uses the address as a proxy-ND node.	To discuss at IETF-60
01-3	Jinmei Tatuya: I'd like to remove unsolicited NAs at the beginning of optimistic DAD session. (I guess we've agreed on this) Erik Nordmark: 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. 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.	2.4 to be removed, 3.1 to be retained. Predictive handover protocols which want to send these can specify that themselves.
01-4	Jinmei Tatuya: I'd like to remove the advantage given to the optimistic node in Section 4.3. As I already pointed out, allowing the advantage can leave a hard-to-diagnose problem if the collision reason is the collision of hardware addresses (see Section 5.4.5 of draft-ietf-ipv6-rfc2462bis-03.txt). And, practically speaking, removing the advantage is not really a severe disadvantage for the optimistic node, since the collision should be rare (again, as I pointed out, I'd use the low odds of collision this way, rather than justifying further easy optimization for optimistic nodes).	this is such a vanishingly unlikely situation that I'm happy to remove it simply because it's unnecessary!
01-5	Erik Nordmark: 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.	Erik Nordmark: When the DAD timer completes without incident, the address becomes a Preferred or a Deprecated address based on its preferred lifetime.
01-6	Erik Nordmark: 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.	?