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

神明達哉 <> Wed, 06 November 2013 19:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6AF5E21E817B for <>; Wed, 6 Nov 2013 11:24:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.222
X-Spam-Level: *
X-Spam-Status: No, score=1.222 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id N7YuKFtp5yzw for <>; Wed, 6 Nov 2013 11:24:07 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c00::22c]) by (Postfix) with ESMTP id EBD5421E80C3 for <>; Wed, 6 Nov 2013 11:24:06 -0800 (PST)
Received: by with SMTP id n12so5423921wgh.35 for <>; Wed, 06 Nov 2013 11:24:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=3qbJLDOdeOwj6Zc7eiWYdsmRhEWx0aLCBkzwXhs8C4A=; b=A2hByxEDvgN7ExVTB41crTz61CtbhLRj/6/RZgeaT4SifaJdSOJhhDWCInTsEkOn2u C9jjfEzzuioUAl6d5J6wIqidWstEgw48w235UUQHWrmOhumbBsOy0q0OHYn2UXx0Lpbq QydodpFuA8fHbPx1aeKZzQJ2/16PkwVQIOnfJ7feafzEQxeghIvbrcKGnY8f4CiBTXW6 u3+GtOxiS+EAzzqn92mM3KgjVM9QU6pAz0vZhgKSSSABrHwOPBr9+cSoMVVjgBua+Vsq NrtvjJpPUZsFGSnZkjld6u2NYkXcYc83cCfODHKI5LGKtT1j4b/0m195SoanSvLUTdwr i30Q==
MIME-Version: 1.0
X-Received: by with SMTP id n8mr22466923wiy.0.1383765846030; Wed, 06 Nov 2013 11:24:06 -0800 (PST)
Received: by with HTTP; Wed, 6 Nov 2013 11:24:05 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <>
Date: Wed, 6 Nov 2013 11:24:05 -0800
X-Google-Sender-Auth: PCA0IPuBaIH1xj_wi-QwLy17lfs
Message-ID: <>
From: =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= <>
To: Mikael Abrahamsson <>
Content-Type: text/plain; charset=ISO-8859-1
Cc: Ole Troan <>, "" <>, "" <>
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: Wed, 06 Nov 2013 19:24:09 -0000

At Tue, 5 Nov 2013 15:21:48 +0100 (CET),
Mikael Abrahamsson <> 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.

I don't understand exactly what this means: "L=1, A=1, A=1 -> A=0, and
A=0".  If you mean something like this

1. a host first receives a prefix information option for a /64 prefix with
   L=1 and A=1
2. the host then receives a prefix information option of the same /64
   prefix with L=1 and A=0

I believe almost all implementations create a direct route for the /64
as well as an address or more using the prefix at step 1.

According to the draft, Windows 7 "deprecate"s (its precise meaning is
not really clear but doesn't matter much here) the address.  All other
implementations listed in the draft do nothing for the address.

I don't know Windows 7 or other implementations do for the /64 direct
route at step 2, but I believe nothing happens on at least all others
than Windows 7.  Perhaps an interesting question is what happens to
the direct route if we keep receiving the L=1 and A=0 prefix
information option and the corresponding address eventually expires.
Unless it has changed recently, BSD variants should still keep the /64
route.  I don't know about Linux; I don't know if iOS works as other
BSD variants on this regard either.

> Are there test suites for all this stuff that implementors can use? What

I think some of such scenarios are covered in TAHI test suites

JINMEI, Tatuya