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]