[要約] RFC 3046は、DHCPリレーエージェント情報オプションに関する仕様を定めたものです。このRFCの目的は、DHCPリレーエントがネットワーク上のクライアントとサーバー間の通信を効率的に中継するための情報を提供することです。
Network Working Group M. Patrick
Request for Comments: 3046 Motorola BCS
Category: Standards Track January 2001
DHCP Relay Agent Information Option
DHCPリレーエージェント情報オプション
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 (2001). All Rights Reserved.
Copyright（c）The Internet Society（2001）。無断転載を禁じます。
Abstract
概要
Newer high-speed public Internet access technologies call for a high-speed modem to have a local area network (LAN) attachment to one or more customer premise hosts. It is advantageous to use the Dynamic Host Configuration Protocol (DHCP) as defined in RFC 2131 to assign customer premise host IP addresses in this environment. However, a number of security and scaling problems arise with such "public" DHCP use. This document describes a new DHCP option to address these issues. This option extends the set of DHCP options as defined in RFC 2132.
新しい高速パブリックインターネットアクセステクノロジーは、高速モデムが1つ以上の顧客の前提ホストにローカルエリアネットワーク（LAN）の添付ファイルを持つことを求めています。RFC 2131で定義されているダイナミックホスト構成プロトコル（DHCP）を使用して、この環境で顧客の前提ホストIPアドレスを割り当てることが有利です。ただし、このような「公開」DHCPの使用により、多くのセキュリティとスケーリングの問題が発生します。このドキュメントでは、これらの問題に対処するための新しいDHCPオプションについて説明します。このオプションは、RFC 2132で定義されているDHCPオプションのセットを拡張します。
The new option is called the Relay Agent Information option and is inserted by the DHCP relay agent when forwarding client-originated DHCP packets to a DHCP server. Servers recognizing the Relay Agent Information option may use the information to implement IP address or other parameter assignment policies. The DHCP Server echoes the option back verbatim to the relay agent in server-to-client replies, and the relay agent strips the option before forwarding the reply to the client.
新しいオプションは、リレーエージェント情報オプションと呼ばれ、クライアントに起因するDHCPパケットをDHCPサーバーに転送する際にDHCPリレーエージェントによって挿入されます。リレーエージェント情報オプションを認識するサーバーは、情報を使用してIPアドレスまたはその他のパラメーター割り当てポリシーを実装する場合があります。DHCPサーバーは、サーバーからクライアントへの応答のリレーエージェントにオプションバックVerbatimをエコーし、リレーエージェントはクライアントに返信を転送する前にオプションをストリップします。
The "Relay Agent Information" option is organized as a single DHCP option that contains one or more "sub-options" that convey information known by the relay agent. The initial sub-options are defined for a relay agent that is co-located in a public circuit access unit. These include a "circuit ID" for the incoming circuit, and a "remote ID" which provides a trusted identifier for the remote high-speed modem.
「リレーエージェント情報」オプションは、リレーエージェントが知っている情報を伝える1つ以上の「サブオプション」を含む単一のDHCPオプションとして編成されています。初期サブオプションは、パブリックサーキットアクセスユニットに共同住宅されているリレーエージェントに対して定義されます。これらには、着信回路の「回路ID」と、リモート高速モデムの信頼できる識別子を提供する「リモートID」が含まれます。
Table of Contents
目次
1 Introduction........................................... 2
1.1 High-Speed Circuit Switched Data Networks.............. 2
1.2 DHCP Relay Agent in the Circuit Access Equipment....... 4
2.0 Relay Agent Information Option......................... 5
2.1 Agent Operation........................................ 6
2.1.1 Reforwarded DHCP requests............................ 7
2.2 Server Operation....................................... 7
3.0 Relay Agent Information Suboptions..................... 8
3.1 Agent Circuit ID....................................... 8
3.2 Agent Remote ID........................................ 9
4.0 Issues Resolved........................................ 9
5.0 Security Considerations................................ 10
6.0 IANA Considerations.................................... 11
7.0 Intellectual Property Notice........................... 12
8.0 References............................................. 12
9.0 Glossary............................................... 13
10.0 Author's Address...................................... 13
11.0 Full Copyright Statement ............................. 14
1 Introduction
1はじめに
Public Access to the Internet is usually via a circuit switched data network. Today, this is primarily implemented with dial-up modems connecting to a Remote Access Server. But higher speed circuit access networks also include ISDN, ATM, Frame Relay, and Cable Data Networks. All of these networks can be characterized as a "star" topology where multiple users connect to a "circuit access unit" via switched or permanent circuits.
インターネットへのパブリックアクセスは、通常、回路スイッチ付きデータネットワークを介して行われます。今日、これは主にリモートアクセスサーバーに接続するダイヤルアップモデムで実装されています。しかし、高速回路アクセスネットワークには、ISDN、ATM、フレームリレー、ケーブルデータネットワークも含まれます。これらのネットワークはすべて、「スター」トポロジとして特徴付けられ、複数のユーザーが切り替えまたは永久回路を介して「回路アクセスユニット」に接続します。
With dial-up modems, only a single host PC attempts to connect to the central point. The PPP protocol is widely used to assign IP addresses to be used by the single host PC.
ダイヤルアップモデムを使用すると、単一のホストPCのみが中央ポイントに接続しようとします。PPPプロトコルは、単一のホストPCが使用するIPアドレスを割り当てるために広く使用されています。
The newer high-speed circuit technologies, however, frequently provide a LAN interface (especially Ethernet) to one or more host PCs. It is desirable to support centralized assignment of the IP addresses of host computers connecting on such circuits via DHCP. The DHCP server can be, but usually is not, co-implemented with the centralized circuit concentration access device. The DHCP server is often connected as a separate server on the "Central LAN" to which the central access device (or devices) attach.
ただし、新しい高速回路技術は、1つ以上のホストPCにLANインターフェイス（特にイーサネット）を頻繁に提供します。DHCPを介してそのような回路で接続するホストコンピューターのIPアドレスの集中課題をサポートすることが望ましいです。DHCPサーバーは、一元化された回路濃度アクセスデバイスと共同で実装されている可能性がありますが、通常はそうではありません。DHCPサーバーは、多くの場合、中央アクセスデバイス（またはデバイス）が接続されている「中央LAN」上の個別のサーバーとして接続されています。
A common physical model for high-speed Internet circuit access is shown in Figure 1, below.
高速インターネット回路アクセスの一般的な物理モデルを以下の図1に示します。
+---------------+ |
Central | Circuit |-- ckt 1--- Modem1-- Host-|- Host A
LAN | | Access | Lan |- Host B
| | Unit 1 | |- Host C
|-----| |-- |
| |(relay agent) |...
+---------+ | +---------------+
| DHCP |--|
| Server | |
+---------+ |
|
| +---------------+
+---------+ | | Circuit |-- ckt 1--- Modem2-- Host--- Host D
| Other | | | Access | Lan
| Servers |--|-----| Unit 2 |
| (Web, | | | |-- ckt 2--- Modem3-- Host--- Host E
| DNS) | | |(relay agent) |... Lan
| | +---------------+
+---------+
Figure 1: DHCP High Speed Circuit Access Model
図1：DHCP高速回路アクセスモデル
Note that in this model, the "modem" connects to a LAN at the user site, rather than to a single host. Multiple hosts are implemented at this site. Although it is certainly possible to implement a full IP router at the user site, this requires a relatively expensive piece of equipment (compared to typical modem costs). Furthermore, a router requires an IP address not only for every host, but for the router itself. Finally, a user-side router requires a dedicated Logical IP Subnet (LIS) for each user. While this model is appropriate for relatively small corporate networking environments, it is not appropriate for large, public accessed networks. In this scenario, it is advantageous to implement an IP networking model that does not allocate an IP address for the modem (or other networking equipment device at the user site), and especially not an entire LIS for the user side LAN.
このモデルでは、「モデム」は単一のホストではなく、ユーザーサイトのLANに接続することに注意してください。このサイトで複数のホストが実装されています。ユーザーサイトに完全なIPルーターを実装することは確かに可能ですが、これには比較的高価な機器が必要です（一般的なモデムコストと比較して）。さらに、ルーターには、すべてのホストだけでなく、ルーター自体にIPアドレスが必要です。最後に、ユーザー側のルーターには、各ユーザーに専用の論理IPサブネット（LIS）が必要です。このモデルは、比較的小さな企業ネットワーキング環境に適していますが、大規模なパブリックアクセスネットワークには適していません。このシナリオでは、モデム（またはユーザーサイトの他のネットワーキング機器デバイス）にIPアドレスを割り当てないIPネットワークモデルを実装することが有利です。特に、ユーザーサイドLANのLI全体ではありません。
Note that using this method to obtain IP addresses means that IP addresses can only be obtained while communication to the central site is available. Some host lan installations may use a local DHCP server or other methods to obtain IP addresses for in-house use.
この方法を使用してIPアドレスを取得することは、中央サイトへの通信が利用可能である間にのみIPアドレスを取得できることを意味することに注意してください。一部のホストLANインストールでは、ローカルDHCPサーバーまたはその他のメソッドを使用して、社内で使用するIPアドレスを取得できます。
It is desirable to use DHCP to assign the IP addresses for public high-speed circuit access. A number of circuit access units (e.g., RAS's, cable modem termination systems, ADSL access units, etc) connect to a LAN (or local internet) to which is attached a DHCP server.
DHCPを使用して、公共の高速回路アクセスにIPアドレスを割り当てることが望ましいです。多くの回路アクセスユニット（RAS、ケーブルモデム終了システム、ADSLアクセスユニットなど）がDHCPサーバーに接続されているLAN（またはローカルインターネット）に接続します。
For scaling and security reasons, it is advantageous to implement a "router hop" at the circuit access unit, much like high-capacity RAS's do today. The circuit access equipment acts as both a router to the circuits and as the DHCP relay agent.
スケーリングとセキュリティの理由については、今日の大容量RASのように、回路アクセスユニットに「ルーターホップ」を実装することが有利です。回路アクセス機器は、回路のルーターとDHCPリレーエージェントの両方として機能します。
The advantages of co-locating the DHCP relay agent with the circuit access equipment are:
DHCPリレーエージェントを回路アクセス機器と共同配置する利点は次のとおりです。
DHCP broadcast replies can be routed to only the proper circuit, avoiding, say, the replication of the DCHP reply broadcast onto thousands of access circuits;
DHCPブロードキャスト応答は、適切な回路のみにルーティングでき、たとえば、DCHP返信の複製を数千のアクセス回路に放送することを回避できます。
The same mechanism used to identify the remote connection of the circuit (e.g., a user ID requested by a Remote Access Server acting as the circuit access equipment) may be used as a host identifier by DHCP, and used for parameter assignment. This includes centralized assignment of IP addresses to hosts. This provides a secure remote ID from a trusted source -- the relay agent.
回路のリモート接続を識別するために使用される同じメカニズム（たとえば、回路アクセス機器として作用するリモートアクセスサーバーによって要求されたユーザーID）は、DHCPによってホスト識別子として使用され、パラメーター割り当てに使用できます。これには、ホストへのIPアドレスの集中割り当てが含まれます。これにより、信頼できるソース（リレーエージェント）から安全なリモートIDが提供されます。
A number of issues arise when forwarding DHCP requests from hosts connecting publicly accessed high-speed circuits with LAN connections at the host. Many of these are security issues arising from DHCP client requests from untrusted sources. How does the relay agent know to which circuit to forward replies? How does the system prevent DHCP IP exhaustion attacks? This is when an attacker requests all available IP addresses from a DHCP server by sending requests with fabricated client MAC addresses. How can an IP address or LIS be permanently assigned to a particular user or modem? How does one prevent "spoofing" of client identifier fields used to assign IP addresses? How does one prevent denial of service by "spoofing" other client's MAC addresses?
ホストのLAN接続を備えた公開されている高速回路を接続するホストからのDHCP要求を転送すると、多くの問題が発生します。これらの多くは、信頼できないソースからのDHCPクライアント要求から生じるセキュリティの問題です。リレーエージェントは、どの回路を転送するかをどのようにして返信するかをどのように把握していますか？システムはどのようにしてDHCP IP枯渇攻撃を防ぎますか？これは、攻撃者が、製造されたクライアントMACアドレスでリクエストを送信することにより、DHCPサーバーから利用可能なすべてのIPアドレスを要求する場合です。IPアドレスまたはLIを特定のユーザーまたはモデムに永続的に割り当てるにはどうすればよいですか？IPアドレスの割り当てに使用されるクライアント識別子フィールドの「スプーフィング」をどのように防ぐのですか？他のクライアントのMACアドレスを「スプーフィング」することにより、どのようにしてサービスの拒否を防ぐのですか？
All of these issues may be addressed by having the circuit access equipment, which is a trusted component, add information to DHCP client requests that it forwards to the DHCP server.
これらの問題はすべて、信頼できるコンポーネントであるサーキットアクセス機器を置くことで対処される場合があります。DHCPクライアントリクエストに情報を追加して、DHCPサーバーに転送します。
This document defines a new DHCP Option called the Relay Agent Information Option. It is a "container" option for specific agent-supplied sub-options. The format of the Relay Agent Information option is:
このドキュメントでは、リレーエージェント情報オプションと呼ばれる新しいDHCPオプションを定義します。これは、特定のエージェントがサプライされたサブオプションの「コンテナ」オプションです。リレーエージェント情報オプションの形式は次のとおりです。
Code Len Agent Information Field
+------+------+------+------+------+------+--...-+------+
| 82 | N | i1 | i2 | i3 | i4 | | iN |
+------+------+------+------+------+------+--...-+------+
The length N gives the total number of octets in the Agent Information Field. The Agent Information field consists of a sequence of SubOpt/Length/Value tuples for each sub-option, encoded in the following manner:
長さnは、エージェント情報フィールドにオクテットの総数を与えます。エージェント情報フィールドは、次の方法でエンコードされた各サブオプションのサブオプト/長さ/値タプルのシーケンスで構成されています。
SubOpt Len Sub-option Value
+------+------+------+------+------+------+--...-+------+
| 1 | N | s1 | s2 | s3 | s4 | | sN |
+------+------+------+------+------+------+--...-+------+
SubOpt Len Sub-option Value
+------+------+------+------+------+------+--...-+------+
| 2 | N | i1 | i2 | i3 | i4 | | iN |
+------+------+------+------+------+------+--...-+------+
No "pad" sub-option is defined, and the Information field shall NOT be terminated with a 255 sub-option. The length N of the DHCP Agent Information Option shall include all bytes of the sub-option code/length/value tuples. Since at least one sub-option must be defined, the minimum Relay Agent Information length is two (2). The length N of the sub-options shall be the number of octets in only that sub-option's value field. A sub-option length may be zero. The sub-options need not appear in sub-option code order.
「パッド」サブオプションは定義されておらず、情報フィールドは255サブオプションで終了してはなりません。DHCPエージェント情報オプションの長さNには、サブオプションコード/長さ/値タプルのすべてのバイトを含めるものとします。少なくとも1つのサブオプションを定義する必要があるため、最小リレーエージェント情報の長さは2つです。サブオプションの長さnは、そのサブオプションの値フィールドのみのオクテットの数でなければなりません。サブオプションの長さはゼロになる場合があります。サブオプションは、サブオプションコードの順序に表示される必要はありません。
The initial assignment of DHCP Relay Agent Sub-options is as follows:
DHCPリレーエージェントサブオプションの最初の割り当ては次のとおりです。
DHCP Agent Sub-Option Description
Sub-option Code
--------------- ----------------------
1 Agent Circuit ID Sub-option
2 Agent Remote ID Sub-option
Overall adding of the DHCP relay agent option SHOULD be configurable, and SHOULD be disabled by default. Relay agents SHOULD have separate configurables for each sub-option to control whether it is added to client-to-server packets.
DHCPリレーエージェントオプションの全体的な追加は構成可能であり、デフォルトで無効にする必要があります。リレーエージェントは、クライアントからサーバーへのパケットに追加されるかどうかを制御するために、各サブオプションに個別の構成可能性を持つ必要があります。
A DHCP relay agent adding a Relay Agent Information field SHALL add it as the last option (but before 'End Option' 255, if present) in the DHCP options field of any recognized BOOTP or DHCP packet forwarded from a client to a server.
リレーエージェント情報フィールドを追加するDHCPリレーエージェントは、クライアントからサーバーに転送された認識されたBOOTPまたはDHCPパケットのDHCPオプションフィールドに、最後のオプションとして（ただし、「終了オプション」255の前）に追加するものとします。
Relay agents receiving a DHCP packet from an untrusted circuit with giaddr set to zero (indicating that they are the first-hop router) but with a Relay Agent Information option already present in the packet SHALL discard the packet and increment an error count. A trusted circuit may contain a trusted downstream (closer to client) network element (bridge) between the relay agent and the client that MAY add a relay agent option but not set the giaddr field. In this case, the relay agent does NOT add a "second" relay agent option, but forwards the DHCP packet per normal DHCP relay agent operations, setting the giaddr field as it deems appropriate.
GIADDRがゼロに設定された信頼性のない回路からDHCPパケットを受信するリレーエージェント（それらが最初のホップルーターであることを示しています）が、パケットに既に存在するリレーエージェント情報オプションを使用すると、パケットを破棄し、エラーカウントを増やすものとします。信頼できる回路には、リレーエージェントとクライアントの間の信頼できる下流（クライアントに近い）ネットワーク要素（ブリッジ）が含まれているため、リレーエージェントオプションを追加しますが、GIADDRフィールドを設定できません。この場合、リレーエージェントは「2番目の」リレーエージェントオプションを追加するのではなく、通常のDHCPリレーエージェント操作ごとにDHCPパケットを転送し、GIADDRフィールドを適切と思われる場合に設定します。
The mechanisms for distinguishing between "trusted" and "untrusted" circuits are specific to the type of circuit termination equipment, and may involve local administration. For example, a Cable Modem Termination System may consider upstream packets from most cable modems as "untrusted", but an ATM switch terminating VCs switched through a DSLAM may consider such VCs as "trusted" and accept a relay agent option added by the DSLAM.
「信頼された」と「信頼できない」回路を区別するためのメカニズムは、回路終了機器のタイプに固有のものであり、現地の投与を伴う場合があります。たとえば、ケーブルモデム終了システムは、ほとんどのケーブルモデムからの上流パケットを「信頼できない」と見なす場合がありますが、DSLAMを介して切り替えられたATMスイッチは、「信頼できる」と見なされ、DSLAMによって追加されたリレーエージェントオプションを受け入れる場合があります。
Relay agents MAY have a configurable for the maximum size of the DHCP packet to be created after appending the Agent Information option. Packets which, after appending the Relay Agent Information option, would exceed this configured maximum size shall be forwarded WITHOUT adding the Agent Information option. An error counter SHOULD be incremented in this case. In the absence of this configurable, the agent SHALL NOT increase a forwarded DHCP packet size to exceed the MTU of the interface on which it is forwarded.
リレーエージェントは、エージェント情報オプションを追加した後、DHCPパケットの最大サイズが作成されるように構成可能なものを持っている場合があります。リレーエージェント情報オプションを追加した後、この構成された最大サイズを超えるパケットは、エージェント情報オプションを追加せずに転送するものとします。この場合、エラーカウンターをインクリメントする必要があります。この構成可能な場合、エージェントは、転送されるインターフェイスのMTUを超えるように転送されたDHCPパケットサイズを増やしてはなりません。
The Relay Agent Information option echoed by a server MUST be removed by either the relay agent or the trusted downstream network element which added it when forwarding a server-to-client response back to the client.
サーバーによってエコーされたリレーエージェント情報オプションは、リレーエージェントまたは信頼できるダウンストリームネットワーク要素のいずれかによって削除される必要があります。
The agent SHALL NOT add an "Option Overload" option to the packet or use the "file" or "sname" fields for adding Relay Agent Information option. It SHALL NOT parse or remove Relay Agent Information options that may appear in the sname or file fields of a server-to-client packet forwarded through the agent.
エージェントは、リレーエージェント情報オプションを追加するために、パケットに「オプションオーバーロード」オプションを追加したり、「ファイル」または「スナム」フィールドを使用したりしてはなりません。エージェントを介して転送されたサーバーからクライアントへのパケットのフィールドに表示される可能性のあるリレーエージェント情報オプションを解析または削除してはなりません。
The operation of relay agents for specific sub-options is specified with that sub-option.
特定のサブオプションのリレー剤の動作は、そのサブオプションで指定されています。
Relay agents are NOT required to monitor or modify client-originated DHCP packets addressed to a server unicast address. This includes the DHCP-REQUEST sent when entering the RENEWING state.
リレーエージェントは、サーバーユニキャストアドレスにアドレス指定されたクライアントに起因するDHCPパケットを監視または変更する必要はありません。これには、更新状態に入るときに送信されるDHCP-Requestが含まれます。
Relay agents MUST NOT modify DHCP packets that use the IPSEC Authentication Header or IPSEC Encapsulating Security Payload [6].
リレーエージェントは、IPSEC認証ヘッダーまたはIPSECを使用してセキュリティペイロードをカプセル化するDHCPパケットを変更してはなりません[6]。
A DHCP relay agent may receive a client DHCP packet forwarded from a BOOTP/DHCP relay agent closer to the client. Such a packet will have giaddr as non-zero, and may or may not already have a DHCP Relay Agent option in it.
DHCPリレーエージェントは、クライアントに近いBOOTP/DHCPリレーエージェントから転送されたクライアントDHCPパケットを受け取る場合があります。このようなパケットには、ゼロ以外のGIADDRがあり、DHCPリレーエージェントオプションがまだ含まれている場合と存在しない場合があります。
Relay agents configured to add a Relay Agent option which receive a client DHCP packet with a nonzero giaddr SHALL discard the packet if the giaddr spoofs a giaddr address implemented by the local agent itself.
非ゼロGIADDRを使用してクライアントDHCPパケットを受信するリレーエージェントオプションを追加するように構成されたリレーエージェントは、GIADDRがローカルエージェント自体によって実装されたGIADDRアドレスをスプーフィングする場合、パケットを破棄するものとします。
Otherwise, the relay agent SHALL forward any received DHCP packet with a valid non-zero giaddr WITHOUT adding any relay agent options. Per RFC 2131, it shall also NOT modify the giaddr value.
それ以外の場合、リレーエージェントは、受信したDHCPパケットを、リレーエージェントオプションを追加せずに有効な非ゼロGIADDRで転送するものとします。RFC 2131ごとに、GIADDR値も変更してはなりません。
DHCP servers unaware of the Relay Agent Information option will ignore the option upon receive and will not echo it back on responses. This is the specified server behavior for unknown options.
リレーエージェント情報オプションを認識していないDHCPサーバーは、受信時にオプションを無視し、応答に反映しません。これは、不明なオプションの指定されたサーバー動作です。
DHCP servers claiming to support the Relay Agent Information option SHALL echo the entire contents of the Relay Agent Information option in all replies. Servers SHOULD copy the Relay Agent Information option as the last DHCP option in the response. Servers SHALL NOT place the echoed Relay Agent Information option in the overloaded sname or file fields. If a server is unable to copy a full Relay Agent Information field into a response, it SHALL send the response without the Relay Information Field, and SHOULD increment an error counter for the situation.
リレーエージェント情報オプションをサポートすると主張するDHCPサーバーは、すべての返信のリレーエージェント情報オプションの内容全体をエコーするものとします。サーバーは、応答の最後のDHCPオプションとしてリレーエージェント情報オプションをコピーする必要があります。サーバーは、過負荷のスナムまたはファイルフィールドにエコーされたリレーエージェント情報オプションを配置してはなりません。サーバーが完全なリレーエージェント情報フィールドを応答にコピーできない場合、リレー情報フィールドなしで応答を送信し、状況のエラーカウンターを増やす必要があります。
The operation of DHCP servers for specific sub-options is specified with that sub-option.
特定のサブオプションのDHCPサーバーの動作は、そのサブオプションで指定されています。
Note that DHCP relay agents are not required to monitor unicast DHCP messages sent directly between the client and server (i.e., those that aren't sent via a relay agent). However, some relay agents MAY chose to do such monitoring and add relay agent options. Consequently, servers SHOULD be prepared to handle relay agent options in unicast messages, but MUST NOT expect them to always be there.
DHCPリレーエージェントは、クライアントとサーバーの間で直接送信されたユニキャストDHCPメッセージ（つまり、リレーエージェントを介して送信されないもの）を監視する必要はないことに注意してください。ただし、一部のリレーエージェントは、そのような監視を行い、リレーエージェントオプションを追加することを選択する場合があります。したがって、サーバーは、ユニキャストメッセージのリレーエージェントオプションを処理するために準備する必要がありますが、常にそこにいることを期待してはなりません。
This sub-option MAY be added by DHCP relay agents which terminate switched or permanent circuits. It encodes an agent-local identifier of the circuit from which a DHCP client-to-server packet was received. It is intended for use by agents in relaying DHCP responses back to the proper circuit. Possible uses of this field include:
このサブオプションは、切り替えまたは永久回路を終了するDHCPリレー剤によって追加される場合があります。DHCPクライアントからサーバーへのパケットが受信された回路のエージェントローカル識別子をコードします。これは、適切な回路に戻ってDHCP応答を中継する際にエージェントが使用することを目的としています。このフィールドの可能な用途は次のとおりです。
- Router interface number - Switching Hub port number - Remote Access Server port number - Frame Relay DLCI - ATM virtual circuit number - Cable Data virtual circuit number
- ルーターインターフェイス番号 - スイッチングハブポート番号 - リモートアクセスサーバーポート番号 - フレームリレーDLCI -ATM仮想回路番号 - ケーブルデータ仮想回路番号
Servers MAY use the Circuit ID for IP and other parameter assignment policies. The Circuit ID SHOULD be considered an opaque value, with policies based on exact string match only; that is, the Circuit ID SHOULD NOT be internally parsed by the server.
サーバーは、IPおよびその他のパラメーター割り当てポリシーに回路IDを使用できます。回路IDは、正確な文字列の一致のみに基づいたポリシーを備えた不透明な値と見なされる必要があります。つまり、回路IDはサーバーによって内部的に解析されるべきではありません。
The DHCP server SHOULD report the Agent Circuit ID value of current leases in statistical reports (including its MIB) and in logs. Since the Circuit ID is local only to a particular relay agent, a circuit ID should be qualified with the giaddr value that identifies the relay agent.
DHCPサーバーは、統計レポート（MIBを含む）およびログ内の現在のリースのエージェント回路ID値を報告する必要があります。回路IDは特定のリレーエージェントにのみローカルであるため、回路IDはリレーエージェントを識別するGIADDR値を認定する必要があります。
SubOpt Len Circuit ID
+------+------+------+------+------+------+------+------+--
| 1 | n | c1 | c2 | c3 | c4 | c5 | c6 | ...
+------+------+------+------+------+------+------+------+--
This sub-option MAY be added by DHCP relay agents which terminate switched or permanent circuits and have mechanisms to identify the remote host end of the circuit. The Remote ID field may be used to encode, for instance:
このサブオプションは、スイッチまたは永久回路を終了し、回路のリモートホスト端を識別するメカニズムを備えたDHCPリレー剤によって追加される場合があります。たとえば、リモートIDフィールドをエンコードするために使用できます。
-- a "caller ID" telephone number for dial-up connection
-- a "user name" prompted for by a Remote Access Server
-- a remote caller ATM address
-- a "modem ID" of a cable data modem
-- the remote IP address of a point-to-point link
-- a remote X.25 address for X.25 connections
The remote ID MUST be globally unique.
リモートIDはグローバルに一意でなければなりません。
DHCP servers MAY use this option to select parameters specific to particular users, hosts, or subscriber modems. The option SHOULD be considered an opaque value, with policies based on exact string match only; that is, the option SHOULD NOT be internally parsed by the server.
DHCPサーバーは、このオプションを使用して、特定のユーザー、ホスト、またはサブスクライバーモデムに固有のパラメーターを選択できます。オプションは、正確な文字列の一致のみに基づいたポリシーを使用して、不透明な値と見なす必要があります。つまり、オプションはサーバーによって内部的に解析されるべきではありません。
The relay agent MAY use this field in addition to or instead of the Agent Circuit ID field to select the circuit on which to forward the DHCP reply (e.g., Offer, Ack, or Nak). DHCP servers SHOULD report this value in any reports or MIBs associated with a particular client.
リレーエージェントは、エージェント回路IDフィールドに加えて、またはその代わりにこのフィールドを使用して、DHCP応答（オファー、ACK、またはNAKなど）を転送する回路を選択できます。DHCPサーバーは、特定のクライアントに関連付けられたレポートまたはMIBSにこの値を報告する必要があります。
SubOpt Len Agent Remote ID
+------+------+------+------+------+------+------+------+--
| 2 | n | r1 | r2 | r3 | r4 | r5 | r6 | ...
+------+------+------+------+------+------+------+------+--
The DHCP relay agent option resolves several issues in an environment in which untrusted hosts access the internet via a circuit based public network. This resolution assumes that all DHCP protocol traffic by the public hosts traverse the DHCP relay agent and that the IP network between the DHCP relay agent and the DHCP server is uncompromised.
DHCPリレーエージェントオプションは、トラストされていないホストが回路ベースのパブリックネットワークを介してインターネットにアクセスする環境でいくつかの問題を解決します。この解像度は、パブリックホストによるすべてのDHCPプロトコルトラフィックがDHCPリレーエージェントを横断すること、およびDHCPリレーエージェントとDHCPサーバーの間のIPネットワークが妥協しないと想定しています。
Broadcast Forwarding
ブロードキャスト転送
The circuit access equipment forwards the normally broadcasted DHCP response only on the circuit indicated in the Agent Circuit ID.
回路アクセス機器は、エージェント回路IDに示されている回路でのみ、通常ブロードキャストされたDHCP応答を転送します。
DHCP Address Exhaustion
DHCPアドレス疲労
In general, the DHCP server may be extended to maintain a database with the "triplet" of
一般に、DHCPサーバーは、の「トリプレット」を持つデータベースを維持するために拡張される場合があります
(client IP address, client MAC address, client remote ID)
（クライアントIPアドレス、クライアントMACアドレス、クライアントリモートID）
The DHCP server SHOULD implement policies that restrict the number of IP addresses to be assigned to a single remote ID.
DHCPサーバーは、単一のリモートIDに割り当てるIPアドレスの数を制限するポリシーを実装する必要があります。
Static Assignment
静的割り当て
The DHCP server may use the remote ID to select the IP address to be assigned. It may permit static assignment of IP addresses to particular remote IDs, and disallow an address request from an unauthorized remote ID.
DHCPサーバーは、リモートIDを使用して、割り当てられるIPアドレスを選択できます。特定のリモートIDへのIPアドレスの静的な割り当てを許可し、許可されていないリモートIDからのアドレスリクエストを禁止する場合があります。
IP Spoofing
IPスプーフィング
The circuit access device may associate the IP address assigned by a DHCP server in a forwarded DHCP Ack packet with the circuit to which it was forwarded. The circuit access device MAY prevent forwarding of IP packets with source IP addresses -other than-those it has associated with the receiving circuit. This prevents simple IP spoofing attacks on the Central LAN, and IP spoofing of other hosts.
回路アクセスデバイスは、転送されたDHCP ACKパケットでDHCPサーバーによって割り当てられたIPアドレスを、転送された回路に関連付けることができます。回路アクセスデバイスは、ソースIPアドレスを使用したIPパケットの転送を防ぐ場合があります。これにより、中央LANに対する単純なIPスプーフィング攻撃、および他のホストのIPスプーフィングが防止されます。
Client Identifier Spoofing
クライアント識別子スプーフィング
By using the agent-supplied Agent Remote ID option, the untrusted and as-yet unstandardized client identifier field need not be used by the DHCP server.
エージェントサプライエージェントリモートIDオプションを使用することにより、DHCPサーバーでは、信頼できない標準化されていないクライアント識別子フィールドを使用する必要はありません。
MAC Address Spoofing
Macアドレススプーフィング
By associating a MAC address with an Agent Remote ID, the DHCP server can prevent offering an IP address to an attacker spoofing the same MAC address on a different remote ID.
MACアドレスをエージェントリモートIDに関連付けることにより、DHCPサーバーは、別のリモートIDで同じMacアドレスをスプーフィングする攻撃者にIPアドレスを提供することを防ぐことができます。
DHCP as currently defined provides no authentication or security mechanisms. Potential exposures to attack are discussed in section 7 of the DHCP protocol specification in RFC 2131 [1].
現在定義されているDHCPは、認証またはセキュリティメカニズムを提供しません。攻撃への潜在的な暴露については、RFC 2131 [1]のDHCPプロトコル仕様のセクション7で説明します。
This document introduces mechanisms to address several security attacks on the operation of IP address assignment, including IP spoofing, Client ID spoofing, MAC address spoofing, and DHCP server address exhaustion. It relies on an implied trusted relationship between the DHCP Relay Agent and the DHCP server, with an assumed untrusted DHCP client. It introduces a new identifer, the "Remote ID", that is also assumed to be trusted. The Remote ID is provided by the access network or modem and not by client premise equipment. Cryptographic or other techniques to authenticate the remote ID are certainly possible and encouraged, but are beyond the scope of this document.
このドキュメントでは、IPスプーフィング、クライアントIDスプーフィング、MACアドレススプーフィング、DHCPサーバーアドレスアドレスの使い果たしなど、IPアドレスの割り当ての操作に関するいくつかのセキュリティ攻撃に対処するメカニズムを紹介します。これは、DHCPリレーエージェントとDHCPサーバーとの間の暗黙の信頼関係に依存しており、想定されていないDHCPクライアントが想定されています。これは、「リモートID」という新しい識別器を導入します。これも信頼されていると想定されています。リモートIDは、クライアントの前提装備ではなく、アクセスネットワークまたはモデムによって提供されます。リモートIDを認証するための暗号化またはその他の手法は確かに可能であり、奨励されていますが、このドキュメントの範囲を超えています。
This option is targeted towards environments in which the network infrastructure -- the relay agent, the DHCP server, and the entire network in which those two devices reside -- is trusted and secure. As used in this document, the word "trusted" implies that unauthorized DHCP traffic cannot enter the trusted network except through secured and trusted relay agents and that all devices internal to the network are secure and trusted. Potential deployers of this option should give careful consideration to the potential security vulnerabilities that are present in this model before deploying this option in actual networks.
このオプションは、ネットワークインフラストラクチャ（リレーエージェント、DHCPサーバー、およびこれらの2つのデバイスが存在するネットワーク全体が信頼され、安全である環境に向けてターゲットにされています。このドキュメントで使用されているように、「信頼された」という言葉は、無許可のDHCPトラフィックがセキュリティで信頼できるリレーエージェントを除いて信頼できるネットワークに入ることができず、ネットワーク内部のすべてのデバイスが安全で信頼できることを意味します。このオプションの潜在的な展開者は、このオプションを実際のネットワークに展開する前に、このモデルに存在する潜在的なセキュリティの脆弱性を慎重に検討する必要があります。
Note that any future mechanisms for authenticating DHCP client to server communications must take care to omit the DHCP Relay Agent option from server authentication calculations. This was the principal reason for organizing the DHCP Relay Agent Option as a single option with sub-options, and for requiring the relay agent to remove the option before forwarding to the client.
DHCPクライアントをサーバー通信に認証するための将来のメカニズムは、サーバー認証計算からDHCPリレーエージェントオプションを省略するように注意する必要があることに注意してください。これは、DHCPリレーエージェントオプションをサブオプションを備えた単一のオプションとして整理し、クライアントに転送する前にリレーエージェントにオプションを削除するよう要求する主な理由でした。
While it is beyond the scope of this document to specify the general forwarding algorithm of public data circuit access units, note that automatic reforwarding of IP or ARP broadcast packets back downstream exposes serious IP security risks. For example, if an upstream broadcast DHCP-DISCOVER or DHCP-REQUEST were re-broadcast back downstream, any public host may easily spoof the desired DHCP server.
パブリックデータ回路アクセスユニットの一般的な転送アルゴリズムを指定するのはこのドキュメントの範囲を超えていますが、IPまたはARPブロードキャストパケットの自動再配置が下流に戻ると、深刻なIPセキュリティリスクが公開されることに注意してください。たとえば、上流のブロードキャストDHCP-DiscoverまたはDHCP-Requestがダウンストリームに戻って再ブロードキャストされた場合、パブリックホストは望ましいDHCPサーバーを簡単に押し上げる可能性があります。
IANA is required to maintain a new number space of "DHCP Relay Agent Sub-options", located in the BOOTP-DHCP Parameters Registry. The initial sub-options are described in section 2.0 of this document.
IANAは、BOOTP-DHCPパラメーターレジストリにある「DHCPリレーエージェントサブオプション」の新しい数字スペースを維持する必要があります。最初のサブオプションは、このドキュメントのセクション2.0で説明されています。
IANA assigns future DHCP Relay Agent Sub-options with a "IETF Consensus" policy as described in RFC 2434 [3]. Future proposed sub-options are to be referenced symbolically in the Internet-Drafts that describe them, and shall be assigned numeric codes by IANA when approved for publication as an RFC.
IANAは、RFC 2434 [3]に記載されているように、将来のDHCPリレーエージェントサブオプションを「IETFコンセンサス」ポリシーで割り当てます。将来の提案されたサブオプションは、それらを説明するインターネットドラフトで象徴的に参照され、RFCとして公開された場合、IANAによって数値コードを割り当てられます。
This section contains two notices as required by [5] for standards track documents.
このセクションには、[5]で要求されている2つの通知が含まれています。
The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat.
IETFは、知的財産またはその他の権利の有効性または範囲に関して、この文書に記載されているテクノロジーの実装または使用に関連すると主張される可能性のある他の権利、またはそのような権利に基づくライセンスがどの程度であるかについての程度に関連する可能性があるという立場はありません。利用可能;また、そのような権利を特定するために努力したことも表明していません。標準トラックおよび標準関連のドキュメントの権利に関するIETFの手順に関する情報は、BCP-11に記載されています。出版のために利用可能にされた権利の請求のコピーと、利用可能になるライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を得ることができますIETF事務局から。
The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights.
IETFは、このドキュメントに含まれる仕様の一部またはすべてに関して請求された知的財産権について通知されています。詳細については、請求権のオンラインリストを参照してください。
[1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[1] DROMS、R。、「動的ホスト構成プロトコル」、RFC 2131、1997年3月。
[2] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extension", RFC 2132, March 1997.
[2] Alexander、S。and R. Droms、「DHCPオプションとBOOTPベンダー拡張機能」、RFC 2132、1997年3月。
[3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[3] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、1998年10月。
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[4] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[5] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[5] Bradner、S。、「インターネット標準プロセス - リビジョン3」、BCP 9、RFC 2026、1996年10月。
[6] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[6] Kent、S。およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。
DSLAM Digital Subscriber Link Access Multiplexer IANA Internet Assigned Numbers Authority LIS Logical IP Subnet MAC Message Authentication Code RAS Remote Access Server
DSLAMデジタルサブスクライバーリンクアクセスマルチプレクサIANAインターネット割り当て番号authorityLis論理IPサブネットMACメッセージ認証コードRASリモートアクセスサーバー
Michael Patrick Motorola Broadband Communications Sector 20 Cabot Blvd., MS M4-30 Mansfield, MA 02048
マイケルパトリックモトローラブロードバンドコミュニケーションセクター20 Cabot Blvd.、M4-30 Mansfield、MA 02048
Phone: (508) 261-5707 EMail: michael.patrick@motorola.com
電話：（508）261-5707メール：michael.patrick@motorola.com
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（2001）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。