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

神明達哉 <jinmei@wide.ad.jp> Wed, 06 November 2013 19:24 UTC

Return-Path: <jinmei.tatuya@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 6AF5E21E817B for <v6ops@ietfa.amsl.com>; Wed, 6 Nov 2013 11:24:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N7YuKFtp5yzw for <v6ops@ietfa.amsl.com>; Wed, 6 Nov 2013 11:24:07 -0800 (PST)
Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id EBD5421E80C3 for <v6ops@ietf.org>; Wed, 6 Nov 2013 11:24:06 -0800 (PST)
Received: by mail-wg0-f44.google.com with SMTP id n12so5423921wgh.35 for <v6ops@ietf.org>; Wed, 06 Nov 2013 11:24:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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 10.180.83.40 with SMTP id n8mr22466923wiy.0.1383765846030; Wed, 06 Nov 2013 11:24:06 -0800 (PST)
Sender: jinmei.tatuya@gmail.com
Received: by 10.194.120.167 with HTTP; Wed, 6 Nov 2013 11:24:05 -0800 (PST)
In-Reply-To: <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> <alpine.DEB.2.02.1311051519120.26054@uplift.swm.pp.se>
Date: Wed, 6 Nov 2013 11:24:05 -0800
X-Google-Sender-Auth: PCA0IPuBaIH1xj_wi-QwLy17lfs
Message-ID: <CAJE_bqedUhEpTx+11WxrJWqR52jAETqN_QvNk3u2AMSk4=X8iA@mail.gmail.com>
From: =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= <jinmei@wide.ad.jp>
To: Mikael Abrahamsson <swmike@swm.pp.se>
Content-Type: text/plain; charset=ISO-8859-1
Cc: Ole Troan <ot@cisco.com>, "v6ops@ietf.org" <v6ops@ietf.org>, "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: Wed, 06 Nov 2013 19:24:09 -0000

At Tue, 5 Nov 2013 15:21:48 +0100 (CET),
Mikael Abrahamsson <swmike@swm.pp.se> 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
(http://www.tahi.org/).

--
JINMEI, Tatuya