From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc3627.txt | 339 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 339 insertions(+) create mode 100644 doc/rfc/rfc3627.txt (limited to 'doc/rfc/rfc3627.txt') diff --git a/doc/rfc/rfc3627.txt b/doc/rfc/rfc3627.txt new file mode 100644 index 0000000..c3d6289 --- /dev/null +++ b/doc/rfc/rfc3627.txt @@ -0,0 +1,339 @@ + + + + + + +Network Working Group P. Savola +Request for Comments: 3627 CSC/FUNET +Category: Informational September 2003 + + + Use of /127 Prefix Length Between Routers Considered Harmful + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2003). All Rights Reserved. + +Abstract + + In some cases, the operational decision may be to use IPv6 /127 + prefix lengths, especially on point-to-point links between routers. + Under certain situations, this may lead to one router claiming both + addresses due to subnet-router anycast being implemented. This + document discusses the issue and offers a couple of solutions to the + problem; nevertheless, /127 should be avoided between two routers. + +1. Introduction + + [ADDRARCH] defines Subnet-router anycast address: in a subnet prefix + of n bits, the last 128-n bits are all zero. It is meant to be in + use of any one router in the subnet. + + Even though having prefix length longer than /64 is forbidden by + [ADDRARCH] section 2.4 for non-000/3 unicast prefixes, using /127 + prefix length has gained a lot of operational popularity; it seems + like that these prefix lengths are being used heavily in point-to- + point links. The operational practise has often been to use the + least amount of address space especially in the presence of a large + number of point-to-point links; it may be unlikely that all of these + links would start to use /64's. Using /127 has also other + operational benefits: you always know which address the other end + uses, and there is no "ping-pong" [PINGPONG] problem with older ICMP + implementations (fixed now in [ICMPv3]). + + + + + + + + +Savola Informational [Page 1] + +RFC 3627 /127 Prefix Length Considered Harmful September 2003 + + +2. Scope of this Memo + + This memo does not advocate the use of long prefixes, but brings up + problems for those that do want to use them, for one reason or + another. + + Detailed discussion on what is the "right" solution is out of the + scope; it is not the goal of this memo to try to find the "best" + addressing solution for everyone. + +3. Problem with /127 and Two Routers + + Note that this problem does not exist between a router and a host, + assuming the PREFIX::0/127 address is assigned to the router. + + Using /127 can be especially harmful on a point-to-point link when + Subnet-router anycast address is implemented. Consider the following + sequence of events: + + 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 scenarios also happen during router reboots, crashes and + such. + + The usability of subnet-router anycast address between two routers on + a point-to-point link is very questionable, but it is still a + mandated feature of [ADDRARCH]. Workarounds for this are presented + in the next section. + + As of yet, this kind of unexpected behavior hasn't been seen at large + perhaps because the Subnet-router anycast address hasn't been + implemented or too widely used. + + + + + + + + +Savola Informational [Page 2] + +RFC 3627 /127 Prefix Length Considered Harmful September 2003 + + +4. Solutions + + 1. One could use /64 for subnets, including point-to-point links. + + 2. One could use only link-local addresses, but that may 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 which would have been used. + + 3. Failing that, /126 does not 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 one, though often cumbersome, + approach. Naturally, not much would be lost if even a shorter + prefix was used, e.g., /112 or /120. + + The author feels that if /64 cannot be used, /112, reserving the + last 16 bits for node identifiers, has probably the least amount + of drawbacks (also see section 3). + + 4. [ADDRARCH] could be revised to state that Subnet-router anycast + address should not be used if the prefix length of the link is not + /64 (or even longer than /120). This does not seem like a good + approach, as we should avoid making assumptions about prefix + lengths in the specifications, to maintain future flexibility. + Also, in some cases, it might be usable to have a Subnet-router + anycast address in some networks with a longer prefix length. + + A more conservative (implementation) approach would be not using + 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 [NDISC] 'Router' bit in Neighbor Advertisement + messages. However, this seems to overload the functionality of + 'R' bit, so it does not 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. This has the + drawback that even if the router using the combined unicast and + anycast address is down, the packets to subnet-router anycast + address will be lost as the other cannot claim the address. This + approach might lead to unpredictability which would be hard to + trace when debugging problems. However, this would normally be an + issue only when the Subnet-router anycast address is used from + outside of the link; usually, this cannot be done reliably as the + prefix length or EUI64 u/g bits cannot be known for certain. + There are other problems with an address being anycast and unicast + + + + + +Savola Informational [Page 3] + +RFC 3627 /127 Prefix Length Considered Harmful September 2003 + + + too: use of 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 the implementations. + + 1) is definitely the best solution, wherever it is possible. 2) may + be usable in some scenarios, but in larger networks (where the most + often the desire would be to use longer prefix length) it may be + deemed very impractical. There are some situations where one of + these may not be an option; 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 checks, like ones described in 4) or + 5). + +5. Other Problems with Long Prefixes + + These issues are not specific to /127. + + One should note that [ADDRARCH] specifies universal/local bits (u/g), + which are the 70th and 71st bits in any address from 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, as the last + 64 bits of a long prefix is very rarely unique. 'G' is still + unspecified, but defaults to zero. Thus, all prefixes with u or g=1 + should be avoided. + + [MIPV6] specifies "Mobile IPv6 Home-Agents" anycast address which is + used for Home Agent Discovery. In consequence, 7 last bits of have + been reserved in [ANYCAST] of every non-000/3 non-multicast address, + similar to [ADDRARCH]. Thus, at least /120 would seem to make sense. + However, as 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 that there is a service + it needs there. In the case of e.g., /126 between routers, the only + to node to be found on this link would be the other router, so the + mechanism does not seem useful. At 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. + + + +Savola Informational [Page 4] + +RFC 3627 /127 Prefix Length Considered Harmful September 2003 + + +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 + + Thanks to Robert Elz and many others on the IPv6 Working Group for + discussion, and Alain Durand for pointing out [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 u-bit. + +9. Author's Address + + Pekka Savola + CSC/FUNET + Espoo, Finland + + EMail: psavola@funet.fi + + + + + + + + + + + + + + + +Savola Informational [Page 5] + +RFC 3627 /127 Prefix Length Considered Harmful September 2003 + + +10. Full Copyright Statement + + 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. + + + + + + + + + + + + + + + + + + + +Savola Informational [Page 6] + -- cgit v1.2.3