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

[Bernard Aboba <[e-mail]>]

Comments below. 



> Date: Tue, 4 Nov 2008 18:11:43 -0500
> From: [e-mail]
> To: [e-mail]
> CC: [e-mail]
> Subject: Re: [dna] #9: Detailed description of ND packets
> 
> Hi Bernard,
> 
> Bernard Aboba wrote:
> > 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).  
> 
> Will do.
> 
> > 
> > "   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. 
> 
> I think this comes back to the issue on when DAD is required. 
> I do understand your point, but I still see an issue with putting the SLLAO
> in the packet when we are not reasonably sure thaFrom [e-mail]  Tue Nov  4 23:33:36 2008
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 33A193A68CD;
	Tue,  4 Nov 2008 23:33:36 -0800 (PST)
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id C5A113A68CD
	for <[e-mail]>; Tue,  4 Nov 2008 23:33:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.599
X-Spam-Level: 
X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[AWL=0.999, 
	BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 8P-pWevq2ohO for <[e-mail]>;
	Tue,  4 Nov 2008 23:33:33 -0800 (PST)
Received: from blu0-omc3-s21.blu0.hotmail.com (blu0-omc3-s21.blu0.hotmail.com
	[65.55.116.96]) by core3.amsl.com (Postfix) with ESMTP id B4D883A67B5
	for <[e-mail]>; Tue,  4 Nov 2008 23:33:33 -0800 (PST)
Received: from BLU137-W38 ([65.55.116.72]) by blu0-omc3-s21.blu0.hotmail.com
	with Microsoft SMTPSVC(6.0.3790.3959); 
	Tue, 4 Nov 2008 23:33:30 -0800
Message-ID: <[e-mail]>
X-Originating-IP: [24.16.101.127]
From: Bernard Aboba <[e-mail]>
To: Suresh Krishnan <[e-mail]>
Date: Tue, 4 Nov 2008 23:33:30 -0800
Importance: Normal
In-Reply-To: <[e-mail]>
References: <[e-mail]>
	<[e-mail]>
	<[e-mail]>
	<[e-mail]>
MIME-Version: 1.0
X-OriginalArrivalTime: 05 Nov 2008 07:33:30.0182 (UTC)
	FILETIME=[CCA3C660:01C93F18]
Cc: [e-mail]
Subject: Re: [dna] #9: Detailed description of ND packets
X-BeenThere: [e-mail]
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:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/dna>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dna>,
	<mailto:[e-mail]?subject=subscribe>
Content-Type: multipart/mixed; boundary="=======09887448="
Sender: [e-mail]
Errors-To: [e-mail]

Comments below. 



> Date: Tue, 4 Nov 2008 18:11:43 -0500
> From: [e-mail]
> To: [e-mail]
> CC: [e-mail]
> Subject: Re: [dna] #9: Detailed description of ND packets
> 
> Hi Bernard,
> 
> Bernard Aboba wrote:
> > 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).  
> 
> Will do.
> 
> > 
> > "   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. 
> 
> I think this comes back to the issue on when DAD is required. 
> I do understand your point, but I still see an issue with putting the SLLAO
> in the packet when we are not reasonably sut the address is not
> duplicated. From your mail, I see that you consider the chance of
> the address being taken by some other node as very low. I do not know
> how to quantify this in text. If I can quantify when DAD is not
> required, I think it will be very straight forward to address your 
> concern. Do you have any suggestions?

A potential suggestion:

The probing node SHOULD include a Source link-layer address option
if either:

a. the probing node has performed duplicate address detection [RFC4862]
after attachment; 

a. the probing node has previously performed duplicate address detection 
[RFC4862] for the source address included within the NS,  and the
conditions described in Section X are satisfied, so that the results of
the prior DAD are still considered valid.  

_______________________________________________
dna mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dna