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)
UUIDベースのDHCPv6一意識別子（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.
この文書は、新しいDHCPv6の一意識別子（DUID）がDUID-UUIDと呼ばれるタイプを定義します。 DUID-のUUIDは既に標準汎用一意識別子（UUID）フォーマットから導出されます。 DUID-UUIDは、それが可能なデバイスがDHCサーバおよびその逆に自分自身を識別するためのUUIDを使用できるようになります。 UUIDが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.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。インターネット標準の詳細については、RFC 5741のセクション2で利用可能です。
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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
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
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.
DHCP一意識別子（DUIDs）クライアントとサーバを識別するためのDHCPv6で使用されています。この文書は、汎用一意識別子（UUID）[RFC4122]を埋め込む新しいDHCP一意識別子（DUID）タイプを定義します。 UUIDが広範囲に既に使用されているとDHCPv6で活用することができ、既存の識別子として機能します。例えば、デバイス上で動作するソフトウェアに容易に入手可能であるファームウェアに埋め込まれたUUIDとx86ベースのシステムの船。
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.
DUIDsはDHCPv6のに慣れていますが、UUIDを経由してDHCPでクライアントを識別することはできません。 DHCPv4 [RFC2132]はUUID（別名グローバル一意識別子（GUID））[RFC4578]を埋め込むクライアントマシン識別子オプション（オプション97）を定義します。この文書は、DHCPv6のにその機能を拡張します。
Terminology specific to IPv6 and DHCPv6 is used as defined in the "Terminology" sections of [RFC3315].
[RFC3315]の「用語」セクションで定義されたIPv6とDHCPv6に特定の用語が使用されます。
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:
DHCPv6のでは、クライアントがDHCP一意識別子（DUIDs）[RFC3315]を経由してサーバに自分自身を識別します。 DUIDsは、DHCPサーバが無い内部構造を持つように不透明なオブジェクトを扱う識別子です。 DUIDsは同じDUIDを使用していない二つのデバイスで、グローバルに一意であることを意図しています。三のDUIDsタイプが事前に定義されています。
DUID-LLT - the Link-Layer address of one of the device's network interfaces, concatenated with a timestamp
DUID-LLT - デバイスのネットワークインターフェイスの1のリンク層アドレス、タイムスタンプと連結
DUID-EN - an Enterprise Number plus additional information specific to the enterprise
DUID - EN - 企業に固有のエンタープライズナンバープラス追加情報
DUID-LL - the Link-Layer address of one of the device's network interfaces
DUID-LL - デバイスのネットワークインターフェイスの1のリンク層アドレス
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.
DUIDsは、彼らは、デバイスのための恒久的な識別子として使用することができるように、時間をかけて一定に維持することを意図しています。 DUID-のLLTの場合には、それらは、一度生成され安定した記憶装置に記憶され、そしてその時点から再利用されることが意図されます。
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).
多段階ネットワークブートロードを採用懸念デバイスを生じている問題の一つ。最初のステップは、（典型的には、ファームウェアの不足）次に、第2の画像をロードするなど、実際のターゲット・システムがロードされるまで、小さなイメージをロードします。ブート・プロセスの各ステップは、DHCPを呼び出すことができます。いくつかの運用環境では、サーバが同じデバイスからの要求を取得しているし、（ロードするための正しい画像へのポインタを含む）適切な構成情報を返すことができます知っているように、シーケンスの各ステップは、同じDUIDを使用することが重要です。
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.
残念ながら、以前に定義されたDUIDsはいずれも多段階ネットワークブートのための理想的ではありません。所与のデバイスが使用できるDUID-LLTとDUID-LL識別子が各ブートステップを横切って一定に維持することが保証されていません。異なる段階がDUID-LLまたはDUID-LLTを使用する場合でも、複数のインタフェースを持つデバイスで、同じインタフェース（従ってDUID）が選択されることを保証する方法はありません。最後に、DUID-LLTの場合には、同じインタフェースが選択されても、各ステージは同一のタイムスタンプ値を使用することを確保することが困難であることができます。 DUID-ENが定義して使用することができるが、このような使用は、定義によって独自です。
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.
この文書は、汎用一意識別子（UUID）[RFC4122]に基づいて、新しいDUIDタイプを定義します。 UUIDがすでに実際に使用し、DHCPによって活用することができ、既存の識別子として機能しています。いくつかの環境では、UUIDベースDUIDは、他の既存のDUIDタイプに好適です。
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.
DUID-UUIDの使用は、それ自体で、この文書に記載されているすべてのネットワークブートの問題を解決しないことに留意されたいです。適したDUID-UUIDの利用可能性を考えると、実装はまだすべてのブート段階が適切なのと同じDUID-UUIDを使用することを確保するための措置をとる必要があります。 DHCPは、すでに複数のDUIDタイプを定義している、すでにから選択するには、いくつかのDUIDsのの問題が存在し、新しいDUIDタイプを定義することはないことを考えると、それ自体で、助けます。しかしながら、そのネットワークブートサービスはDUID-UUIDを使用するように設定することができ、他のソフトウェアが同様にそうすることができる、と考えられています。これは、一般的に起こる確保することが、このドキュメントの範囲を超えています。
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, 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.
多くのUUIDが今日使用されているが、必ずしもすべてのUUIDは、（[RFC3315]のセクション9を参照）DHCPの要件を満たしています。 DHCP UUIDへのアクセスを必要とするブートプロセスのどの部分にも簡単に利用できるようDHCPのUUIDは、同様にシステムの再起動、システムの再構成イベント、システムソフトウェアとオペレーティングシステムのアップグレードまたは再インストール間で永続的である必要があります。たとえば、Microsoftのコンポーネントオブジェクトモジュール（COM）で使用されるのUUID、およびファイルシステム中の標識のパーティションのために、彼らはブートローダーファームウェアにアクセスできないことがあり、時間の経過とともに変化することができますとして適切でない可能性があります。
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.
DUID-UUIDを使用して、この仕様の実装は、システムの再起動と再構成イベント全体で永続的であり、それが自分自身を識別するために必要な全てのDHCPプロトコルエージェントに提供されていますUUIDを選択する必要があります。例えば、システム・ファームウェアの一部である、またはシステムファームウェアによって管理されるUUIDは、この要件を満たします。
The DUID-UUID is carried within Client Identifier or Server Identifier options. It has the following format:
DUID-UUIDは、クライアント識別子またはサーバー識別子オプション内で搬送されます。これは、次の形式になります。
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
図1：DUID UUIDのフォーマット
DUID-Type - DUID-UUID (4) - (16 bits)
DUIDタイプ - DUID-UUID（4） - （16ビット）
UUID - An [RFC4122] UUID (128 bits)
UUID - [RFC4122] UUID（128ビット）
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.
この文書は、IPv6のためのネットブートのトピックに関する2009年11月DHCのメーリングリストでの議論に触発されました。 DHCPv4の中でうまく働いていたのDHCPv6で何かをすることは困難であったところ具体的には、いくつかのシナリオを説明しました。
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.
トーマスフート、アンドレKostur、スティーブン・ヤコブ、スレシュクリシュナン、テッド・レモン、バーニーフォルツ、およびヴィンセント・ジマー：私たちは、この文書にその具体的な意見や提案のために、特に以下の個人に感謝したいと思います。
IANA has assigned the value 4 for use by the DHCPv6 DUID-UUID type.
IANAは、DHCPv6のDUID-UUIDタイプによって使用するために値4を割り当てました。
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.
クライアントとサーバ間のDHCPトラフィックが平文で送信されます。クライアントとサーバー間のパス上に存在する盗聴者は、DHCPトラフィックを確認し、特定のマシンのUUIDを得ることができました。これは、いくつかのプライバシーの問題を提起が、この文書で定義されたDUIDタイプを使用することによってもたらされた新しい問題ではありませんがあります。
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.
[RFC2132]アレクサンダー、S.とR. Droms、 "DHCPオプションとBOOTPベンダー拡張機能"、RFC 2132、1997年3月。
[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.
[RFC3315] Droms、R.、バウンド、J.、フォルツ、B.、レモン、T.、パーキンス、C.、およびM.カーニー、 "IPv6のための動的ホスト構成プロトコル（DHCPv6）"、RFC 3315、2003年7月。
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, July 2005.
[RFC4122]リーチ、P.、Mealling、M.、およびR. Salzの、 "汎用一意識別子（UUID）URN名前空間"、RFC 4122、2005年7月。
[RFC4578] Johnston, M. and S. Venaas, "Dynamic Host Configuration Protocol (DHCP) Options for the Intel Preboot eXecution Environment (PXE)", RFC 4578, November 2006.
[RFC4578]ジョンストン、M.とS. Venaas、 "インテルプリブート実行環境（PXE）のための動的ホスト構成プロトコル（DHCP）オプション"、RFC 4578、2006年11月。
Authors' Addresses
著者のアドレス
Thomas Narten IBM
トーマスNarts IBM
EMail: narten@us.ibm.com
メールアドレス：narten@us.ibm.com
Jarrod B. Johnson IBM
ジャロッド・B・ジョンソンIBM
EMail: jarrod.b.johnson@gmail.com
メールアドレス：jarrod.b.johnson@gmail.com