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

[Usman Latif <[e-mail]>]

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