comments on draft-pioxfolks-6man-pio-exclusive-bit-01

神明達哉 <jinmei@wide.ad.jp> Tue, 28 March 2017 15:41 UTC

Return-Path: <jinmei.tatuya@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DD86129449 for <ipv6@ietfa.amsl.com>; Tue, 28 Mar 2017 08:41:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.702
X-Spam-Level:
X-Spam-Status: No, score=-1.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 qAofDZwoa2kD for <ipv6@ietfa.amsl.com>; Tue, 28 Mar 2017 08:41:41 -0700 (PDT)
Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (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 04DE7120725 for <6man@ietf.org>; Tue, 28 Mar 2017 08:41:37 -0700 (PDT)
Received: by mail-qt0-x233.google.com with SMTP id i34so67590547qtc.0 for <6man@ietf.org>; Tue, 28 Mar 2017 08:41:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=Z8E21qpnm/zv7mZABvom9rVN2DbS9Vn1paGg7Ayo8rY=; b=g0sRZymyXnAgoUmADWDpFCl6Aag4CRK9x0G39gjBx7FktYPZ7iaI84ok7rL4sBE7ca W2EVjSHfyrcLMSZJfU/XsXa+mz3cYyEdiVbAzqIGrYDwLJp9QGLluRAmM0q7E2n4uZKS AT1Dek9wxHEL/nkuwwL7bvuVRUPSOJXurqpO9bCqmWUASqq9Omg+sToDjfLmx2RLL5W7 vkMuI2u0nz1pZNUxRLY6DG+s5/OpxDgJBQkqzzGV3sklxRRaVXu10Q4o/tUM4zn0eyNb XUv+Z4aXKg6fCDn21YvNy8M2HJtEvUL5eL1d1+AmlCXNoyyA0d48mUE8F/ojdviq/RVW cf6A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=Z8E21qpnm/zv7mZABvom9rVN2DbS9Vn1paGg7Ayo8rY=; b=g6vuFkuo4QiciMBLHLlArFUUwGfTUYY33SKl6sqbhqBQ4whmLlIfKl52MQ5rOtL0AY qzjyo53h/Ubpi5Cr1+JMzWAr0NeOQVvzXfS2oMONOXQd3ws37Ujm2vMozPIyBEfBFrrR /1DLi9QiSfnDKevRc3w8xWVtPMP24xrCysZBdL69Qvt5uHINwLUZvhIRJA79cAzC/lSq t7ncP3IaSitnRhQEvp/tftccvX73t2gWBCPPlWMxwEwHH5N345iUu7oAivutU7xMAjfM HjfUliP6qxo9Fjvk99KbctOqCUwgQMc5NFATIp+NlChlpvnlJyl2f+aUixPgUc7x2bUS hajw==
X-Gm-Message-State: AFeK/H1d0zFutkxQYwsnpiA9wRYgX2VEHyPxXNu4Tqzqc4JLS5w9xW8uBwFKs2uuT0fQpQPbaD1hbZenyieUhA==
X-Received: by 10.237.42.194 with SMTP id t60mr29332773qtd.269.1490715695729; Tue, 28 Mar 2017 08:41:35 -0700 (PDT)
MIME-Version: 1.0
Sender: jinmei.tatuya@gmail.com
Received: by 10.237.61.204 with HTTP; Tue, 28 Mar 2017 08:41:35 -0700 (PDT)
From: 神明達哉 <jinmei@wide.ad.jp>
Date: Tue, 28 Mar 2017 08:41:35 -0700
X-Google-Sender-Auth: QfnltsKZahKcbWu9MGuQ5N0zXZI
Message-ID: <CAJE_bqfXsV1PAoT3QTU41dUV3Sa5wDNm2y7wkCLGZtZfAhWriQ@mail.gmail.com>
Subject: comments on draft-pioxfolks-6man-pio-exclusive-bit-01
To: "6man@ietf.org" <6man@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/OMCVJ3JiehZrFLMp4BG7qDUV7FM>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
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, 28 Mar 2017 15:41:42 -0000

Some random comments and questions on
draft-pioxfolks-6man-pio-exclusive-bit-01:

- What should the host do if the X flag changes from on to off?

- Is there any intent to provide a larger prefix (i.e. smaller plen)
  than the prefix whose length is used for the traditional SLAAC?  For
  example, is it part of the intended usage to advertise a /56 with
  X=on when /64 is the length for SLAAC in that link?  If so, the
  following interpretation of Section 4.2.2 may not be really
  reasonable:
   o  interpret the A bit as it it were 1 (A=1)
  In fact, the X flag allows newer hosts that understand the flag to
  do more than the traditional A flag means: the host can generate an
  address on a different interface than the receiving interface of the
  RA, and it can even re-advertise the prefix in a "downstream" link.
  This is so even if we assume the traditional SLAAC prefix length.

- Perhaps this draft should say routers SHOULD NOT set the L flag of a
  PIO if it sets the X flag.

- I don't follow the following part of section 4.2.2.2:

   from an exclusive prefix to any available interface; it is not
   required to configure the address on the link over which the PIO-X RA
   was received (i.e. it is under no obligation to form addresses such
   that they would be classified as on-link (according to the definition
   in <RFC5942> section 4, item 1).

  The item of RFC5942 is this:

   1.  The assignment of an IPv6 address -- whether through IPv6
       stateless address autoconfiguration [RFC4862], DHCPv6 [RFC3315],
       or manual configuration -- MUST NOT implicitly cause a prefix
       derived from that address to be treated as on-link and added to
       the Prefix List.  A host considers a prefix to be on-link only
       through explicit means, such as those specified in the on-link
       definition in the Terminology section of [RFC4861] (as modified
       by this document) or via manual configuration.  Note that the
       requirement for manually configured addresses is not explicitly
       mentioned in [RFC4861].

  First off, this items is not a "definition" but a requirement.
  Secondly, my interpretation of the requirement is just that we
  cannot assume a particular prefix as on-link derived from an
  address.  I don't see a clear relationship between this and the
  draft text, which states that the host can configure an address on a
  different interface.

  BTW, there's a missing closing parenthesis in the text.

--
JINMEI, Tatuya