[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Comments on RFC2462bis



Hi Suresh,

    See comments inline :)

Thanks,
O.L.N. Rao


----- Original Message ----- 
From: "Suresh Krishnan" <suresh.krishnan@ericsson.ca>
To: "O.L.N.Rao" <olnrao@samsung.com>
Cc: "Suresh Krishnan" <suresh.krishnan@ericsson.ca>; <ipv6@ietf.org>;
"JINMEI Tatuya / 神明達哉" <jinmei@isl.rdc.toshiba.co.jp>
Sent: Wednesday, July 14, 2004 4:53 AM
Subject: Re: Comments on RFC2462bis


Hi Mr.Rao,
  See comments inline.

Thanks
Suresh

On Tue, 13 Jul 2004, O.L.N.Rao wrote:

>
>----- Original Message ----- 
>From: "Suresh Krishnan" <suresh.krishnan@ericsson.ca>
>To: "JINMEI Tatuya / ç¥zæ~Zé"å"?" <jinmei@isl.rdc.toshiba.co.jp>
>Cc: <ipv6@ietf.org>
>Sent: Tuesday, July 13, 2004 7:46 AM
>Subject: Comments on RFC2462bis
>
>
>> Hi Tatuya,
>> I have a few comments regarding 2462bis.
>>
>> 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]
>>
>> 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,
>
>OLN ===> Destination Address is not Tentative Address here

>==>I did not see the word destination address mentioned in the paragraph.
>Maybe that is the intention but it is not mentioned explicitly. See my
>other mail to Jinmei Tatuya regarding the wording of this sentence and
>let me know if you disagree.

OLN ==> You are right. No mention of "Destination Address".
May be I have got the meaning directly as I have implemented it :).

>
>>      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."
>>
>
>OLN ==> Definitely a stack is not supposed to pick up the packet that is
>*destined*
>                  to a *not-yet-assigned* address.

>==> True, but besides the point. I was in no way implying that the
>stack must or must not do that. Again, please check my reply to Jinmei
>Tatuya and see if you disagree. It was just a question of fuzzy wording.

OLN ==> I agree here too.  For the new reader, this paragraph is not giving
the direct intended meaning.


>
>>
>> Section 5.4.3 Page 15 bullet point number 1 sqytarting 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.
>
>In this case the node that has already assigned the address will have the
>address in permanent address list and not in the tentative address list.
>In this case, the first node (who owns address) defends the other fellows
>DAD by sending DAD-NA
>DAD-NA is NA with the DAD Performed Address in Target Address field and
sent
>to All Nodes Multicast.

==> I was not talking about the vanilla case. This was the case I was
talking about.

Assume there are three nodes A, B and C. Let's say node A has
autoconfigured address "x" and is trying to do a DAD for it. Node B has
this address assigned to one of its interfaces and node C is trying to
communicate to node B. It will send a NS to the solicited-node multicast
address of "x" which both A and B will receive.

This is no longer an issue for me since Jinmei Tatuya clarified this in
his previous mail. If the source address of the NS is an unicast the
reception procedure terminates immediately and does not continue to check
other cases. This is the part I misunderstood.

OLN ==> hmm...fine.. In this case
OLN ==> [AR - Address Resolution]
OLN ==> DAD-NS and AR-NS are just different only in SOURCE Address.
OLN ==> Anyway by this time, you might have got this difference.

[PS : DAD-NA & AR-NA are different only in DESTINATION Address, FYI]


<snipped>

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------



--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------