Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard Thu, 16 February 2017 08:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 52BCD1295FA; Thu, 16 Feb 2017 00:39:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key); domainkeys=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wK8-nMWoxGuA; Thu, 16 Feb 2017 00:39:50 -0800 (PST)
Received: from ( [IPv6:2607:7c80:54:3::87]) by (Postfix) with ESMTP id E0345129538; Thu, 16 Feb 2017 00:39:50 -0800 (PST)
Received: from ([]) by with ESMTP; 16 Feb 2017 08:39:50 +0000
Received: from (localhost []) by (Postfix) with ESMTP id B4483D788B; Thu, 16 Feb 2017 00:39:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=O2p9p3HcDMD96FZuJy+50ZB2USY=; b= CnbF6VyI7ere0ofzOFtVZX5kYLH3GPu6Bgb7WBqVgTHMDVXmyoWeRfXVumkqfKpB Rc2hcMFTrALJGYs0WSuDC66tqhnJIQKkOZf6MKQZl4C9b9ms781Rgpa/HGWS1nAI lAjSwRSwGiSlChIbYSAEtNFk4GzlkJFTcUcR7wp6W3c=
DomainKey-Signature: a=rsa-sha1; c=nofws;; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=i5LelZqJp7EIAlVoiUyb56T oKLwTpDCeLUYq1TPYfteA8T/tVivnlG0A7t31qB6NKajZ2C0qrqqQ92+ObSIj2lN +xHP7w7kW5nvGCl7Cq0BKJFkckA/Za5oDzIUcIn2G7Qw+8UPkigzlIvSpZRbw6XR FcFjJtuwOwJVgCuB9Zj0=
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by (Postfix) with ESMTPSA id 3DA44D788A; Thu, 16 Feb 2017 00:39:49 -0800 (PST)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by (Postfix) with ESMTP id 6AE3A8BD949D; Thu, 16 Feb 2017 09:40:02 +0100 (CET)
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_C4A368FC-FA21-4D21-B1FE-97FC692845BA"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Subject: Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard
Date: Thu, 16 Feb 2017 09:40:01 +0100
In-Reply-To: <>
To: Randy Bush <>
References: <> <> <> <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3259)
Archived-At: <>
Cc: 6man WG <>, IETF-Discussion Discussion <>,,
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, 16 Feb 2017 08:39:52 -0000

Randy, Karsten, Steinar,

>>   IPv6 unicast routing is based on prefixes of any valid length up to
>>   128 [BCP198].  For example, [RFC6164] standardises 127 bit prefixes
>>   on inter-router point-to-point links.  However, the Interface ID of
>>   unicast addresses used for Stateless Address Autoconfiguration
>>   [RFC4862] is required to be 64 bits long. The rationale for the 64
>>   bit boundary in IPv6 addresses can be found in [RFC7421]
> i can live with this.

I presume the reason why you can live with it, is exactly because of the earlier pointed out loophole? :-)

You can't have it. At least not in this context. Write a draft.

See 7421, 6177, 7368, section 3.4.

There are many reasons for the 64 bit boundary.
  - Allowing identifier locator split: 8+8 / GSE that led to ILNP and NPT66
  - Simplicity in addressing (no more subnet masks)
  - A fair balance between the users and the providers of networks.
    Ensure that users get a fair share of addresses and try to avoid
    operators charging per address.

The 64 bit boundary is so embedded in the set of IPv6 specifications that it would be very hard to unravel at this point. It certainly cannot be a single paragraph put in during the advancement of 4291. Write a draft. Or write a book on protocol politics and the underlaying values reflected in the specifications...

Best regards,

PS: With an implementor hat on, I write code that can deal with any prefix length.