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]