Network Working Group T. Lemon
Request for Comments: 4361 Nominum
Updates: 2131, 2132, 3315 B. Sommerfield
Category: Standards Track Sun Microsystems
February 2006
Node-specific Client Identifiers for
Dynamic Host Configuration Protocol Version Four (DHCPv4)
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
This document specifies the format that is to be used for encoding Dynamic Host Configuration Protocol Version Four (DHCPv4) client identifiers, so that those identifiers will be interchangeable with identifiers used in the DHCPv6 protocol. This document also addresses and corrects some problems in RFC 2131 and RFC 2132 with respect to the handling of DHCP client identifiers.
この文書では、これらの識別子は、DHCPv6のプロトコルで使用される識別子と互換になるように、動的ホスト構成プロトコルバージョン四つ（のDHCPv4）クライアント識別子を符号化するために使用される形式を指定します。また、このドキュメントでは、アドレスとDHCPクライアント識別子の取り扱いに関して、RFC 2131およびRFC 2132でいくつかの問題を修正します。
Table of Contents
目次
1. Introduction ....................................................2
2. Terminology .....................................................2
3. Applicability ...................................................2
4. Problem Statement ...............................................3
4.1. Client identities are ephemeral. ...........................3
4.2. Clients can accidentally present multiple identities. ......3
4.3. RFC 2131/2132 and RFC 3315 identifiers are incompatible. ...4
4.4. RFC 2131 does not require the use of a client identifier. ..4
5. Requirements ....................................................4
6. Implementation ..................................................6
6.1. DHCPv4 Client Behavior .....................................6
6.2. DHCPv6 Client Behavior .....................................7
6.3. DHCPv4 Server Behavior .....................................7
6.4. Changes from RFC 2131 ......................................8
6.5. Changes from RFC 2132 ......................................9
7. Notes on DHCP Clients in Multi-stage Network Booting ............9
8. Security Considerations ........................................10
9. References .....................................................10
9.1. Normative References ......................................10
9.2. Informative References ....................................10
This document specifies the way in which Dynamic Host Configuration Protocol Version 4 [RFC2131] clients should identify themselves. DHCPv4 client implementations that conform to this specification use a DHCP Unique Identifier (DUID) as specified in Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315]. The DUID is encapsulated in a DHCPv4 client identifier option, as described in "DHCP Options and BOOTP Vendor Extensions" [RFC2132]. The behaviour described here supersedes the behavior specified in RFC2131 and RFC2132.
この文書では、動的ホスト構成プロトコルバージョン4 [RFC2131]クライアントが自分自身を識別する必要がありますする方法を指定します。 IPv6の動的ホスト構成プロトコル（DHCPv6の）[RFC3315]で指定されたように、この仕様に準拠するのDHCPv4クライアントの実装は、DHCP一意識別子（DUID）を使用します。 「DHCPオプションとBOOTPベンダー拡張機能」で説明したようにDUIDは、[RFC2132]、DHCPv4のクライアント識別子オプションにカプセル化されます。ここで説明する動作は、RFC2131とRFC2132で指定された動作を優先します。
The reason for making this change is that as we make the transition from IPv4 to IPv6, there will be network devices that must use both DHCPv4 and DHCPv6. Users of these devices will have a smoother network experience if the devices identify themselves consistently, regardless of the version of DHCP they are using at any given moment. Most obviously, DNS updates made by the DHCP server on behalf of the client will be handled more correctly. This change also addresses certain limitations in the functioning of RFC 2131/2132-style DHCP client identifiers.
この変更を行うための理由は、我々は、IPv4からIPv6への移行を行うよう、DHCPv4とDHCPv6の両方を使用しなければならないネットワークデバイスが存在することです。デバイスが一貫自分自身を識別した場合、これらのデバイスのユーザーは関係なく、任意の時点で使用しているDHCPのバージョンの、スムーズなネットワークの経験を持っています。ほとんど明らかに、クライアントに代わってDHCPサーバーによって行われたDNSの更新は、より正確に処理されます。この変更は、RFC 2132分の2131スタイルのDHCPクライアント識別子の機能に一定の制限に対処しています。
This document first describes the problem to be solved. It then states the new technique that is to be used to solve the problem. Finally, it describes the specific changes that one would have to make to RFC 2131 and RFC 2132 in order for those documents not to contradict what is described in this document.
この文書では、最初に解決すべき問題について説明します。これは、その問題を解決するために使用される新しい技術を述べています。最後に、それは1つが、この文書で説明されているものと矛盾しないように、それらの文書にするためにRFC 2131およびRFC 2132に作成しなければならない具体的な変更点について説明します。
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].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
This document updates RFC 2131 and RFC 2132. This document also specifies behavior that is required of DHCPv4 and DHCPv6 clients that are intended to operate in a dual-stack configuration. Finally, this document recommends behavior for host configurations where more than one DHCP client must operate in sequence in order to fully configure the client (e.g., a network boot loader and the operating system it loads).
このドキュメントの更新RFC 2131およびRFC 2132また、このドキュメントでは、デュアルスタック構成で動作することを意図しているのDHCPv4とDHCPv6クライアントに要求される動作を指定します。最後に、この文書は、複数のDHCPクライアントが完全にクライアントを設定するために順番に動作させなければならないホスト構成のための行動を推奨しています（例えば、ネットワークブートローダーとそれがロードオペレーティングシステム）。
DHCPv4 clients and servers that are implemented according to this document should be implemented as if the changes specified in sections 6.3 and 6.4 have been made to RFC 2131 and RFC 2132. DHCPv4 clients should, in addition, follow the behavior specified in section 6.1. DHCPv6 clients should follow the behavior specified in section 6.2. DHCPv4 servers should additionally follow the behavior specified in section 6.3.
セクション6.3と6.4で指定された変更は、ほかに、6.1節で指定された動作に従うべきであるRFC 2131およびRFC 2132のDHCPv4クライアントに行われているかのように、この文書に基づいて実装されているのDHCPv4クライアントとサーバを実装する必要があります。 DHCPv6クライアントは、セクション6.2で指定された動作に従ってください。 DHCPv4サーバは、さらに6.3節で指定された動作に従ってください。
RFC 2132 recommends that client identifiers be generated by using the permanent link-layer address of the network interface that the client is trying to configure. One result of this recommendation is that when the network interface hardware on a client computer is replaced, the identity of the client changes. The client loses its IP address and any other resources associated with its old identifier (for example, its domain name as published through the DHCPv4 server).
RFC 2132は、クライアント識別子は、クライアントが設定しようとしているネットワークインタフェースのパーマネントリンク層アドレスを使用することによって生成されることをお勧めします。この勧告の一つの結果は、クライアントコンピュータ上のネットワーク・インターフェース・ハードウェアを交換した際に、クライアントのアイデンティティが変化することです。クライアントは、そのIPアドレスとその古い識別子に関連付けられている任意の他のリソースを失う（例えば、DHCPv4サーバを通じて公開され、そのドメイン名）。
Consider a DHCPv4 client that has two network interfaces, one of which is wired and one of which is wireless. The DHCPv4 client will succeed in configuring either zero, one, or two network interfaces. Under the current specification, each network interface will receive a different IP address. The DHCPv4 server will treat each network interface as a completely independent DHCPv4 client, on a completely independent host.
配線との一方が無線である一方が2つのネットワークインタフェースを有し、DHCPv4のクライアントを考えます。 DHCPv4クライアントは、ゼロ、1、または2つのネットワークインタフェースのいずれかを設定することに成功します。現在の仕様では、各ネットワークインタフェースは、異なるIPアドレスを受信します。 DHCPv4サーバは完全に独立したホスト上で、完全に独立したDHCPv4クライアントとして各ネットワークインタフェースを扱います。
Thus, when the client presents some information to be updated in a network directory service, such as the DNS, the name that is presented will be the same on both interfaces, but the identity that is presented will be different. What will happen is that one of the two interfaces will get the name, and will retain that name as long as it has a valid lease, even if it loses its connection to the network, while the other network interface will never get the name. In some cases, this will achieve the desired result; when only one network interface is connected, sometimes its IP address will be published. In some cases, the one connected interface's IP address will not be the one that is published. When there are two interfaces, sometimes the correct one will be published, and sometimes not.
クライアントは、DNSなどのネットワークディレクトリサービスに更新されるいくつかの情報を提示したときにこのように、提示された名前は、両方のインターフェイスで同じになりますが、提示されたアイデンティティは異なるものになります。何が起こるだろうことは、他のネットワークインタフェースが名を取得することはありませんしながら、2つのインターフェイスの1つが、それはネットワークへの接続を失った場合でも、名前を取得し、限り、それは有効なリースを持っているように、その名前を保持するということです。いくつかのケースでは、これは、所望の結果を達成します。 1つのネットワークインターフェイスのみが接続されているとき、時々、そのIPアドレスが公開されます。いくつかのケースでは、1つの接続されたインタフェースのIPアドレスは公開されているいずれかになりません。二つのインタフェースがある場合、時には正しいものは公表され、時にはれません。
This is likely to be a particular problem with modern laptops, which usually have built-in wireless ethernet and wired ethernet. When the user is near a wired outlet, he or she may want the additional speed and privacy provided by a wired connection, but that same user may unplug from the wired network and wander around, still connected to the wireless network. When a transition like this happens, under the current scheme, if the address of the wired interface is the one that gets published, this client will be seen by hosts attempting to connect to it as if it has intermittent connectivity, even though it actually has continuous network connectivity through the wireless port.
これは通常、内蔵されているワイヤレスイーサネットと有線イーサネット現代のラップトップ、持つ特有の問題である可能性が高いです。ユーザーは、有線コンセントの近くにある場合は、彼または彼女は、有線接続によって提供される追加の速さとプライバシーを望むかもしれないが、その同じユーザは、有線ネットワークから外し、まだワイヤレスネットワークに接続され、さまようことがあります。このような遷移が発生すると、有線インタフェースのアドレスが公開されますものであれば、現在のスキームの下で、このクライアントは、それが実際に持っているにもかかわらず、それは断続的な接続を持っているかのように、それに接続しようとするホストが見られます無線ポートを介して連続ネットワーク接続。
Another common case of a duplicate identity being presented occurs when a boot monitor such as a Pre-Boot Execution Environment (PXE) loader specifies one DHCP client identifier, and then the operating system loaded by the boot loader specifies a different identity.
ブートモニタは、ブート前実行環境（PXE）ローダとして1つのDHCPクライアント識別子を指定して、ブートローダーによってロードされたオペレーティングシステムが異なるIDを指定する際に提示されている重複したアイデンティティのもう一つの一般的なケースが発生します。
The 'client identifier' option is used by DHCPv4 clients and servers to identify clients. In some cases, the value of the 'client identifier' option is used to mediate access to resources (for example, the client's domain name, as published through the DHCPv4 server). RFC 2132 and RFC 3315 specify different methods for deriving client identifiers. These methods guarantee that the DHCPv4 and DHCPv6 identifiers will be different. This means that mediation of access to resources using these identifiers will not work correctly in cases where a node may be configured using DHCPv4 in some cases and DHCPv6 in other cases.
「クライアント識別子」オプションは、クライアントを識別するためのDHCPv4クライアントとサーバによって使用されます。いくつかのケースでは、「クライアント識別子」オプションの値は、リソースへのアクセスを仲介するために使用されます（たとえば、クライアントのドメイン名、DHCPv4サーバを通じて公開されます）。 RFC 2132およびRFC 3315には、クライアント識別子を導出するためのさまざまな方法を指定します。これらのメソッドは、DHCPv4とDHCPv6の識別子が異なるものになることを保証します。これは、これらの識別子を使用してリソースへのアクセスの調停は、ノードが他のケースでは、いくつかの例とDHCPv6でのDHCPv4を使用して構成することができる場合には正しく動作しないことを意味します。
RFC 2131 allows the DHCPv4 server to identify clients either by using the client identifier option sent by the client or, if the client did not send one, the client's link-layer address. Like the client identifier format recommended by RFC 2131, this suffers from the problems previously described in sections 4.2 and 4.3.
RFC 2131には、DHCPv4サーバは、クライアントが、クライアントのリンク層アドレスを1に送信しなかった場合、クライアントから送信されたクライアント識別子オプションを使用するかのいずれかによって、クライアントを識別することができます。 RFC 2131によって推奨されるクライアント識別子の形式と同様に、これは、以前のセクション4.2および4.3に記載の問題があります。
In order to address the problems stated in section 4, DHCPv4 client identifiers must have the following characteristics:
第4章で述べた問題に対処するためには、DHCPv4のクライアント識別子は、次のような特徴を持っている必要があります。
- They must be persistent, in the sense that a particular host's client identifier must not change simply because a piece of network hardware is added or removed.
- 彼らは、ネットワークハードウェアの部分が追加または削除されているため、特定のホストのクライアント識別子は、単に変化してはならないという意味で、永続的でなければなりません。
- It must be possible for the client to represent itself as having more than one network identity, for example, so that a client with two network interfaces can express to the DHCPv4 server that these two network interfaces are to receive different IP addresses, even if they happen to be connected to the same link.
- 2つのネットワークインタフェースを有するクライアントは、これら2つのネットワークインタフェースが異なるIPアドレスを受信するようにされているDHCPv4サーバに表現できるように、クライアントは、例えば、複数のネットワークIDを有するものとして自分自身を表現することはあっても、可能でなければなりません彼らは同じリンクに接続することが起こります。
- In cases where the DHCPv4 client is expressing more than one network identity at the same time, it must nevertheless be possible for the DHCPv4 server to determine that the two network identities belong to the same host.
- DHCPv4のクライアントが同時に複数のネットワークアイデンティティを表現している場合には、それにもかかわらず、2人のネットワークのアイデンティティが同じホストに属していることを決定するために、DHCPv4サーバのために可能でなければなりません。
- In some cases it may be desirable for a DHCP client to present the same identity on two interfaces, so that if they both happen to be connected to the same network, they will both receive the same IP address. In such cases, it must be possible for the client to use exactly the same identifier for each interface.
- DHCPクライアントの2つのインターフェイス上で同じIDを提示するために、それらの両方が同じネットワークに接続することが起こるならばという、彼らは両方とも同じIPアドレスを受け取ることになりますので、いくつかのケースでは、ことが望ましいことがあります。クライアントは、インターフェイスごとに正確に同じ識別子を使用するためにこのような場合には、それが可能でなければなりません。
- DHCPv4 servers that do not conform to this specification, but that are compliant with the older client identifier specification, must correctly handle client identifiers sent by clients that conform to this specification.
- この仕様に準拠しますが、いないのDHCPv4サーバは正しく、この仕様に準拠したクライアントによって送信されたクライアント識別子を処理しなければならない、古いクライアント識別子の仕様に準拠しています。
- DHCPv4 servers that do conform to this specification must interoperate correctly with DHCPv4 clients that do not conform to this specification, except that when configuring such clients, behaviors such as those described in section 2 may occur.
- この仕様に準拠しないのDHCPv4サーバは、クライアントを構成するときに、そのようなセクション2に記載されているような行動が発生する可能性があることを除いて、この仕様に準拠していないのDHCPv4クライアントと正しく相互運用する必要があります。
- The use by DHCPv4 clients of the chaddr field of the DHCPv4 packet as an identifier must be deprecated.
- 識別子としてのDHCPv4パケットのとchaddrフィールドのDHCPv4のクライアントによって使用は廃止されなければなりません。
- DHCPv4 client identifiers used by dual-stack hosts that also use DHCPv6 must use the same host identification string for both DHCPv4 and DHCPv6. For example, a DHCPv4 server that uses the client's identity to update the DNS on behalf of a DHCPv4 client must register the same client identity in the DNS that would be registered by the DHCPv6 server on behalf of the DHCPv6 client running on that host, and vice versa.
- また、DHCPv4とDHCPv6の両方に同じホスト識別文字列を使用しなければならないのDHCPv6を使用するデュアルスタックホストが使用するのDHCPv4クライアント識別子。例えば、DHCPv4のクライアントの代わりにDNSを更新するために、クライアントのIDを使用していますDHCPv4サーバは、そのホスト上で実行されているDHCPv6クライアントに代わってDHCPv6サーバによって登録されますDNSで同じクライアントIDを登録する必要がありますし、逆に。
In order to satisfy all but the last of these requirements, we need to construct a DHCPv4 client identifier out of two parts. One part must be unique to the host on which the client is running. The other must be unique to the network identity being presented. The DHCP Unique Identifier (DUID) and Identity Association Identifier (IAID) specified in RFC 3315 satisfy these requirements.
すべてが、これらの要件の最後を満たすために、我々は二つの部分から出たDHCPv4クライアント識別子を構築する必要があります。一方の部分は、クライアントが実行されているホストに固有でなければなりません。他には、提示されているネットワークアイデンティティに一意である必要があります。 RFC 3315で指定されたDHCP一意識別子（DUID）とアイデンティティ協会識別子（IAID）は、これらの要件を満たします。
In order to satisfy the last requirement, we must use the DUID to identify the DHCPv4 client. So, taking all the requirements together, the DUID and IAID described in RFC 3315 are the only possible solution.
最後の要件を満たすために、我々は、DHCPv4のクライアントを識別するためにDUIDを使用する必要があります。だから、一緒にすべての要件を取って、DUIDとIAIDは、RFC 3315に記述が唯一可能な解決策です。
By following these rules, a compliant DHCPv4 client will interoperate correctly with both compliant and non-compliant DHCPv4 servers. A non-compliant DHCPv4 client will also interoperate correctly with a compliant DHCPv4 server. If either server or client is not compliant, the goals stated in the document are not met, but there is no loss of functionality.
これらのルールに従うことで、対応のDHCPv4クライアントは準拠し、非準拠のDHCPv4サーバーの両方で正しく相互運用できます。非準拠のDHCPv4クライアントも準拠したDHCPv4サーバと正しく相互運用されます。サーバーまたはクライアントが準拠していない場合は、ドキュメントに記載された目標が満たされていないが、機能の損失はありません。
Here we specify changes to the behavior of DHCPv4 clients and servers. We also specify changes to the wording in RFC 2131 and RFC 2132. DHCPv4 clients, servers, and relay agents that conform to this specification must implement RFC 2131 and RFC 2132 with the wording changes specified in sections 6.3 and 6.4.
ここでは、DHCPv4のクライアントとサーバの動作への変更を指定します。また、セクション6.3および6.4に指定された文言の変更とRFC 2131およびRFC 2132を実装する必要があり、この仕様に準拠RFC 2131およびRFC 2132のDHCPv4クライアント、サーバ、およびリレーエージェントでの文言の変更を指定します。
DHCPv4 clients conforming to this specification MUST use stable DHCPv4 node identifiers in the dhcp-client-identifier option. DHCPv4 clients MUST NOT use client identifiers based solely on layer two addresses that are hard-wired to the layer two device (e.g., the ethernet MAC address) as suggested in RFC 2131, except as allowed in section 9.2 of RFC 3315. DHCPv4 clients MUST send a 'client identifier' option containing an Identity Association Unique Identifier, as defined in section 10 of RFC 3315, and a DHCP Unique Identifier, as defined in section 9 of RFC 3315. These together constitute an RFC 3315-style binding identifier.
この仕様に準拠したDHCPv4クライアントは、dhcp-client-identifierオプションで安定したDHCPv4ノード識別子を使用しなければなりません。 RFC 3315のDHCPv4クライアントのセクション9.2で認められている場合を除き、RFC 2131で提案されているようにDHCPv4のクライアントは、単に層の上にハード配線層2のデバイス（例えば、イーサネットMACアドレス）にある2つのアドレスをベースのクライアント識別子を使用してはならないMUST RFC 3315のセクション9一緒にこれらの中で定義されているRFC 3315スタイルの結合識別子を構成し、RFC 3315のセクション10で定義されているように、アイデンティティ協会一意識別子を含む「クライアント識別子」オプションを送信し、DHCP一意識別子。
The general format of the DHCPv4 'client identifier' option is defined in section 9.14 of RFC 2132.
DHCPv4の「クライアント識別子」オプションの一般的なフォーマットは、RFC 2132のセクション9.14で定義されています。
To send an RFC 3315-style binding identifier in a DHCPv4 'client identifier' option, the type of the 'client identifier' option is set to 255. The type field is immediately followed by the IAID, which is an opaque 32-bit quantity. The IAID is immediately followed by the DUID, which consumes the remaining contents of the 'client identifier' option. The format of the 'client identifier' option is as follows:
DHCPv4の「クライアント識別子」オプションでRFC 3315スタイルの結合識別子を送信するために、「クライアント識別子」オプションのタイプは、タイプフィールドは直ちに不透明な32ビットの値であるIAID、続いて255に設定されています。 IAIDはすぐに「クライアント識別子」オプションの残りの内容を消費DUID、続いています。次のように「クライアント識別子」オプションの形式は次のとおりです。
Code Len Type IAID DUID
+----+----+-----+----+----+----+----+----+----+---
| 61 | n | 255 | i1 | i2 | i3 | i4 | d1 | d2 |...
+----+----+-----+----+----+----+----+----+----+---
Any DHCPv4 client that conforms to this specification SHOULD provide a means by which an operator can learn what DUID the client has chosen. Such clients SHOULD also provide a means by which the operator can configure the DUID. A device that is normally configured by both a DHCPv4 and DHCPv6 client SHOULD automatically use the same DUID for DHCPv4 and DHCPv6 without any operator intervention.
この仕様に準拠した任意のDHCPv4クライアントは、オペレータがDUIDクライアントが選択したものを学ぶことができる手段を提供する必要があります。このようなクライアントは、オペレータがDUIDを設定することができる手段を提供する必要があります。通常DHCPv4とDHCPv6クライアントの両方によって構成されているデバイスは、自動的にオペレータの介入なしDHCPv4とDHCPv6の同じDUIDを使用すべきです。
DHCPv4 clients that support more than one network interface SHOULD use the same DUID on every interface. DHCPv4 clients that support more than one network interface SHOULD use a different IAID on each interface.
複数のネットワークインタフェースをサポートするのDHCPv4クライアントは、すべてのインターフェイス上で同じDUIDを使用すべきです。複数のネットワークインタフェースをサポートするのDHCPv4クライアントは、各インターフェイスで異なるIAIDを使用すべきです。
A DHCPv4 client that generates a DUID and that has stable storage MUST retain this DUID for use in subsequent DHCPv4 messages, even after an operating system reboot.
DUIDを生成し、それが安定した記憶装置を有するのDHCPv4クライアントがあっても、オペレーティングシステムの再起動後に、後続のDHCPv4メッセージで使用するためのこのDUIDを保持しなければなりません。
Any DHCPv6 client that conforms to this specification SHOULD provide a means by which an operator can learn what DUID the client has chosen. Such clients SHOULD also provide a means by which the operator can configure the DUID. A device that is normally configured by both a DHCPv4 and DHCPv6 client SHOULD automatically use the same DUID for DHCPv4 and DHCPv6 without any operator intervention.
この仕様に準拠したDHCPv6クライアントは、オペレータがDUIDクライアントが選択したものを学ぶことができる手段を提供する必要があります。このようなクライアントは、オペレータがDUIDを設定することができる手段を提供する必要があります。通常DHCPv4とDHCPv6クライアントの両方によって構成されているデバイスは、自動的にオペレータの介入なしDHCPv4とDHCPv6の同じDUIDを使用すべきです。
This document does not require any change to DHCPv4 or DHCPv6 servers that follow RFC 2131 and RFC 2132. However, some DHCPv4 servers can be configured not to conform to RFC 2131 and RFC 2132, in the sense that they ignore the 'client identifier' option and use the client's hardware address instead.
このドキュメントは、しかし、RFC 2131およびRFC 2132に従うのDHCPv4またはDHCPv6のサーバに変更を必要としない、いくつかのDHCPv4サーバーは、「クライアント識別子」オプションを無視するという意味で、RFC 2131およびRFC 2132に準拠しないように設定することができます代わりに、クライアントのハードウェアアドレスを使用します。
DHCPv4 servers that conform to this specification MUST use the 'client identifier' option to identify the client if the client sends it.
この仕様に準拠したDHCPv4サーバは、クライアントがそれを送信する場合、クライアントを識別するためのクライアント識別子 'オプションを使用しなければなりません。
DHCPv4 servers MAY use administrator-supplied values for chaddr and htype to identify the client in the case where the administrator is assigning a fixed IP address to the client, even if the client sends a client identifier option. This is ONLY permitted in the case where the DHCPv4 server administrator has provided the values for chaddr and htype, because in this case if it causes a problem, the administrator can correct the problem by removing the offending configuration information.
DHCPv4サーバは、クライアントがクライアント識別子オプションを送信した場合でも、管理者がクライアントに固定IPアドレスを割り当てている場合には、クライアントを識別するとchaddrとhtypeフィールドの管理者が指定する値を使用するかもしれません。それが問題になる場合は、この場合には、管理者が問題の設定情報を削除することによって、問題を修正することができますので、これはONLY、DHCPv4サーバ管理者はとchaddrとhtypeフィールドの値を提供している場合には許可されています。
In section 2 of RFC 2131, on page 9, the text that reads "; for example, the 'client identifier' may contain a hardware address, identical to the contents of the 'chaddr' field, or it may contain another type of identifier, such as a DNS name" is deleted.
RFC 2131のセクション2で、9ページ、「読み取るテキストで、例えば、「クライアント識別子は 『とchaddr』フィールドの内容と同一のハードウェア・アドレスを含むことができる、またはそれは識別子の別のタイプを含んでいてもよいですこのようなDNS名として」削除されます。
In section 4.2 of RFC 2131, the text "The client MAY choose to explicitly provide the identifier through the 'client identifier' option. If the client supplies a 'client identifier', the client MUST use the same 'client identifier' in all subsequent messages, and the server MUST use that identifier to identify the client. If the client does not provide a 'client identifier' option, the server MUST use the contents of the 'chaddr' field to identify the client." is replaced by the text "The client MUST explicitly provide a client identifier through the 'client identifier' option. The client MUST use the same 'client identifier' option for all messages."
RFC 2131のセクション4.2では、テキストは、「クライアントが明示的に 『クライアント識別子』オプションを通じて識別子を提供することを選択するかもしれません。クライアントは、 『クライアント識別子』を提供する場合、クライアントは後続のすべてに同じ 『クライアント識別子』を使用しなければなりませんメッセージ、およびサーバーがクライアントを識別するために、その識別子を使用しなければならない。クライアントは、「クライアント識別子」オプションを提供していない場合は、サーバーは、クライアントを識別するために「とchaddr」フィールドの内容を使用しなければなりません。」テキストに置き換えられ、「クライアントが明示的に 『クライアント識別子』オプションを介してクライアント識別子を提供しなければならない。クライアントは、すべてのメッセージに対して同じ 『クライアント識別子』オプションを使用しなければなりません。」
In the same section, the text "Use of 'chaddr' as the client's unique identifier may cause unexpected results, as that identifier may be associated with a hardware interface that could be moved to a new client. Some sites may choose to use a manufacturer's serial number as the 'client identifier', to avoid unexpected changes in a client's network address due to transfer of hardware interfaces among computers. Sites may also choose to use a DNS name as the 'client identifier', causing address leases to be associated with the DNS name rather than a specific hardware box." is replaced by the text "The DHCP client MUST NOT rely on the 'chaddr' field to identify it."
その識別子は、新しいクライアントに移動することができ、ハードウェア・インタフェースに関連付けすることができるのと同じセクションでは、クライアントの一意の識別子として 『とchaddr』のテキスト」を使用するには、予期しない結果を引き起こす可能性があります。いくつかのサイトには、メーカーのを使用することもできます「クライアント識別子」などのシリアル番号、原因コンピュータ間のハードウェア・インタフェースの転送にクライアントのネットワークアドレスで予期しない変更を避けるために。サイトには、アドレスのリースが関連付けさせる、「クライアント識別子」としてDNS名を使用することもできますDNS名ではなく、特定のハードウェアボックスをオンにします。」テキストに置き換えられ、「DHCPクライアントは、それを識別するために 『とchaddr』フィールド当てにしてはいけません。」
In section 4.4.1 of RFC 2131, the text "The client MAY include a different unique identifier" is replaced with "The client MUST include a unique identifier".
RFC 2131のセクション4.4.1には、「クライアントが異なるユニークな識別子を含むことができる」テキスト「は、クライアントが一意の識別子を含まなければならない」と置き換えています。
In section 3.1, items 4 and 6; section 3.2 item 3 and 4; and section 4.3.1, where RFC 2131 says that 'chaddr' may be used instead of the 'client identifier' option, the text "or 'chaddr'" and "'chaddr' or" is deleted.
セクション3.1で、項目4,6、セクション3.2項目3及び4;およびセクション4.3.1、RFC 2131は「とchaddr」の代わりに、「クライアント識別子」オプション、テキスト「や 『とchaddr』」を使用することができることを言うと、「『とchaddr』または」が削除されます。
Note that these changes do not relieve the DHCPv4 server of the obligation to use 'chaddr' as an identifier if the client does not send a 'client identifier' option. Rather, they oblige clients that conform with this document to send a 'client identifier' option, and not rely on 'chaddr' for identification. DHCPv4 servers MUST use 'chaddr' as an identifier in cases where 'client identifier' is not sent, in order to support old clients that do not conform with this document.
これらの変更は、クライアントが「クライアント識別子」オプションを送信しない場合には、識別子として「とchaddr」を使用する義務のDHCPv4サーバを緩和していないことに注意してください。むしろ、彼らは、「クライアント識別子」オプションを送信するには、この文書に準拠クライアントを義務付ける、および識別のための「とchaddr」に依存しません。 DHCPv4サーバは、この文書に準拠していない古いクライアントをサポートするために、「クライアント識別子」が送信されない場合の識別子として「とchaddr」を使用しなければなりません。
The text in section 9.14, beginning with "The client identifier MAY consist of" through "that meet this requirement for uniqueness." is replaced with "the client identifier consists of a type field whose value is normally 255, followed by a four-byte IA_ID field, followed by the DUID for the client as defined in RFC 3315, section 9." The text "its minimum length is 2" in the following paragraph is deleted.
始まるセクション9.14でのテキストを通じて「クライアント識別子は、からなるものであってもよい」「一意のため、この要件を満たしています。」 「RFC 3315で定義されるように、クライアント識別子は、クライアントのDUID続く4バイトIA_IDフィールドに続く、値255は通常、タイプフィールドの部9からなる」に置き換えられ次の段落内のテキスト「その最小の長さは2であるが、」削除されます。
In some cases a single device may actually run more than one DHCP client in sequence, in the process of loading an operating system over the network. In such cases, it may be that the first-stage boot uses a different client identifier, or no client identifier, than the subsequent stage or stages.
いくつかのケースでは、単一のデバイスは、実際にネットワークを介して、オペレーティングシステムをロードするプロセスでは、順番に複数のDHCPクライアントを実行することができます。このような場合には、第一段目のブートが後段又は段階以外、異なるクライアント識別子、または全くクライアント識別子を使用することであってもよいです。
The effect of this, under the DHCPv4 protocol, is that the two (in some cases more than two!) boot stages will present different identities. A DHCPv4 server will therefore allocate two different IP addresses to the two different boot stages.
この効果は、DHCPv4のプロトコルの下で、2は（いくつかのケースでは二つ以上！）ブート段階は異なるアイデンティティを提示することです。 DHCPv4サーバは、したがって、二つの異なるブートステージに2つの異なるIPアドレスを割り当てます。
Some DHCP servers work around this problem for the common case where the boot Programmable Read Only Memory (PROM) presents no client identifier, and the operating system DHCP client presents a client identifier constructed from the Message Authentication Code (MAC) address of the network interface -- both are treated as the same identifier. This prevents the consumption of an extra IP address.
一部のDHCPサーバは、ブートプログラム可能な読み出し専用メモリ（PROM）は何のクライアント識別子を提示していない一般的な場合のために、この問題を回避、およびオペレーティングシステムのDHCPクライアントは、ネットワークインタフェースのメッセージ認証コード（MAC）アドレスから構築クライアント識別子を提示します - 両方が同じ識別子として扱われます。これは、余分なIPアドレスの消費を防ぐことができます。
A compliant DHCPv4 client does not use a client identifier constructed from the MAC address of the network interface, because network interfaces are not stable. So a compliant DHCPv4 client cannot be supported by a simple hack like the one described previously; this may have some significant impact at some sites.
ネットワークインタフェースは安定ではないので、対応のDHCPv4クライアントは、ネットワークインタフェースのMACアドレスから構成されたクライアント識別子を使用していません。だから、対応のDHCPv4クライアントは、前述のような単純なハックでサポートすることはできません。これは、いくつかのサイトでいくつかの重要な影響を与える可能性があります。
We cannot state the solution to this problem as a set of requirements, because the circumstances in which this occurs vary too widely. However, we can make some suggestions.
これが発生する状況があまりにも大きく異なるので、我々は、要件のセットとして、この問題に対する解決策を述べることはできません。しかし、我々はいくつかの提案を行うことができます。
First, we suggest that DHCP clients in network boot loaders request short lease times, so that their IP addresses are not retained. Such clients should send a DHCPRELEASE message to the DHCP server before moving on to the next stage of the boot process. Such clients should provide a way for the operating system DHCP client to configure a DUID to use in subsequent boots. DHCP clients in the final stage should, where possible, configure the DUID used by the boot PROM to be the same as the DUID used by the operating system.
まず、我々は彼らのIPアドレスが保持されないように、ネットワークブートローダーでのDHCPクライアントは、短いリース時間を要求することを示唆しています。このようなクライアントは、ブートプロセスの次の段階に移る前にDHCPサーバにDHCPRELEASEメッセージを送信する必要があります。このようなクライアントは、後続のブーツで使用するDUIDを設定するには、オペレーティングシステムのDHCPクライアントのための方法を提供しなければなりません。最終段階でのDHCPクライアントは、可能な場合、オペレーティングシステムで使用されるDUIDと同じになるようにブートPROMによって使用されるDUIDを設定する必要があります。
Second, implementors of DHCPv4 clients that are expected to only be used in a multi-stage network boot configuration, that are not expected ever to network boot using DHCPv6, and that have a MAC address that cannot be easily changed may not need to implement the changes described in this specification. There is some danger in making this assumption--the first solution suggested is definitely better. A compromise might be to have the final-stage DHCP client detect whether it is running on legacy hardware; if it is, it uses the old identifier; if it is not, it follows the scheme described in the previous paragraph.
第二に、唯一のDHCPv6を使用してネットワークブートするために、これまで予想されていない多段ネットワークブート構成で使用し、それを簡単に変更することができないMACアドレスを持つことが期待されるのDHCPv4クライアントの実装は、実装する必要はありません本明細書に記載された変更。この仮定を行うことで、いくつかの危険性があります - 提案最初のソリューションは、間違いなく良いです。妥協は最終段のDHCPクライアントは、それが従来のハードウェア上で実行されているかどうかを検出持っているかもしれません。それがあれば、それは昔の識別子を使用しています。そうでない場合、それは前の段落で説明した手法に従っています。
This document raises no new security issues. Potential exposure to attack in the DHCPv4 protocol is discussed in section 7 of the DHCP protocol specification [RFC2131] and in Authentication for DHCP messages [RFC3118]. Potential exposure to attack in the DHCPv6 protocol is discussed in section 23 of RFC 3315.
この文書は、どんな新しい安全保障問題も提起しません。 DHCPv4のプロトコルで攻撃する可能性曝露は、DHCPメッセージ[RFC3118]のためのDHCPプロトコル仕様[RFC2131]のセクション7および認証に記載されています。 DHCPv6のプロトコルで攻撃する可能性曝露は、RFC 3315のセクション23に記載されています。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131] Droms、R.、 "動的ホスト構成プロトコル"、RFC 2131、1997年3月。
[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月。
[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001.
[RFC3118] Droms、R.とW. Arbaugh、 "DHCPメッセージの認証"、RFC 3118、2001年6月。
Authors' Addresses
著者のアドレス
Ted Lemon Nominum 2385 Bay Road Redwood City, CA 94063 USA
テッド・レモンノミナム2385ベイロードレッドウッドシティー、CA 94063 USA
Phone: +1 650 381 6000 EMail: mellon@nominum.com
電話：+1 650 381 6000 Eメール：mellon@nominum.com
Bill Sommerfeld Sun Microsystems 1 Network Drive Burlington, MA 01824
ビル・ゾンマーフェルトSun Microsystemsの1ネットワークドライブバーリントン、MA 01824
Phone: +1 781 442 3458 EMail: sommerfeld@sun.com
電話：+1 781 442 3458 Eメール：sommerfeld@sun.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。