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

Brian E Carpenter <brian.e.carpenter@gmail.com> Tue, 05 November 2013 15:35 UTC

Return-Path: <brian.e.carpenter@gmail.com>
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 A9A5721F9E36 for <v6ops@ietfa.amsl.com>; Tue, 5 Nov 2013 07:35:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.535
X-Spam-Level:
X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, 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 WzEsxY8jKDws for <v6ops@ietfa.amsl.com>; Tue, 5 Nov 2013 07:35:00 -0800 (PST)
Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 7D3D521F9DA8 for <v6ops@ietf.org>; Tue, 5 Nov 2013 07:34:59 -0800 (PST)
Received: by mail-ie0-f174.google.com with SMTP id qd12so15067166ieb.5 for <v6ops@ietf.org>; Tue, 05 Nov 2013 07:34:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=JpMBguGA6didX3hqYKflIBwgf+eORwmZ7aWDllr7X+0=; b=qU+lFw0vjONzCit7bqwONy7nAA6FwR/J172ftAYeuSKGcTrGufgrLGsIunVoQIz/n0 P4y/67VXA6WsN0AHFfs1+ipegxIFiPyZDbF3iQIX/iCzOz72p15X8yIaJUWekuAu0fsX HGdNlpOUg5ll3YAu81kc4EUP2gCCAO6hTRE03LQbIg5Ac5PSPATiSBZyxjDCYJcMXOvV LImT8ItZGFnmHCsg4+iPoOFB02orBeWWyMvKOnU2Cd0UFV9F/FqieAdMGr0kaFO5DUnI UY2SPVoc5TLfA5WQpbZE9LJo1h37gyWZ5xJKZPtJNzGGoZV/pHaDK8vZqMrX8d6y+Rj4 J5PA==
X-Received: by 10.50.16.68 with SMTP id e4mr16261231igd.12.1383665698886; Tue, 05 Nov 2013 07:34:58 -0800 (PST)
Received: from [31.133.148.174] (dhcp-94ae.meeting.ietf.org. [31.133.148.174]) by mx.google.com with ESMTPSA id v2sm2600406igz.3.2013.11.05.07.34.57 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 05 Nov 2013 07:34:58 -0800 (PST)
Message-ID: <52791025.6070601@gmail.com>
Date: Wed, 06 Nov 2013 04:35:01 +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: Mikael Abrahamsson <swmike@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> <alpine.DEB.2.02.1311051519120.26054@uplift.swm.pp.se>
In-Reply-To: <alpine.DEB.2.02.1311051519120.26054@uplift.swm.pp.se>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: Ole Troan <ot@cisco.com>, "v6ops@ietf.org" <v6ops@ietf.org>, =?UTF-8?B?56We5piO6YGU5ZOJ?= <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 15:35:00 -0000

On 06/11/2013 03:21, Mikael Abrahamsson wrote:
> 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.

>From yesterday's discussion, the outcomes seem a little more complicated
than that.

1. I think the problem statement as it stands (with the English cleaned
up) is a very useful document with two audiences:

 a) the IETF, including 6man, because it points to ambiguity in our specs;
 b) the operator community, because it warns of some very specific
    operational (mis)behaviours with currently deployed code.

Because of b) I think it needs to become an RFC quite soon.

2. Then (probably as a separate document) we need an analysis of
which problems are a result of

  a) implementation errors, which the IETF can document but not fix;
  b) differing interpretations of MAYs and SHOULDs (Fred's point),
     where the IETF could consider BCP guidance to implementors;
  c) errors or ambiguities in the standards, which 6man should fix.

     Brian