G'day Jinmei,
thanks for your comments. I'm working my way through the
list, here's some initial thoughts.
> My substantial comments are basically based on the view that we only
> accept this kind of approach if the impact on non-optimistic
> implementations is limited very carefully and as small as possible.
I'd agree with this: that's the intention of the draft and I
won't be happy with it if it doesn't.
-----
> 1. overall, this approach depends on reasonably small reachable time
> (per Section 4.2 of RFC2461). If this value happens to be set to a
> large value (say, a few to 10 minutes?) via RA, a duplicate
> link-layer address of an optimistic node can mistakenly be stored
> for the unreasonaly large period. While this is a general issue on
> the reasonable value of reachable time, I think this draft should
> explicitly note that since it is going to modify the existing
> protocol and affect implementations. Perhaps we even need to define
> the upper limit of reachable that to allow the optimistic behavior.
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.
(please let me know if I'm missing the point entirely)
-----
> 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. I probably need to amend
the wording of the text: it isn't clear that section 4.2 paras
4 and 5 are linked and that the slow, NUD case only occurs
"If a neighbour is just preparing to begin communication with the
address" AND "the defending NA has the Override flag cleared".
Editorially, it needs to be discussed and I agree an explicit
consensus would be good. I'll add it to the issues list, and
bring it up at San Diego.
-----
> 3. I don't think the advantage for the optimistic node when two nodes
> simultaneously perform DAD is justified (Section 4.3).
> [...]
> So, I'd request to simply remove the special privilege.
(I'm still thinking about this one ... I'll put it on the issues list)
-----
> 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.
> (the last paragraph of Section 4.4 talks about this a little bit,
> but it's still unclear and I'm not sure if this applies to the
> entire behavior or it is just limited to the particular section).
Okay, I'll try and expand the text there. Suggestions welcome.
-----
> 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).
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?
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.
-----
> 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?
-----
> 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.
> 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 :-)
-----
> 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? I couldn't find a name for it
anywhere. Does it have a name?
If you can point out other places where I've used non-defined
terminology that'd be handy: it's a bad habit of mine (as per
my 'flag' gaffe above ...)
> Additionally, even after the DAD procedure (successfully), the address
> does not necessarily become a preferred one; the preferred lifetime
> can be 0 from the beginning. (The same comment should apply to
> Section 3.2)
A good point which I hadn't considered at all :-) I'll have
to have a think about this.
-----
> 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.
-----
> 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!
> * (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!
(oh, and I see I made a typo there ... )
-----
> 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!
-----
> 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.
-----
> 14. In section 4.1
>
> The Optimistic Node already has the link-layer address of the router
> (from the RA), and the router either already knows the link-layer
> address of the ON from the unsolicited NA, or can determine it
> through standard NUD.
>
> I don't understand how the router can determine the link-layer address
> through NUD...do you mean "ND" here?
Yes, ND. Oops. Now I'm confusing even myself.
-----
> 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 :-)
> (In this sense, I don't care about "behaviour":-)
How about "Alumini?um"? Do I have to say it funny as well :-) :-) :-)
-----
> 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.
-----
> 17. there appears to be a mixture on the notation between "an SLLAO" and
> "a SLLAO". Those should be consistent. Also, if "an" is the
> intended one, I guess phrase "a NC" (which occurs several times in
> the draft) should actually be "an NC".
Argh! Like apostrophes, that's invisible to me. I'll grep through and
standardize them.
-----
Thanks again for your comments, I hope we can iterate this a couple
of times before the session and get some mutual consensus (even if we
still disagree, at least we'll know exactly what we disagree about!)
-----Nick
--
Nick Moore, Resarch Fellow | <[EMAIL PROTECTED]>
Monash University CTIE | <http://www.ctie.monash.edu.au/ipv6/>
Australian Telecommunications CRC | <http://www.telecommunications.crc.org.au/>
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
