Network Working Group M. Patrick
Request for Comments: 3046 Motorola BCS
Category: Standards Track January 2001
DHCP Relay Agent Information Option
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.
著作権（C）インターネット協会（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.
新しい高速公共のインターネットアクセス技術は、一つ以上の顧客宅内ホストにローカル・エリア・ネットワーク（LAN）添付ファイルを持つように高速モデムを求めます。この環境で顧客宅内ホストのIPアドレスを割り当てるために、RFC 2131で定義されたように、動的ホスト構成プロトコル（DHCP）を使用することが有利です。しかし、セキュリティおよびスケーリングの問題の数は、このような「公共」の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サーバーは、サーバーからクライアントへの応答でリレーエージェントに戻ってそのままオプションをエコー、およびリレーエージェントは、クライアントへの応答を転送する前にオプションを取り除きます。
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.
このモデルでは、「モデム」はなく、1つのホストに比べて、ユーザサイトでLANに接続していることに注意してください。複数のホストは、このサイトで実装されています。それは、ユーザーのサイトでフルIPルータを実装することは確かに可能であるが、これは（典型的なモデムのコストと比較して）機器の比較的高価な部分を必要とします。さらに、ルータは、すべてのホストのために、しかし、ルータ自身のためだけではなくIPアドレスが必要です。最後に、ユーザ側ルータは、ユーザーごとに専用の論理IPサブネット（LIS）が必要です。このモデルは、比較的小規模な企業のネットワーク環境に適していますが、それは大規模な、公衆アクセスネットワークには適していません。このシナリオでは、それは（ユーザサイトで、または他のネットワーク機器装置）モデムのIPアドレスを割り当てないIPネットワークモデルを実装することが有利であり、特にいないユーザ側LANのための全体のLIS。
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設備は、社内利用のためにIPアドレスを取得するために、ローカルDHCPサーバまたは他の方法を使用することができます。
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.
公共の高速回路にアクセスするためのIPアドレスを割り当てるDHCPを使用することが望ましいです。回路アクセスユニットの数（例えば、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の枯渇攻撃を防ぐのですか？攻撃者が利用可能なすべてのIPを作製し、クライアントのMACアドレスを持つリクエストを送信することにより、DHCPサーバからアドレスを要求したときです。どのようにIPアドレスまたはLISは、恒久的に、特定のユーザーまたはモデムに割り当てることができますか？どのようにして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 /長さ/値のタプルのシーケンスで構成されています。
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つ（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.
（存在する場合、しかし前「末端オプション」255）リレーエージェント情報フィールドを追加するDHCPリレーエージェントは、クライアントからサーバに転送任意の認識BOOTPまたはDHCPパケットのDHCPオプションフィールドに最後のオプションとして追加するものとします。
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フィールドを設定しないことがあり、クライアントとの間に信頼できる（クライアント側）に、下流のネットワーク要素（ブリッジ）を含有してもよいです。この場合、リレーエージェントは、「第二」のリレーエージェントオプションを追加しませんが、それが適切であると考えるようgiaddrフィールドを設定し、通常のDHCPリレーエージェント操作あたりのDHCPパケットを転送します。
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.
「信頼」と「信頼できない」回路を区別するためのメカニズムは、回線終端装置の種類に特異的であり、及び局所投与を含み得ます。例えば、ケーブルモデム終端システムが「信頼できない」として、ほとんどのケーブルモデムからのアップストリームパケットを考慮することができるが、VCを終了するATMスイッチはDSLAMを介して切り替え「信頼できる」などのVCを考慮し、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パケットの最大サイズのために設定がエージェント情報オプションを付加した後に作成しなければならないかもしれません。リレーエージェント情報オプションを付加した後、この設定された最大サイズを超えてしまい、パケットは、エージェント情報オプションを追加せずに転送されなければなりません。エラーカウンタは、この場合にはインクリメントされるべきである（SHOULD）。この設定可能がない場合には、エージェントは、それが転送されているインターフェイスの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.
エージェントは、パケットに「オプションのオーバーロード」オプションを追加したり、リレーエージェント情報オプションを追加するための「ファイル」または「snameの」フィールドを使用してはなりません。これは、エージェントを介して転送され、サーバからクライアントへのパケットのsnameのか、ファイルのフィールドに表示されることがありリレーエージェント情報オプションを解析したり、削除しないものとします。
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パケットを監視または変更する必要はありませんされているサーバーのユニキャストアドレス宛。これはRENEWING状態に入るときに送信されるDHCP-REQUESTを含んでいます。
Relay agents MUST NOT modify DHCP packets that use the IPSEC Authentication Header or IPSEC Encapsulating Security Payload [6].
リレーエージェントは、[6] IPSEC認証ヘッダやIPSECカプセル化セキュリティペイロードを使用してDHCPパケットを変更してはいけません。
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は、ローカルエージェント自身によって実装のgiaddrアドレスを偽装た場合にパケットを廃棄するゼロ以外のgiaddrとクライアントのDHCPパケットを受信リレーエージェントオプションを追加するように設定します。
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.
それ以外の場合は、リレーエージェントは、任意のリレーエージェントのオプションを追加することなく、有効なゼロ以外のgiaddrを持つ任意の受信したDHCPパケットを転送するものとします。 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オプションとしてリレーエージェント情報オプションをコピーする必要があります。サーバーが過負荷SNAMEまたはファイルのフィールドにエコーリレーエージェント情報オプションを置かないものとします。サーバが応答にフルリレーエージェント情報フィールドをコピーすることができない場合は、リレー情報フィールドせずに応答を送信しなければならない、との状況のためのエラーカウンタを増加すべきです。
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
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.
リレーエージェントがDHCP応答を転送するように回路を選択するために、エージェント回線IDフィールドの代わりに加えて、このフィールドを使用するか（例えば、オファー、ACK、またはNAK）。 DHCPサーバは、特定のクライアントに関連付けられている任意のレポートやMIBの中に、この値を報告する必要があります。
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サーバ間のIPネットワークが妥協であることをDHCPリレーエージェントを横断していることを前提としています。
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サーバは、IPの数は、単一のリモートIDに割り当てられるアドレスを制限するポリシーを実装する必要があります。
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サーバが割り当てるIPアドレスを選択するために、リモートIDを使用することができます。これは、特定のリモート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.
エージェントリモートIDとMACアドレスを関連付けることにより、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にDHCPプロトコル仕様のセクション7に記載されている[1]。
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リレーエージェントのオプションを省略するように注意する必要があることに注意してください。これは、サブオプションを持つ1つのオプションとして、クライアントに転送する前に、オプションを削除するには、リレーエージェントを必要とするために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に記載されているように「IETFコンセンサス」ポリシーと将来DHCPリレーエージェントサブオプションを割り当て、[3]。今後の提案のサブオプションは、それらを記述するインターネットドラフトで象徴的に参照することで、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]アレクサンダー、S.と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]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[5] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[5]ブラドナーの、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]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、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インターネット割り当て番号機関LIS論理IPサブネットMACメッセージ認証コードRASリモートアクセスサーバー
Michael Patrick Motorola Broadband Communications Sector 20 Cabot Blvd., MS M4-30 Mansfield, MA 02048
マイケル・パトリックモトローラブロードバンド通信セクター20カボットブルバード、MS M4-30マンスフィールド、MA 02048
Phone: (508) 261-5707 EMail: michael.patrick@motorola.com
電話：（508）261-5707 Eメール：michael.patrick@motorola.com
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。