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

[Suresh Krishnan <[e-mail]>]

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 that 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 thinkFrom [e-mail]  Tue Nov  4 15:13:38 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 E6FED3A69D4;
	Tue,  4 Nov 2008 15:13:38 -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 4623A3A6A96
	for <[e-mail]>om>; Tue,  4 Nov 2008 15:13:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.453
X-Spam-Level: 
X-Spam-Status: No, score=-6.453 tagged_above=-999 required=5 tests=[AWL=0.146, 
	BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 rf6F3FwLO2Z5 for <[e-mail]>om>;
	Tue,  4 Nov 2008 15:13:37 -0800 (PST)
Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9])
	by core3.amsl.com (Postfix) with ESMTP id 7890E3A69D4
	for <[e-mail]>rg>; Tue,  4 Nov 2008 15:13:37 -0800 (PST)
Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se
	[138.85.77.50])
	by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id mA4NFLsR018306;
	Tue, 4 Nov 2008 17:15:21 -0600
Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.53]) by
	eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 4 Nov 2008 17:13:25 -0600
Received: from [142.133.10.113] ([142.133.10.113]) by
	eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 4 Nov 2008 17:13:25 -0600
Message-ID: <[e-mail]>
Date: Tue, 04 Nov 2008 18:11:43 -0500
From: Suresh Krishnan <[e-mail]>
User-Agent: Thunderbird 2.0.0.17 (X11/20080925)
MIME-Version: 1.0
To: Bernard Aboba <[e-mail]>
References: <[e-mail]>
	<[e-mail]>
	<[e-mail]>
In-Reply-To: <[e-mail]>
X-OriginalArrivalTime: 04 Nov 2008 23:13:25.0845 (UTC)
	FILETIME=[F0A94850:01C93ED2]
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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: [e-mail]
Errors-To: [e-mail]

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 that 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 wi it will be very straight forward to address your 
concern. Do you have any suggestions?

Thanks
Suresh

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


ll be very straight forward to address your 
concern. Do you have any suggestions?

Thanks
Suresh

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