IETF Logo Mail Archive

Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC

神明達哉 <jinmei@wide.ad.jp> Mon, 20 October 2014 18:13 UTC

Return-Path: <jinmei.tatuya@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A355F1A8A08 for <v6ops@ietfa.amsl.com>; Mon, 20 Oct 2014 11:13:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.978
X-Spam-Level:
X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MqHVTVpiNyHT for <v6ops@ietfa.amsl.com>; Mon, 20 Oct 2014 11:13:00 -0700 (PDT)
Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BADA1A8A86 for <v6ops@ietf.org>; Mon, 20 Oct 2014 11:12:59 -0700 (PDT)
Received: by mail-wi0-f180.google.com with SMTP id em10so7094233wid.13 for <v6ops@ietf.org>; Mon, 20 Oct 2014 11:12:58 -0700 (PDT)
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=wd+RFhrdjbn0GbujmskFSfGVxys/YVN9QpUYECGRQr8=; b=CiG8fsih3k9RBCqtT87ryL498Wt94h9CoA8AqO5TXzJ9FKUbHZAGc51U+HBtEHL8+n Y3umTk9/ENPU1wDBd24NKdFxBtXn586CWRSBIncKQuO0/xOsu3TtyRkWJDw8cJdjs208 SIg8wtICnZ/9XM4v0vDpsXcKYLX8qFRzA8TxnH/GQiiqx02oDMrcxquR9GQ0twJ2Wo9D S9L1LWWBszS0zpeGXPx+QRe/WFL+xSCCCx8jc+dwNH9KHqQx8wwRpijqgn0ko9oF2TYW NiQrmqvFEaiWNTHh0DDU9v8gURNCGaqAvKtq/qWcU5RAgljTVIlsZmQYso16PdQHcEez tg1Q==
MIME-Version: 1.0
X-Received: by 10.194.58.8 with SMTP id m8mr36129978wjq.43.1413828778605; Mon, 20 Oct 2014 11:12:58 -0700 (PDT)
Sender: jinmei.tatuya@gmail.com
Received: by 10.194.79.202 with HTTP; Mon, 20 Oct 2014 11:12:58 -0700 (PDT)
In-Reply-To: <201410191800.s9JI02XP029920@irp-lnx1.cisco.com>
References: <201410191800.s9JI02XP029920@irp-lnx1.cisco.com>
Date: Mon, 20 Oct 2014 11:12:58 -0700
X-Google-Sender-Auth: 6RY_UiLpe_mwbuzpko71ToveZyQ
Message-ID: <CAJE_bqdb7NJKj99ToDz0r9AbGD_jMo_FzXaiE6__Uj1bTTj11A@mail.gmail.com>
From: 神明達哉 <jinmei@wide.ad.jp>
To: "Fred Baker (fred)" <fred@cisco.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/1z_4FiC2AbFo4TxbjCSfRb6i4dI
Cc: "v6ops@ietf.org" <v6ops@ietf.org>
Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
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: Mon, 20 Oct 2014 18:13:01 -0000

At Sun, 19 Oct 2014 11:00:02 -0700,
fred@cisco.com wrote:

> This is to initiate a two week working group last call of
> http://tools.ietf.org/html/draft-ietf-v6ops-dhcpv6-slaac-problem.
> Please read it now. If you find nits (spelling errors, minor suggested
> wording changes, etc), comment to the authors; if you find greater
> issues, such as disagreeing with a statement or finding additional
> issues that need to be addressed, please post your comments to the
> list.
>
> We are looking specifically for comments on the importance of the
> document as well as its content. If you have read the document and
> believe it to be of operational utility, that is also an important
> comment to make.

I have a mixed feeling about the importance of the document.  I
personally don't think it worth publishing in its current form,
although I wouldn't be opposed to it if the wg thinks it's useful.

Vagueness and ambiguity regarding M, O, and A flags (especially the
first two) are well known, and it's not surprising that different
implementations behave differently.  Since such a divergence can cause
a critical operational issue, I see a value in documenting these.

On the other hand, the specific issues described in Section 3.2 don't
seem to be very critical to me.

In the case described in Section 3.2.1, the host would only have
link-local addresses.  Such a host wouldn't be able to do many useful
things anyway (potentially, there may be some interesting scenarios
for a completely isolated, single-link, autonomous network with only
link-local addresses, but I suspect there are many other fundamental
issues to solve for such environments before we even worry about the
M/O/A flags).

The issues described in Section 3.2 seem to be caused largely because
they switch the address configuration mechanism (SLAAC to DHCPv6 or
vice versa) in addition to renumbering.  While that could happen in
theory, it seems to be a quite artificial discussion.

Actually, I guess there should be more pragmatic examples of
operational issues because of the described divergence and I wonder
whether these minor cases are really the only things we can imagine
(although I don't have a specific idea right now).  If these sections
can be revised with more convincing examples, I would be more
supportive about publishing it.

Some specific comments (mostly editorial and nits) on the draft text:

- Section 1:

   The M, O and A
   flags are advisory, not prescriptive.

  In my understanding, the A flag is quite prescriptive.  If a host
  implementation doesn't perform SLAAC for a prefix information option
  with A flag on, that implementation would be considered
  non-compliant.  At the very least, the level of "advisory" vs
  "prescriptive" is much different between M,O and A, so listing all
  of them in this sentence seems to be misleading, if not simply
  incorrect.

- Section 2.1: s/setting/settings/

   [...]  The following setting are all allowed:

- Section 2.2: s/setting/settings/

   [...]  The following setting are all
   allowed:

--
JINMEI, Tatuya

v2.23.0 | Report a Bug | By Email