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

[Usman Latif <[e-mail]>]

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:

> Thanks Brian, your email clears a lot of ambiguity.
> So I presume it's safe to use /127s on different p2p links from the same /64 subnet. (as per 6164)
> This pretty much means that the second statement in my first email would be the final outcome - i.e.
> 
> - 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.
> 
> Pls note that there is still a mindset out there (call it being apprehensive or being overly cautious) - after speaking with peers in the telco carrier space, they are still assigning /127s and reserving whole /64s for each p2p link separately - this was the basis of my original discussion that we need to "break this myth and be clear and conclusive that operators/carriers etc or for that matter whoever is implementing v6 addressing on p2p links or loopbacks is not required to reserve a whole /64 for each of them separately and its completely a matter of choice whether they choose to assign /127 from the same /64 or keep separate /64 for each instance of p2p link or loopbacks etc"
> 
> Regards,
> Usman
> 
> Sent from my iPhone
> 
> 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
>