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

[Usman Latif <[e-mail]>]

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 <[e-mail]> wrote:


From: Usman Latif <[e-mail]>
Subject: Re: IPv6 address assignment for strictly point-to-point links and Device Loopbacks
To: "[e-mail]" <[e-mail]>
Cc: "Brian E Carpenter" <[e-mail]>
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 <[e-mail]> wrote:





On 22/09/2012, at 9:06 AM, Brian E Carpenter <[e-mail]> 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