Internet Engineering Task Force P. Savola Internet Draft CSC/FUNET Expiration Date: October 2002 April 2002 Use of /127 Prefix Length Between Routers Considered Harmful draft-savola-ipv6-127-prefixlen-02.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. 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 draft discusses the issue and offers a couple of solutions to the problem; nevertheless, /127 should be avoided between two routers. Savola [Expires October 2002] [Page 1] Internet Draft draft-savola-ipv6-127-prefixlen-02.txt April 2002 1. Problem with /127 and Two Routers [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. Note that this problem does not exist between a router and a host, assuming the PREFIX::0/127 address is assigned to the router. This draft does not advocate the use of long prefixes, but brings up problems for those that do want to use them. 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 yet on this link. 3. 3ffe:ffff::1/127 address is added to Router A; now it performs Duplicate Address Detection [NDISC] for 3ffe:ffff::1 (normal address) and, being a router in the subnet, also 3ffe:ffff::0, and succeeds. 4. Now Router B has been planned and configured to use 3ffe:ffff::0/127 as its IPv6 address, but adding it will fail Duplicate Address Detection, 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]. A workaround for this is presented in solutions section. As of yet, this kind of unexpected behaviour hasn't been seen at large perhaps because Subnet-router anycast address hasn't been implemented too widely yet. Savola [Expires October 2002] [Page 2] Internet Draft draft-savola-ipv6-127-prefixlen-02.txt April 2002 2. Solutions 1. One could use /64 for subnets, including point-to-point links. 2. 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. 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 the next section). 3. [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. 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. 4. 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 usually 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 too: use of it as a source address, whether to use unicast or anycast semantics in [NDISC], and others: allowing this behaviour would seem to only add a lot of complexity to the implementations. 1) is definitely the best solution, wherever it is possible. There are some situations where it may not be an option; then an operational work-around for this operational problem, that is 2), appears to be the best course of action. This is because it may be Savola [Expires October 2002] [Page 3] Internet Draft draft-savola-ipv6-127-prefixlen-02.txt April 2002 very difficult to know whether all implementations implement some checks, like ones described in 3) or 4). 3. 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 to scenarios where 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 do this would be the other router. At least, MIPv6 HA Discovery should not be performed if the prefix length is longer than e.g. /120. 4. References 4.1. Normative References [ADDRARCH] Hinden, R., Deering, S., "IP Version 6 Addressing Architecture", RFC2373, July 1998. [ANYCAST] Johnson, D., Deering, S., "Reserved IPv6 Subnet Anycast Addresses", RFC2526, March 1999. 4.2. Informative References [NDISC] Narten, T., Nordmark, E., Simpson W., "Neighbor Discovery for IP Version 6 (IPv6)", RFC2461, December 1998. [MIPV6] Johnson, D., Perkins, C., "Mobility Support in IPv6", draft-ietf-mobileip-ipv6-16.txt (work in progress). Savola [Expires October 2002] [Page 4] Internet Draft draft-savola-ipv6-127-prefixlen-02.txt April 2002 5. 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. 6. Acknowledgements Robert Elz and many others on ipv6 working group for discussion, Alain Durand for pointing out [ADDRARCH] requirements for prefix lengths. Charles Perkins pointed out MIPv6 HA requirements. Randy Bush commented the draft extensively, and Erik Nordmark pointed out issues with u-bit. Author's Address Pekka Savola CSC/FUNET Espoo, Finland EMail: psavola@funet.fi Savola [Expires October 2002] [Page 5]