Internet Engineering Task Force (IETF) D. Miles, Ed.
Request for Comments: 6221 S. Ooghe
Updates: 3315 Alcatel-Lucent
Category: Standards Track W. Dec
ISSN: 2070-1721 Cisco Systems
S. Krishnan
A. Kavanagh
Ericsson
May 2011
Lightweight DHCPv6 Relay Agent
Abstract
抽象
This document proposes a Lightweight DHCPv6 Relay Agent (LDRA) that is used to insert relay agent options in DHCPv6 message exchanges identifying client-facing interfaces. The LDRA can be implemented in existing access nodes (such as Digital Subscriber Link Access Multiplexers (DSLAMs) and Ethernet switches) that do not support IPv6 control or routing functions.
この文書では、クライアント側インターフェイスを特定のDHCPv6メッセージ交換の中継エージェントオプションを挿入するために使用される軽量のDHCPv6リレーエージェント（LDRA）を提案しています。 LDRAは、IPv6制御またはルーティング機能をサポートしていない（例えば、デジタル加入者リンクアクセスマルチプレクサ（DSLAMの）とイーサネットスイッチなど）は、既存のアクセス・ノードに実装することができます。
Status of This Memo
このメモのステータス
This is an Internet Standards Track document.
これは、インターネット標準化過程文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。インターネット標準の詳細については、RFC 5741のセクション2で利用可能です。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6221.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6221で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Requirements Language ......................................3
2. Background ......................................................3
3. Terminology .....................................................3
4. Server Considerations ...........................................5
5. Message Format ..................................................5
5.1. Relay-Forward Message ......................................5
5.2. Relay-Reply Message ........................................6
5.3. Mandatory DHCP Options .....................................6
5.3.1. Relay-Message Option ................................6
5.3.2. Interface-ID Option .................................6
6. Agent Behaviour .................................................7
6.1. Relaying a Client Message ..................................7
6.1.1. Client Message Validation ...........................8
6.1.2. Trusted and Untrusted Interfaces ....................8
6.2. Relaying a Relay-Reply Message from the Network ............8
7. Network Topology ................................................9
7.1. Client and Server on Same Link .............................9
7.2. Client and Server behind Relay Agent ......................11
7.3. Relay Agent in Front of LDRA ..............................12
8. Contributors ...................................................15
9. Security Considerations ........................................15
10. References ....................................................15
10.1. Normative References .....................................15
10.2. Informative References ...................................16
DHCPv6 Relay Agents [RFC3315] are deployed to forward DHCPv6 messages between clients and servers when they are not on the same IPv6 link and are often implemented alongside a routing function in a common node. A Lightweight DHCPv6 Relay Agent (LDRA) allows Relay Agent Information to be inserted by an access node that performs a link-layer bridging (i.e., non-routing) function. An LDRA resides on the same IPv6 link as the client and a DHCPv6 Relay Agent or server, and is functionally the equivalent of the Layer 2 Relay Agent proposed for DHCPv4 operation in [L2RA].
DHCPv6のリレーエージェント[RFC3315]は、彼らが同じIPv6リンク上ではなく、多くの場合、共通ノードにおけるルーティング機能と一緒に実装されている場合、クライアントとサーバー間のDHCPv6メッセージを転送するために展開されています。軽量のDHCPv6リレーエージェント（LDRA）リレーエージェント情報がリンク層ブリッジング（すなわち、非ルーティング）機能を実行するアクセス・ノードによって挿入されることを可能にします。 LDRAは、クライアントとDHCPv6リレーエージェント又はサーバーと同じIPv6リンク上に存在し、そして機能的にレイヤ2リレーエージェントのと等価である[L2RA]にDHCPv4の動作のために提案されています。
Unlike a DHCPv6 Relay Agent specified in [RFC3315], an LDRA does not implement any IPv6 control functions (e.g., ICMPv6) or have any routing capability in the node.
[RFC3315]で指定されたDHCPv6リレーエージェントとは異なり、LDRAは、任意のIPv6制御機能（例えば、ICMPv6の）を実装またはノード内の任意のルーティング機能を有していません。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
A variety of different link-layer network topologies exist for the aggregation of IPv6 nodes into one or more routers. In Layer 2 aggregation networks (IEEE 802.1D bridging or similar) that have many nodes on a single link, a DHCPv6 server or DHCP Relay Agent would normally be unaware of how a DHCP client is attached to the network. The LDRA allows Relay Agent Information, including the Interface-ID option [RFC3315], to be inserted by the access node so that it may be used by the DHCPv6 server for client identification. A typical application in a broadband service provider could be equivalent to a Layer 2 DHCP Relay Agent as described in the Broadband Forum TR-101 report [TR-101] and in [L2RA].
異なるリンク層ネットワークトポロジの様々な1つまたは複数のルータにIPv6ノードの集合のために存在します。単一リンク上で多くのノードを持つレイヤ2個のアグリゲーションネットワーク（IEEE 802.1Dブリッジングまたは類似）では、DHCPv6サーバまたはDHCPリレーエージェントは、通常、DHCPクライアントがネットワークに接続されているかを知らないだろう。 LDRAは、クライアントの識別にDHCPv6サーバによって使用されることができるように、アクセスノードによって挿入されるインタフェース-IDオプション[RFC3315]を含む、リレーエージェント情報を可能にします。ブロードバンドサービスプロバイダーでの典型的なアプリケーションは、ブロードバンドフォーラムTR-101レポート[TR-101]にし、[L2RA]で説明したように、レイヤ2 DHCPリレーエージェントと同等である可能性があります。
Access Node A device that combines many interfaces onto one link. An access node is not IP-aware in the data path.
アクセスノードつのリンクに多くのインターフェイスを組み合わせデバイス。アクセスノードは、データパスにおけるIP-認識しません。
Address An IP layer identifier for an interface or set of interfaces.
インターフェイスのIPレイヤ識別子をアドレスまたはインターフェイスのセット。
Client-facing An interface on the access node that carries traffic towards the DHCPv6 client.
DHCPv6クライアントに向けてトラフィックを伝送するアクセスノード上のインタフェースをクライアントに面し。
Host A non-routing IPv6 node that is participating in a DHCPv6 message exchange.
DHCPv6のメッセージ交換に参加している非ルーティングIPv6ノードをホストします。
IP Internet Protocol Version 6 (IPv6).
IPインターネットプロトコルバージョン6（IPv6）の。
LDRA Lightweight DHCPv6 Relay Agent.
LDRA軽量のDHCPv6リレーエージェント。
Lightweight Relay Agent A function on the access node that intercepts DHCP messages between clients and servers. The function exists as a bump in the wire on the IP link.
軽量リレーエージェントクライアントとサーバ間でDHCPメッセージを傍受し、アクセスノード上の機能。関数は、IPリンク上のワイヤでバンプとして存在します。
Link A communication facility or medium over which nodes can communicate at the link layer.
ノードはリンク層で通信を行う通信設備または媒体をリンクします。
Link-local address An IP address having only local scope, indicated by having the address prefix fe80::/10, that can be used to reach neighbouring nodes attached to the same link. Every interface has a link-local address.
リンクローカルアドレスのアドレスプレフィックスFE80 :: / 10、同一のリンクに接続隣接ノードに到達するために使用することができる持っていることによって示され、ローカルスコープを有するIPアドレス。すべてのインターフェイスは、リンクローカルアドレスを持っています。
Network-facing An interface on the access node that carries traffic towards the DHCPv6 server(s).
DHCPv6サーバ（複数可）に向かってトラフィックを伝送するアクセスノードのインタフェースをネットワークに面します。
Node A device that implements IPv6.
IPv6を実装して、デバイスをノード。
Router A node that forwards packets not directly addressed to itself.
パケットが直接自分宛ではない転送ノードをルータ。
Relay Agent A node that acts as an intermediary to deliver DHCP messages between clients and servers and being on the same link as the client.
エージェントにクライアントとサーバ間でDHCPメッセージを配信するために仲介役として機能し、クライアントと同じリンク上にあるノードを中継。
Unspecified address An IPv6 address that is comprised entirely of zeros.
未指定アドレスゼロで完全に構成されたIPv6アドレス。
This document updates the behaviour specified in Section 11 of DHCP for IPv6 [RFC3315]. RFC 3315 states, in part:
この文書では、IPv6 [RFC3315]のためのDHCPのセクション11で指定された動作を更新します。一部ではRFC 3315の状態、：
If the server receives the message from a forwarding relay agent, then the client is on the same link as the one to which the interface, identified by the link-address field in the message from the relay agent, is attached.
サーバは、転送リレーエージェントからのメッセージを受信した場合、クライアントは、リレーエージェントからのメッセージ内のリンク・アドレス・フィールドによって識別されるインターフェイスは、添付されているものと同じリンク上にあります。
DHCP server implementations conforming to this specification MUST, for the purposes of address selection, ignore any link-address field whose value is zero. In the above text from RFC 3315, "link-address" refers to both the link-address field of the Relay-Forward message, and the link-address fields in any Relay-Forward messages that may be nested within the Relay-Forward message.
この仕様に準拠したDHCPサーバの実装は、アドレス選択の目的のために、その値がゼロである任意のリンク・アドレス・フィールドを無視しなければなりません。 RFC 3315から上記のテキストにおいて、「リンクアドレス」はリレー転送メッセージのリンクアドレスフィールドの両方を参照し、リレー転送メッセージ内でネストすることができる任意のリレー転送メッセージ内のリンク・アドレス・フィールド。
The Lightweight DHCPv6 Relay Agent (LDRA) exchanges DHCP messages between clients and servers using the message formats established in [RFC3315].
軽量のDHCPv6リレーエージェント（LDRAは）[RFC3315]に設立されたメッセージ・フォーマットを使用してクライアントとサーバ間でDHCPメッセージを交換します。
To maintain interoperability with existing DHCP relays and servers, the message format is unchanged from [RFC3315]. The LDRA implements the same message types as a normal DHCPv6 Relay Agent. They are:
既存のDHCPリレーとサーバとの相互運用性を維持するために、メッセージの形式は[RFC3315]から変更されていません。 LDRAは、通常のDHCPv6リレーエージェントと同じメッセージタイプを実装しています。彼らです：
o Relay-Forward Messages
Oリレーフォワードメッセージ
o Relay-Reply Messages
Oリレー応答メッセージ
The Relay-Forward message is created by any DHCPv6 Relay Agent, including an LDRA, to forward messages between clients and servers or other relay agents. These messages are built as specified in [RFC3315].
リレーフォワードメッセージは、クライアントとサーバまたは他のリレーエージェントとの間でメッセージを転送するために、LDRAを含む、任意のDHCPv6のリレーエージェントによって作成されます。これらのメッセージは、[RFC3315]で指定されるように構築されています。
The Relay-Forward message contains relay agent parameters that identify the client-facing interface on which any reply messages should be forwarded. These parameters are link-address, peer-address, and Interface-ID. The link-address parameter MUST be set to the unspecified address. The peer-address parameter MUST be set as specified in Section 6.1. The Interface-ID Relay Agent option MUST be included in the Relay-Forward message. The LDRA MAY insert additional relay agent options.
リレーフォワードメッセージは、任意の応答メッセージが転送されるべきでクライアントに面したインターフェイスを識別し、リレーエージェントのパラメータが含まれています。これらのパラメータは、リンクアドレス、ピア・アドレス、およびインターフェイス-IDです。リンクアドレスパラメータが未指定アドレスに設定しなければなりません。 6.1節で指定されたピア・アドレスのパラメータを設定しなければなりません。インターフェイス-IDリレーエージェントオプションは、リレーフォワードメッセージに含まれなければなりません。 LDRAは、追加のリレーエージェントのオプションを挿入することができます。
The Relay-Reply message is constructed by a DHCPv6 server to send parameters to a DHCP client when a relay agent is present between the server and the client. The Relay-Reply message may be sent after an initial Relay-Forward message as the parameters link-address, peer-address, and Interface-ID, as well as the relay agent's IP address, are learnt from the Relay-Forward message.
リレー応答メッセージは、リレーエージェントは、サーバとクライアントの間に存在する場合、DHCPクライアントにパラメータを送信するためにDHCPv6サーバから構成されています。リレー応答メッセージは、パラメータのリンクアドレス、ピア・アドレス、およびインターフェイス-IDだけでなく、リレーエージェントのIPアドレスは、リレーフォワードメッセージから学習されるように、最初のリレーメッセージを転送した後に送信されることがあります。
The server MUST include the Interface-ID option in the Relay-Reply Message to indicate to the LDRA the interface on which the decapsulated message should be forwarded.
サーバは、LDRAにデカプセル化メッセージを転送すべきインターフェイスを示すためにリレー応答メッセージのインタフェース-IDオプションを含まなければなりません。
Parameters are exchanged between the DHCP client, Relay Agent, and server through the use of DHCP options. There is a set of mandatory DHCP options that MUST be included by the LDRA in all Relay-Forward messages. These are the:
パラメータは、DHCPオプションを使用してDHCPクライアント、リレーエージェント、およびサーバー間で交換されます。すべてのリレーフォワードメッセージにLDRAに含まれなければならない義務的なDHCPオプションのセットがあります。これらは次のとおりであります：
o Relay-Message Option
Oリレーメッセージオプション
o Interface-ID Option
Oインタフェース-IDオプション
A DHCPv6 Relay Agent relays messages between clients and servers or other relay agents through Relay-Forward and Relay-Reply message types. The original client DHCP message (i.e., the packet payload, excluding UDP and IP headers) is encapsulated in a Relay Message option [RFC3315].
DHCPv6のリレーエージェントはリレーフォワードおよびリレー応答メッセージの種類によってクライアントとサーバまたは他のリレーエージェント間のメッセージを中継します。元のクライアントDHCPメッセージ（UDPおよびIPヘッダを除いた、すなわち、パケットのペイロードは、）リレーメッセージオプション[RFC3315]に封入されています。
If a Relay-Message would exceed the MTU of the outgoing interface, it MUST be discarded, and an error condition SHOULD be logged.
リレーメッセージが発信インターフェイスのMTUを超える場合、それは捨てなければなりません、エラー状態が記録されるべきです。
The LDRA MUST include the Interface-ID option [RFC3315] in all Relay-Forward messages. When an LDRA receives a Relay-Reply message with an Interface-ID option present and link-address unspecified, the LDRA MUST relay the decapsulated message to the client on the interface identified in the Interface-ID option.
LDRAは、すべてのリレーフォワードメッセージで、interface-idオプション[RFC3315]を含まなければなりません。 LDRAは、本インタフェース-IDオプションとリンクアドレス指定されていないとリレー応答メッセージを受信すると、LDRAインターフェイス-IDオプションで識別されたインターフェイス上のクライアントにデカプセル化メッセージを中継しなければなりません。
Servers MAY use the Interface-ID for parameter assignment policies. The format of the Interface-ID is outside the scope of this contribution. The Interface-ID SHOULD be considered an opaque value; i.e., the server SHOULD NOT try to parse the contents of the Interface-ID option. The LDRA SHOULD use the same Interface-ID value for a given interface, and this value SHOULD be retained across restarts. This is because if the Interface-ID changes, a server will not be able to use it reliably in parameter assignment policies.
サーバは、パラメータの割り当てポリシーのインターフェイス-IDを使用するかもしれません。インタフェース-IDの形式は、この寄与の範囲外です。インタフェース-IDは、不透明な値と見なされるべきです。すなわち、サーバは、interface-idオプションの内容を解析しようとしないでください。 LDRAは、所定のインターフェイスのために同じインタフェース-IDの値を使用する必要があり、この値は、再起動しても保持されるべきです。インターフェイス-IDが変化した場合、サーバは、パラメータの割り当てポリシーに確実にそれを使用することはできないためです。
The LDRA MUST have each of its interfaces configured as either client-facing or network-facing. The LDRA uses the notion of client-facing and network-facing interfaces to process DHCPv6 messages.
LDRAは、クライアント向き又はネットワーク側のいずれかとして構成され、そのインターフェイスの各々がなければなりません。 LDRAは、顧客対応とDHCPv6メッセージを処理するために、ネットワーク側インターフェイスの概念を使用しています。
The LDRA MUST intercept and process all IP traffic received on any client-facing interface that has:
LDRAはインターセプトし、すべてのIPトラフィックが持っている任意のクライアントに面したインターフェイス上で受信し処理しなければなりません：
o destination IP address set to All_DHCP_Relay_Agents_and_Servers (ff02::1:2);
All_DHCP_Relay_Agents_and_Serversに設定O宛先IPアドレス（FF02 :: 1：2）。
o protocol type UDP; and
OプロトコルタイプUDP。そして
o destination port 547.
O宛先ポート547。
The LDRA MUST also prevent the original message from being forwarded on the network-facing interface.
LDRAは、ネットワークに面したインターフェイスに転送され、元のメッセージを防止しなければなりません。
The lightweight relay agent adds any other options it is configured or required to include in the Relay-Forward message. The LDRA MUST set the link-address field of the Relay-Forward message to the Unspecified Address (::) and MUST include the Interface-ID option in all DHCP Relay-Forward messages.
軽量リレーエージェントは、それが構成されるか、またはリレーフォワードメッセージに含めるために必要な他のオプションを追加します。 :)そして、すべてのDHCPリレーフォワードメッセージで、interface-idオプションを含める必要があります。LDRAは（未指定アドレスへのリレーフォワードメッセージのリンクアドレスフィールドを設定しなければなりません。
If the message received on the client-facing interface is a Relay-Forward message, the LDRA MUST set the hop-count field in the newly created Relay-Forward message to the value of the hop-count field in the received message, incremented by 1 as specified in [RFC3315].
クライアントに面したインターフェイス上で受信したメッセージがリレーメッセージの転送をされた場合は、LDRAはインクリメントし、受信したメッセージ中のホップ・カウント・フィールドの値に新しく作成されたリレーフォワードメッセージでホップ・カウント・フィールドを設定しなければなりません[RFC3315]で指定されるように1。
The LDRA MUST copy the IP destination and link-layer destination addresses from the client-originated message into the IP destination address and link-layer destination address of the Relay-Forward message.
LDRAは、リレーフォワードメッセージのIP宛先アドレスとリンク層の宛先アドレスにクライアントから発信されたメッセージからIP送信先とリンク層の宛先アドレスをコピーしなければなりません。
The LDRA MUST copy the IP source address from the client-originated message into the peer-address field of the Relay-Forward message. The LDRA MUST copy the link-layer source address from the client-originated message into the link-layer source address of the Relay-Forward message.
LDRAは、リレーフォワードメッセージのピア・アドレスフィールドに、クライアントから発信されたメッセージからIP送信元アドレスをコピーする必要があります。 LDRAは、リレーフォワードメッセージのリンク層の送信元アドレスに、クライアントから発信されたメッセージからリンク層の送信元アドレスをコピーしなければなりません。
On receipt of a DHCP message on a client-facing interface, the LDRA MUST discard a message if it is of one of the following message types:
それは次のメッセージの種類の一つである場合、クライアントに面したインターフェイス上でDHCPメッセージを受信すると、LDRAはメッセージを捨てなければなりません。
o ADVERTISE (2)
O（2）ADVERTISE
o REPLY (7)
O REPLY（7）
o RECONFIGURE (10)
入出力RECONFIGURE（10）
o RELAY-REPL (13)
Oリレー-REPL（13）
Options contained in the DHCPv6 message MUST NOT be validated by the LDRA, making it the responsibility of the DHCP server to check message option validity and allow new options to be introduced without changes on the LDRA.
DHCPv6のメッセージに含まれるオプションは、DHCPサーバの責任メッセージオプションの妥当性をチェックし、新しいオプションがLDRAに変更することなく導入することができるようになって、LDRAによって検証されてはなりません。
In [RFC3046], DHCPv4 Relay Agents had their client-facing interfaces set to "trusted" and "untrusted". An LDRA MUST implement a configuration setting for all client-facing interfaces, marking them either as trusted or as untrusted. This setting SHOULD be configurable per interface. When a client-facing interface is deemed untrusted, the LDRA MUST discard any message of type RELAY-FORW (12) received from the client-facing interface.
[RFC3046]で、DHCPv4のリレーエージェントは、クライアント側インターフェイスは「信頼」と「信頼できない」に設定されていました。 LDRAは、信頼できるとして、または信頼されていないのいずれか、それらを記念して、すべてのクライアント側インターフェイスの構成設定を実装しなければなりません。この設定は、インターフェイスごとに設定可能にすべきです。クライアント側に向かうインターフェイスを信頼できないとみなされる場合、LDRAは型リレー-FORW（12）のいずれかのメッセージを破棄し、クライアントに面しインターフェースから受信しなければなりません。
The LDRA MUST intercept and process all IP traffic received on the network-facing interface that has:
LDRAはインターセプトし、すべてのIPトラフィックが持つネットワークに面したインターフェイス上で受信し処理しなければなりません：
o a link-local scoped source address;
リンクローカルスコープの送信元アドレスO;
o a link-local scoped destination address;
リンクローカルスコープの宛先アドレスO;
o protocol type UDP; and
OプロトコルタイプUDP。そして
o destination port 547
O宛先ポート547
An LDRA MUST inspect the DHCP message type and only forward Relay-Reply messages. Other DHCP message types MUST be silently discarded.
LDRAは、DHCPメッセージの種類を検査し、前方にのみリレー応答メッセージをしなければなりません。その他のDHCPメッセージタイプは黙って捨てなければなりません。
The Relay-Reply message is considered valid by the LDRA if it passes the validity checks to be performed by a relay agent per [RFC3315] and
リレー応答メッセージは、それが[RFC3315]あたりのリレーエージェントによって実行される妥当性チェックに合格した場合LDRAによって有効とみなされ、
- the Interface-ID option is present, and the value corresponds to a valid interface in the access node;
- インタフェース-IDオプションが存在し、値は、アクセスノードの有効なインタフェースに対応します。
- the Relay-Reply peer-address and the destination IP address are identical, and it is a link-local scoped address when no IP address is configured on the LDRA; and
- リレー返信ピア・アドレスおよび宛先IPアドレスが同一であり、それにはIPアドレスがLDRAに設定されていないリンクローカルスコープアドレスです。そして
- the link-address is the Unspecified Address when no IP address is configured on the LDRA.
- リンクアドレスは、IPアドレスがLDRAに設定されていない未指定アドレスです。
If the Relay-Reply message is valid, the LDRA copies the peer-address into the destination IP address field. The LDRA SHOULD forward the packet to the correct client-facing interface using the destination link-layer (Media Access Control (MAC)) address or the Interface-ID in the Relay-Reply. The LDRA SHOULD NOT retransmit the packet on any other interface. The contents of the Relay Message option are put into an IP/UDP packet and then forwarded to the client.
リレー応答メッセージが有効な場合、LDRAコピー先のIPアドレスフィールドにピアアドレス。 LDRAは、リレー、返信の宛先リンク層（メディアアクセス制御（MAC））アドレスまたはインターフェイスIDを使用して、正しいクライアントに面したインターフェイスにパケットを転送する必要があります。 LDRAは他のインターフェイス上のパケットを再送信すべきではありません。リレーメッセージオプションの内容は、IP / UDPパケットに入れ、その後、クライアントに転送されます。
The LDRA MUST copy the link-layer and IP source address from the Relay-Reply message into the IP/UDP packet that is forwarded to the client.
LDRAは、クライアントに転送されたIP / UDPパケットにリレー-Replyメッセージからリンク層およびIPソースアドレスをコピーしなければなりません。
The LDRA intercepts any DHCPv6 message received on client-facing interfaces with the traffic pattern specified in Section 6.1. The LDRA MUST NOT forward the original client message to a network-facing interface; it MUST process the message and add the appropriate Relay-Forward options as described in previous sections.
LDRAは、任意のDHCPv6メッセージは、セクション6.1で指定されたトラフィックパターンとクライアント側インターフェイスで受信インターセプト。 LDRAは、ネットワーク側インタフェースに、元のクライアントメッセージを転送してはなりません。それはメッセージを処理し、前のセクションで説明したように、適切なリレー転送オプションを追加しなければなりません。
The access node acts as a bridge; it has no information about any IP prefixes that are valid on the link. Thus, a server should consider address and parameter assignment as if the client DHCP message were not relayed.
アクセスノードは、ブリッジとして機能します。それがリンク上で有効な任意のIPプレフィックスに関する情報がありません。クライアントのDHCPメッセージが中継されていなかったかのようにこのように、サーバは、アドレスとパラメータの割り当てを検討すべきです。
+--------+
Client -------| |
| Access |
Client -------| Node |-----+
| (LDRA) | |
Client -------| | |
+--------+ |
| +--------+
|------| Server |
| +--------+
+--------+ |
Client -------| | |
| Access | |
Client -------| Node |-----+
| (LDRA) |
Client -------| |
+--------+
<--------- IPv6 Link -------->
For example, if a client sent a DHCP Solicit message that was relayed by the LDRA to the server, the server would receive the following Relay-Forward message from the LDRA:
クライアントがサーバにLDRAによって中継されたDHCP要請メッセージを送信した場合、サーバは、LDRAから、次のリレーフォワードメッセージを受け取ることになります。
src-ip: client link-local address
SRC-IP：クライアントのリンクローカルアドレス
dst-ip: All_DHCP_Relay_Agents_and_Servers
DST-IP：All_DHCP_Relay_Agents_and_Servers
msg-type: RELAY-FORW
MSG-タイプ：RELAY-FOR
hop-count: 0
ホップ数：0
link-address: Unspecified_Address
リンクアドレス：Unspecified_Address
peer-address: client link-local address
ピアアドレス：クライアントのリンクローカルアドレス
Interface-ID Option:
インターフェイス-IDオプション：
interface-id: LDRA-inserted interface-id
インターフェイスID：LDRA挿入インターフェイスID
Relay-Message Option, which contains:
含まれているリレーメッセージオプション、：
msg-type: SOLICIT
MSG-タイプ：SOLICIT
Solicit Message Options: <from client>
勧誘メッセージオプション：<クライアントから>
The client and server are on different IPv6 links, separated by one or more relay agents that will typically act as a router. The LDRA will send Relay-Forward messages upstream towards the second relay agent, which in turn will process the messages.
クライアントとサーバーは、通常のルータとして機能する1つの以上のリレーエージェントで区切って、異なるのIPv6リンクです。 LDRAは、順番にメッセージを処理する第2のリレーエージェントに向かって上流リレーフォワードメッセージを送信します。
+--------+
Client -------| |
| Access |
Client -------| Node |-----+
| (LDRA) | |
Client -------| | |
+--------+ |
| +--------+ +--------+
|------| RelayB |-------| Server |
| +--------+ +--------+
+--------+ |
Client -------| | |
| Access | |
Client -------| Node |-----+
| (LDRA) |
Client -------| |
+--------+
<------- IPv6 Link A -------> <--IPv6 Link B-->
For example, if a client sent a DHCP Solicit message that was relayed by the LDRA to another relay agent and then to the server, the server would receive the following Relay-Forward message from the LDRA: src-ip: relayB
例えば、クライアントは別のリレーエージェントにLDRAによって中継されたDHCP要請メッセージを送信した場合、サーバーには、サーバーはLDRAから次のリレーフォワードメッセージが表示されます：SRC-IP：relayBを
dst-ip: server
DST-IP：サーバー
msg-type: RELAY-FORW
MSG-タイプ：RELAY-FOR
hop-count: 1
ホップ数：1
link-address: relayB address from link A
リンクアドレス：リンクAからrelayBアドレス
peer-address: client link-local address
ピアアドレス：クライアントのリンクローカルアドレス
Relay-Message Option, which contains:
含まれているリレーメッセージオプション、：
msg-type: RELAY-FORW
MSG-タイプ：RELAY-FOR
hop-count: 0
ホップ数：0
link-address: Unspecified_Address
リンクアドレス：Unspecified_Address
peer-address: client link-local address
ピアアドレス：クライアントのリンクローカルアドレス
Interface-ID Option:
インターフェイス-IDオプション：
interface-id: LDRA-inserted interface-id
インターフェイスID：LDRA挿入インターフェイスID
Relay-Message Option, which contains:
含まれているリレーメッセージオプション、：
msg-type: SOLICIT
MSG-タイプ：SOLICIT
Solicit Message Options: <from client>
勧誘メッセージオプション：<クライアントから>
The client and server are on different IPv6 links, separated by one or more relay agents that will typically act as a router, and there is an [RFC3315] Relay Agent on the client-facing interface of the LDRA. The LDRA will send Relay-Forward messages upstream towards the second relay agent, which in turn will process the messages.
クライアントとサーバーは、通常のルータとして機能する1つの以上のリレーエージェントで区切って、異なるのIPv6リンク上にあり、LDRAのクライアントに面したインターフェイスの[RFC3315]リレーエージェントがあります。 LDRAは、順番にメッセージを処理する第2のリレーエージェントに向かって上流リレーフォワードメッセージを送信します。
+--------+
RelayC -------| |
| Access |
RelayC -------| Node |-----+
| (LDRA) | |
RelayC -------| | |
+--------+ |
| +--------+ +--------+
|------| RelayB |-------| Server |
| +--------+ +--------+
+--------+ |
RelayC -------| | |
| Access | |
RelayC -------| Node |-----+
| (LDRA) |
RelayC -------| |
+--------+
<------- IPv6 Link A -------> <--IPv6 Link B-->
For example, if a client sent a DHCP Solicit message that was relayed by RelayC and the LDRA to another relay agent, RelayB, and then to the server, the server would receive the following Relay-Forward message: src-ip: relayB
例えば、クライアントは別のリレーエージェント、RelayBにRelayCによって中継されたDHCP要請メッセージとLDRAを送信した場合、その後、サーバーに、サーバーは次のリレーフォワードメッセージが表示されます：SRC-IP：relayBを
dst-ip: server
DST-IP：サーバー
msg-type: RELAY-FORW
MSG-タイプ：RELAY-FOR
hop-count: 2
ホップ数：2
link-address: relayB address from link A
リンクアドレス：リンクAからrelayBアドレス
peer-address: relayC
ピアアドレス：relayC
Relay-Message Option, which contains:
含まれているリレーメッセージオプション、：
msg-type: RELAY-FORW
MSG-タイプ：RELAY-FOR
hop-count: 1
ホップ数：1
link-address: Unspecified_Address
リンクアドレス：Unspecified_Address
peer-address: relayC
ピアアドレス：relayC
Interface-ID Option:
インターフェイス-IDオプション：
interface-id: LDRA-inserted interface-id
インターフェイスID：LDRA挿入インターフェイスID
Relay-Message Option, which contains:
含まれているリレーメッセージオプション、：
msg-type: RELAY-FORW
MSG-タイプ：RELAY-FOR
hop-count: 0
ホップ数：0
link-address: global or Unspecified_Address
リンクアドレス：グローバルまたはUnspecified_Address
peer-address: end client address
ピアアドレス：エンドクライアントアドレス
Interface-ID Option: (if required)
インターフェイス-IDのオプション：（必要な場合）
interface-id: relayC-inserted Interface-ID
インターフェイスID：インタフェース-ID relayC挿入
Relay-Message Option, which contains:
含まれているリレーメッセージオプション、：
msg-type: SOLICIT
MSG-タイプ：SOLICIT
Solicit Message Options: <from end client>
勧誘メッセージオプション：<エンドクライアントから>
The authors would like to thank the following for their support: Lieven Levrau, Alastair Johnson, Robert Haylock, Mickey Vucic, Ludwig Pauwels, Fernando Cuervo, John Kaippallimalil, Fredrik Garneij, Alfred Hoenes, Ted Lemon, Tatuya Jinmei, David Hankins, and Ralph Droms.
著者は、彼らのサポートのために次のことを感謝したいと思います：リーフェンLevrau、アラステア・ジョンソン、ロバートHaylock、ミッキーVucic、ルートヴィヒPauwels、フェルナンド・クエルボ、ジョンKaippallimalil、フレドリックGarneij、アルフレッドHoenes、テッド・レモン、達也神明、デビッド・ハンキンズ、ラルフDroms。
Comments are solicited and should be addressed to the DHC WG mailing list (dhcwg@ietf.org) and/or the authors.
コメントが募集され、DHC WGメーリングリスト（dhcwg@ietf.org）および/または作者に対処する必要があります。
The security issues pertaining to DHCPv6 Relay Agents as specified in Section 23 of [RFC3315] are also applicable to LDRAs. The LDRA SHOULD implement some form of rate-limiting on client-originated traffic in order to prevent excessive process utilisation. The traffic to be rate-limited can be easily identified since the LDRA listens only to client-originated IPv6 traffic sent to the All_DHCPv6_Servers_and_Relay_Agents address on UDP port 547 and does not process any other client-originated traffic. As DHCP is session-oriented, messages in excess of the rate-limit may be silently discarded.
[RFC3315]のセクション23で指定されたDHCPv6リレーエージェントに関連するセキュリティ上の問題もLDRAsにも適用可能です。 LDRAは、過剰なプロセスの利用を防ぐために律速クライアントから発信されたトラフィック上のいくつかのフォームを実装する必要があります。 LDRAは、UDPポート547上のアドレスや他のクライアントから発信されたトラフィックを処理しないだけAll_DHCPv6_Servers_and_Relay_Agentsに送信されたクライアントから発信IPv6トラフィックをリッスンので、レート制限するトラフィックの識別を容易に行うことができます。 DHCPはセッション指向であるため、レート制限を超えるメッセージは静かに破棄されることがあります。
The hop-count-based determination of the trustworthiness of the LDRA can be easily defeated by a rogue relay agent on the network-facing interface of the LDRA.
LDRAの信頼性のホップカウントに基づく決意を容易LDRAのネットワーク側インタフェース上の不正リレーエージェントに敗北することができます。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315] Droms、R.、編、バウンド、J.、フォルツ、B.、レモン、T.、パーキンス、C.、およびM.カーニー、 "IPv6のための動的ホスト構成プロトコル（DHCPv6）"、RFC 3315 、2003年7月。
[L2RA] Joshi, B. and P. Kurapati, "Layer 2 Relay Agent Information", Work in Progress, April 2011.
[L2RA]ジョシ、B.およびP. Kurapati、 "レイヤ2リレーエージェント情報"、進歩、2011年4月の作業。
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, January 2001.
[RFC3046]パトリック、M.、 "DHCPリレーエージェント情報オプション"、RFC 3046、2001年1月。
[TR-101] The Broadband Forum, "Migration to Ethernet-Based DSL Aggregation", Technical Report TR-101, April 2006.
[TR-101]ブロードバンドフォーラム、 "イーサネットベースのDSLアグリゲーションへの移行"、技術レポートTR-101、2006年4月。
Authors' Addresses
著者のアドレス
David Miles (editor) Alcatel-Lucent L3 / 215 Spring St. Melbourne, Victoria 3000 Australia
デビッド・マイルズ（編集者）アルカテル・ルーセントL3 / 215春セントメルボルン、ビクトリア3000オーストラリア
Phone: +61 3 9664 3308 EMail: david.miles@alcatel-lucent.com
電話：+61 3 9664 3308 Eメール：david.miles@alcatel-lucent.com
Sven Ooghe Alcatel-Lucent Copernicuslaan 50 2018 Antwerp, Belgium
スヴェンOogheアルカテル・ルーセントCopernicuslaan 50 2018アントワープ、ベルギー
EMail: sven.ooghe@alcatel-lucent.com
メールアドレス：sven.ooghe@alcatel-lucent.com
Wojciech Dec Cisco Systems Haarlerberdweg 13-19 1101 CH Amsterdam, The Netherlands
ヴォイチェフ12月シスコシステムズHaarlerberdweg 13-19 1101 CHアムステルダム、ネザーランズ
EMail: wdec@cisco.com
メールアドレス：wdec@cisco.com
Suresh Krishnan Ericsson 8400 Blvd. Decarie Town of Mount Royal, Quebec Canada
スレシュクリシュナンエリクソン8400ブルバードマウントロイヤル、ケベック州、カナダのDecarieタウン
EMail: suresh.krishnan@ericsson.com
メールアドレス：suresh.krishnan@ericsson.com
Alan Kavanagh Ericsson 8400 Blvd. Decarie Town of Mount Royal, Quebec Canada
アラン・カバナーエリクソン8400ブルバードマウントロイヤル、ケベック州、カナダのDecarieタウン
EMail: alan.kavanagh@ericsson.com
メールアドレス：alan.kavanagh@ericsson.com