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

Usman Latif <> Thu, 27 September 2012 00:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3664F21F8610 for <>; Wed, 26 Sep 2012 17:08:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.852
X-Spam-Status: No, score=-1.852 tagged_above=-999 required=5 tests=[AWL=-0.173, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_SORBS_WEB=0.619]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PDE+VCNEzTUo for <>; Wed, 26 Sep 2012 17:08:09 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id 4BD8A21F85F7 for <>; Wed, 26 Sep 2012 17:08:09 -0700 (PDT)
Received: from [] by with NNFMP; 27 Sep 2012 00:08:06 -0000
Received: from [] by with NNFMP; 27 Sep 2012 00:08:06 -0000
Received: from [] by with NNFMP; 27 Sep 2012 00:08:06 -0000
X-Yahoo-Newman-Property: ymail-3
Received: (qmail 61288 invoked by uid 60001); 27 Sep 2012 00:08:06 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=s1024; t=1348704486; bh=/1pb2I4O5HKf1fiaR5sQbRbhN15Db9xdRgNiB2KO9Ew=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=RkavkoDwKMB2ZmljdTy2zs9i87gBZjTAGbvEysN2j5OYj7yNu9jEZ4HjUnYhqxxm61laf5oBix3sQwoN42eJ7iDElOk3cXLJX1GD0CvcHEJxKbjAoXYmRMCYttEQGaq00qzrwVpu7Mhn4E9oOd3wDF8w9BzVPlhf6of5qTHKTFE=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024;; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=onoxUchN6Y8MkydIL2R5sndSGD/Zh5BtkycOlz8opTeSIiwYLqNC4QJVEVmnoaznTTa00zR07celZPNOEvcW/eWo29GWujdvXqaLEFSOtmjpi1P1kqyMHK2ncRpZNvx92cs0tGE8tSdzpcflYd4uizzkKoeI4WJORTjLrO8a/sY=;
X-YMail-OSG: aMjiNCMVM1kc87UFjOoKWgStEwbBaQV5Mfbz1.2q3JFagzJ hvUf.iBbzDaluvopJGgVce6MhqHbL7nYxGcwZlB9i9H0KmpVT.ztSucrM7QN xjFtdLtuysCwrWLafqvZpAoSmyMKURGI.vgYj4qocuu21sAJuc5ucw7lHIRQ P1GdkG9y9_ksmpQzsFevPOM6.Jxh3su4ROnOm7uSUuBUYkbqqARrRnBXYdB9 hdN03Lr0PlrrhQTovHAPxE52b3khcWwzH8z_R6LO.XB.odr3kSEdQrI0xBny SYgSHFgU2M4R_96KwBKFV_KpDLBWn3cIDmAqfNiLh7ZVtPh9VSCx6gu.DmRG 6Io0.rbcepaFRtLDkiPUi2pe2BzIwJ_uy0BM9tQmq2cT1xIhRZjimDUfvFNf jd9Hqx7Mih_6nqGTnJhHkAjkiW6ozkc8wzDCFy.lHwqUsygDF..9pQHdsmVy vYadQ4lAh0zuQ8qXMFfXA3._iqNFMat8ScLwUhCo0I1ZNyKPWIOScQ0gGrxW RUWi8itnckkWWvQ--
Received: from [] by via HTTP; Wed, 26 Sep 2012 17:08:06 PDT
X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/
Message-ID: <>
Date: Wed, 26 Sep 2012 17:08:06 -0700 (PDT)
From: Usman Latif <>
Subject: Re: IPv6 address assignment for strictly point-to-point links and Device Loopbacks
To: =?iso-8859-1?Q?Ole_Tr=F8an?= <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="1833503604-188053447-1348704486=:49402"
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: Thu, 27 Sep 2012 00:08:10 -0000

I am not trying to stir up a debate over something that only "I" feel
There is clearly two set of recommendations over the same addressing scenario which I am only trying to clarify with the IETF community.

RFC 6164 has recommendations that do not encompass all the recommendations that were put forward in RFC 5375

So although when RFC 6547 moved the RFC 3627 to historical status, it completely ignored that RFC 5375 has additional recommendations for the same /127 and /128 addressing scenarios.

What I am now trying to clarify is - should we consider recommendations in RFC 5375 (section B.2) as obsolete ? 

When the two set of recommendations for /127 assignment i.e. one coming from RFC 6164 and the other coming from RFC 5375 are competing with each other, should we ignore those in 5375 and only comply with 6164

For those who feel that manual (and consecutive) assignment of /127 for p2p links from the same /64 or /128 for loopbacks from the same /64 subnet is not going to cause any overlap - I would recommend to read section B.2 of RFC 5375 and then provide some comments afterwards.

--- On Wed, 26/9/12, Ole Trøan <> wrote:

From: Ole Trøan <>
Subject: Re: IPv6 address assignment for strictly point-to-point links and Device Loopbacks
To: "Usman Latif" <>
Cc: "Randy Bush" <>om>, "" <>
Received: Wednesday, 26 September, 2012, 1:06 PM

> 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.