Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard

神明達哉 <> Fri, 24 February 2017 22:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 25823129529; Fri, 24 Feb 2017 14:24:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KuiFEDVPDvSV; Fri, 24 Feb 2017 14:24:43 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c0d::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A7595129525; Fri, 24 Feb 2017 14:24:43 -0800 (PST)
Received: by with SMTP id b16so28194295qte.0; Fri, 24 Feb 2017 14:24:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=cQMj9L8UtavpiAntJeVZV9DrUh0+PnpvJVLmLDuTtoM=; b=kWvtkfwYJiFSaR5sF0WJPQeuKOpH5bhLPMGrKRTTWkfOY9tgiegmEvJFMyhb7yDOZ8 nuIW6ZJUCULLP5PaivN0yfjrgoHwM/huEsd54j+P1g2NQdsA6kYIBLGW0NnC6qhX+b8z PkNVoUfHsNasBEVH4y5Vj4JwmTAmnYSw+zCTsr8LAh6QV1+/+cRca8y6HIXPHyVTE1NW AQsHZMyE0y0xHHeIqeHQ6YrkjiTwSm+tvHsQ/j6WbYXr5ZrKHEMYcht1br1wpRTLpnbT MRROhdBuEZPkus6t+/dGKQ/YBSjmDkOXJLuUozRLTrN8G0UgxVYa4kTN76YNuXA20hdY QuMg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=cQMj9L8UtavpiAntJeVZV9DrUh0+PnpvJVLmLDuTtoM=; b=GXVtDEpDt1+gpDbwE2DYjgx2/BfisEGniZ7gFyVDfHDr/2VM0qeMxwtePtjdCfi3d4 5DOY9K3X2v+Aa85F2FTZpnDEljC4OyRgWiLtRg/YIs0J41LCCb71NfbAmgWaE31M/EKE u9E72exOpYgGtu0wk1hJo4CzxBHhCb6eq/aoPzpKakwQWYvw6iA3Iq0U0IRi05o/4TaT RjVRs1RlEhJdYsxT4F+sFSDJpYpc/DaeQ/7aZum7GrfjCvhxF5brUtcq4FECHEjnMu4F rI1/W4eHNS7La9Zfs8PR4zx+yjHa/NcLJccMwI6yXIiENpXBxm2DOd4MTFCMCoOKXrTu pc+g==
X-Gm-Message-State: AMke39kq/h2pR0cWxDNJVBto5znJEHGbd/jRGYAlCZwHMxNbEi+PyxLpG+UPwTRpEEE0RvtSdAqZB+VJaA88Xg==
X-Received: by with SMTP id o28mr5627443qto.269.1487975082503; Fri, 24 Feb 2017 14:24:42 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Fri, 24 Feb 2017 14:24:41 -0800 (PST)
In-Reply-To: <>
References: <20170221001940.GB84656@Vurt.local> <> <20170221101339.GC84656@Vurt.local> <> <54c81141-e4f5-4436-9479-9c02be6c09bb@Spark> <> <> <> <4936e96b-fc82-4de0-9188-ced9547deb2f@Spark> <> <> <> <> <> <> <> <> <> <> <>
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= <>
Date: Fri, 24 Feb 2017 14:24:41 -0800
X-Google-Sender-Auth: B2ZgJMh9L3S-hbU00aeu6n1Xzak
Message-ID: <>
Subject: Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard
To: David Farmer <>
Content-Type: text/plain; charset=UTF-8
Archived-At: <>
Cc: 6man WG <>, IETF-Discussion Discussion <>, Fernando Gont <>,,
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 24 Feb 2017 22:24:45 -0000

At Fri, 24 Feb 2017 02:20:09 -0600,
David Farmer <> wrote:

> >    IPv6 unicast routing is based on prefixes of any valid length up to
> >    and including 128 [BCP198].  However, subnet prefixes of 64 bits in
> >    length are REQUIRED for use with Stateless Address Autoconfiguration
> >    (SLAAC)[RFC4862] and are RECOMMENDED for all other general purpose
> >    use. The rationale for the 64 bit boundary in IPv6 addresses can be
> >    found in [RFC7421].
> >
> > Except RFC4862(SLAAC) does not say anywhere that 64 bits long IIDs are
> > required.
> > Only mention I find of 64 is given as an example for EUI-64 for ethernet
> > links.
> I believe most implementations of SLAAC require /64, but I could be wrong.

I don't know about "most implementations", but at least BSD variants
don't unconditionally require /64 for the IID (and therefore prefix)
length of SLAAC.  It literally implements what RFC4862 states:

   interface identifier -  [...]  The
      exact length of an interface identifier and the way it is created
      is defined in a separate link-type specific document that covers
      issues related to the transmission of IP over a particular link
      type (e.g., [RFC2464]).

That is, for the SLAAC implementation the length of the IID is a
parameter per link-type, not a magic constant value of 64.  And, as
specified in RFC2464, the value for Ethernet links is defined to be
64.  For an external observer it may not be distinguishable from the
magic number is hardcoded as if required for the entire
implementation, but the actual implementation is far from that.

So, aside from whether the above text is good in the main context of
this thread, just to make it more accurate it should be, e.g.:

    IPv6 unicast routing is based on prefixes of any valid length up to
    and including 128 [BCP198].  However, subnet prefixes of 64 bits
    are REQUIRED for use with Stateless Address Autoconfiguration
    (SLAAC)[RFC4862] in some link types such as Ethernet [RFC2464]. [...]

BTW, I think your idea of separating the implementation guidance and
operational guidance can be a compromise.  If I correctly interpret
the interests of main stake holders in this thread, these are:

- some educated adults (aka "operators") want to be allowed to
  configure there IPv6 addresses with an arbitrary IID (and therefore
  arbitrary length of subnet prefix).  and they don't want rfc4291bis
  to explicitly ban such an operation
- some implementers want to be allowed to write code that only allows
  64-bit IIDs for IPv6 addresses (except those that start with the
  binary value 000) to configure for that implementation.  and they
  don't want rfc4291bis to make such an implementation non-compliant.
- maybe some others also want to use the existence of such
  implementations as leverage to refuse ISPs offering very small size
  of subnet.

If I'm correct that these are main concerns, text like your proposal
seems to meet these even if no one is completely satisfied.

JINMEI, Tatuya