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 <osma...@yahoo.com> 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 <brian.e.carpen...@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 >
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
