| 6MAN | B. E. Carpenter, Ed. |
| Internet-Draft | Univ. of Auckland |
| Intended status: Informational | T. J. Chown |
| Expires: July 09, 2014 | Univ. of Southampton |
| F. Gont | |
| SI6 Networks / UTN-FRH | |
| S. Jiang | |
| Huawei Technologies Co., Ltd | |
| A. Petrescu | |
| CEA, LIST | |
| A. Yourtchenko | |
| cisco | |
| January 05, 2014 |
Analysis of the 64-bit Boundary in IPv6 Addressing
draft-carpenter-6man-why64-00
The IPv6 unicast addressing format includes a separation between the prefix used to route packets to a subnet and the interface identifier used to specify a given interface connected to that subnet. Historically the interface identifier has been defined as 64 bits long, leaving 64 bits for the prefix. This document discusses the reasons for this fixed boundary and the issues involved in treating it as a variable boundary.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on July 09, 2014.
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
The IPv6 addressing architecture [RFC4291] specifies that a unicast address is divided into n bits of subnet prefix followed by (128-n) bits of interface identifier (IID). Since IPv6 routing is entirely based on variable length subnet masks, there is no architectural assumption that n has any particular fixed value. However, RFC 4291 also describes a method of forming interface identifiers from IEEE EUI-64 hardware addresses [IEEE802] and this does specify that such interface identifiers are 64 bits long. Various other methods of forming interface identifiers also specify a length of 64 bits. This has therefore become the de facto length of almost all IPv6 interface identifiers. One exception is documented in [RFC6164], which standardises 127-bit prefixes for inter-router links.
Recently it has been clarified that the bits in an IPv6 interface identifier have no particular meaning and should be treated as opaque values [I-D.ietf-6man-ug]. Therefore, there are no bit positions in the currently used 64 bits that need to be preserved.
The question is often asked why the boundary is set rigidly at /64. This limits the length of a routing prefix to 64 bits, whereas architecturally, and from the point of view of routing protocols, it could be anything (in theory) between /1 and /128 inclusive. Here, we only discuss the question of a shorter IID, allowing a longer routing prefix.
The purpose of this document is to analyse the issues around this question. We make no proposal for change, but we do analyse the possible effects of a change.
In this section we describe existing scenarios where prefixes longer than /64 have been used or proposed.
A site may not be delegated a sufficiently large prefix from which to allocate a /64 prefix to all of its internal subnets. In this case the site may either determine that it does not have enough address space to number all its network elements and thus, at the very best, be only partially operational, or it may choose to use internal prefixes longer than /64 to allow multiple subnets and the hosts within them to be configured with addresses.
In this case, the site might choose, for example, to use a /80 per subnet, in combination with hosts using either manually configured addressing or DHCPv6.
It should be noted that the homenet architecture text [I-D.ietf-homenet-arch] states that a CPE should consider the lack of sufficient address space to be an error condition, rather than using prefixes longer than /64 internally.
A site may be concerned that it is open to neighbour discovery (ND) cache exhaustion attacks, whereby an attacker sends a large number of messages in rapid succession to a series of (most likely inactive) host addresses within a specific subnet, in an attempt to fill a router's ND cache with ND requests pending completion, in so doing denying correct operation to active devices on the network.
An example would be to use a /120 prefix, limiting the number of addresses in the subnet to be similar to an IPv4 /24 prefix, which should not cause any concerns for ND cache exhaustion. Note that the prefix does need to be quite long for this scenario to be valid. The number of theoretically possible ND cache slots on the segment needs to be of the same order of magnitude as the actual number of hosts. Thus small increases from the /64 prefix length do not have a noticeable impact: even 2^32 potential entries, a factor of two billion decrease compared to 2^64, is still more than enough to exhaust the memory on current routers.
As in the previous scenario, hosts would likely be manually configured with addresses, or use DHCPv6.
The precise 64-bit length of the Interface ID is widely mentioned in numerous RFCs describing various aspects of IPv6. It is not straightforward to distinguish cases where this has normative impact or affects interoperability.
First and foremost, the RFCs describing the architectural aspects of IPv6 addressing explicitly state, refer and repeat this apparently immutable value: Addressing Architecture [RFC4291], Reserved Interface Identifiers [RFC5453], ILNP [RFC6741]. Customer Edge routers impose /64 for their interfaces [RFC6204]. Only the IPv6 Subnet Model [RFC5942] refers to the assumption of /64 prefix length as a potential implementation error.
Numerous IPv6-over-foo documents make mandatory statements with respect to the 64-bit length of the Interface ID to be used during the Stateless Autoconfiguration. These documents are [RFC2464] (Ethernet), [RFC2467] (FDDI), [RFC2470] (Token Ring), [RFC2492] (ATM), [RFC2497] (ARCnet), [RFC2590] (Frame Relay), [RFC3146] (IEEE 1394), [RFC4338] (Fibre Channel), [RFC4944] (IEEE 802.15.4), [RFC5072] (PPP), [RFC5121] [RFC5692] (IEEE 802.16), [I-D.ietf-6lowpan-btle], [I-D.ietf-6man-6lobac], [I-D.brandt-6man-lowpanz].
To a lesser extent, the address configuration RFCs themselves may in some way assume the 64-bit length of an Interface ID (SLAAC for the link-local addresses, DHCPv6 for the potentially assigned EUI-64-based IP addresses, Default Router Preferences [RFC4191] for its impossibility of Prefix Length 4, Optimistic Duplicate Address Detection [RFC4429] which computes 64-bit-based collision probabilities).
The MLDv2 protocol [RFC3810] mandates all queries be sent with the fe80::/64 link-local source address prefix and subsequently bases the querier election algorithm on the link-local subnet prefix length of length /64.
The IPv6 Flow Label Specification [RFC6437] gives an example of a 20-bit hash function generation which relies on splitting an IPv6 address in two equally-sized 64bit-length parts.
IPv6 transition mechanisms such as NAT64 and NPTv6, as well as Basic transition and Teredo rely on the use of IIDs of length 64.
The proposed method [I-D.ietf-v6ops-64share] of extending an assigned /64 prefix from a smartphone's cellular interface to its WiFi link relies on prefix length, and implicitely on the length of the Interface ID, to be valued at 64.
The HBA, CGA and SeND RFCs rely on the 64bit identifier length, as do the Privacy extensions and some examples in IKEv2bis.
464XLAT [RFC6877] explicitly mentions acquiring /64 prefixes. However, it also discusses the possibility of using the interface address on the device as the endpoint for the traffic, thus potentially removing this dependency.
[RFC2526] reserves a number of subnet anycast addresses by reserving some anycast IIDs. An anycast IID so reserved cannot be less than 7 bits long. This means that a subnet prefix length longer than /121 is not possible, and a subnet of exactly /121 would be useless since all its identifiers are reserved. It also means that half of a /120 is reserved for anycast. This could of course be fixed in the way described for /127 in [RFC6164], i.e., avoiding the use of anycast within a /120 subnet.
Other RFCs refer to mandatory alignment on 64-bit boundaries, 64-bit data structures, 64-bit counters in MIB, 64-bit sequence numbers and cookies in security. Finally, the 64 number may be considered 'magic' in some RFCs, (e.g., 64k limits in DNS and Base64 encodings in MIME) but this of course has no influence on the length of the IID. All the same, a programmer might be lulled into assuming a comfortable rule of thumb that an IID is always length 64.
This section discusses several specific aspects of IPv6 where we can expect operational breakage with subnet prefixes other than /64.
It goes without saying that if prefixes longer than /64 are to be used, all hosts must be capable of generating IIDs shorter than 64 bits, in order to follow the auto-configuration procedure correctly [RFC4862]. There is however the rather special case of the link-local prefix. While RFC 4862 is careful not to define any specific length of link-local prefix within fe80::/10, operationally there would be a problem unless all hosts on a link use IIDs of the same length to configure a link-local address during reboot. Typically today the choice of /64 for the link-local prefix length is hard-coded per interface. There might be no way to change this except conceivably by manual configuration, which will be impossible if the host concerned has no local user interface.
Still to be written - some experiments are underway, and more input is welcomed. Some points made earlier on the v6ops list can be incorporated here.
The length of the interface identifier has implications for privacy [I-D.ietf-6man-ipv6-address-generation-privacy]. In any case in which the value of the identifier is intended to be hard to guess, whether or not it is cryptographically generated, it is apparent that more bits are better. For example, if there are only 20 bits to be guessed, at most just over a million guesses are needed, today well within the capacity of a low cost attack mechanism. It is hard to state in general how many bits are enough to protect privacy, since this depends on the resources available to the attacker, but it seems clear that a privacy solution needs to resist an attack requiring billions rather than millions of guesses. Trillions would be better, suggesting that at least 40 bits should be available. Thus we can argue that subnet prefixes longer than say /80 might raise privacy concerns by making the IID guessable.
A prefix long enough to limit the number of addresses comparably to an IPv4 subnet, such as /120, would create exactly the same situation for privacy as IPv4.
Still to be written - suggestions welcome. Some points made earlier on the v6ops list can be incorporated here.
Summary of pros and cons; risks (write this bit last!)
In addition to the privacy issues mentioned in Section 6, and the issues mentioned with CGAs and HBAs in Section 4, the length of the subnet prefix affects the matter of defence against scanning attacks [RFC5157]. Assuming the attacker has discovered or guessed the prefix length, a longer prefix reduces the space that the attacker needs to scan, e.g., to only 256 addresses if the prefix is /120. On the other hand, if the attacker has not discovered the prefix length and assumes it to be /64, routers can trivially discard attack packets that do not fall within an actual subnet.
However, assume that an attacker finds one valid address A and then starts a scanning attack by scanning "outwards" from A, by trying A+1, A-1, A+2, A-2, etc. This attacker will easily find all hosts in any subnet with a long prefix, because they will have addresses close to A. We therefore conclude that any prefix containing densely packed valid addresses is vulnerable to a scanning attack, without the attacker needing to guess the prefix length. Therefore, to preserve IPv6's advantage over IPv4 in resisting scanning attacks, it is important that subnet prefixes are short enough to allow sparse allocation of identifiers within each subnet. The considerations are similar to those for privacy, and we can again argue that prefixes longer than say /80 might significantly increase vulnerability. Ironically, this argument is exactly converse to the argument for longer prefixes to resist an ND cache attack, as described in Section 2.2.
This document requests no action by IANA.
Valuable comments were received from Stig Venaas, ... and other participants in the IETF.
This document was produced using the xml2rfc tool [RFC2629].
draft-carpenter-6man-why64-00: original version, 2014-01-06.