RFC 8064

Recommendation on Stable IPv6 Interface Identifiers

📅 published February 2017, from ietf

RFC 8064: Recommendation on Stable IPv6 Interface Identifiers 🦋

okay bestie, so this is RFC 8064, published February 2017 as a Standards Track document 💅. The authors are F. Gont (SI6 Networks / UTN-FRH), A. Cooper (Cisco), D. Thaler (Microsoft), and W. Liu (Huawei Technologies). It's ISSN 2070-1721, and it updates RFC 2464, RFC 2467, RFC 2470, RFC 2491, RFC 2492, RFC 2497, RFC 2590, RFC 3146, RFC 3572, RFC 4291, RFC 4338, RFC 4391, RFC 5072, and RFC 5121 🌸. The header doesn't list anything it obsoletes, so it's only updating things, not replacing whole docs. The big theme is stable IPv6 addresses built with SLAAC, and how to make them less of a privacy disaster 🔥.

Abstract ✨

the whole vibe here is that this doc changes the default way stable Interface Identifiers (IIDs) get generated when SLAAC makes a stable IPv6 address. the new default is the scheme from RFC 7217, and it says NO to embedding stable link-layer addresses in IPv6 IIDs 🙅‍♀️. it formally updates RFC 2464, RFC 2467, RFC 2470, RFC 2491, RFC 2492, RFC 2497, RFC 2590, RFC 3146, RFC 3572, RFC 4291, RFC 4338, RFC 4391, RFC 5072, and RFC 5121. and just so nobody gets confused, it does NOT change any existing recommendations about temporary addresses from RFC 4941 🦋.

Status of This Memo 🎀

This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.

Information about the current status of this document, any errata, and how to give feedback on it can be found at http://www.rfc-editor.org/info/rfc8064 🧚.

Copyright (c) 2017 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) as they stand on the publication date of this document. Please read these documents carefully, because they spell out your rights and restrictions for this document. Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as described in the Simplified BSD License 🫶.

Table of Contents 🍓

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
3.  Generation of IPv6 Interface Identifiers with SLAAC . . . . .   5
4.  Future Work . . . . . . . . . . . . . . . . . . . . . . . . .   5
5.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   8
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1. Introduction ✨

okay so [RFC4862] defines Stateless Address Autoconfiguration (SLAAC) for IPv6 [RFC2460]. usually that means a host ends up with one or more "stable" addresses. each one is a prefix from a local router plus an Interface Identifier (IID) [RFC4291], and that IID normally has a stable link-layer address baked in, like an IEEE LAN MAC address 💖.

in some network technologies and adaptation layers, using an IID based on a link-layer address can actually be useful. for example, [RFC6282] lets you compress IPv6 datagrams over IEEE 802.15.4-based networks [RFC4944] when the IID is based on the underlying link-layer address 🌈.

the security and privacy problems with putting a stable link-layer address in an IPv6 IID have been known for a while, and [RFC7721] goes into way more detail. the big ones are:

  • Network-activity correlation
  • Location tracking
  • Address scanning
  • Device-specific vulnerability exploitation

and it's not just this one thing. reusing identifiers that have their own meaning or properties across different contexts or scopes can hurt security and privacy too [NUM-IDS] 😭. with traditional stable IPv6 IIDs, some of the problems depend on the link-layer address itself (like whether it's ephemeral or randomly generated), and others (like how little entropy the IID has) depend on the algorithm that makes the IID. so if you're writing standard recommendations for stable IIDs that are supposed to get particular security and privacy properties, you do need to say NO to embedding stable link-layer addresses in IPv6 IIDs.

some popular IPv6 implementations have already moved away from the traditional stable IID scheme to deal with those problems [Microsoft] 🔥.

because of all that, this doc changes the recommended default IID scheme for stable IPv6 addresses made with SLAAC to the one in [RFC7217], and it recommends against embedding stable link-layer addresses in IPv6 Interface Identifiers so those problems get mitigated. basically, this document just swaps out the default algorithm recommended for generating stable IPv6 IIDs 💅.

NOTE: [RFC4291] defines the "Modified EUI-64 format" for IIDs. Appendix A of [RFC4291] then describes how to turn an IEEE EUI-64 identifier, or an IEEE 802 48-bit MAC address that an EUI-64 identifier is derived from, into an IID in the Modified EUI-64 format.

in a bunch of situations, addresses that stay the same for as long as a host is connected to one subnet are seen as desirable. stable addresses can be great for network management, event logging, access control enforcement, quality of service, or server and router interfaces 🧚. stable addresses (as opposed to temporary addresses [RFC4941]) also allow long-lived TCP connections, and they're usually wanted when a host is doing server-like things, like receiving incoming connections 🌸.

the recommendations here only apply when an implementation would otherwise configure a stable IPv6 IID that contains a link-layer address. this document does not change any existing recommendations about temporary addresses from [RFC4941], and the recommendations don't apply when SLAAC is used to generate non-stable IPv6 addresses (for example, by embedding a link-layer address that gets periodically randomized). this document also doesn't introduce any new requirements about when stable addresses should be configured. so the recommendations here simply improve the security and privacy properties of stable addresses 💖.

2. Terminology 🎀

Stable address:

  • An address that does not vary over time within the same network (as defined in [RFC7721]).

okay so the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be read as described in RFC 2119 [RFC2119] 🫶.

3. Generation of IPv6 Interface Identifiers with SLAAC 💅

okay this is the actual meat of it, so pay attention bestie 👑. Nodes SHOULD implement and employ [RFC7217] as the default scheme for generating stable IPv6 addresses with SLAAC. A link layer MAY also define a mechanism for stable IPv6 address generation that is more efficient and does not address the security and privacy considerations discussed in Section 1. The choice of whether or not to enable the security- and privacy-preserving mechanism SHOULD be configurable in such a case.

so the default is 7217, but a link layer is allowed to have its own cheaper stable mechanism that doesn't do the security and privacy stuff. and even then, you should be able to turn the privacy-preserving one on or off 🦋.

By default, nodes SHOULD NOT employ IPv6 address generation schemes that embed a stable link-layer address in the IID. In particular, this document RECOMMENDS that nodes do not generate stable IIDs with the schemes specified in [RFC2464], [RFC2467], [RFC2470], [RFC2491], [RFC2492], [RFC2497], [RFC2590], [RFC3146], [RFC3572], [RFC4338], [RFC4391], [RFC5072], and [RFC5121] 🙈.

the rest of the doc (Future Work, Security Considerations, References, Acknowledgements, and Authors' Addresses) is coming in part 2, so stay tuned, periodt 🌈.

6.1. Normative References 📚

okay bestie, here are the receipts 🧾✨ these are the RFCs this spec leans on, and they're listed exactly as the document cites them:

6.2. Informative References 🧠

these ones are extra reading, the bonus track that gives you more context 💜

Acknowledgements 🫶

the authors wanna give a huge shoutout to Bob Hinden, Ray Hunter, and Erik Nordmark, in alphabetical order, for a super detailed review of this doc 🔥

the authors also want to thank (in alphabetical order) Fred Baker, Carsten Bormann, Scott Brim, Brian Carpenter, Samita Chakrabarti, Tim Chown, Lorenzo Colitti, Jean-Michel Combes, Greg Daley, Esko Dijk, Ralph Droms, David Farmer, Brian Haberman, Ulrich Herberg, Philip Homburg, Jahangir Hossain, Jonathan Hui, Christian Huitema, Ray Hunter, Erik Kline, Sheng Jiang, Roger Jorgensen, Dan Luedtke, Kerry Lynn, George Mitchel, Gabriel Montenegro, Erik Nordmark, Simon Perreault, Tom Petch, Alexandru Petrescu, Michael Richardson, Arturo Servin, Mark Smith, Tom Taylor, Ole Troan, Tina Tsou, Glen Turner, Randy Turner, James Woodyatt, and Juan Carlos Zuniga 💖 for sharing valuable comments on earlier draft versions of this document. literal icons, all of them 👑

Authors' Addresses 💌

Fernando Gont
SI6 Networks / UTN-FRH
Evaristo Carriego 2644
Haedo, Provincia de Buenos Aires  1706
Argentina

Phone: +54 11 4650 8472
Email: fgont@si6networks.com
URI:   https://www.si6networks.com


Alissa Cooper
Cisco
707 Tasman Drive
Milpitas, CA  95035
United States of America

Phone: +1-408-902-3950
Email: alcoop@cisco.com
URI:   https://www.cisco.com/


Dave Thaler
Microsoft
Microsoft Corporation
One Microsoft Way
Redmond, WA  98052

Phone: +1 425 703 8835
Email: dthaler@microsoft.com


Will (Shucheng) Liu
Huawei Technologies
Bantian, Longgang District
Shenzhen  518129
China

Email: liushucheng@huawei.com
📦 where this page comes from