Internet Engineering Task Force P. Savola Internet Draft CSC/FUNET Expiration Date: August 2002 February 2002 Note about the Use of IPv6 /127 Prefix Length draft-savola-ipv6-127-prefixlen-01.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. 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. 1. Problem with /127 [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 fo non-000/3 unicast prefixes, using /127 prefix length has gained a lot of operational popularity; it seems Savola [Expires August 2002] [Page 1] Internet Draft draft-savola-ipv6-127-prefixlen-00.txt February 2002 like that these prefix lengths are being used heavily in point-to- point links, often perhaps partially due to RIR address allocation policies for Internet Exchanges [IX-ALLOC]. 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 is plugged in the network with Router B (e.g. cross- over cable). 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 DAD, and Router B does not have any address. Similar scenarios also happen during router reboots, crashes and such. 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. 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). Naturally, not much would be lost if even a shorter prefix was used, e.g. /112 or /120. 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 or /128. Savola [Expires August 2002] [Page 2] Internet Draft draft-savola-ipv6-127-prefixlen-00.txt February 2002 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. 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 very difficult to know whether all implementations implement some checks, like ones described in 3) or 4). 3. 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. 4. Acknowledgements Robert Elz and many others on ipv6 working group for discussion, Alain Durand for pointing out [ADDRARCH] requirements for prefix lengths. 5. References [ADDRARCH] Hinden, R., Deering, S., "IP Version 6 Addressing Architecture", RFC2373, July 1998. [IX-ALLOC] Jimmerson, R. "Exchange point requests for IPv6 address space", ARIN IPv6 mailing-list, http://www.arin.net/mailinglists/v6wg/0082.html [NDISC] Narten, T., Nordmark, E., Simpson W., "Neighbor Discovery for IP Version 6 (IPv6)", RFC2461, December 1998. Savola [Expires August 2002] [Page 3] Internet Draft draft-savola-ipv6-127-prefixlen-00.txt February 2002 Author's Address Pekka Savola CSC/FUNET Espoo, Finland EMail: psavola@funet.fi Savola [Expires August 2002] [Page 4]