[v6ops] comments on draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00

神明達哉 <jinmei@wide.ad.jp> Sun, 01 November 2015 23:15 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 BC8951B31F4 for <v6ops@ietfa.amsl.com>; Sun, 1 Nov 2015 15:15:22 -0800 (PST)
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 3r6jV41_-bLG for <v6ops@ietfa.amsl.com>; Sun, 1 Nov 2015 15:15:21 -0800 (PST)
Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::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 7D4891B31F0 for <v6ops@ietf.org>; Sun, 1 Nov 2015 15:15:21 -0800 (PST)
Received: by igbhv6 with SMTP id hv6so43650946igb.0 for <v6ops@ietf.org>; Sun, 01 Nov 2015 15:15:21 -0800 (PST)
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:content-type; bh=1LHoTV+bRPwL1A2B9ed+EPMdStwWQ46qKbvepcNYV2w=; b=0/FAcAcNCZfYo8mw+ZCZP7dPx8DRerPxL0zMci/BiUWte8px3JfhkDZTT72CB10cni St83n0sAey3WOjLZR23ljwR6qzl72hdAL04Au6BRf2wVHYlU2uZ6C7oq4AIKhjlViJmC iRSCWX6AKIx6dbGOVoW0EoOnTafRcgxv7OmT+3dlpxKd55q2C9C9b5ynwiIbokteRbxk 6UUl4OZ/dofOe3/X3TtZAOJlOBVECGwQnfDwXRTEmgJIfLMP9ZW821j2IcL6tBmfTV8E K1Ta9Dts6Dxec8PQ0CMRZhI5qFgmHOzcj9Fv+AQq8o53mF/nGCt4NmfRSbT7mwGzujNk mv2g==
MIME-Version: 1.0
X-Received: by 10.50.70.1 with SMTP id i1mr8881661igu.78.1446419720961; Sun, 01 Nov 2015 15:15:20 -0800 (PST)
Sender: jinmei.tatuya@gmail.com
Received: by 10.107.140.71 with HTTP; Sun, 1 Nov 2015 15:15:20 -0800 (PST)
Date: Mon, 02 Nov 2015 08:15:20 +0900
X-Google-Sender-Auth: seyc-V3zdIy7wXZA2aTlEIDJN5I
Message-ID: <CAJE_bqei0dhr4xvngyz6OP2-T=VxE-__p1yhAoOLxAOCfNj6kQ@mail.gmail.com>
From: 神明達哉 <jinmei@wide.ad.jp>
To: "v6ops@ietf.org" <v6ops@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/IK89fdtpab9sz27OiGpmrIieD8c>
Subject: [v6ops] comments on draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00
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: <https://mailarchive.ietf.org/arch/browse/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: Sun, 01 Nov 2015 23:15:22 -0000

I have a couple of minor comments on
draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00

- Section 4.2
   [...] Since the
   address is composed by the UE/subscriber device itself it will need
   to verify that the address is unique on the shared network.

 "Since the address is composed by the UE/subscriber device itself"
 sounds like suggesting that you don't have to verify the uniqueness
 if the address is assigned via DHCPv6.  Is that the intent?  If so,
 this is not really correct per Section 5.4 of RFC4862.

- Section 5

   In an environment using DHCPv6 IA_NA for IPv6 address
   assignment this is achieved by having the AP insert an interface-id
   RFC3315 [RFC3315] in the UE/subscriber DHCPv6 Solicit message.

  Is this some new protocol extension proposed by this document?  As
  far as I know the Interface-id option is basically only expected to
  appear in Relay-forward and Reply-reply (but not Solicit) messages,
  even if RFC3315 may not explicitly prohibit other messages from
  including it.  Besides, I don't understand what "the AP insert"
  means...does this mean the AP modifies the Solicit sent by the
  client as a middlebox?  That would be a quite controversial
  behavior, and I think the document should at least clarify that
  point explicitly; or, if this is intended to say something else, it
  should probably explain it in more detail as at least I didn't get
  it.

--
JINMEI, Tatuya