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

Usman Latif <osmankh@yahoo.com> Tue, 25 September 2012 01:30 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 C7E0B1F0CAF for <ipv6@ietfa.amsl.com>; Mon, 24 Sep 2012 18:30:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.024
X-Spam-Level:
X-Spam-Status: No, score=-2.024 tagged_above=-999 required=5 tests=[AWL=-0.045, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.619]
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 mGP8fd6VM8xj for <ipv6@ietfa.amsl.com>; Mon, 24 Sep 2012 18:30:13 -0700 (PDT)
Received: from nm25-vm4.bullet.mail.ne1.yahoo.com (nm25-vm4.bullet.mail.ne1.yahoo.com [98.138.91.185]) by ietfa.amsl.com (Postfix) with SMTP id 9200C1F0CA8 for <ipv6@ietf.org>; Mon, 24 Sep 2012 18:30:13 -0700 (PDT)
Received: from [98.138.226.177] by nm25.bullet.mail.ne1.yahoo.com with NNFMP; 25 Sep 2012 01:30:09 -0000
Received: from [98.138.89.246] by tm12.bullet.mail.ne1.yahoo.com with NNFMP; 25 Sep 2012 01:30:09 -0000
Received: from [127.0.0.1] by omp1060.mail.ne1.yahoo.com with NNFMP; 25 Sep 2012 01:30:09 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 338999.69759.bm@omp1060.mail.ne1.yahoo.com
Received: (qmail 55236 invoked by uid 60001); 25 Sep 2012 01:30:09 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1348536609; bh=C9NfSMGp6jIzzCm3EkDpcvvtz8/yLyRuP5dLTxBUcWE=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=II4vugZhyjQukb2SFGtlKjBR8X5spso8cA3kmZVb7YYZfYrmoZFa+9mPE2FL8wFtHI3s1diqpPTr/bMd0TftpOxxT6EctL4L5AIXHZsx9CaYJq1kuXwqkhRRqfpNjs2PgzbzBfBvRM+jrfTlT1xQvfY5KKK7zlJ2Zks6zBhkhHA=
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:MIME-Version:Content-Type; b=5TirCGqlgPPM1J32qAlVKB3r648B1hzzluZGXtA91cUa7wUK9zyDzrbf1r3KMfCyrAS4t4Y3rlCXT6rFEhstuo3Dkgt7B1FYowwme7BF1YzoPHah18whgBw5PLDpdSS2hOAIRhBMO8LF3fg5Fk1Gna76ryvDhJqiLZK0FNCG7xs=;
X-YMail-OSG: e7dG4_wVM1km_YYfwH8zSo9iLCmliROhpmLlcYWrsmiHTGO QwDypmC0y51Po8IHaERN6iVqWhhxBn4mfRNp_UXn42LwLAMkOqTSFPJLKgv6 EheHm9SdkPQlDT85YH19_6eR5HId7qflZ_5baclNUkHIy_Nih_ryIwXya.Co qBwlbsvVWsMw1EsBvatMcCXLvETlsjAblETMJSQaZumci5DpbfbL6D.4xUGF pK6ZX4g02gyiIaxOQoVjJcKOEeu64dKRpr43ZRPGXt31.qYXSCMedDQJvun4 IxPz7AoABOouB5zJKOxa54X4S5AFDy7BUtgzcu6k6w.N0qavFNgQSlGQaQHy d2X8x.X7zjfJ96dkTtTzxSl_haauQZ2XyAwXHZ1L2E.rdRhgXLA90REk910c aumRgWDxmkwASrizdh0eIG7jEXsLs7Ij_f8NnGJeflXjVkPlzMXnKt9FO4q3 zgwnVzPYccAdgAGYKi0nqbjL0bB0V3GnoW_HXXQ4WY5pTkr5rFIYKT_pvPDa 7y7N6ckQzG3L2tK1KvoZe0I.D8Y2umc8DfqAFcogX3jrux9VQhw4ljxjgszv r1Ql2HNs0qOjHTRhtVDtPYZBt071TwFImMhW.b.QFoxYq9wFO3jZgm3cvDg- -
Received: from [203.94.155.226] by web126004.mail.ne1.yahoo.com via HTTP; Mon, 24 Sep 2012 18:30:09 PDT
X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.121.434
Message-ID: <1348536609.37841.YahooMailClassic@web126004.mail.ne1.yahoo.com>
Date: Mon, 24 Sep 2012 18:30:09 -0700 (PDT)
From: Usman Latif <osmankh@yahoo.com>
Subject: Re: 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="1688457910-719174945-1348536609=:37841"
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: Tue, 25 Sep 2012 01:30:14 -0000





To summarize the whole discussion and clarify the last points:

RFC 3627 discouraged use of /127 and most RFCs up until RFC 5375 recommended using /64 even on p2p inter-router links.

RFC 6164 recommends using /127 on p2p links - however there is no explicit recommendation for /128 on device Loopbacks (e.g. for peering establishment etc)

The specific statement in RFC 6164 states that while using /127, care should be taken not to use following reserved address:

(a) Addresses with all zeros in the rightmost 64 bits SHOULD NOT be assigned 
as unicast addresses, to avoid colliding with the Subnet-Router anycast address 
(b) Addresses in which the rightmost 64 bits are assigned the highest 128 values 
(i.e., ffff:ffff:ffff:ff7f to ffff:ffff:ffff: ffff) SHOULD NOT be used as unicast addresses, 
to avoid colliding with reserved subnet anycast addresses

Whereas the RFC 5375 recommended not to use the following:


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
 
So the questions that come out of the above discussion are:

- What are the recommendations for device Loopbacks and what reserved address ranges need to be considered by network operators while using /128s for Loopbacks (should these be followed based on RFC 5357?)

- Which recommendations out of RFC 5375 and RFC 6164 should be followed by network operators while using /127s for inter-router point-to-point links
 
 
I (like many other engineers) would be looking for some feedback on the above two points to get a clear guideline for p2p and loopback addressing
 
 
Regards
Usman
 


--- On Sat, 22/9/12, Usman Latif <osmankh@yahoo.com> wrote:


From: Usman Latif <osmankh@yahoo.com>
Subject: Re: IPv6 address assignment for strictly point-to-point links and Device Loopbacks
To: "ipv6@ietf.org" <ipv6@ietf.org>
Cc: "Brian E Carpenter" <brian.e.carpenter@gmail.com>
Received: Saturday, 22 September, 2012, 6:07 PM





Forgot to include IPv6 group email in my last email (below)
Further to that, RFC 6164 states in the same statement that:


"When assigning and using any /127 prefixes, the following considerations 
apply. Some addresses have special meanings, in particular addresses 
corresponding to reserved anycast addresses. When assigning prefixes 
(and addresses) to links, care should be taken to ensure that addresses 
reserved for such purposes aren't inadvertently assigned and used as 
unicast addresses. Otherwise, nodes may receive packets that they are 
not intended to receive. Specifically, assuming that a number of point-to-point 
links will be numbered out of a single /64 prefix: 
 (a) Addresses with all zeros in the rightmost 64 bits SHOULD NOT be assigned 
as unicast addresses, to avoid colliding with the Subnet-Router anycast address 
(b) Addresses in which the rightmost 64 bits are assigned the highest 128 values 
(i.e., ffff:ffff:ffff:ff7f to ffff:ffff:ffff: ffff) SHOULD NOT be used as unicast addresses, 
to avoid colliding with reserved subnet anycast addresses"


One question that comes up here is that why did RFC 6164 exclude
additional recommendations that were stated in RFC 5375 which stated:


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


So should one only care about excluding reserved addresses as per RFC 6164 or should we also care about reserving addresses as per RFC 5375?


5375 seems to have more special addresses covered and is also a hint that in the hindsight there could be more special addresses in future using bits in lower 64-bit portion of v6 address(?)


I wonder if it's possible to leave portions of lower 64 bits in v6 address for special purposes (both EUI-64 and non EUI-64) so that we get best of both worlds i.e. leave room open for future development and assignment of special addresses using portions in lower 64 bits reserved for this purpose and at the same time allowing users to tap into the lower 64 bit address space for general address assignment purposes using portions that are not reserved for this purposes...


Regards,
Usman


Sent from my iPhone

On 22/09/2012, at 12:35 PM, Usman Latif <osmankh@yahoo.com> wrote:





On 22/09/2012, at 9:06 AM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:


On 21/09/2012 22:35, Usman Latif wrote:


Thanks Wes for the feedback.



...





Without this stated clearly there is likely to be some instances where readers interpret it the wrong way and end up assigning multiple p2p links with /127 subnets from a single given /64 and end up having to re-address their network in future when/if future standards use lower order 64 bits for special purposes.



[WEG] Given the fact that there is a standard that documents the use of a /127 for P2P links (6164), 



Wes, I think that statement is even a bit weak, since 6164 actually says:



"assuming that a number of point-to-point links will be numbered out of a single /64 prefix:"



so it is very clear: it is allowed by the standard to share a /64 among

however many pt2pt links the operator cares to. This is *not* a wrong

interpretation.



As you say, any future work will need to take account of this.



Brian