Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6
RFC 8981
Document | Type |
RFC - Proposed Standard
(February 2021; No errata)
Obsoletes RFC 4941
|
|
---|---|---|---|
Authors | Fernando Gont , Suresh Krishnan , Thomas Narten , Richard Draves | ||
Last updated | 2021-02-28 | ||
Replaces | draft-fgont-6man-rfc4941bis | ||
Stream | Internet Engineering Task Force (IETF) | ||
Formats | plain text html xml pdf htmlized (tools) htmlized bibtex | ||
Reviews | |||
Stream | WG state | Submitted to IESG for Publication | |
Document shepherd | Ole Trøan | ||
Shepherd write-up | Show (last changed 2020-06-04) | ||
IESG | IESG state | RFC 8981 (Proposed Standard) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Yes | ||
Telechat date | |||
Responsible AD | Erik Kline | ||
Send notices to | otroan@employees.org | ||
IANA | IANA review state | Version Changed - Review Needed | |
IANA action state | No IANA Actions |
Internet Engineering Task Force (IETF) F. Gont Request for Comments: 8981 SI6 Networks Obsoletes: 4941 S. Krishnan Category: Standards Track Kaloom ISSN: 2070-1721 T. Narten R. Draves Microsoft Research February 2021 Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6 Abstract This document describes an extension to IPv6 Stateless Address Autoconfiguration that causes hosts to generate temporary addresses with randomized interface identifiers for each prefix advertised with autoconfiguration enabled. Changing addresses over time limits the window of time during which eavesdroppers and other information collectors may trivially perform address-based network-activity correlation when the same address is employed for multiple transactions by the same host. Additionally, it reduces the window of exposure of a host as being accessible via an address that becomes revealed as a result of active communication. This document obsoletes 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 provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8981. Copyright Notice Copyright (c) 2021 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 (https://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. Table of Contents 1. Introduction 1.1. Terminology 1.2. Problem Statement 2. Background 2.1. Extended Use of the Same Identifier 2.2. Possible Approaches 3. Protocol Description 3.1. Design Guidelines 3.2. Assumptions 3.3. Generation of Randomized IIDs 3.3.1. Simple Randomized IIDs 3.3.2. Generation of IIDs with Pseudorandom Functions 3.4. Generating Temporary Addresses 3.5. Expiration of Temporary Addresses 3.6. Regeneration of Temporary Addresses 3.7. Implementation Considerations 3.8. Defined Protocol Parameters and Configuration Variables 4. Implications of Changing IIDs 5. Significant Changes from RFC 4941 6. Future Work 7. IANA Considerations 8. Security Considerations 9. References 9.1. Normative References 9.2. Informative References Acknowledgments Authors' Addresses 1. Introduction [RFC4862] specifies Stateless Address Autoconfiguration (SLAAC) for IPv6, which typically results in hosts configuring one or more "stable" IPv6 addresses composed of a network prefix advertised by a local router and a locally generated interface identifier (IID). The security and privacy implications of such addresses have been discussed in detail in [RFC7721], [RFC7217], and [RFC7707]. This document specifies an extension to SLAAC for generating temporary addresses that can help mitigate some of the aforementioned issues. This document is a revision of RFC 4941 and formally obsoletes it. Section 5 describes the changes from [RFC4941]. The default address selection for IPv6 has been specified in [RFC6724]. In some cases, the determination as to whether to use stable versus temporary addresses can only be made by an application. For example, some applications may always want to use temporary addresses, while others may want to use them only in some circumstances or not at all. An Application Programming Interface (API) such as that specified in [RFC5014] can enable individual applications to indicate a preference for the use of temporary addresses. Section 2 provides background information. Section 3 describes aShow full document text