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
- [dna] #9: Detailed description of ND packets dna issue tracker
- Re: [dna] #9: Detailed description of ND packets dna issue tracker
- Re: [dna] #9: Detailed description of ND packets Bernard Aboba
- Re: [dna] #9: Detailed description of ND packets Suresh Krishnan
- Re: [dna] #9: Detailed description of ND packets Bernard Aboba