Re: [dna] #9: Detailed description of ND packets

"Bernard Aboba" <Bernard_Aboba@hotmail.com> Mon, 03 November 2008 23:48 UTC

Return-Path: <dna-bounces@ietf.org>
X-Original-To: dna-archive@lists.ietf.org
Delivered-To: ietfarch-dna-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0E403A6CB6; Mon, 3 Nov 2008 15:48:18 -0800 (PST)
X-Original-To: dna@core3.amsl.com
Delivered-To: dna@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17C523A6CB1 for <dna@core3.amsl.com>; Mon, 3 Nov 2008 15:48:18 -0800 (PST)
X-Quarantine-ID: <ezN71oxqL0A1>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID"
X-Spam-Flag: NO
X-Spam-Score: -2.248
X-Spam-Level:
X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.351, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ezN71oxqL0A1 for <dna@core3.amsl.com>; Mon, 3 Nov 2008 15:48:17 -0800 (PST)
Received: from bay0-omc3-s32.bay0.hotmail.com (bay0-omc3-s32.bay0.hotmail.com [65.54.246.232]) by core3.amsl.com (Postfix) with ESMTP id E3F2528C366 for <dna@ietf.org>; Mon, 3 Nov 2008 15:48:12 -0800 (PST)
Received: from hotmail.com ([10.4.31.16]) by bay0-omc3-s32.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 Nov 2008 15:48:11 -0800
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 3 Nov 2008 15:48:11 -0800
Message-ID: <BLU137-DAV68DDCBA5CA1C8A39E4083931D0@phx.gbl>
Received: from 131.107.0.103 by BLU137-DAV6.phx.gbl with DAV; Mon, 03 Nov 2008 23:48:05 +0000
X-Originating-IP: [131.107.0.103]
X-Originating-Email: [bernard_aboba@hotmail.com]
X-Sender: bernard_aboba@hotmail.com
From: Bernard Aboba <Bernard_Aboba@hotmail.com>
To: dna@ietf.org, suresh.krishnan@ericsson.com
References: <066.f169d2d63fdb2387bcc420998f59f2e8@tools.ietf.org> <075.51e61ab87e8f5373a0968495907d2543@tools.ietf.org>
In-Reply-To: <075.51e61ab87e8f5373a0968495907d2543@tools.ietf.org>
Date: Mon, 03 Nov 2008 15:48:05 -0800
Message-ID: <006401c93e0e$9db922b0$d92b6810$@com>
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ack9WTgjYBgnvGIRStyhs3+j2CDP2gAs+nrw
Content-Language: en-us
X-OriginalArrivalTime: 03 Nov 2008 23:48:11.0045 (UTC) FILETIME=[A11FCD50:01C93E0E]
Subject: Re: [dna] #9: Detailed description of ND packets
X-BeenThere: dna@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNA working group mailing list <dna.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dna>, <mailto:dna-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/dna>
List-Post: <mailto:dna@ietf.org>
List-Help: <mailto:dna-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dna>, <mailto:dna-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: dna-bounces@ietf.org
Errors-To: dna-bounces@ietf.org

There is an issue in Section 4.5.1.  This section should also describe the
link layer addresses in the NS packet, to make clear that the NS is
sent to the previously cached link layer address of the router (NOT to
a multicast address).  

"   The probing node SHOULD NOT include a Source link-layer address
   option if it has not performed duplicate address detection [RFC4862],
   for the source address of the NS, on the newly attached link."

In DNAv4 (RFC 4436), the goal was not only to detect network attachment, but
also to establish bi-directional reachability.  By not including the Source
link-layer address, Simple DNA does not achieve this goal. 

Assuming that the NS is sent to a unicast MAC address of the target router,
it will not
be received unless the host is attached to the router from which it had
previously 
obtained an address.  Assuming that the host had previously done duplicate
address
detection and that the address is still presumed operable (e.g. this wasn't
done so
long ago as to be uselesFrom dna-bounces@ietf.org  Mon Nov  3 15:48:18 2008
Return-Path: <dna-bounces@ietf.org>
X-Original-To: dna-archive@ietf.org
Delivered-To: ietfarch-dna-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id E0E403A6CB6;
	Mon,  3 Nov 2008 15:48:18 -0800 (PST)
X-Original-To: dna@core3.amsl.com
Delivered-To: dna@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 17C523A6CB1
	for <dna@core3.amsl.com>; Mon,  3 Nov 2008 15:48:18 -0800 (PST)
X-Quarantine-ID: <ezN71oxqL0A1>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID"
X-Spam-Flag: NO
X-Spam-Score: -2.248
X-Spam-Level: 
X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.351, 
	BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id ezN71oxqL0A1 for <dna@core3.amsl.com>;
	Mon,  3 Nov 2008 15:48:17 -0800 (PST)
Received: from bay0-omc3-s32.bay0.hotmail.com (bay0-omc3-s32.bay0.hotmail.com
	[65.54.246.232])
	by core3.amsl.com (Postfix) with ESMTP id E3F2528C366
	for <dna@ietf.org>; Mon,  3 Nov 2008 15:48:12 -0800 (PST)
Received: from hotmail.com ([10.4.31.16]) by bay0-omc3-s32.bay0.hotmail.com
	with Microsoft SMTPSVC(6.0.3790.3959); 
	Mon, 3 Nov 2008 15:48:11 -0800
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	Mon, 3 Nov 2008 15:48:11 -0800
Message-ID: <BLU137-DAV68DDCBA5CA1C8A39E4083931D0@phx.gbl>
Received: from 131.107.0.103 by BLU137-DAV6.phx.gbl with DAV;
	Mon, 03 Nov 2008 23:48:05 +0000
X-Originating-IP: [131.107.0.103]
X-Originating-Email: [bernard_aboba@hotmail.com]
X-Sender: bernard_aboba@hotmail.com
From: "Bernard Aboba" <Bernard_Aboba@hotmail.com>
To: <dna@ietf.org>,
	<suresh.krishnan@ericsson.com>
References: <066.f169d2d63fdb2387bcc420998f59f2e8@tools.ietf.org>
	<075.51e61ab87e8f5373a0968495907d2543@tools.ietf.org>
In-Reply-To: <075.51e61ab87e8f5373a0968495907d2543@tools.ietf.org>
Date: Mon, 3 Nov 2008 15:48:05 -0800
Message-ID: <006401c93e0e$9db922b0$d92b6810$@com>
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ack9WTgjYBgnvGIRStyhs3+j2CDP2gAs+nrw
Content-Language: en-us
X-OriginalArrivalTime: 03 Nov 2008 23:48:11.0045 (UTC)
	FILETIME=[A11FCD50:01C93E0E]
Subject: Re: [dna] #9: Detailed description of ND packets
X-BeenThere: dna@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNA working group mailing list <dna.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dna>,
	<mailto:dna-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/dna>
List-Post: <mailto:dna@ietf.org>
List-Help: <mailto:dna-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dna>,
	<mailto:dna-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: dna-bounces@ietf.org
Errors-To: dna-bounces@ietf.org

There is an issue in Section 4.5.1.  This section should also describe the
link layer addresses in the NS packet, to make clear that the NS is
sent to the previously cached link layer address of the router (NOT to
a multicast address).  

"   The probing node SHOULD NOT include a Source link-layer address
   option if it has not performed duplicate address detection [RFC4862],
   for the source address of the NS, on the newly attached link."

In DNAv4 (RFC 4436), the goal was not only to detect network attachment, but
also to establish bi-directional reachability.  By not including the Source
link-layer address, Simple DNA does not achieve this goal. 

Assuming that the NS is sent to a unicast MAC address of the target router,
it will not
be received unless the host is attached to the router from which it had
previously 
obtained an address.  Assuming that the host had previously done duplicate
address
detection and that the address is still presumed operable (e.g. this wasn't
done so
long ago as to be useless), ths), then there is no risk of neighbor cache
pollution.  
Either the NS packet vanishes into space, or it is received by the router to
which
it was addressed, with little risk of neighbor cache pollution. 

Given this, it would seem to me that in any situation in which an NS probe
would be
recommended, the Source link-layer address should be included.  Where
duplicate
address detection was never performed, or where it is no longer valid, there
is
no address to confirm, so that doing simple DNAv6 doesn't make sense. 
  



-----Original Message-----
From: dna-bounces@ietf.org [mailto:dna-bounces@ietf.org] On Behalf Of dna
issue tracker
Sent: Sunday, November 02, 2008 6:10 PM
To: suresh.krishnan@ericsson.com
Cc: dna@ietf.org
Subject: Re: [dna] #9: Detailed description of ND packets

#9: Detailed description of ND packets
------------------------------------------+---------------------------------
 Reporter:  suresh.krishnan@ericsson.com  |        Owner:  Suresh Krishnan
     Type:  defect                        |       Status:  closed         
 Priority:  major                         |    Milestone:                 
Component:  simple                        |      Version:                 
 Severity:  Active WG Document            |   Resolution:  fixed          
 Keywords:                                |  
------------------------------------------+---------------------------------
Changes (by suresh.krishnan@ericsson.com):

  * status:  new => closed
  * resolution:  => fixed


Comment:

 4.5.  Contents of the Neighbor Discovery messages

 4.5.1.  Neighbor Solicitation messages

    This section describes the contents of the neighbor solicitation
    probe messages sent during the probing procedure.

    Source Address:           A link-local address assigned to the
                              probing host.

    Destination Address:      The link-local address of the router being
                              probed as learnt from the SDAT.

    Hop Limit:                255

    ND Options:

    Target Address:           The link-local address of the router being
                              probed as learnt from the SDAT.

    The probing node SHOULD NOT include a Source link-layer address
    option if it has not performed duplicate address detection [RFC4862],
    for the source address of the NS, on the newly attached link.

 4.5.2.  Router Solicitation messages

    This section describes the contents of the router solicitation probe
    message sent during the probing procedure.

    Source Address:           A link-local address assigned to the
                              probing host.

    Destination Address:      The all-routers multicast address.

    Hop Limit:                255

    The probing node SHOULD NOT include a Source link-layer address
    option if it has not performed duplicate address detection [RFC4862],
    for the source address of the NS, on the newly attached link.

-- 
Ticket URL: <http://svn.tools.ietf.org/wg/dna/trac/ticket/9#comment:1>
dna <http://tools.ietf.org/dna/>

_______________________________________________
dna mailing list
dna@ietf.org
https://www.ietf.org/mailman/listinfo/dna

_______________________________________________
dna mailing list
dna@ietf.org
https://www.ietf.org/mailman/listinfo/dna


en there is no risk of neighbor cache
pollution.  
Either the NS packet vanishes into space, or it is received by the router to
which
it was addressed, with little risk of neighbor cache pollution. 

Given this, it would seem to me that in any situation in which an NS probe
would be
recommended, the Source link-layer address should be included.  Where
duplicate
address detection was never performed, or where it is no longer valid, there
is
no address to confirm, so that doing simple DNAv6 doesn't make sense. 
  



-----Original Message-----
From: dna-bounces@ietf.org [mailto:dna-bounces@ietf.org] On Behalf Of dna
issue tracker
Sent: Sunday, November 02, 2008 6:10 PM
To: suresh.krishnan@ericsson.com
Cc: dna@ietf.org
Subject: Re: [dna] #9: Detailed description of ND packets

#9: Detailed description of ND packets
------------------------------------------+---------------------------------
 Reporter:  suresh.krishnan@ericsson.com  |        Owner:  Suresh Krishnan
     Type:  defect                        |       Status:  closed         
 Priority:  major                         |    Milestone:                 
Component:  simple                        |      Version:                 
 Severity:  Active WG Document            |   Resolution:  fixed          
 Keywords:                                |  
------------------------------------------+---------------------------------
Changes (by suresh.krishnan@ericsson.com):

  * status:  new => closed
  * resolution:  => fixed


Comment:

 4.5.  Contents of the Neighbor Discovery messages

 4.5.1.  Neighbor Solicitation messages

    This section describes the contents of the neighbor solicitation
    probe messages sent during the probing procedure.

    Source Address:           A link-local address assigned to the
                              probing host.

    Destination Address:      The link-local address of the router being
                              probed as learnt from the SDAT.

    Hop Limit:                255

    ND Options:

    Target Address:           The link-local address of the router being
                              probed as learnt from the SDAT.

    The probing node SHOULD NOT include a Source link-layer address
    option if it has not performed duplicate address detection [RFC4862],
    for the source address of the NS, on the newly attached link.

 4.5.2.  Router Solicitation messages

    This section describes the contents of the router solicitation probe
    message sent during the probing procedure.

    Source Address:           A link-local address assigned to the
                              probing host.

    Destination Address:      The all-routers multicast address.

    Hop Limit:                255

    The probing node SHOULD NOT include a Source link-layer address
    option if it has not performed duplicate address detection [RFC4862],
    for the source address of the NS, on the newly attached link.

-- 
Ticket URL: <http://svn.tools.ietf.org/wg/dna/trac/ticket/9#comment:1>
dna <http://tools.ietf.org/dna/>

_______________________________________________
dna mailing list
dna@ietf.org
https://www.ietf.org/mailman/listinfo/dna

_______________________________________________
dna mailing list
dna@ietf.org
https://www.ietf.org/mailman/listinfo/dna