RFC 3627

Title Block 🎀

okay bestie, RFC 3627 is titled "Use of /127 Prefix Length Between Routers Considered Harmful" 💅 It was written by P. Savola of CSC/FUNET and dated September 2003. It's Informational, so it's shared as info for the Internet community and doesn't set a standard 🧚 The title block doesn't list anything it obsoletes or updates.

---

Status of This Memo ✨

this is just info for the Internet community, not an Internet standard of any kind. Distribution is unlimited 🌸

Copyright Notice 🫶

Copyright (C) The Internet Society (2003). All Rights Reserved.

Abstract 🔥

ok so sometimes people decide to use IPv6 /127 prefix lengths, especially on point-to-point links between routers. under certain conditions, one router can end up claiming both addresses, because subnet-router anycast gets implemented 😭 this doc talks about the issue and gives a couple of ways to fix it. but honestly? /127 should be avoided between two routers 🙈

1. Introduction 💖

[ADDRARCH] defines the Subnet-router anycast address: in a subnet prefix of n bits, the last 128-n bits are all zero. it's meant to be used by any one router on the subnet 🦋

even though [ADDRARCH] section 2.4 forbids prefix lengths longer than /64 for non-000/3 unicast prefixes, /127 has gotten super popular in operations 👑 it seems like these prefix lengths are being used a lot on point-to-point links. the operational habit has been to use as little address space as possible, especially when there are tons of point-to-point links, and it's unlikely all of those links would switch to /64s. /127 also has other perks: you always know which address the other end is using, and there's no "ping-pong" [PINGPONG] problem with older ICMP implementations (fixed now in [ICMPv3]) ✨

2. Scope of this Memo 🍓

this memo isn't pushing long prefixes. it's just pointing out problems for people who want to use them, for one reason or another 🌈

figuring out what the "right" solution is isn't the point here. this memo isn't trying to find the "best" addressing solution for everyone 💅

3. Problem with /127 and Two Routers 💀

heads up: this problem doesn't happen between a router and a host, as long as the PREFIX::0/127 address is assigned to the router 🎀

/127 can be really harmful on a point-to-point link when Subnet-router anycast address is implemented. here's the sequence of events that goes wrong 😭

1. Router A and Router B are connected by a point-to-point link.
2. Neither has anything configured or set up on this link.
3. 3ffe:ffff::1/127 address is added to Router A; now it performs Duplicate Address Detection (DAD) [NDISC] for 3ffe:ffff::1. Router A also adds the Subnet-router anycast address 3ffe:ffff::0/127. (DAD is not performed for anycast addresses.)
4. Now Router B has been planned and configured to use 3ffe:ffff::0/127 as its unicast IPv6 address, but adding it will fail DAD, and Router B does not have any address.

similar stuff happens during router reboots, crashes, and things like that 🙈

using the subnet-router anycast address between two routers on a point-to-point link is super questionable, but it's still a mandated feature of [ADDRARCH] 🥺 workarounds are in the next section ✨

as of now, this kind of unexpected behavior hasn't shown up at scale, maybe because the Subnet-router anycast address hasn't been implemented or used very widely 🦋

4. Solutions 👑

1. one could use /64 for subnets, including point-to-point links.
2. one could use only link-local addresses, but that might make network maintenance and debugging impractical, at least in bigger networks. for example, "traceroute" can only return a list of nodes on the path, not the links that would have been used 😭
3. failing that, /126 doesn't have this problem, and it can be used safely on a point-to-point link (e.g., using the 2nd and the 3rd address for unicast). this is analogous to using /30 for IPv4. using two /128 addresses is also an option, though it's often cumbersome. naturally, not much would be lost even if a shorter prefix was used, e.g., /112 or /120 🧚

the author feels that if /64 can't be used, /112, reserving the last 16 bits for node identifiers, probably has the least drawbacks (also see section 3) 💖

4. [ADDRARCH] could be revised to state that the Subnet-router anycast address should not be used if the prefix length of the link isn't /64 (or even longer than /120). this doesn't seem like a good approach, since we should avoid making assumptions about prefix lengths in the specifications, to keep future flexibility. also, in some cases it might be useful to have a Subnet-router anycast address in some networks with a longer prefix length 🌸

a more conservative (implementation) approach would be to not use Subnet-router anycast addresses in subnets with a prefix length of /127 if there are only two routers on the link. this can be noticed with the [NDISC] 'Router' bit in Neighbor Advertisement messages. however, this seems to overload the functionality of the 'R' bit, so it doesn't look like a good approach in the long run 🙈

5. it's also possible to improve implementations: if /127 is used on a point-to-point link, never claim two addresses. the drawback is that even if the router using the combined unicast and anycast address is down, packets to the subnet-router anycast address will be lost, because the other router can't claim the address. this approach might lead to unpredictability that would be hard to trace when debugging problems. however, this would normally only be an issue when the Subnet-router anycast address is used from outside the link. usually, that can't be done reliably, since the prefix length or EUI64 u/g bits can't be known for certain. there are other problems with an address being both anycast and unicast too: using it as a source address, whether to use unicast or anycast semantics in [NDISC], and others. allowing this behavior would seem to only add a lot of complexity to implementations 🔥

Option 1) is definitely the best solution, wherever it's possible. Option 2) may be usable in some scenarios, but in larger networks (where the desire is most often to use a longer prefix length) it may be considered very impractical. there are some situations where one of these isn't an option, and then an operational work-around for this operational problem, that is 3), appears to be the best course of action. this is because it may be very difficult to know whether all implementations implement some of the checks described in 4) or 5) 🫶

5. Other Problems with Long Prefixes 🌈

these issues aren't specific to /127 💅

you should note that [ADDRARCH] specifies the universal/local bits (u/g), which are the 70th and 71st bits in any address from the non-000/3 range. when assigning prefixes longer than 64 bits, these should be taken into consideration. in almost every case, u should be 0, since the last 64 bits of a long prefix are very rarely unique. 'G' is still unspecified, but defaults to zero. so all prefixes with u or g=1 should be avoided 🙈

[MIPV6] specifies the "Mobile IPv6 Home-Agents" anycast address, which is used for Home Agent Discovery. as a result, the last 7 bits of every non-000/3 non-multicast address have been reserved in [ANYCAST], similar to [ADDRARCH]. so at least /120 would seem to make sense. however, since the sender must know the destination's prefix length, this "reserved anycast addresses" mechanism is only applicable when the sender knows about the link and expects a service it needs to be there. for something like /126 between routers, the only node to be found on that link would be the other router, so the mechanism doesn't seem useful. at the very least, Mobile IPv6 Home Agent Discovery should not be performed if the prefix length is longer than /120 🦋

6. References 📚

6.1. Normative References

• [ADDRARCH] Hinden, R. and S. Deering, "IP Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.
• [ANYCAST] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast Addresses", RFC 2526, March 1999.

6.2. Informative References

• [NDISC] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
• [MIPV6] Johnson, D., Perkins, C., Arkko, J., "Mobility Support in IPv6", Work in Progress.
• [ICMPv3] Conta, A., Deering, S., "Internet Control Message Protocol (ICMPv6)", Work in Progress.
• [PINGPONG] Hagino, J., Jinmei, T., Zill, B., "Avoiding ping-pong packets on point-to-point links", Work in Progress.

7. Security Considerations 🚨

⚠️ Beyond those already existing in other specifications, solution 4) might lead to denial of service in the case that one router is down: the packet to subnet-router anycast address would be lost.

8. Acknowledgements 🫶

thank you to Robert Elz and many others on the IPv6 Working Group for the discussion 💖 and to Alain Durand for pointing out the [ADDRARCH] requirements for prefix lengths. Charles Perkins pointed out MIPv6 HA requirements. Randy Bush and Ole Troan commented on the document extensively, and Erik Nordmark pointed out issues with the u-bit 🧚

9. Author's Address 🎀

Pekka Savola CSC/FUNET Espoo, Finland

EMail: psavola@funet.fi

10. Full Copyright Statement 💜

here's the legal stuff, kept word for word:

Copyright (C) The Internet Society (2003).  All Rights Reserved.

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works.  However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.

This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement 🌸

funding for the RFC Editor function is currently provided by the Internet Society ✨