On 2004-09-24, JINMEI Tatuya / [EMAIL PROTECTED]@C#:H wrote:
>
> I'm not sure if this version addresses the three points below I made
> in the previous last call (*)
> (*) http://www1.ietf.org/mail-archive/web/ipv6/current/msg03082.html
Hi Jinmei,
Well, I'm glad it's managed to address the rest of them!
I'm not sure if I understand your first point, though, because
I thought we'd cleared that up ... it wasn't on your later "big issues"
list ...
> > (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.
... stored where, and by who? Only neighbours actively communicating
with a node SHOULD update their NC entries, and the Optimistic NA (O=0)
won't override them. There's a tiny window of opportunity for an
Optimistic node with a duplicate address to interfere with a proxy ND
address during address resolution , but this will be sorted out by
NUD anyway. Can you give me an example of when this will cause a
problem?
> > 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.
Would "Implementations of protocols which do not explicitly define
behaviour for Optimistic Addresses should treat them equivalently
to Deprecated Addresses ..." be more or less clear?
(Or if anyone who does understand why I'm trying to say can
suggest some wording, that'd be great ...)
> > 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).
You're correct on this one, I'd meant to remove the first 'immediately'.
The rest of the text has been changed.
> I also have a couple of additional comments on new changes in version
> 02, which I think can be substantial.
>
> 1. In section 2.4:
>
> Implementing this behaviour may be difficult and unnecessary, so it
> is left as an option to the implementor.
>
> I don't really understand this sentence...what does "this behaviour"
> actually specifies? (Depending on the answer to the previous
> question) why implementing it may be difficult and unnecessary? Or as
> a meta-question, is it really adequate to asses whether implementing
> something may be difficult or not in a protocol specification?
Okay, this section is trying to explain why the fourth rule in 3.1
is only a SHOULD rather than a MUST. It's basically to cut the
implementor some slack: in a situation (mobile phones come to mind)
where communication is primarily with hosts not on your local
network, there's no need to implement this feature, and the only
penalty is that network-local communications have to wait for
DAD to complete. It's a compromise between universality and simplicity.
> 2. In section 4.2:
>
> In the course of establishing connections, the ON may send NAs either
> spontaneously or in response to received NSs.
>
> What do you mean by saying "the ON may send NAs spontaneously"? If
> this means unsolicited NAs to all-nodes multicast group, I believe we
> decided to remove that feature from the spec. In fact, no other parts
> of the 02 version talk about the unsolicited NAs. So, if this is the
> intent, we should simply remove this part and rewrite the sentence as:
>
> In the course of establishing connections, the ON may send NAs in
> response to received NSs.
We agreed that there is no point in mentioning unsolicited NAs
in OptiDAD, because they are only useful to a tiny minority.
I thought we'd agreed that it wasn't necessary to explicitly
disallow them though.
RFC 2461 7.2.6 says:
|
| In some cases a node may be able to determine that its link-layer
| address has changed (e.g., hot-swap of an interface card) and may
| wish to inform its neighbors of the new link-layer address quickly.
| In such cases a node MAY send up to MAX_NEIGHBOR_ADVERTISEMENT
| unsolicited Neighbor Advertisement messages to the all-nodes
| multicast address. These advertisements MUST be separated by at
| least RetransTimer seconds.
I guess whether that allows unsolicited NAs on arrival is open to
debate: I'd think of that as a change of LL address from nothing
to something, and a prime example of a time you might wish to inform
your neighbours of your LL address quickly.
Either way, I don't want to override 2461 on this particular thing.
> Finally, I found some editorial nits. Those are very minor and aren't
> a showstopper. (i.e., if they need to be addresses, it can be done
> later with IESG comments.)
Thanks for those, I'll clear them up too.
-----Nick
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
