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

Usman Latif <osmankh@yahoo.com> Fri, 21 September 2012 07:04 UTC

Return-Path: <osmankh@yahoo.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4804621F86B3 for <ipv6@ietfa.amsl.com>; Fri, 21 Sep 2012 00:04:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f1xHKuXZhaUe for <ipv6@ietfa.amsl.com>; Fri, 21 Sep 2012 00:04:01 -0700 (PDT)
Received: from nm14-vm0.bullet.mail.ne1.yahoo.com (nm14-vm0.bullet.mail.ne1.yahoo.com [98.138.91.52]) by ietfa.amsl.com (Postfix) with SMTP id 3C65311E808A for <ipv6@ietf.org>; Fri, 21 Sep 2012 00:03:57 -0700 (PDT)
Received: from [98.138.90.49] by nm14.bullet.mail.ne1.yahoo.com with NNFMP; 21 Sep 2012 07:03:54 -0000
Received: from [98.138.89.233] by tm2.bullet.mail.ne1.yahoo.com with NNFMP; 21 Sep 2012 07:03:54 -0000
Received: from [127.0.0.1] by omp1048.mail.ne1.yahoo.com with NNFMP; 21 Sep 2012 07:03:54 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 66477.4601.bm@omp1048.mail.ne1.yahoo.com
Received: (qmail 54393 invoked by uid 60001); 21 Sep 2012 07:03:54 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1348211034; bh=xnxH0pPj0ziUAJtMN0k+f8UmOX9M71lEvrht7wvpFfA=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=wyydK5mueXbQMCmrtak5mXGwrQrQB4fxZSxr6SmDTe/QtODVdyAl4+Z7dxg2UUb5hNQEpcLDZjdbj+Qg7YBUsOxQTt46Vav1LgWOG1dTgb04vBpmci3tv+coJumUSN5NIn06SJ/xIelMSyiUGjpRre8E2OiEPVPYmzBdPlzWsZA=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=SmioJ2+1vmlZDrpri5ZAnaOuN2P3XYwXG3EZv2YE7+E+OiYlsu6I/9+ellcJy6wsaGWIdBhCQ1rHQ3KO2kUxRz6JH3u+qcUol2cCtz0RVqYrzF1YCv7Yjo1QaHYVVYr60uHY7c8aAhAKLvHWTuy5VCsgzVmoiq0Ir7GGiJWDlfc=;
X-YMail-OSG: IJEgj2YVM1kdz1Sx30QTJhLEwWuDwO0j1CDltES5MwRxyAn HJes8mdED24.gD596znGwpFTv.ydMx0t34OPpLdG.SlMTXZTax7YGU4artp9 bh25ZXVXlOvWOMQEooegAJBZKdJtKDghvNoeRUMWnRR8X3OIW69kbmdyPxA2 QrW.uk1kVjuPbT6FtQBXA9BWynBOLJnfpd8vHTTIbLZ4hKBh8m6YCY13UT09 EKCWc0Lmw.tUCsb_jL7VwQoImn9GmVDH9phfc1NpOvnzdOvNr.861.HnIQBH 5EoYMZrRlHvPe6Ny.I9DtwgX0L8KrMaNSMDSK8nrnurCaBdic03a84YSeEXq mi4CuFNMp059T1XJVe71USJhCXnh5EQ0ZmgJzkOpUeovspoblQcPlVlZtiCL U7CSrLkAL9fOS0RzIXjLwKO8ZIi69qV5XZ27W0PbhV8RxkHeNpOTGgnIZdZj 9ydKt68TDoulDOqFu0A--
Received: from [203.94.155.226] by web126005.mail.ne1.yahoo.com via HTTP; Fri, 21 Sep 2012 00:03:53 PDT
X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.121.416
Message-ID: <1348211033.52674.YahooMailClassic@web126005.mail.ne1.yahoo.com>
Date: Fri, 21 Sep 2012 00:03:53 -0700 (PDT)
From: Usman Latif <osmankh@yahoo.com>
Subject: IPv6 address assignment for strictly point-to-point links and Device Loopbacks
To: ipv6@ietf.org
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="1833503604-2009576388-1348211033=:52674"
X-Mailman-Approved-At: Fri, 21 Sep 2012 00:31:42 -0700
Cc: bob.hinden@gmail.com
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Sep 2012 07:06:50 -0000

Hi,
 
I am one of the many Network Engineers/architects that are today on the verge of assigning IPv6 addressing in their core networks.

There are two points that I would like to open a debate on and really looking for some substantial reasoning and logic on.
 
And the points are: 
 
Q1: "What is the IETF best-practice / recommendation for assigning IPv6 addressing to strictly point-to-point links where we know there will never be more than one device on each end of the link for the foreseeable future"
 
Q2: "What is the IETF best practice / recommendation for assigning IPv6 addressing for Loopback interfaces on routers"

I have gone through some RFCs (RFC 4291, RFC 5375, RFC 3627, RFC 3177 / 6177 and RFC 6164)
 
As a network engineer with IPv4 and some IPv6 background, I am inclined to use /127 addressing on strictly point to point links and /128 for Loopbacks - but after discussion with peers in the industry have learnt that although the recommendations are to use /127 for p2p and /128 for Loopbacks, its better to reserve the whole /64 for each p2p inter-router link.
 
There are conflicting recommendations and are not giving me the right direction e.g.:
RFC 4291 states: "For all unicast addresses, except those that start with the binary value 000, Interface IDs are required to be 64 bits long and to be constructed in Modified EUI-64 format."
 
RFC 5375 states: "126-bit subnet prefixes are typically used for point-to-point links similar to a the IPv4 address-conservative /30 allocation for point-to-point links.  The usage of this subnet address length does not lead to any considerations beyond those discussed earlier in this section, particularly those related to the 'u' and 'g' bits (see B.2.4.)
For /128 assignment..... it is recommended to take the 'u' and 'g' bits into consideration and to make sure that there is no overlap with any of the following well-known addresses:
   o  Subnet Router Anycast Address
   o  Reserved Subnet Anycast Address
   o  Addresses used by Embedded-RP
   o  ISATAP Addresses"
 
My main concern is the following:
 
Some standards "assume" that the lower-order 64-bits of an IPv6 address are reserved for host addresses (following from an EUI-64 format) and you see some specific addresses in those lower order 64 bits reserved for specific purposes (router anycast, embedded IPv6 RP, ISATAP etc). This gives indication that in future if vendors continue on with this assumption of 64 bits host space and dont take into account that there may be deployments out there where operators / carriers have chosen to use /126 or /127s on their p2p inter-router links from the same /64 subnets - this could lead to major issues for both the operators and their end-customers.
 
I suppose bodies like IETF all need to ensure that there are definitive guidelines around addressing architectures so that future implementations of procotol stacks and features donot overlap with bits in the IPv6 address space that could potentially be used on p2p inter-router links (i.e. there could be address assignments done based on subnet prefixes longer than /64 on p2p links) and obviously if some implementation in future uses the bits from that space, it would become a big challenge for operators and their customers to re-address their p2p inter-router links.
 
In summary we need clear guidelines on the following:

- For IPv6 implementation on strictly p2p (inter-router links) and for device Loopbacks, we can use /127 and /128 respectively but are required to reserve the whole corresponding /64 for each of the p2p links (and loopbacks) i.e. a seperate /64 needs to be reserved for each p2p and loopback.

OR

- For IPv6 implementation on strictly p2p (inter-router links) and for device Loopbacks, we can use /127 and /128 respectively and are NOT reuqired to reserve the whole corresponding /64 for each of the p2p links (and loopbacks) i.e. for example multiple p2p links can be assigned /127 from the same /64 - this has implication that any future implementation of protocol/stack needs to be careful not to "assume" and reserve some or all of the lower-64 bits in IPv6 address for its implementation.
 
 
Thanks
Usman

Email: osmankh@yahoo.com