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

Brian E Carpenter <> Tue, 05 November 2013 15:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A9A5721F9E36 for <>; Tue, 5 Nov 2013 07:35:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.535
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WzEsxY8jKDws for <>; Tue, 5 Nov 2013 07:35:00 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c03::22e]) by (Postfix) with ESMTP id 7D3D521F9DA8 for <>; Tue, 5 Nov 2013 07:34:59 -0800 (PST)
Received: by with SMTP id qd12so15067166ieb.5 for <>; Tue, 05 Nov 2013 07:34:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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 with SMTP id e4mr16261231igd.12.1383665698886; Tue, 05 Nov 2013 07:34:58 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id v2sm2600406igz.3.2013. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 05 Nov 2013 07:34:58 -0800 (PST)
Message-ID: <>
Date: Wed, 06 Nov 2013 04:35:01 +1300
From: Brian E Carpenter <>
Organization: University of Auckland
User-Agent: Thunderbird (Windows/20070728)
MIME-Version: 1.0
To: Mikael Abrahamsson <>
References: <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: Ole Troan <>, "" <>, =?UTF-8?B?56We5piO6YGU5ZOJ?= <>, "" <>
Subject: Re: [v6ops] new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.