IETF Logo Mail Archive

Re: FW: New Version Notification for draft-hsingh-6man-enhanced-dad-01.txt

Brian E Carpenter <brian.e.carpenter@gmail.com> Sat, 15 October 2011 19:18 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A478021F8A69 for <ipv6@ietfa.amsl.com>; Sat, 15 Oct 2011 12:18:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.319
X-Spam-Level:
X-Spam-Status: No, score=-103.319 tagged_above=-999 required=5 tests=[AWL=0.280, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 35c2e+hiQA4O for <ipv6@ietfa.amsl.com>; Sat, 15 Oct 2011 12:18:38 -0700 (PDT)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8402B21F8A64 for <ipv6@ietf.org>; Sat, 15 Oct 2011 12:18:38 -0700 (PDT)
Received: by bkas6 with SMTP id s6so1967090bka.31 for <ipv6@ietf.org>; Sat, 15 Oct 2011 12:18:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=uJwYpwxuvBNqbWoncgkEOEf7QH1PIDnM80f2r8Dx5fo=; b=cY+Rb+t/GCtuSzQ54Q4MVZxYWQwu7LkXEYgM6ZWyh2FRHTA73zw4dpRUmzXK6c4gMF E8CXoy2jRYfKYlsA5YlUPUh+22oZcERz415IhcRp8msYezj7YZ4o5JsByowwak3ZYBey 5mv/xdy4xxuUE3vfve08b5s286IijVBpuLAA8=
Received: by 10.223.63.75 with SMTP id a11mr12671250fai.9.1318706317587; Sat, 15 Oct 2011 12:18:37 -0700 (PDT)
Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id r6sm12107896fam.0.2011.10.15.12.18.33 (version=SSLv3 cipher=OTHER); Sat, 15 Oct 2011 12:18:36 -0700 (PDT)
Message-ID: <4E99DC84.2080001@gmail.com>
Date: Sun, 16 Oct 2011 08:18:28 +1300
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: "Hemant Singh (shemant)" <shemant@cisco.com>
Subject: Re: FW: New Version Notification for draft-hsingh-6man-enhanced-dad-01.txt
References: <5B6B2B64C9FE2A489045EEEADDAFF2C3030A436F@XMB-RCD-109.cisco.com> <4E98B7AE.9050103@forthnet.gr> <5B6B2B64C9FE2A489045EEEADDAFF2C3031303AC@XMB-RCD-109.cisco.com> <4E98C626.2060102@forthnetgroup.gr> <4E98C933.4040402@gmail.com> <4E98D102.3060601@forthnetgroup.gr> <5B6B2B64C9FE2A489045EEEADDAFF2C3031303DE@XMB-RCD-109.cisco.com> <4E99734C.5050304@forthnetgroup.gr> <5B6B2B64C9FE2A489045EEEADDAFF2C303130411@XMB-RCD-109.cisco.com>
In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C303130411@XMB-RCD-109.cisco.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: IPv6 WG Mailing List <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 15 Oct 2011 19:18:39 -0000

Answering Tassos' question specifically, if the use of the flow label for
ND/DAD requires a signalling phase to tell the other end the flow label
value in use, it is clearly out of scope for 3697bis. (Not forbidden,
just not described.)

However, I can't imagine how you would signal anything before
performing neighbour discovery.

I thnk it's just orthogonal to 3697bis. The usage of the flow label
in link-local scope before completing address assignment doesn't seem to me
to be constrained by 2460, 3697 or 3697bis.

However, I agree that 20 bits is small for a nonce. It puts you into
birthday-paradox territory on a LAN with a few hundred nodes.

   Brian

On 2011-10-16 01:55, Hemant Singh (shemant) wrote:
> I certainly don’t believe so.   The usual use of Flow Label seems to assume the labeled packet traverses more than one hop.  After all, the typical use of the Flow Label is to let each hop know what processing to do based on the Flow Label.   However, a link-local domain whose traffic is restricted to within one link with no traversal across a router/hop, the Flow Label does not have a hop-by-hop use but certainly if some information needs to be provided to all nodes the flow label can be used.  But such information is best provided by the control protocol of ND used in the link.  So why overload the Flow Label.   Anyway, some folks may not like the small size of 20 bits to be used in a nonce .
> 
>  
> 
> Hemant
> 
>  
> 
> From: Tassos Chatzithomaoglou [mailto:achatz@forthnetgroup.gr] 
> Sent: Saturday, October 15, 2011 7:50 AM
> To: Brian E Carpenter
> Cc: Hemant Singh (shemant); IPv6 WG Mailing List
> Subject: Re: FW: New Version Notification for draft-hsingh-6man-enhanced-dad-01.txt
> 
>  
> 
> Also, looking at draft-ietf-6man-flow-3697bis-07, i can see the following under introduction:
> 
> A stateful
>    scenario is one where a node that processes the flow label value
>    needs to store information about the flow, including the flow label
>    value. 
> 
> ...
> 
>    The flow label can be used most simply in stateless scenarios.  This
>    specification concentrates on the stateless model and how it can be
>    used as a default mechanism.  Details of stateful models, signaling,
>    specific flow state establishment methods and their related service
>    models are out of scope for this specification.  
>  
> 
> Does this mean that the usage of flow label on ND/DAD is out of scope of 3697bis?
> 
> --
> Tassos
> 
> 
> 
> 
>

v2.23.0 | Report a Bug | By Email