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

[Usman Latif <[e-mail]>]

Hi,


Based on the response i have received so far it appears that there are still gaps in our approach towards IPv6 addressing (maybe the original way the stack was written also is not ideal - but lets not go there and try to find the best way out with what we've got)


IMO RFC 6164 although being very authoritative and direct about use of /127 (from the same /64) on each p2p link is not giving us any insight into other current (or future) reserved addresses that were explained in more detail in RFC 5375 so in doing that RFC 6164 is raising doubts in our minds about using /127 (from the same /64) for p2p router links and also there is no talk in RFC 6164 about use of /128 loopbacks and what cautions are needed there - whereas we saw that in RFC 5375 (although informational only) there was a more comprehensive discussion around use of shorter length prefixes for p2p links and loopbacks


The motivations for RFC 6164 can also be debated here e.g:


Ping-Pong issue is dealt with RFC 4443


Neighbor Cache exhaustion on p2p links can be controlled if we use filters to restrict a router to perform ND for only the known IP on the far-end of the p2p link or a similar mechanism that provides control over creating neighbor cache only for the known IP on the farend (although this would require some additional config overhead but is worth considering)


Also there are so many other scenarios where this would still pose an issue wherever we have /64 assigned so better to provide a more holistic solution than to only consider router p2p links only.


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


Pls let me know if there is work being done in this space...


Regards
Usman
 



On 26/09/2012, at 2:52 AM, Randy Bush <[e-mail]> wrote:




perhaps we learned some things over time?

randy





From: Usman Latif <[e-mail]>
Date: 25 September 2012 11:30:09 AM AEST
To: [e-mail]
Subject: Re: IPv6 address assignment for strictly point-to-point links and Device Loopbacks














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