doc: Add RFC documents

1 files changed, 507 insertions, 0 deletions

diff --git a/doc/rfc/rfc8064.txt b/doc/rfc/rfc8064.txt
new file mode 100644
index 0000000..c4037e5
--- /dev/null
+++ b/doc/rfc/rfc8064.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                           F. Gont
+Request for Comments: 8064                        SI6 Networks / UTN-FRH
+Updates: 2464, 2467, 2470, 2491, 2492,                         A. Cooper
+         2497, 2590, 3146, 3572, 4291,                             Cisco
+         4338, 4391, 5072, 5121                                D. Thaler
+Category: Standards Track                                      Microsoft
+ISSN: 2070-1721                                                   W. Liu
+                                                     Huawei Technologies
+                                                           February 2017
+
+
+          Recommendation on Stable IPv6 Interface Identifiers
+
+Abstract
+
+   This document changes the recommended default Interface Identifier
+   (IID) generation scheme for cases where Stateless Address
+   Autoconfiguration (SLAAC) is used to generate a stable IPv6 address.
+   It recommends using the mechanism specified in RFC 7217 in such
+   cases, and recommends against 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.  This document does not
+   change any existing recommendations concerning the use of temporary
+   addresses as specified in 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
+   http://www.rfc-editor.org/info/rfc8064.
+
+
+
+
+
+
+
+
+
+
+
+
+Gont, et al.                 Standards Track                    [Page 1]
+
+RFC 8064              Default Interface Identifiers        February 2017
+
+
+Copyright Notice
+
+   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) 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  . . . . . . . . . . . . . . . . . . . . . . . .   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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gont, et al.                 Standards Track                    [Page 2]
+
+RFC 8064              Default Interface Identifiers        February 2017
+
+
+1.  Introduction
+
+   [RFC4862] specifies Stateless Address Autoconfiguration (SLAAC) for
+   IPv6 [RFC2460], which typically results in hosts configuring one or
+   more "stable" addresses composed of a network prefix advertised by a
+   local router, and an Interface Identifier (IID) [RFC4291] that
+   typically embeds a stable link-layer address (e.g., an IEEE LAN MAC
+   address).
+
+   In some network technologies and adaptation layers, the use of an IID
+   based on a link-layer address may offer some advantages.  For
+   example, [RFC6282] allows for the compression of 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 implications of embedding a stable link-
+   layer address in an IPv6 IID have been known for some time now and
+   are discussed in great detail in [RFC7721].  They include:
+
+   o  Network-activity correlation
+
+   o  Location tracking
+
+   o  Address scanning
+
+   o  Device-specific vulnerability exploitation
+
+   More generally, the reuse of identifiers that have their own
+   semantics or properties across different contexts or scopes can be
+   detrimental for security and privacy [NUM-IDS].  In the case of
+   traditional stable IPv6 IIDs, some of the security and privacy
+   implications are dependent on the properties of the underlying link-
+   layer addresses (e.g., whether the link-layer address is ephemeral or
+   randomly generated), while other implications (e.g., reduction of the
+   entropy of the IID) depend on the algorithm for generating the IID
+   itself.  In standardized recommendations for stable IPv6 IID
+   generation meant to achieve particular security and privacy
+   properties, it is necessary to recommend against embedding stable
+   link-layer addresses in IPv6 IIDs.
+
+   Furthermore, some popular IPv6 implementations have already deviated
+   from the traditional stable IID generation scheme to mitigate the
+   aforementioned security and privacy implications [Microsoft].
+
+   As a result of the aforementioned issues, this document changes the
+   recommended default IID generation scheme for generating stable IPv6
+   addresses with SLAAC to that specified in [RFC7217] and recommends
+   against embedding stable link-layer addresses in IPv6 Interface
+
+
+
+Gont, et al.                 Standards Track                    [Page 3]
+
+RFC 8064              Default Interface Identifiers        February 2017
+
+
+   Identifiers, such that the aforementioned issues are mitigated.  That
+   is, this document simply replaces the default algorithm that is
+   recommended to be employed when generating stable IPv6 IIDs.
+
+   NOTE:
+      [RFC4291] defines the "Modified EUI-64 format" for IIDs.
+      Appendix A of [RFC4291] then describes how to transform an IEEE
+      EUI-64 identifier, or an IEEE 802 48-bit MAC address from which an
+      EUI-64 identifier is derived, into an IID in the Modified EUI-64
+      format.
+
+   In a variety of scenarios, addresses that remain stable for the
+   lifetime of a host's connection to a single subnet are viewed as
+   desirable.  For example, stable addresses may be viewed as beneficial
+   for network management, event logging, enforcement of access control,
+   provision of quality of service, or for server or router interfaces.
+   Similarly, stable addresses (as opposed to temporary addresses
+   [RFC4941]) allow for long-lived TCP connections and are also usually
+   desirable when performing server-like functions (i.e., receiving
+   incoming connections).
+
+   The recommendations in this document apply only in cases where
+   implementations otherwise would have configured a stable IPv6 IID
+   containing a link-layer address.  For example, this document does not
+   change any existing recommendations concerning the use of temporary
+   addresses as specified in [RFC4941] and the recommendations do not
+   apply to cases where SLAAC is employed to generate non-stable IPv6
+   addresses (e.g., by embedding a link-layer address that is
+   periodically randomized); in addition, this document does not
+   introduce any new requirements regarding when stable addresses are to
+   be configured.  Thus, the recommendations in this document 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]).
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [RFC2119].
+
+
+
+
+
+
+
+
+
+Gont, et al.                 Standards Track                    [Page 4]
+
+RFC 8064              Default Interface Identifiers        February 2017
+
+
+3.  Generation of IPv6 Interface Identifiers with SLAAC
+
+   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.
+
+   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].
+
+4.  Future Work
+
+   At the time of this writing, the mechanisms specified in the
+   following documents might require updates to be fully compatible with
+   the recommendations in this document:
+
+   o  "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based
+      Networks" [RFC6282]
+
+   o  "Transmission of IPv6 Packets over IEEE 802.15.4 Networks"
+      [RFC4944]
+
+   o  "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless
+      Personal Area Networks (6LoWPANs)" [RFC6775]
+
+   o  "Transmission of IPv6 Packets over ITU-T G.9959 Networks"
+      [RFC7428]
+
+   Future revisions or updates of these documents should consider the
+   issues of privacy and security mentioned in Section 1 and explain any
+   design and engineering considerations that lead to the use of stable
+   IIDs based on a node's link-layer address.
+
+5.  Security Considerations
+
+   This document recommends against the (default) use of predictable
+   Interface Identifiers in IPv6 addresses.  It recommends [RFC7217] as
+   the default scheme for generating IPv6 stable addresses with SLAAC,
+   such that the security and privacy issues of IIDs that embed stable
+   link-layer addresses are mitigated.
+
+
+
+
+Gont, et al.                 Standards Track                    [Page 5]
+
+RFC 8064              Default Interface Identifiers        February 2017
+
+
+6.  References
+
+6.1.  Normative References
+
+   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119,
+               DOI 10.17487/RFC2119, March 1997,
+               <http://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC2460]   Deering, S. and R. Hinden, "Internet Protocol, Version 6
+               (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
+               December 1998, <http://www.rfc-editor.org/info/rfc2460>.
+
+   [RFC2464]   Crawford, M., "Transmission of IPv6 Packets over Ethernet
+               Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998,
+               <http://www.rfc-editor.org/info/rfc2464>.
+
+   [RFC2467]   Crawford, M., "Transmission of IPv6 Packets over FDDI
+               Networks", RFC 2467, DOI 10.17487/RFC2467, December 1998,
+               <http://www.rfc-editor.org/info/rfc2467>.
+
+   [RFC2470]   Crawford, M., Narten, T., and S. Thomas, "Transmission of
+               IPv6 Packets over Token Ring Networks", RFC 2470,
+               DOI 10.17487/RFC2470, December 1998,
+               <http://www.rfc-editor.org/info/rfc2470>.
+
+   [RFC2491]   Armitage, G., Schulter, P., Jork, M., and G. Harter,
+               "IPv6 over Non-Broadcast Multiple Access (NBMA)
+               networks", RFC 2491, DOI 10.17487/RFC2491, January 1999,
+               <http://www.rfc-editor.org/info/rfc2491>.
+
+   [RFC2492]   Armitage, G., Schulter, P., and M. Jork, "IPv6 over ATM
+               Networks", RFC 2492, DOI 10.17487/RFC2492, January 1999,
+               <http://www.rfc-editor.org/info/rfc2492>.
+
+   [RFC2497]   Souvatzis, I., "Transmission of IPv6 Packets over ARCnet
+               Networks", RFC 2497, DOI 10.17487/RFC2497, January 1999,
+               <http://www.rfc-editor.org/info/rfc2497>.
+
+   [RFC2590]   Conta, A., Malis, A., and M. Mueller, "Transmission of
+               IPv6 Packets over Frame Relay Networks Specification",
+               RFC 2590, DOI 10.17487/RFC2590, May 1999,
+               <http://www.rfc-editor.org/info/rfc2590>.
+
+   [RFC3146]   Fujisawa, K. and A. Onoe, "Transmission of IPv6 Packets
+               over IEEE 1394 Networks", RFC 3146, DOI 10.17487/RFC3146,
+               October 2001, <http://www.rfc-editor.org/info/rfc3146>.
+
+
+
+
+Gont, et al.                 Standards Track                    [Page 6]
+
+RFC 8064              Default Interface Identifiers        February 2017
+
+
+   [RFC4291]   Hinden, R. and S. Deering, "IP Version 6 Addressing
+               Architecture", RFC 4291, DOI 10.17487/RFC4291, February
+               2006, <http://www.rfc-editor.org/info/rfc4291>.
+
+   [RFC4338]   DeSanti, C., Carlson, C., and R. Nixon, "Transmission of
+               IPv6, IPv4, and Address Resolution Protocol (ARP) Packets
+               over Fibre Channel", RFC 4338, DOI 10.17487/RFC4338,
+               January 2006, <http://www.rfc-editor.org/info/rfc4338>.
+
+   [RFC4391]   Chu, J. and V. Kashyap, "Transmission of IP over
+               InfiniBand (IPoIB)", RFC 4391, DOI 10.17487/RFC4391,
+               April 2006, <http://www.rfc-editor.org/info/rfc4391>.
+
+   [RFC4862]   Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
+               Address Autoconfiguration", RFC 4862,
+               DOI 10.17487/RFC4862, September 2007,
+               <http://www.rfc-editor.org/info/rfc4862>.
+
+   [RFC4941]   Narten, T., Draves, R., and S. Krishnan, "Privacy
+               Extensions for Stateless Address Autoconfiguration in
+               IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,
+               <http://www.rfc-editor.org/info/rfc4941>.
+
+   [RFC4944]   Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
+               "Transmission of IPv6 Packets over IEEE 802.15.4
+               Networks", RFC 4944, DOI 10.17487/RFC4944, September
+               2007, <http://www.rfc-editor.org/info/rfc4944>.
+
+   [RFC5072]   Varada, S., Ed., Haskins, D., and E. Allen, "IP Version 6
+               over PPP", RFC 5072, DOI 10.17487/RFC5072, September
+               2007, <http://www.rfc-editor.org/info/rfc5072>.
+
+   [RFC5121]   Patil, B., Xia, F., Sarikaya, B., Choi, JH., and S.
+               Madanapalli, "Transmission of IPv6 via the IPv6
+               Convergence Sublayer over IEEE 802.16 Networks",
+               RFC 5121, DOI 10.17487/RFC5121, February 2008,
+               <http://www.rfc-editor.org/info/rfc5121>.
+
+   [RFC6282]   Hui, J., Ed. and P. Thubert, "Compression Format for IPv6
+               Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
+               DOI 10.17487/RFC6282, September 2011,
+               <http://www.rfc-editor.org/info/rfc6282>.
+
+   [RFC6775]   Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.
+               Bormann, "Neighbor Discovery Optimization for IPv6 over
+               Low-Power Wireless Personal Area Networks (6LoWPANs)",
+               RFC 6775, DOI 10.17487/RFC6775, November 2012,
+               <http://www.rfc-editor.org/info/rfc6775>.
+
+
+
+Gont, et al.                 Standards Track                    [Page 7]
+
+RFC 8064              Default Interface Identifiers        February 2017
+
+
+   [RFC7217]   Gont, F., "A Method for Generating Semantically Opaque
+               Interface Identifiers with IPv6 Stateless Address
+               Autoconfiguration (SLAAC)", RFC 7217,
+               DOI 10.17487/RFC7217, April 2014,
+               <http://www.rfc-editor.org/info/rfc7217>.
+
+   [RFC7428]   Brandt, A. and J. Buron, "Transmission of IPv6 Packets
+               over ITU-T G.9959 Networks", RFC 7428,
+               DOI 10.17487/RFC7428, February 2015,
+               <http://www.rfc-editor.org/info/rfc7428>.
+
+6.2.  Informative References
+
+   [Microsoft] Davies, J., "Understanding IPv6, 3rd. ed",
+               page 83, Microsoft Press, 2012,
+               <http://it-ebooks.info/book/1022/>.
+
+   [NUM-IDS]   Gont, F. and I. Arce, "Security and Privacy Implications
+               of Numeric Identifiers Employed in Network Protocols",
+               Work in Progress, February 2016.
+
+   [RFC3572]   Ogura, T., Maruyama, M., and T. Yoshida, "Internet
+               Protocol Version 6 over MAPOS (Multiple Access Protocol
+               Over SONET/SDH)", RFC 3572, DOI 10.17487/RFC3572, July
+               2003, <http://www.rfc-editor.org/info/rfc3572>.
+
+   [RFC7721]   Cooper, A., Gont, F., and D. Thaler, "Security and
+               Privacy Considerations for IPv6 Address Generation
+               Mechanisms", RFC 7721, DOI 10.17487/RFC7721, March 2016,
+               <http://www.rfc-editor.org/info/rfc7721>.
+
+Acknowledgements
+
+   The authors would like to thank (in alphabetical order) Bob Hinden,
+   Ray Hunter, and Erik Nordmark, for providing a detailed review of
+   this document.
+
+   The authors would like 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 providing
+   valuable comments on earlier draft versions of this document.
+
+
+
+Gont, et al.                 Standards Track                    [Page 8]
+
+RFC 8064              Default Interface Identifiers        February 2017
+
+
+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
+
+
+
+
+
+
+
+
+
+
+Gont, et al.                 Standards Track                    [Page 9]
+