[要約] RFC 4361は、DHCPv4で使用されるノード固有のクライアント識別子に関する仕様です。このRFCの目的は、ネットワーク上のデバイスを一意に識別するための方法を提供することです。
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)
動的ホスト構成プロトコルバージョン4（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).
Copyright（c）The Internet Society（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.
このドキュメントは、動的ホスト構成プロトコルバージョン4（DHCPV4）クライアント識別子をエンコードするために使用される形式を指定し、それらの識別子がDHCPV6プロトコルで使用される識別子と交換可能になります。このドキュメントでは、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]クライアントが自分自身を識別する方法を指定します。この仕様に準拠するDHCPV4クライアントの実装は、IPv6（DHCPV6）[RFC3315]の動的ホスト構成プロトコルで指定されているDHCP一意の識別子（DUID）を使用します。DUIDは、「DHCPオプションとBOOTPベンダー拡張機能」[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 2131/2132スタイルの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.
このドキュメントでは、最初に解決すべき問題について説明します。次に、問題を解決するために使用される新しい手法を述べます。最後に、これらのドキュメントがこのドキュメントに記載されていることと矛盾しないために、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.
このドキュメントに従って実装されるDHCPV4クライアントとサーバーは、セクション6.3および6.4で指定された変更がRFC 2131およびRFC 2132に行われたかのように実装する必要があります。さらに、DHCPV4クライアントはセクション6.1で指定された動作に従う必要があります。DHCPV6クライアントは、セクション6.2で指定された動作に従う必要があります。DHCPV4サーバーは、セクション6.3で指定された動作にさらに従う必要があります。
4.1. Client identities are ephemeral.
4.1. クライアントのアイデンティティは一時的です。
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は、クライアントが構成しようとしているネットワークインターフェイスの永続的なリンク層アドレスを使用して、クライアントの識別子を生成することを推奨しています。この推奨の結果の1つは、クライアントコンピューターのネットワークインターフェイスハードウェアが置き換えられると、クライアントのIDが変更されることです。クライアントは、IPアドレスと古い識別子に関連付けられたその他のリソース（たとえば、DHCPV4サーバーを介して公開されているドメイン名）を失います。
4.2. Clients can accidentally present multiple identities.
4.2. クライアントは誤って複数のアイデンティティを提示できます。
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クライアントを考えてみましょう。そのうちの1つは有線で、そのうちの1つはワイヤレスです。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アドレスが公開されているものではありません。2つのインターフェイスがある場合、正しいインターフェイスが公開される場合があり、時にはそうでない場合もあります。
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クライアント識別子を指定し、ブートローダーによってロードされたオペレーティングシステムが異なるアイデンティティを指定すると発生します。
4.3. RFC 2131/2132 and RFC 3315 identifiers are incompatible.
4.3. RFC 2131/2132およびRFC 3315識別子は互換性がありません。
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の識別子が異なることが保証されます。つまり、これらの識別子を使用したリソースへのアクセスの調停は、場合によってはDHCPV4を使用してノードを構成し、他の場合はDHCPV6を使用してノードを構成できない場合に正しく機能しないことを意味します。
4.4. RFC 2131 does not require the use of a client identifier.
4.4. RFC 2131は、クライアント識別子の使用を必要としません。
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サーバーがクライアントを識別できるようにします。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つのネットワークインターフェイスを持つクライアントがDHCPV4サーバーにこれらの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クライアントが同時に複数のネットワークIDを表現している場合、それでもDHCPV4サーバーが2つのネットワークIDが同じホストに属していると判断することができなければなりません。
- 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サーバーは、この仕様に準拠していないDHCPV4クライアントと正しく相互操作する必要があります。ただし、このようなクライアントを構成する場合、セクション2で説明されているような動作が発生する可能性があります。
- 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.
- DHCPV6も使用するデュアルスタックホストが使用するDHCPV4クライアント識別子は、DHCPV4とDHCPV6の両方に同じホスト識別文字列を使用する必要があります。たとえば、クライアントのIDを使用してDHCPV4クライアントに代わってDNSを更新するDHCPV4サーバーは、そのホストで実行されているDHCPV6クライアントに代わってDHCPV6サーバーによって登録されるDNSで同じクライアントIDをDNSに登録する必要があります。逆に。
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.
これらの要件の最後を除くすべてを満たすには、2つの部分からDHCPV4クライアント識別子を構築する必要があります。一部の部分は、クライアントが実行されているホストに固有のものでなければなりません。もう1つは、提示されているネットワークIDに固有のものでなければなりません。RFC 3315で指定されたDHCP一意の識別子（DUID）およびID関連識別子（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.
最後の要件を満たすために、DUIDを使用してDHCPV4クライアントを識別する必要があります。したがって、すべての要件をまとめて、RFC 3315で説明されているDuidとIAIDが唯一の可能なソリューションです。
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クライアントとサーバーの動作の変更を指定します。また、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ノード識別子を使用する必要があります。DHCPV4クライアントは、RFC 3315のセクション9.2で許可されている場合を除き、RFC 2131で提案されているように、レイヤー2デバイス（例えば、イーサネットMACアドレス）にハードワイヤードされたレイヤー2アドレスのみに基づいてクライアント識別子を使用してはなりません。RFC 3315のセクション10で定義されているアイデンティティアソシエーションの一意の識別子と、RFC 3315のセクション9で定義されている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スタイルのバインディング識別子を送信するには、「クライアント識別子」オプションのタイプは255に設定されます。タイプフィールドはすぐにIAIDが続きます。。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を構成できる手段も提供する必要があります。通常、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を構成できる手段も提供する必要があります。通常、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の管理者がサプリした値を使用してクライアントを識別できます。これは、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.
9ページのRFC 2131のセクション2では、「クライアント識別子」が「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のテキストは、「クライアントの識別子は、この一意性の要件を満たす「介」で構成される場合があります。」「クライアント識別子は、値が通常255であり、4バイトIA_IDフィールドが続くタイプフィールドで構成され、次にRFC 3315、セクション9で定義されているクライアントのDUIDが続きます。」次の段落のテキスト「最小長は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クライアントを順番に実行することがあります。そのような場合、第1段階のブーツは、後続の段階またはステージよりも異なるクライアント識別子、またはクライアント識別子を使用しない可能性があります。
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つ（場合によっては2つ以上！）のブートステージが異なるIDを提示することです。したがって、DHCPV4サーバーは、2つの異なるブートステージに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.
まず、ネットワークブートローダーのDHCPクライアントが短いリース時間を要求し、IPアドレスが保持されないことをお勧めします。このようなクライアントは、ブートプロセスの次の段階に進む前に、DHCPRELEASEメッセージをDHCPサーバーに送信する必要があります。このようなクライアントは、オペレーティングシステムDHCPクライアントが後続のブーツで使用するDUIDを構成する方法を提供する必要があります。最終段階のDHCPクライアントは、可能であれば、ブートプロムが使用するDUIDをオペレーティングシステムで使用する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.
第二に、マルチステージネットワークブート構成でのみ使用されると予想されるDHCPV4クライアントの実装者、DHCPV6を使用してブートをネットワークすると予想されていない、そして簡単に変更できないMACアドレスを持つ必要がない場合がありますこの仕様で説明されている変更。この仮定を行うことにはいくつかの危険があります。提案された最初の解決策は間違いなく優れています。妥協点は、最終段階の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プロトコル仕様[RFC2131]のセクション7およびDHCPメッセージの認証[RFC3118]で説明します。DHCPV6プロトコルでの攻撃への潜在的な暴露については、RFC 3315のセクション23で説明します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Alexander、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.、Bound、J.、Volz、B.、Lemon、T.、Perkins、C。、およびM. Carney、「IPv6の動的ホスト構成プロトコル」、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ベイロードレッドウッドシティ、カリフォルニア94063 USA
Phone: +1 650 381 6000
EMail: mellon@nominum.com
Bill Sommerfeld Sun Microsystems 1 Network Drive Burlington, MA 01824
ビルゾンマーフェルドサンマイクロシステムズ1ネットワークドライブバーリントン、マサチューセッツ州01824
Phone: +1 781 442 3458
EMail: sommerfeld@sun.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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）によって提供されます。