IETF Logo Mail Archive

Re: [v6ops] new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem

Mikael Abrahamsson <swmike@swm.pp.se> Tue, 05 November 2013 14:21 UTC

Return-Path: <swmike@swm.pp.se>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2610011E80E6 for <v6ops@ietfa.amsl.com>; Tue, 5 Nov 2013 06:21:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
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 ruIg+kWOG+IZ for <v6ops@ietfa.amsl.com>; Tue, 5 Nov 2013 06:21:52 -0800 (PST)
Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id DE3F411E8141 for <v6ops@ietf.org>; Tue, 5 Nov 2013 06:21:49 -0800 (PST)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 7E465A1; Tue, 5 Nov 2013 15:21:48 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 74D229C; Tue, 5 Nov 2013 15:21:48 +0100 (CET)
Date: Tue, 05 Nov 2013 15:21:48 +0100
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: Ole Troan <ot@cisco.com>
In-Reply-To: <15A60E31-DAD1-4E72-8E27-52868FAF9203@cisco.com>
Message-ID: <alpine.DEB.2.02.1311051519120.26054@uplift.swm.pp.se>
References: <201310211245.r9LCj0B29668@ftpeng-update.cisco.com> <alpine.DEB.2.02.1311050427070.26054@uplift.swm.pp.se> <CAJE_bqcsqpeERWmgaC5xW9J_zpBJYCGeVzQmF7y2Ki3jG+AVag@mail.gmail.com> <alpine.DEB.2.02.1311051251410.26054@uplift.swm.pp.se> <15A60E31-DAD1-4E72-8E27-52868FAF9203@cisco.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
Cc: "v6ops@ietf.org" <v6ops@ietf.org>, 神明達哉 <jinmei@wide.ad.jp>, "draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org" <draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org>
Subject: Re: [v6ops] new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Nov 2013 14:21:53 -0000

On Tue, 5 Nov 2013, Ole Troan wrote:

>> Yes, I know this is about address configuration. I am still curious if all OSes keep the /64 interface route when A changes to 0 (or is 0 to begin with). If you feel this is out of scope that's fine, then my curiosity will stay unanswered.
>
> in the nit-picking department, wouldn't that really be the L flag?

Well, my question was for L=1, A=1, A=1 -> A=0, and A=0 cases. In case the 
implementor got the addressing generation mixed up with the route stuff.

Are there test suites for all this stuff that implementors can use? What 
should come out of this eventually is a document where all 
states/transitions should be tested and the document should say exactly 
what is the expected behaviour.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se

v2.23.0 | Report a Bug | By Email