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

Re: Comments on RFC2462bis




----- Original Message ----- 
From: "Suresh Krishnan" <suresh.krishnan@ericsson.ca>
To: "JINMEI Tatuya / 神明達哉" <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

>      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.

>
> 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.

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.

>
>
> 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.
>
> 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.
>
> Regards
> Suresh
>
>  On Mon, 12 Jul 2004, JINMEI Tatuya / [ISO-2022-JP]
> $B?@L@C#:H(B wrote:
>
> >Reminder: the following wg last call will end tomorrow (July 13th).
> >So far, I've only seen one comment in response to the last call (the
> >one from itojun about "disabling interface" on DAD failure).
> >
> >I'm afraid wg members are too busy for processing a rush of new I-Ds
> >or for writing/updating their own drafts, but if anyone of you could
> >review the document by the end of the last call, it would really be
> >appreciated.
> >
> >Right now, I'm planning to revise the draft once again before the
> >final I-D cutoff on July 19th.
> >
> >Thanks,
> >
> > JINMEI, Tatuya
> > Communication Platform Lab.
> > Corporate R&D Center, Toshiba Corp.
> > jinmei@isl.rdc.toshiba.co.jp
> >
> >>>>>> On Tue, 29 Jun 2004 06:31:13 -0400,
> >>>>>> Brian Haberman <brian@innovationslab.net> said:
> >
> >> All,
> >>       This note starts a 2 week IPv6 Working Group Last Call on:
> >
> >> Title : IPv6 Stateless Address Autoconfiguration
> >> Author(s) : S. Thomson, et al.
> >> Filename : draft-ietf-ipv6-rfc2462bis-02.txt
> >> Pages : 30
> >> Date : 2004-6-17
> >
> >> being recycled at Draft Standard.  All substantive comments should be
> >> directed to the mailing list.  Editorial comments can be directed to
> >> the mailing list or the editor.
> >
> >> This last call will end on July 13, 2004.
> >
> >--------------------------------------------------------------------
> >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
> --------------------------------------------------------------------
>



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