Re: Proposal to further clarify prefix length issues in I-D.ietf-6man-rfc4291bis

james woodyatt <> Thu, 09 March 2017 16:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A2EE41296B2 for <>; Thu, 9 Mar 2017 08:42:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 nS11Jqo0-VQq for <>; Thu, 9 Mar 2017 08:42:43 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c00::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4E57B12959C for <>; Thu, 9 Mar 2017 08:42:43 -0800 (PST)
Received: by with SMTP id o126so30747146pfb.3 for <>; Thu, 09 Mar 2017 08:42:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=MXwhM/ooEdGdzSolpAC5twEb6/Zmzw0xcmhXUkNfC3o=; b=jh1yngQFDUaISXU4oQi08qlvX1QAxlRUyirWr99UouKZ7v0rDwr01TGR1vhjvnjEJY iT3flgJrDBgPoYRBnrp672+39LoA7s524QwsxaLAvzKjfn6pX1ubVnvY8kXXPV7fZUMM mbuur5p0jK9kexqvacRxPRahoxQS194RK0e2Hs+/H/e1xn4Rikx4x6USW1W0eQ7yHByp RwFSpwy/SFYW9rHfpLCSRlxmcBRam0tFdJ9tgb7gLpa2TDNjg0vSrZWvkqWhgnPrXAbW CP1fSglkYubNwTelSlW/Z3KxDELcpEJBRaDq21QwMkPMTl5lzfnGv+ShDpWDxeqG9h78 +8Og==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=MXwhM/ooEdGdzSolpAC5twEb6/Zmzw0xcmhXUkNfC3o=; b=SrI/vUP82XqBNd29DJtBIN0XJzmzbJ5s0HXJ/6/k22akJXAerszZj2r4XMFocKunzv SSkhn24jUV4prHmSmCUhhQCmRvrQ3JuZuqgU+fad4sgBkfDSPgEWIJzctu+7qpDjz2x1 42T4B1NH0zsyRdsMBL2TI2vqnxPW4EEHZS+3I2a4/CQy1z5AjruYmtqao+IrEgRSCSDV V8BS6cElM+QaaAIAi7auR3ZYd2bFSJaah7bY6Wz0Gpn9c0nGfpMyjpnE53g1NYKF+pxc I1388ipo46LEdOc007piQFRj73/xhb2TgsLma40q193lvmMKu6iAVm8QLYPQJQV/Ihlh vuOQ==
X-Gm-Message-State: AMke39n8u+swSAtOWd9HVi6bK6zkOhbJI/zmErCV2iuMHLZQtJ85rFsM1twLI1CXUIf5tgWJ
X-Received: by with SMTP id r18mr14567007pgd.193.1489077762614; Thu, 09 Mar 2017 08:42:42 -0800 (PST)
Received: from ?IPv6:2001:5a8:4:2290:61:8955:a321:5690? ([2001:5a8:4:2290:61:8955:a321:5690]) by with ESMTPSA id e129sm13568021pfe.8.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Mar 2017 08:42:42 -0800 (PST)
From: james woodyatt <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_386D30F5-B37F-416B-8E9B-EA57694A2873"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Subject: Re: Proposal to further clarify prefix length issues in I-D.ietf-6man-rfc4291bis
Date: Thu, 9 Mar 2017 08:42:41 -0800
In-Reply-To: <>
To: Philip Homburg <>
References: <>
X-Mailer: Apple Mail (2.3259)
Archived-At: <>
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: Thu, 09 Mar 2017 16:42:46 -0000

On Mar 9, 2017, at 03:16, Philip Homburg <> wrote:
> It seems to me that RFC 4291 uses the term interface identifier for what
> are now two separate concepts. 
> The first interface identifier concept is that for any prefix of length n,
> the length of the interface identifier is 128-n. Let me call this prefix-iid.
> The second iid concept is in auto configuration of addresses. I'll call this
> slaac-iid.
> The way I see i […]

I see it differently.

Predecessors of I-D.ietf-6man-rfc4192bis going back to RFC 2373 have provided text in the Interface Identifiers subsection defining the uniqueness properties of IIDs, and usage of that term has always been clearly limited to the part of unicast address following a subnet prefix. The part following any other unicast routing prefix has always been unnamed and unstructured, and its uniqueness properties are not those of an IID unless it is long enough to include the whole IID within it.

In my proposed clarification (both liberal and conservative versions), I preserve the distinction that subnet prefixes precede IIDs, whereas other routing prefixes, e.g. on-link prefixes, do not. If that doesn’t seem clear in my proposal for §2.4.8 Neighbor Discovery, then I could see adding text to that effect. Right now, it seems clear enough to me, so I’m holding off.

--james woodyatt < <>>