RFC3046 日本語訳
3046 DHCP Relay Agent Information Option. M. Patrick. January 2001. (Format: TXT=30633 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Patrick Request for Comments: 3046 Motorola BCS Category: Standards Track January 2001
コメントを求めるワーキンググループM.パトリックの要求をネットワークでつないでください: 3046年のモトローラBCSカテゴリ: 標準化過程2001年1月
DHCP Relay Agent Information Option
DHCP中継エージェント情報オプション
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
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)愛着を1人以上の顧客前提ホストに持っているように求めます。 Dynamic Host Configuration Protocol(DHCP)を使用するのは顧客前提ホストIPにこの環境におけるアドレスを配属するためにRFC2131で定義されるように有利です。 しかしながら、多くのセキュリティとスケーリング問題はそのような「公共」のDHCP使用で起こります。 このドキュメントは、これらの問題を扱うために新しいDHCPオプションについて説明します。 このオプションはRFC2132で定義されるように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サーバに送るとき、新しいオプションは、Relayエージェント情報オプションと呼ばれて、DHCP中継エージェントによって挿入されます。Relayエージェント情報オプションを認識するサーバは、IPアドレスか他のパラメタ課題が方針であると実装するのに情報を使用するかもしれません。 DHCP Serverはサーバからクライアントへの回答で中継エージェントにオプションを逐語的にecho backです、そして、回答をクライアントに送る前に、中継エージェントはオプションを剥取ります。
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」を含めます。
Patrick Standards Track [Page 1] RFC 3046 DHCP Relay Agent Information Option January 2001
RFC3046DHCPがエージェント情報オプション2001年1月にリレーするパトリック標準化過程[1ページ]
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つの序論… 2 1.1 高速回路はデータ網を切り換えました… 2 1.2 DHCPは回路アクセス設備でエージェントをリレーします… 4 2.0 エージェント情報オプションをリレーしてください… 5 2.1 エージェント操作… 6 2.1 .1 Reforwarded DHCP要求… 7 2.2 サーバ操作… 7 3.0 エージェント情報Suboptionsをリレーしてください… 8 3.1 エージェントCircuit ID… 8 3.2 エージェントの遠く離れたID… 9 解決された4.0冊… 9 5.0 セキュリティ問題… 10 6.0 IANA問題… 11 7.0 知的所有権通知… 12 8.0の参照箇所… 12 9.0用語集… 13 10.0作者のアドレス… 13 11.0 完全な著作権宣言文… 14
1 Introduction
1つの序論
1.1 High-Speed Circuit Switched Data Networks
1.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.
通常回路の切り換えられたデータ網を通してインターネットへの公共のAccessがあります。 今日、ダイヤルアップモデムがRemote Access Serverに接続する状態で、これは主として実装されます。しかし、また、より高い速度回路アクセスネットワークはISDN、ATM、Frame Relay、およびCable Data Networksを含んでいます。 複数のユーザが切り換えられたか永久的な回路を通して「回路アクセスユニット」に接続する「星」トポロジーとしてこれらのネットワークのすべてを特徴付けることができます。
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.
しかしながら、より新しい高速回路技術は頻繁にLANインタフェース(特にイーサネット)を1台以上のホストPCに提供します。 DHCPを通してそのような回路に接続するホストコンピュータのIPアドレスの集結された課題をサポートするのは望ましいです。 集結された回路集中アクセスデバイスで共同実装されて、DHCPサーバは、あることができますが、通常、ありません。 DHCPサーバは別々のサーバとして中央のアクセスデバイス(または、デバイス)が付く「中央のLAN」でしばしば接続されます。
Patrick Standards Track [Page 2] RFC 3046 DHCP Relay Agent Information Option January 2001
RFC3046DHCPがエージェント情報オプション2001年1月にリレーするパトリック標準化過程[2ページ]
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
| | +---------------+
+---------+
+---------------+ | 中央| 回路|-- ckt1--- Modem1--ホスト|- LANを接待してください。| | アクセス| ラン|- ホストB| | ユニット1| |- ホストC|-----| |-- | | |(中継エージェント) |... +---------+ | +---------------+ | DHCP|--| | サーバ| | +---------+ | | | +---------------+ +---------+ | | 回路|-- ckt1--- Modem2--ホスト--- ホストD| 他| | | アクセス| ラン| サーバ|--|-----| ユニット2| | (| | | | ウェブ、--ckt2--Modem3(ホスト)はEを接待します| DNS) | | |(中継エージェント) |... ラン| | +---------------+ +---------+
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アドレスをも必要とします。 最終的に、ユーザサイドルータは各ユーザのために、専用Logical IP Subnet(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インストールが社内の使用にローカルのDHCPサーバかIPアドレスを得る他のメソッドを使用するかもしれません。
Patrick Standards Track [Page 3] RFC 3046 DHCP Relay Agent Information Option January 2001
RFC3046DHCPがエージェント情報オプション2001年1月にリレーするパトリック標準化過程[3ページ]
1.2 DHCP Relay Agent in the Circuit Access Unit
1.2 回路アクセスユニットの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のs、ケーブルモデム終了システム、ADSLアクセスユニットなど)がLAN(または、地方のインターネット)に接続するユニットにどれが付属a DHCPサーバであるかにアクセスします。
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のものsが今日するように。 回路アクセス設備は両方として回路と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.
回路のリモート接続を特定するのに使用される同じメカニズム(例えば回路アクセス設備として機能するRemote Access Serverによって要求されたユーザ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?
要求を公的に接続するホストからDHCPに転送すると高速回路がホストのLAN接続と共にアクセスされたとき、多くの問題が起こります。 これらの多くがDHCPクライアント要求から信頼できないソースから起こる安全保障問題です。 中継エージェントは、回答を進めるのをどのようにどの回路に知っていますか? システムはどのようにDHCP IP疲労困憊攻撃を防ぎますか? これは攻撃者が作られたクライアントMACアドレスでDHCPサーバから要求を送ることによってすべての利用可能なIPアドレスを要求する時です。 永久に、どうしたらIPアドレスかLISを特定のユーザかモデムに割り当てることができますか? 1つは、IPアドレスを割り当てるのに使用されるクライアント識別子分野が「だまされること」をどのように防ぎますか? 1つは、他のクライアントの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クライアント要求に情報を追加してください。
Patrick Standards Track [Page 4] RFC 3046 DHCP Relay Agent Information Option January 2001
RFC3046DHCPがエージェント情報オプション2001年1月にリレーするパトリック標準化過程[4ページ]
2.0 Relay Agent Information Option
2.0 中継エージェント情報オプション
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:
このドキュメントはRelayエージェント情報Optionと呼ばれる新しいDHCP Optionを定義します。 それは特定のエージェント供給されたサブオプションのための「コンテナ」オプションです。 Relayエージェント情報オプションの形式は以下の通りです。
Code Len Agent Information Field
+------+------+------+------+------+------+--...-+------+
| 82 | N | i1 | i2 | i3 | i4 | | iN |
+------+------+------+------+------+------+--...-+------+
コードレンエージェント情報フィールド+------+------+------+------+------+------+--...-+------+ | 82 | N| i1| i2| i3| i4| | コネ| +------+------+------+------+------+------+--...-+------+
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はエージェント情報Fieldの八重奏の総数を与えます。 エージェント情報分野は以下の方法でコード化されたそれぞれのサブオプションのためのSubOpt/長さ/値のtuplesの系列から成ります:
SubOpt Len Sub-option Value
+------+------+------+------+------+------+--...-+------+
| 1 | N | s1 | s2 | s3 | s4 | | sN |
+------+------+------+------+------+------+--...-+------+
SubOpt Len Sub-option Value
+------+------+------+------+------+------+--...-+------+
| 2 | N | i1 | i2 | i3 | i4 | | iN |
+------+------+------+------+------+------+--...-+------+
SubOptレンサブオプション価値+------+------+------+------+------+------+--...-+------+ | 1 | N| s1| s2| s3| s4| | sN| +------+------+------+------+------+------+--...-+------+ SubOptレンサブオプション価値+------+------+------+------+------+------+--...-+------+ | 2 | N| i1| i2| i3| i4| | コネ| +------+------+------+------+------+------+--...-+------+
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エージェント情報Optionの長さNはサブオプションコード/長さ/値のtuplesのすべてのバイトを含んでいるものとします。 少なくとも1つのサブオプションを定義しなければならないので、最小のRelayエージェント情報の長さは2(2)です。 サブオプションの長さNはそのサブオプションだけの値の分野で八重奏の数になるでしょう。 サブオプションの長さはゼロであるかもしれません。 サブオプションはサブオプションコードオーダーに現れる必要はありません。
The initial assignment of DHCP Relay Agent Sub-options is as follows:
DHCP RelayエージェントSub-オプションの初期の課題は以下の通りです:
DHCP Agent Sub-Option Description
Sub-option Code
--------------- ----------------------
1 Agent Circuit ID Sub-option
2 Agent Remote ID Sub-option
DHCPエージェントサブオプション記述サブオプションコード--------------- ---------------------- 1 エージェント回路IDサブオプション2のエージェントの遠く離れたIDサブオプション
Patrick Standards Track [Page 5] RFC 3046 DHCP Relay Agent Information Option January 2001
RFC3046DHCPがエージェント情報オプション2001年1月にリレーするパトリック標準化過程[5ページ]
2.1 Agent Operation
2.1 エージェント操作
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中継エージェントオプションSHOULDを言い足して、SHOULD、デフォルトで無効にされてください。 中継エージェントSHOULDには、それがクライアントからサーバへのパケットに加えられるか否かに関係なく、制御するそれぞれのサブオプションのための別々のconfigurablesがあります。
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.
Relayエージェント情報分野SHALLを加えているDHCP中継エージェントは最後のオプションとしてそれを加えます。(しかし、クライアントからサーバまで'終わりのOption'255、プレゼント) DHCPオプションがさばく何かのコネがBOOTPを認識したか、そして、または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(彼らが最初に、ホップルータであることを示す)にもかかわらず、Relayエージェント情報オプションが既に存在していた状態でパケットSHALLで信頼されていない回路からDHCPパケットを受ける中継エージェントが、パケットを捨てて、誤り件数を増加します。 信じられた回路は中継エージェントオプションを加えますが、giaddr分野を設定しないかもしれない中継エージェントとクライアントの間の川下で信じられた(クライアントについて、より近い)ネットワーク要素(ブリッジ)を含むかもしれません。 この場合、中継エージェントは、1「秒」の間の中継エージェントオプションを加えませんが、通常の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.
「信じられ」て「信頼されていない」回路を見分けるためのメカニズムは、回線終端設備のタイプに特定であり、地方行政にかかわるかもしれません。 例えば、Cable Modem Termination Systemは、ほとんどのケーブルモデムからの上流のパケットが「信頼されていない」とみなすかもしれませんが、DSLAMを通して切り換えられたVCsを終えるATMスイッチが中継エージェントを「信じ」て、受け入れるようなVCsを考えるかもしれないので、オプションは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.
中継エージェントはaをエージェント情報オプションを追加した後にDHCPパケットの最大サイズが作成されるのにおいて構成可能にするかもしれません。 Relayエージェント情報オプションを追加した後にこの構成された最大サイズを超えているパケットにエージェント情報オプションを加えるWITHOUTを送るでしょう。 この場合増加されていて、誤りはSHOULDを打ち返します。 これが不在のとき、構成可能です、エージェントSHALL NOTはそれが進められるインタフェースの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.
サーバからクライアントへのクライアントへの応答を進めるときそれを加えた中継エージェントか信じられた川下のネットワーク要素のどちらかでサーバによって反映されたRelayエージェント情報オプションを取り除かなければなりません。
Patrick Standards Track [Page 6] RFC 3046 DHCP Relay Agent Information Option January 2001
RFC3046DHCPがエージェント情報オプション2001年1月にリレーするパトリック標準化過程[6ページ]
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.
エージェントSHALL NOTは、「オプションオーバーロード」オプションをパケットに加えるか、またはRelayエージェント情報オプションを加えるのに「ファイル」か"sname"分野を使用します。 それ、SHALL NOTはサーバからクライアントへのパケットの分野がエージェントを通して転送したsnameかファイルに現れるかもしれないRelayエージェント情報オプションを、分析するか、または取り除きます。
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].
中継エージェントはIPSEC Authentication Headerを使用するDHCPパケットかIPSEC Encapsulating Security有効搭載量[6]を変更してはいけません。
2.1.1 Reforwarded DHCP requests
2.1.1 Reforwarded 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エージェントオプションを持っているかもしれません。
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が地元のエージェント自身によって実装されたアドレスであると偽造するなら非零でクライアントDHCPパケットを受けるRelayエージェントオプションを加えるために、giaddr SHALLがパケットを捨てるのを構成しました。
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.
さもなければ、中継エージェントSHALLは有効な非ゼロgiaddr WITHOUTがどんな中継エージェントオプションも加えているどんな容認されたDHCPパケットも進めます。 また、RFC2131に従って、それはgiaddr値を変更しないものとします。
2.2 Server Operation
2.2 サーバ操作
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.
情報オプションがオプションを無視するRelayエージェントに気づかないDHCPサーバは、受信して、応答のときにそれをecho backでないでしょう。 これは未知のオプションのための指定されたサーバの振舞いです。
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.
Relayエージェント情報オプションがSHALLであるとサポートすると主張するDHCPサーバがすべての回答におけるRelayエージェント情報オプションの全体のコンテンツを反響します。 サーバSHOULDは応答における最後のDHCPオプションとしてRelayエージェント情報オプションをコピーします。 サーバSHALL NOTは反響しているRelayエージェント情報オプションを積みすぎられたsnameかファイル分野に置きます。 サーバがaをコピーできないなら、Relayエージェント情報分野を応答に洗い張りしてください、それ。SHALLはRelay情報Fieldなしで応答を送ります、そして、SHOULDは状況のために誤りカウンタを増加します。
Patrick Standards Track [Page 7] RFC 3046 DHCP Relay Agent Information Option January 2001
RFC3046DHCPがエージェント情報オプション2001年1月にリレーするパトリック標準化過程[7ページ]
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メッセージをモニターする必要はないことに注意してください。 しかしながら、いつかの中継エージェント5月は、そのようなモニターをして、中継エージェントオプションを加えるのを選びました。 その結果、サーバSHOULDは、ユニキャストメッセージにおける中継エージェントオプションを扱うように準備されますが、それらがそこにいつもあると予想してはいけません。
3.0 Relay Agent Information Sub-options
3.0 中継エージェント情報サブオプション
3.1 Agent Circuit ID Sub-option
3.1 エージェント回路IDサブオプション
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
- ルータインタフェース番号--切り換えHubポートナンバー--リモートAccess Serverポートナンバー--フレームRelay DLCI(ATMの仮想の回路番号)は仮想の回路番号にDataに電報を打ちます。
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と他のパラメタ課題方針にCircuit IDを使用するかもしれません。 Circuit ID SHOULDが不透明な値であると考えられて、正確に基づいた方針で、マッチだけを結んでください。 すなわち、サーバによって分析されて、Circuit ID SHOULD NOTは内部的にそうです。
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サーバSHOULDは統計報告(MIBを含んでいる)とログの現在のリースのエージェントCircuit ID価値を報告します。 特定の中継エージェントだけにおいて、Circuit IDが地方であるので、回路IDは中継エージェントを特定するgiaddr値で資格があるべきです。
SubOpt Len Circuit ID
+------+------+------+------+------+------+------+------+--
| 1 | n | c1 | c2 | c3 | c4 | c5 | c6 | ...
+------+------+------+------+------+------+------+------+--
SubOptレンCircuit ID+------+------+------+------+------+------+------+------+-- | 1 | n| c1| c2| c3| c4| c5| c6| ... +------+------+------+------+------+------+------+------+--
Patrick Standards Track [Page 8] RFC 3046 DHCP Relay Agent Information Option January 2001
RFC3046DHCPがエージェント情報オプション2001年1月にリレーするパトリック標準化過程[8ページ]
3.2 Agent Remote ID Sub-option
3.2 エージェントのリモートIDサブオプション
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中継エージェントによって加えられるかもしれません(切り換えられたか永久的な回路を終えて、回路のリモートホスト端を特定するメカニズムを持っています)。 Remote 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
-- ダイアルアップ接続のための「発信者番号」電話番号--「ユーザ名」はRemote Access Server(リモート訪問者ATMアドレス)によるケーブルデータモデム(ポイントツーポイント接続のリモートIPアドレス)の「モデムID」のためにX.25接続に、リモートなX.25アドレスをうながしました。
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サーバは、特定のユーザ、ホスト、または加入者モデムに特定のパラメタを選択するのにこのオプションを使用するかもしれません。オプションSHOULDが不透明な値であると考えられて、正確に基づいた方針で、マッチだけを結んでください。 すなわち、サーバによって分析されて、オプションSHOULD NOTは内部的にそうです。
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.
中継エージェントは、分野かエージェントCircuit ID分野の代わりにDHCP回答(例えば、Offer、Ack、またはNak)を進める回路を選択するのにこの分野を使用するかもしれません。 DHCPサーバSHOULDは特定のクライアントに関連しているどんなレポートやMIBsでもこの値を報告します。
SubOpt Len Agent Remote ID
+------+------+------+------+------+------+------+------+--
| 2 | n | r1 | r2 | r3 | r4 | r5 | r6 | ...
+------+------+------+------+------+------+------+------+--
SubOptレンエージェントの遠く離れたID+------+------+------+------+------+------+------+------+-- | 2 | n| r1| r2| r3| r4| r5| r6| ... +------+------+------+------+------+------+------+------+--
4.0 Issues Resolved
4.0 解決された問題
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.
回路アクセス設備が進める、通常、回路だけにおけるbroadcasted DHCP応答はエージェントでCircuit IDを示しました。
Patrick Standards Track [Page 9] RFC 3046 DHCP Relay Agent Information Option January 2001
RFC3046DHCPがエージェント情報オプション2001年1月にリレーするパトリック標準化過程[9ページ]
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サーバSHOULDは単一の遠く離れた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サーバは、IPアドレスが割り当てられるのを選択するのに遠く離れたIDを使用するかもしれません。 それは、IPアドレスの静的な課題を特定のリモートIDに可能にして、権限のない遠く離れた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.
エージェントによって供給されたエージェントRemote IDオプションを使用することによって、信頼されていなくてまだ非標準化されたクライアント識別子分野はDHCPサーバによって使用される必要はありません。
MAC Address Spoofing
マックーアドレススプーフィング
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.
エージェントRemote IDにMACアドレスを関連づけることによって、DHCPサーバは、同じMACが異なった遠く離れたIDに関するアドレスであると偽造する攻撃者にIPアドレスを提供するのを防ぐことができます。
5.0 Security Considerations
5.0 セキュリティ問題
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はどんな認証もセキュリティー対策も提供しません。RFC2131[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
このドキュメントはIPアドレス課題の操作へのいくつかのセキュリティー攻撃を扱うためにメカニズムを紹介します、IPスプーフィング、Client IDスプーフィング、MACアドレススプーフィング、およびDHCPサーバを含んでいて
Patrick Standards Track [Page 10] RFC 3046 DHCP Relay Agent Information Option January 2001
RFC3046DHCPがエージェント情報オプション2001年1月にリレーするパトリック標準化過程[10ページ]
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.
疲労困憊を扱ってください。 それは想定された信頼されていないDHCPクライアントとのDHCP RelayエージェントとDHCPサーバとの暗示している信じられた関係を当てにします。 新しいidentifer、「遠く離れたID」をそれは導入します、また、それが信じられると思われます。 アクセスネットワークかモデムはクライアント前提設備で提供するのではなく、Remote 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 Relayエージェントオプションを省略するために注意されなければならないことに注意してください。 これはただ一つのオプションとしてサブオプションでDHCP RelayエージェントOptionを組織化して、中継エージェントが推進の前にオプションをクライアントに移すのが必要であることの主要な理由でした。
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サーバを偽造するかもしれないいずれも。
6.0 IANA Considerations
6.0 IANA問題
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 Parameters Registryに位置する「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はRFC2434[3]で説明されるように「IETFコンセンサス」方針で今後のDHCP RelayエージェントSub-オプションを割り当てます。 今後の提案されたサブオプションはそれらについて説明するインターネット草稿で象徴的に参照をつけられるためにあって、公表のためにRFCとして承認されると、IANAによって数字コードを割り当てられるものとします。
Patrick Standards Track [Page 11] RFC 3046 DHCP Relay Agent Information Option January 2001
RFC3046DHCPがエージェント情報オプション2001年1月にリレーするパトリック標準化過程[11ページ]
7.0 Intellectual Property Notices
7.0 知的所有権通知
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はどんな知的所有権の正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 どちらも、それはそれを表しません。どんなそのような権利も特定するためにいずれも取り組みにしました。 BCP-11で標準化過程の権利と規格関連のドキュメンテーションに関するIETFの手順に関する情報を見つけることができます。 権利のクレームのコピーで利用可能に作られるべきライセンスの保証、または一般的なライセンスか許可が作成者によるそのような所有権の使用に得させられた試みの結果が公表といずれにも利用可能になったか、または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は本書では含まれた仕様いくつかかすべてに関して要求された知的所有権について通知されました。 詳しい情報に関しては、要求された権利のオンラインリストに相談してください。
8.0 References
8.0の参照箇所
[1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997.
[1]Droms、R.、「ダイナミックなホスト構成プロトコル」、RFC2131、1997年3月。
[2] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extension", RFC 2132, March 1997.
[2] アレクサンダー、S.、R.Droms、および「DHCPオプションとBOOTPベンダー拡張子」(RFC2132)は1997を行進させます。
[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問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[4] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[5] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
[5] ブラドナー、S.、「改正3インチ、BCP9、RFC2026、1996年インターネット標準化過程--10月。」
[6] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[6] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。
Patrick Standards Track [Page 12] RFC 3046 DHCP Relay Agent Information Option January 2001
RFC3046DHCPがエージェント情報オプション2001年1月にリレーするパトリック標準化過程[12ページ]
9.0 Glossary
9.0 用語集
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インターネットは論理的なIPのサブネットMACメッセージ立証コードRASリモートアクセス・サーバーを数の権威LISに割り当てました。
10.0 Author's Address
10.0 作者のアドレス
Michael Patrick Motorola Broadband Communications Sector 20 Cabot Blvd., MS M4-30 Mansfield, MA 02048
MS M4-30マンスフィールド、MA セクター20カボーBlvd.、マイケルパトリックモトローラ広帯域通信02048
Phone: (508) 261-5707 EMail: michael.patrick@motorola.com
以下に電話をしてください。 (508) 261-5707 メールしてください: michael.patrick@motorola.com
Patrick Standards Track [Page 13] RFC 3046 DHCP Relay Agent Information Option January 2001
RFC3046DHCPがエージェント情報オプション2001年1月にリレーするパトリック標準化過程[13ページ]
11.0 Full Copyright Statement
11.0 完全な著作権宣言文
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Patrick Standards Track [Page 14]
パトリック標準化過程[14ページ]
一覧
スポンサーリンク
