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-00.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.5.1 for non-000/3 prefixes, using /127 prefix length has gained a lot of operational popularity; it seems like that Savola [Expires August 2002] [Page 1] Internet Draft draft-savola-ipv6-127-prefixlen-00.txt February 2002 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 should 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 (using the 2nd and the 3rd address for unicast). 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. 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 Savola [Expires August 2002] [Page 2] Internet Draft draft-savola-ipv6-127-prefixlen-00.txt February 2002 address. 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. Operatinal work-arounds for this operational problem, that is, solutions 1) and 2), appear to be the best course of action. 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. Author's Address Pekka Savola CSC/FUNET Espoo, Finland EMail: psavola@funet.fi Savola [Expires August 2002] [Page 3]