doc: Add RFC documents

1 files changed, 283 insertions, 0 deletions

diff --git a/doc/rfc/rfc6355.txt b/doc/rfc/rfc6355.txt
new file mode 100644
index 0000000..8ec4770
--- /dev/null
+++ b/doc/rfc/rfc6355.txt
@@ -0,0 +1,283 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                         T. Narten
+Request for Comments: 6355                                    J. Johnson
+Category: Standards Track                                            IBM
+ISSN: 2070-1721                                              August 2011
+
+
+   Definition of the UUID-Based DHCPv6 Unique Identifier (DUID-UUID)
+
+Abstract
+
+   This document defines a new DHCPv6 Unique Identifier (DUID) type
+   called DUID-UUID.  DUID-UUIDs are derived from the already-
+   standardized Universally Unique IDentifier (UUID) format.  DUID-UUID
+   makes it possible for devices to use UUIDs to identify themselves to
+   DHC servers and vice versa.  UUIDs are globally unique and readily
+   available on many systems, making them convenient identifiers to
+   leverage within DHCP.
+
+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 5741.
+
+   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/rfc6355.
+
+Copyright Notice
+
+   Copyright (c) 2011 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.
+
+
+
+
+
+Narten & Johnson             Standards Track                    [Page 1]
+
+RFC 6355                        DUID-UUID                    August 2011
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2
+   2.  Background  . . . . . . . . . . . . . . . . . . . . . . . . . . 2
+   3.  UUID Considerations . . . . . . . . . . . . . . . . . . . . . . 3
+   4.  DUID-UUID Format  . . . . . . . . . . . . . . . . . . . . . . . 4
+   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 4
+   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
+   7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
+   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 5
+     8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 5
+     8.2.  Informative Reference . . . . . . . . . . . . . . . . . . . 5
+
+1.  Introduction
+
+   DHCP Unique Identifiers (DUIDs) are used in DHCPv6 to identify
+   clients and servers.  This document defines a new DHCP Unique
+   Identifier (DUID) type that embeds a Universally Unique IDentifier
+   (UUID) [RFC4122].  UUIDs are already in widespread use and serve as
+   an existing identifier that could be leveraged by DHCPv6.  For
+   example, x86-based systems ship with an embedded UUID in firmware
+   that is readily available to the software running on the device.
+
+   Although DUIDs are new to DHCPv6, identifying clients in DHCP via a
+   UUID is not.  DHCPv4 [RFC2132] defines a Client Machine Identifier
+   Option (option 97) that embeds a UUID (aka a Globally Unique
+   Identifier (GUID)) [RFC4578].  This document extends that capability
+   to DHCPv6.
+
+   Terminology specific to IPv6 and DHCPv6 is used as defined in the
+   "Terminology" sections of [RFC3315].
+
+2.  Background
+
+   In DHCPv6, clients identify themselves to servers via DHCP Unique
+   Identifiers (DUIDs) [RFC3315].  DUIDs are identifiers that DHCP
+   servers treat as opaque objects with no internal structure.  DUIDs
+   are intended to be globally unique, with no two devices using the
+   same DUID.  Three DUIDs types have been defined previously:
+
+   DUID-LLT -  the Link-Layer address of one of the device's network
+               interfaces, concatenated with a timestamp
+
+   DUID-EN -   an Enterprise Number plus additional information specific
+               to the enterprise
+
+   DUID-LL -   the Link-Layer address of one of the device's network
+               interfaces
+
+
+
+Narten & Johnson             Standards Track                    [Page 2]
+
+RFC 6355                        DUID-UUID                    August 2011
+
+
+   DUIDs are intended to remain constant over time, so that they can be
+   used as permanent identifiers for a device.  In the case of DUID-
+   LLTs, they are intended to be generated once, stored in stable
+   storage, and reused from that point forward.
+
+   One issue that has arisen concerns devices that employ multi-step
+   network boot loading.  An initial step (typically run out of
+   firmware) loads a small image that, in turn, loads a second image and
+   so forth until the actual target system is loaded.  Each step in the
+   booting process may invoke DHCP.  In some operational environments,
+   it is important that each step in the sequence use the same DUID, so
+   that the server knows it is getting requests from the same device and
+   can return the proper configuration information (including the
+   pointer to the correct image to load).
+
+   Unfortunately, none of the previously defined DUIDs are ideal for
+   multi-step network booting.  The DUID-LLT and DUID-LL identifiers
+   that a given device may use are not guaranteed to remain constant
+   across each booting step.  Even if the different stages used DUID-LL
+   or DUID-LLT, on devices with multiple interfaces, there is no way to
+   guarantee that the same interface (and hence DUID) will be selected.
+   Finally, in the case of DUID-LLT, even if the same interface is
+   chosen, it can be difficult to ensure that each stage uses the same
+   timestamp value.  While a DUID-EN could be defined and used, such
+   usage is proprietary by definition.
+
+   This document defines a new DUID type, based on the Universally
+   Unique IDentifier (UUID) [RFC4122].  UUIDs are already used in
+   practice and serve as an existing identifier that could be leveraged
+   by DHCP.  In some environments, a UUID-based DUID is preferable to
+   the other existing DUID types.
+
+   It should be noted that use of a DUID-UUID will not, by itself, solve
+   all the network boot problems described in this document.  Given the
+   availability of a suitable DUID-UUID, implementations will still need
+   to take steps to ensure that all boot stages use the same DUID-UUID
+   as appropriate.  Given that DHCP has already defined multiple DUID
+   types, the question of which of several DUIDs to select from already
+   exists, and defining a new DUID type does not, by itself, help.  It
+   is believed, however, that network boot services can be configured to
+   use a DUID-UUID and that other software can do so as well.  Ensuring
+   this happens in general is beyond the scope of this document.
+
+3.  UUID Considerations
+
+   Although many UUIDs are in use today, not all UUIDs meet DHCP's
+   requirements (see Section 9 of [RFC3315]).  DHCP UUIDs should be
+   persistent across system restarts, system reconfiguration events,
+
+
+
+Narten & Johnson             Standards Track                    [Page 3]
+
+RFC 6355                        DUID-UUID                    August 2011
+
+
+   system software and operating system upgrades or reinstallation as
+   well as be easily available to any part of the boot process that
+   requires access to the DHCP UUID.  For example, UUIDs used in
+   Microsoft's Component Object Module (COM), and for labeling
+   partitions in filesystems, are likely not appropriate as they may not
+   be accessible to firmware boot loaders and can change over time.
+
+   Implementations of this specification using DUID-UUID must select a
+   UUID that is persistent across system restart and reconfiguration
+   events and that is available to all DHCP protocol agents that may
+   need to identify themselves.  For instance, a UUID that is part of
+   the system firmware, or managed by the system firmware, satisfies
+   this requirement.
+
+4.  DUID-UUID Format
+
+   The DUID-UUID is carried within Client Identifier or Server
+   Identifier options.  It has the following format:
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |          DUID-Type (4)        |    UUID (128 bits)            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
+   |                                                               |
+   |                                                               |
+   |                                -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+                        Figure 1: DUID-UUID Format
+
+   DUID-Type -  DUID-UUID (4) - (16 bits)
+
+   UUID -  An [RFC4122] UUID (128 bits)
+
+5.  Acknowledgements
+
+   This document was inspired by a discussion on the DHC mailing list in
+   November 2009 on the topic of netboot for IPv6.  Specifically, some
+   scenarios were described where it was difficult to do something in
+   DHCPv6 that had worked well in DHCPv4.
+
+   We would like to thank the following individuals in particular for
+   their specific comments and suggestions on this document: Thomas
+   Huth, Andre Kostur, Stephen Jacob, Suresh Krishnan, Ted Lemon, Bernie
+   Volz, and Vincent Zimmer.
+
+
+
+
+Narten & Johnson             Standards Track                    [Page 4]
+
+RFC 6355                        DUID-UUID                    August 2011
+
+
+6.  IANA Considerations
+
+   IANA has assigned the value 4 for use by the DHCPv6 DUID-UUID type.
+
+7.  Security Considerations
+
+   DHCP traffic between a client and server is sent in the clear.  An
+   eavesdropper residing on the path between the client and server could
+   see DHCP traffic and obtain the UUID for a particular machine.  This
+   may raise some privacy issues but is not a new issue brought on by
+   the use of the DUID type defined in this document.
+
+8.  References
+
+8.1.  Normative References
+
+   [RFC2132]  Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
+              Extensions", RFC 2132, March 1997.
+
+   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
+              and M. Carney, "Dynamic Host Configuration Protocol for
+              IPv6 (DHCPv6)", RFC 3315, July 2003.
+
+   [RFC4122]  Leach, P., Mealling, M., and R. Salz, "A Universally
+              Unique IDentifier (UUID) URN Namespace", RFC 4122,
+              July 2005.
+
+8.2.  Informative Reference
+
+   [RFC4578]  Johnston, M. and S. Venaas, "Dynamic Host Configuration
+              Protocol (DHCP) Options for the Intel Preboot eXecution
+              Environment (PXE)", RFC 4578, November 2006.
+
+Authors' Addresses
+
+   Thomas Narten
+   IBM
+
+   EMail: narten@us.ibm.com
+
+
+   Jarrod B. Johnson
+   IBM
+
+   EMail: jarrod.b.johnson@gmail.com
+
+
+
+
+
+
+Narten & Johnson             Standards Track                    [Page 5]
+