[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comments on RFC2462bis
Hi Jinmei,
See comments inline.
Thanks
Suresh
On Tue, 13 Jul 2004, JINMEI Tatuya / [ISO-2022-JP]
$B?@L@C#:H(B wrote:
>>>>>> 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.
==> Sounds good.
>
>> 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.
==> I see your point but this is still fuzzy.
This is what it says
====================
"Note that the "other packets" include Neighbor Solicitation
and Advertisement messages to the tentative address containing the
tentative address in the Target Address field."
This is what it actually means
==============================
"Note that the "other packets" include Neighbor Solicitation
and Advertisement messages with the tentative address as the IP
destination address and contain the tentative address in the
Target Address field."
>> If another node is simultaneously doing DAD on the same tentative
address
>> 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.
>
==> Mea culpa. Did not see that the processing stops there when the
destination is unicast.
>> 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.
>
==> I disagree. check out the following text in RFC2461bis in section
4.6.2 under the definition of prefix information option.
"A router SHOULD NOT send a prefix
option for the link-local prefix and a host SHOULD
ignore such a prefix option"
Note that this is an unqualified statement. The processing of the prefix
information whether it is for on-link or addrconf functions must obey
this.
>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).
==> I don't think 2461bis differentiates between sending and receiving in
this regard. 2461bis specifies the format of the prefix information
option in section 4.6.2. The contents of this option field specify that
that preferred lifetime MUST NOT be greater than valid lifetime
"Preferred lifetime ...
Note that the value of this field MUST NOT exceed
the Valid Lifetime field to avoid preferring
addresses that are no longer valid."
>
>> 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).
==> OK. I was more interested about the rationale behind choosing the 2
hour magic number sice the Max possible interval between router
advertisements is 30 minutes.
>
> 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
--------------------------------------------------------------------