[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comments on RFC2462bis
>>>>> On Mon, 12 Jul 2004 22:16:41 -0400 (EDT),
>>>>> Suresh Krishnan <suresh.krishnan@ericsson.ca> said:
> I have a few comments regarding 2462bis.
Thanks for the review and the comments.
In short, I'll update the draft for the first point. At the moment I
don't see the need for a revise for the rest.
> Section 2:
> Solicited-node multicast address: The draft mentions that the algorithm
> for computing this address is described in RFC2461. This is not true. The
> algorithm is described in the address architecture RFC [RFC3513]
Good catch! Apparently this is an error when the specification was
updated from RFC1971 to RFC2462. I'll correct this point in the next
revision of rfc2462bis.
> Section 5.4 DAD Page 13
> The following text makes no sense to me. Maybe I am reading this wrong but
> isn't this self contradictory
> "That is, the interface must
> accept Neighbor Solicitation and Advertisement messages containing
> the tentative address in the Target Address field, but processes such
> packets differently from those whose Target Address matches an
> address assigned to the interface. Other packets addressed to the
> tentative address should be silently discarded. Note that the "other
> packets" include Neighbor Solicitation and Advertisement messages to
> the tentative address containing the tentative address in the Target
> Address field."
No, because "the other packet" is unicasted to the tentative address
while DAD NA/NS are multicasted. I think this should be clarified in
the following part:
...
Address field. Such a case should not happen in normal operation,
though, since these messages are multicasted in the Duplicate Address
Detection Procedure.
And I do not see the need for further clarification.
> Section 5.4.3 Page 15 bullet point number 1 starting with "If a Neighbor
> solicitation for a tentative address..."
> It is stated that
> "This condition occurs when two nodes run Duplicate Address
> Detection simultaneously, but transmit initial solicitations at
> different times"
> This condition can also occur if another node has this address already
> assigned to an interface and a third node is running a neighbor
> solicitation for this address.
No, because this part is written under the assumption described in the
first paragraph of Section 5.4.3:
On receipt of a valid Neighbor Solicitation message on an interface,
node behavior depends on whether the target address is tentative or
not. If the target address is not tentative (i.e., it is assigned to
the receiving interface), the solicitation is processed as described
in RFC 2461 [5]. If the target address is tentative, and the source
address is a unicast address, the solicitation's sender is performing
address resolution on the target; the solicitation should be silently
ignored. Otherwise, processing takes place as described below. In
^^^^^^^^^
all cases, a node MUST NOT respond to a Neighbor Solicitation for a
tentative address.
> 5.5.3 Router Advertisement processing
> Bullet points b) and c) are redundant as they belong in RFC2461/2461bis
> and not here as they are not specific to autoconfiguration. Probably these
> can be removed.
I don't think the duplication is redundant in the first place, since
the processes of ND and autoconf can be done separately. For example,
RFC2461 says in Section 6.3.4 that:
Note: Implementations can choose to process the on-link aspects of
the prefixes separately from the address autoconfiguration aspects
of the prefixes by, e.g., passing a copy of each valid Router
Advertisement message to both an "on-link" and an "addrconf"
function. Each function can then operate independently on the
prefixes that have the appropriate flag set.
Besides, bullet c) does not seem to be duplicate with RFC2461.
rfc2461bis clarified this point (maily) from the sender (router) side,
but it still does not contain the validity check at the receiver's
side (and I think it's intentional).
> Bullet point e) references a DoS attack but there are no references to
> it. Maybe it makes sense to add an informative reference to it.
I don't think so. There is actually no appropriate difference since
this was discussed in the update work from RFC1971 to RFC2462. And,
in fact, detailed explanation about the attack is provided in bullet
e).
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
jinmei@isl.rdc.toshiba.co.jp
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------