comments on draft-huitema-6man-random-addresses-00

神明達哉 <jinmei@wide.ad.jp> Tue, 14 July 2015 20:22 UTC

Return-Path: <jinmei.tatuya@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A1471B2C7E for <ipv6@ietfa.amsl.com>; Tue, 14 Jul 2015 13:22:51 -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 R1Go2lBW27V2 for <ipv6@ietfa.amsl.com>; Tue, 14 Jul 2015 13:22:50 -0700 (PDT)
Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05C831B2C76 for <ipv6@ietf.org>; Tue, 14 Jul 2015 13:22:47 -0700 (PDT)
Received: by iebmu5 with SMTP id mu5so19462902ieb.1 for <ipv6@ietf.org>; Tue, 14 Jul 2015 13:22:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=DQWx0+rBfP/w3fVdtDyD8LVBjoBRU8hAU7GvBkh8eKg=; b=quWPw8A9sM/mht60Nil3X16QmE4KQHBIl4xlpJmfG628zTJhbwrooEqxV+K95Qa8vH VLGkxx7DdkGkHGer+gahCZb/228O1VTqD0odPZgKjY0EeFFh7S9lgc4TUah+qvhNCjDq VMufEV2ZMiKgbR2pv+iUbjAUhQctWroj2kkjctblOk/6nvnKDpQmXnRJv92tOY9oIQdP hSXUdzcL5t4itF4p4O1z4L9ID8lKyDNKfNozKZimGIbsWtjCYAQbChXCG7EwtBr3vXf5 U5RR+WPTvS5Uv2/m8RHfdTCELaVkNTcTv556Xih0QV6JZdBjPw0eESwb2c7HrLDnuOiX 1nrg==
MIME-Version: 1.0
X-Received: by 10.107.3.104 with SMTP id 101mr600210iod.48.1436905366468; Tue, 14 Jul 2015 13:22:46 -0700 (PDT)
Sender: jinmei.tatuya@gmail.com
Received: by 10.107.169.140 with HTTP; Tue, 14 Jul 2015 13:22:46 -0700 (PDT)
Date: Tue, 14 Jul 2015 13:22:46 -0700
X-Google-Sender-Auth: 47nhU9rhrHNWQOSMzf85VleCHzc
Message-ID: <CAJE_bqfELzqnujW80isz18RMErZ_8C+m6x+c4h_zVHjZtydqPw@mail.gmail.com>
Subject: comments on draft-huitema-6man-random-addresses-00
From: 神明達哉 <jinmei@wide.ad.jp>
To: Christian Huitema <huitema@microsoft.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/ipv6/mWs_Y8B4gM-fOC4-8hIt-w0JqwA>
Cc: IPv6 IPv6 List <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Jul 2015 20:22:51 -0000

I have a few small comments on draft-huitema-6man-random-addresses-00:

- Section 3.4:

   Tracking over time is prevented if the Net_IFace parameter is set to
   the current link layer address.  In that case, the stable addresses
   will have exactly the same lifetime as the link-layer identifiers.
   This SHOULD be the default solution for mobile hosts.

  I'm afraid this SHOULD could violate the sense of a MUST regarding
  Net_Iface of RFC7217:

   o  It MUST be constant across system bootstrap sequences and other
      network events (e.g., bringing another interface up or down).

  Although the RFC isn't very specific about "other network events",
  it seems to me that it generally intends to not change for events
  like changing a link-layer address, e.g, from the following
  statement:

   Net_Iface identifiers that are attached to the NIC, such that a
   removable NIC always gets the same IPv6 address, irrespective of the
   system communications port to which it is attached.

  I'm not making this comment to mean we cannot say that it SHOULD be
  the default, but I think it would be helpful if the draft mentions
  the implication and (if necessary) states that this draft updates
  RFC7217 in that the sense of a MUST is now loosened.

- The draft uses the term "link-local" many times.  I suspect it
  should actually be "link-layer".  One example is this:

   Using randomized link-local addresses doesn't change that.
   (Section 3.2)

- A very minor editorial nit: Section 3.5, second paragraph:
  s/is a host/if a host/
  s/configure but doen't use/configures but doesn't use/

   [...]  This is
   also true is a host uses temporary addresses and configure but doen't
   use a stable address.  The address configuration will require

--
JINMEI, Tatuya