Re: IPv6 address assignment for strictly point-to-point links and Device Loopbacks

Ole Trøan <> Wed, 26 September 2012 08:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C041421F845B for <>; Wed, 26 Sep 2012 01:36:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.519
X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=-0.220, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9qTcvEX+uGbK for <>; Wed, 26 Sep 2012 01:36:16 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 235B421F8455 for <>; Wed, 26 Sep 2012 01:36:16 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id 96D0A5E10; Wed, 26 Sep 2012 01:36:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h= content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; s=selector1; bh=G0krfStPk9S442FaZxw8P mEkl5E=; b=tGz876L6vRAKQ4jPR+lu0T6jdVdI2p+QxPxupEKQ3JaGEpv7TnEjK to/qK7Sn7ESyaNnVsZ7UHCHd48/AZfPpVgrtRTrSGon1ZMPAPMb89GA9ncNea9qp 4lpPpPv2pM8F4TL2bXhNVcg1mjtvLT6CRDV7ZUzFMrY+CAqJZgLkMA=
DomainKey-Signature: a=rsa-sha1; c=nofws;; h= content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; q=dns; s=selector1; b=AZvo4MlMC29XWV2 M173/oumEiiEmUoy7N2iRE90+8UZQraJMFSta8STAB91lTkgcjNepL60VBL69QSR 28V8cBUHlOWDT8m0BHj2/J59019O1xR7/I1Sllz0APIKz0WZHsno9bxPYw9Yce7g Nmff3hsN95l7JWffvHVfIt1S8oZ4=
Received: from ( []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by (Postfix) with ESMTPSA id 791A55D91; Wed, 26 Sep 2012 01:36:14 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_ACA9C84F-371B-4742-9B2F-E07FF25CFEDD"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\))
Subject: Re: IPv6 address assignment for strictly point-to-point links and Device Loopbacks
From: =?iso-8859-1?Q?Ole_Tr=F8an?= <>
In-Reply-To: <>
Date: Wed, 26 Sep 2012 10:36:11 +0200
Message-Id: <>
References: <>
To: Usman Latif <>
X-Mailer: Apple Mail (2.1498)
Cc: "" <>
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 26 Sep 2012 08:36:16 -0000

> Also its a good idea to encompass recommendations for p2p and loopbacks (and for that matter any assignment where prefix length is going beyond /64 into smaller subnets) into one standard track because the cautions and potential overlap issues that may exist for a /127 would pretty much be similar for /128 or any prefix that goes into the lower-64 bit territory...

> One major concern I have with using /127 and /128 on p2p and loopbacks respectively is that we need to be careful that there are existing (ISATAP etc) and potentially future implementations that would use/reserve bits in the lower 64 bits -so unless we set aside bit boundaries in the lower 64 bits, we are likely to overlap with these... which is why if we use /127 with a whole /64 reserved for the p2p subnet, then it should be okay but if /127 or /128s are numbered from the same /64 consecutively, then obviously its likely that the reserved bits used by other implementations would overlap. When this happens, any scenario where the router (which has this overlap) is SRC/DST of packets would be confused whether to interpret those lower-64 bits as simple global unicast prefix or try to treat the lower-64 bits in a different way (according to the protocol implementation which is using that bit pattern).

a few general points:
 - the 64 bit boundary is a "policy". implementations should handle any prefix length.
   implementations should, and as far as I know do, consider all bits in the address as transparent.
 - a loopback interface using a /128 cannot by definition overlap with anything else. 
 - for a point to point link the operator should know if there applications at either of two end points requiring the use of
   reserved addresses, if so the link must use a /64 otherwise /127 is fine.

these are operational choices, and I don't see a need to change IPv6 addressing architecture or protocol specifications.