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

Usman Latif <> Thu, 27 September 2012 01:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A81CC21F8443 for <>; Wed, 26 Sep 2012 18:03:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.967
X-Spam-Status: No, score=-1.967 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.619]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5nWYJoonFxdT for <>; Wed, 26 Sep 2012 18:03:32 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id D6F1721F8441 for <>; Wed, 26 Sep 2012 18:03:31 -0700 (PDT)
Received: from [] by with NNFMP; 27 Sep 2012 01:03:20 -0000
Received: from [] by with NNFMP; 27 Sep 2012 01:03:20 -0000
Received: from [] by with NNFMP; 27 Sep 2012 01:03:20 -0000
X-Yahoo-Newman-Property: ymail-3
Received: (qmail 27082 invoked by uid 60001); 27 Sep 2012 01:03:20 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=s1024; t=1348707800; bh=wlPaWPluEcq4R27ZK0vKbbpF25KdXCWbni+mcs1GS1k=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=iDQHVQmmMAvXVCLrK6USwvCb1/ATIdeTpnzSb4lfb+AGsI6Hv1pUsINPhYcfaNrdCYdSXyfF+zslW2UajjEQ+VMYWFe6mtiOwcrN7vyVBcoasqloDsvPIIEdVgEkoDfh1ZqI2J3dJFvWSRxxESrE23pXvYqbl/fI+KZIVow3sIY=
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=EmGj2jWDeBdOaoQAsvg6+535Hg4YgSl08sqGqF6XrEbtjE326prbB/Y031SqXHVB6eXLC3nGR5gpS6yixONIWOvzv5lEUBNX30YJfsvhubbI3IeJhqyRVyrLptRwTko2qVvfB3PVQxN5iD2YTzISnQFxsDwemGQxhLNQyAevehs=;
X-YMail-OSG: B24jlgkVM1nbr5Bn9YPoUyu1umP_25uQ_ARb5dwsfortRCD POLalt6ChyQOe41mosvVw8bHeLsdE03AryvSV7qTY_DZuAS7NRo1wP_Ii4f6 kKMLKd.aqCbdnMISHoPEQfIJEXEoVCE6hpH4mWhXo9xZZ.aoPkyI0RkFRKDo g43TnXkhFsZmYM0SwTvZ_77HibiqOWLCR4PXDv_x23JE0DMq6JSs1DxCLzUb M9cuuRg9eeIujHtStPIE0WV0YLe7TWLIMI49_sacZQ53Y2pe.ui4h6zi2zoA 8klz6y676nKofz2j6vqU4hWBS3_9VcGlJxmc0v.5CExKGDqbEH4P0kxwGYk1 GQ5fa9WluFBUnfawqp_.bugNfFDD.9t1..1E0Ctjzh8C2bzOmuQ3AoYvWT11 Xv9DO.UO1rx6.HOUDxsi.8GMss5JdKFd37FY9GqBckqcVj1BjCVS3ekMXxt0 KKFrgJj3VrMPpwA.aWpG5qUOIO9C_l5.DFjYkhkkvNrLmJ4fc05_rOc.8Byd ZKXg8Wb0u
Received: from [] by via HTTP; Wed, 26 Sep 2012 18:03:19 PDT
X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/
Message-ID: <>
Date: Wed, 26 Sep 2012 18:03:19 -0700 (PDT)
From: Usman Latif <>
Subject: Re: IPv6 address assignment for strictly point-to-point links and Device Loopbacks
To: SM <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="-1134493521-1300443015-1348707799=:26800"
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 01:03:32 -0000

I am still confused - And I'll try to explain my confusion.

While we can still go ahead and say recommendations on /127 that exist in section B.2.2 of RFC 5375 no longer hold true and the recommendations on /127 that exist in RFC 6164 prevail over 5375

The above is fine - but if you read RFC 5375 section B.2 in detail, it talks about all prefix lengths above /64 and encompasses /128 for loopbacks in its recommendations as well (section B.2.3) - whereas RFC 6164 does NOT talk about addressing for loopback interfaces at all

What is even more confusing is that if you consider the recommendations for /128 as per RFC 5375 as TRUE, then you go back into a loop thinking that there should be no discrimination between /127 or /128 because RFC 5375 talks about "overlap" and restricts / cautions us about reserved bits that should not be used for /128 assignments and uses the same recommendation for /127

Question: How can those reserved bits NOT be a problem for /127 assignments but a problem for /128 assignments?

This is why I think if (for whatever reason which I am still trying to digest) we have decided to use /127 without considering reserved bits for IEEE or other protocols, we need to provide similar or atleast some recommendations for /128 on loopbacks that sit inline with what we have recommended in RFC 6164 - otherwise the confusion still exists !!
I hope I am able to convey my confusion correctly... and this is shared by many peers in the industry that I have spoken to... hence the reason in practice although they are assigning /127 on p2p links, they are still reserving the whole parent /64 for each p2p link seperately......

--- On Thu, 27/9/12, SM <> wrote:

From: SM <>
Subject: Re: IPv6 address assignment for strictly point-to-point links and Device Loopbacks
To: "Usman Latif" <>
Received: Thursday, 27 September, 2012, 4:52 AM

Hi Usman,
At 17:08 26-09-2012, Usman Latif wrote:
> 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 ?