[要約] RFC 6221は、軽量なDHCPv6リレーエージェントの仕様を定義しています。このRFCの目的は、IPv6ネットワークでのDHCPv6リレーションシップをサポートするための効率的な方法を提供することです。
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
軽量DHCPV6リレーエージェント
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コントロールまたはルーティング機能をサポートしていない既存のアクセスノード（デジタルサブスクライバーリンクアクセスマルチプレクサ（DSLAMS）やイーサネットスイッチなど）に実装できます。
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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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リンクに存在し、[L2RA]でDHCPV4操作用に提案されたレイヤー2リレーエージェントに機能的に同等です。
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].
IPv6ノードを1つ以上のルーターに集約するために、さまざまなリンク層ネットワークトポロジが存在します。単一のリンクに多くのノードがあるレイヤー2集約ネットワーク（IEEE 802.1Dブリッジングなど）では、DHCPV6サーバーまたはDHCPリレーエージェントは通常、DHCPクライアントがネットワークにどのように接続されているかを知りません。LDRAを使用すると、インターフェイスIDオプション[RFC3315]を含むリレーエージェント情報をアクセスノードで挿入して、クライアント識別のためにDHCPV6サーバーで使用できるようにします。ブロードバンドサービスプロバイダーの典型的なアプリケーションは、ブロードバンドフォーラム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.
アクセスノード多くのインターフェイスを1つのリンクに結合するデバイス。アクセスノードは、データパスでは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.
Link-Localアドレスは、アドレスのプレフィックス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.
Routerは、それ自体に直接対処されていないパケットを転送するノード。
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の上記のテキストでは、「Link-Address」は、リレーフォワードメッセージのリンクアドレスフィールドと、リレーフォワードメッセージ内にネストされるリレーフォワードメッセージのリンクアドレスフィールドの両方を指します。。
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.
リレーフォワードメッセージには、返信メッセージを転送する必要があるクライアント向けインターフェイスを識別するリレーエージェントパラメーターが含まれています。これらのパラメーターは、Link-Address、Peer-Address、およびInterface-IDです。Link-Addressパラメーターは、不特定のアドレスに設定する必要があります。ピアアドレスパラメーターは、セクション6.1で指定されているように設定する必要があります。Interface-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.
リレーレップメッセージは、サーバーとクライアントの間にリレーエージェントが存在する場合に、DHCPV6サーバーによってDHCPクライアントにパラメーターを送信するために構築されます。リレーのリレーンフォワードメッセージの後にリレー対応メッセージを送信することができます。パラメーターリンクアドレス、ピアアドレス、およびインターフェイス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.
サーバーには、リレーレプリーメッセージにインターフェイス-IDオプションを含めて、脱カプセル化メッセージを転送するインターフェイスをLDRAに示す必要があります。
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 Interface-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には、すべてのリレーフォワードメッセージにインターフェイス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.
サーバーは、パラメーター割り当てポリシーにInterface-IDを使用できます。Interface-IDの形式は、この貢献の範囲外です。Interface-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);
o ALL_DHCP_RELAY_AGENTS_AND_SERVERS（FF02 :: 1：2）に設定されている宛先IPアドレス。
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.
軽量リレーエージェントは、リレーフォワードメッセージに含めるように構成または必要な他のオプションを追加します。LDRAは、リレーフォワードメッセージのリンクアドレスフィールドを不特定のアドレス（：:)に設定し、すべてのDHCPリレーフォワードメッセージにインターフェイスIDオプションを含める必要があります。
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）
o REPLY (7)
o 返信（7）
o RECONFIGURE (10)
o 再構成（10）
o RELAY-REPL (13)
o リレーレップ（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メッセージに含まれるオプションは、LDRAによって検証されてはならないため、メッセージオプションの有効性を確認し、LDRAを変更せずに新しいオプションを導入できるようにするDHCPサーバーの責任となります。
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はクライアント向けインターフェイスから受け取ったタイプリレーフォー（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 Link-Local Scoped Destinationアドレス。
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メッセージタイプを検査する必要があり、Relay-Replyメッセージのみを検査する必要があります。他の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
リレーのメッセージは、LDRAが[RFC3315]ごとにリレーエージェントによって実行される有効性チェックに合格した場合、LDRAによって有効と見なされます。
- the Interface-ID option is present, and the value corresponds to a valid interface in the access node;
- Interface-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アドレスは同一であり、LDRAでIPアドレスが構成されていない場合、リンクローカルスコープアドレスです。と
- the link-address is the Unspecified Address when no IP address is configured on the LDRA.
- LDRAでIPアドレスが構成されていない場合、Link-Addressは不特定のアドレスです。
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は、宛先リンクレイヤー（Media Access Control（MAC））アドレスまたはインターフェイスIDをリレー対応のインターフェイス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ソースアドレスをリレー対応メッセージから、クライアントに転送されるIP/UDPパケットにコピーする必要があります。
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は、セクション6.1で指定されたトラフィックパターンを使用して、クライアント向けインターフェイスで受信したDHCPV6メッセージをインターセプトします。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タイプ：リレーフォー
hop-count: 0
ホップカウント：0
link-address: Unspecified_Address
Link-Address：unspecified_address
peer-address: client link-local address
ピアアドレス：クライアントリンクローカルアドレス
Interface-ID Option:
Interface-IDオプション：
interface-id: LDRA-inserted interface-id
Interface-ID：LDRAが挿入されたInterface-ID
Relay-Message Option, which contains:
リレーメサージオプション。
msg-type: SOLICIT
MSGタイプ：勧誘
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.
クライアントとサーバーは異なるIPv6リンク上にあり、通常はルーターとして機能する1つ以上のリレーエージェントによって区切られています。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タイプ：リレーフォー
hop-count: 1
ホップカウント：1
link-address: relayB address from link A
Link-Address：リンクからのreaybアドレスa
peer-address: client link-local address
ピアアドレス：クライアントリンクローカルアドレス
Relay-Message Option, which contains:
リレーメサージオプション。
msg-type: RELAY-FORW
MSGタイプ：リレーフォー
hop-count: 0
ホップカウント：0
link-address: Unspecified_Address
Link-Address：unspecified_address
peer-address: client link-local address
ピアアドレス：クライアントリンクローカルアドレス
Interface-ID Option:
Interface-IDオプション：
interface-id: LDRA-inserted interface-id
Interface-ID：LDRAが挿入されたInterface-ID
Relay-Message Option, which contains:
リレーメサージオプション。
msg-type: SOLICIT
MSGタイプ：勧誘
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.
クライアントとサーバーは異なるIPv6リンク上にあり、通常はルーターとして機能する1つ以上のリレーエージェントによって区切られており、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
たとえば、クライアントがRelaycとLDRAによってリレーされたDHCP勧誘メッセージを別のリレーエージェントであるRelayBに送信し、サーバーに送信した場合、サーバーは次のリレーフォワードメッセージを受信します：SRC-IP：lerayb
dst-ip: server
DST-IP：サーバー
msg-type: RELAY-FORW
MSGタイプ：リレーフォー
hop-count: 2
ホップカウント：2
link-address: relayB address from link A
Link-Address：リンクからのreaybアドレスa
peer-address: relayC
ピアアドレス：reayc
Relay-Message Option, which contains:
リレーメサージオプション。
msg-type: RELAY-FORW
MSGタイプ：リレーフォー
hop-count: 1
ホップカウント：1
link-address: Unspecified_Address
Link-Address：unspecified_address
peer-address: relayC
ピアアドレス：reayc
Interface-ID Option:
Interface-IDオプション：
interface-id: LDRA-inserted interface-id
Interface-ID：LDRAが挿入されたInterface-ID
Relay-Message Option, which contains:
リレーメサージオプション。
msg-type: RELAY-FORW
MSGタイプ：リレーフォー
hop-count: 0
ホップカウント：0
link-address: global or Unspecified_Address
Link-Address：Globalまたはunspecified_Address
peer-address: end client address
ピアアドレス：クライアントアドレスを終了します
Interface-ID Option: (if required)
Interface-idオプション：（必要に応じて）
interface-id: relayC-inserted Interface-ID
Interface-ID：reayc-Intered interface-id
Relay-Message Option, which contains:
リレーメサージオプション。
msg-type: SOLICIT
MSGタイプ：勧誘
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.
ドロム。
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リレー剤に関連するセキュリティの問題もLDRAに適用できます。LDRAは、過度のプロセスの利用を防ぐために、クライアントに起因するトラフィックに何らかのレート制限を実装する必要があります。LDRAは、UDPポート547のALL_DHCPV6_SERVERS_AND_RELAY_AGENTSアドレスに送信されたクライアントによって発行されたIPv6トラフィックのみを聴くため、LDRAはUDPポート547に送信され、他のクライアントオリジネートされたトラフィックを処理しないため、レート制限されるトラフィックは簡単に識別できます。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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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.、Ed。、Bound、J.、Volz、B.、Lemon、T.、Perkins、C。、およびM. Carney、「IPv6のダイナミックホスト構成プロトコル」、RFC 3315、2003年7月。
[L2RA] Joshi, B. and P. Kurapati, "Layer 2 Relay Agent Information", Work in Progress, April 2011.
[L2RA] Joshi、B。およびP. Kurapati、「レイヤー2リレーエージェント情報」、2011年4月の作業。
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, January 2001.
[RFC3046] Patrick、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
David Miles（編集者）Alcatel-Lucent L3 / 215 Spring St. Melbourne、Victoria 3000 Australia
Phone: +61 3 9664 3308
EMail: david.miles@alcatel-lucent.com
Sven Ooghe Alcatel-Lucent Copernicuslaan 50 2018 Antwerp, Belgium
Sven Ooghe Alcatel-Lucent Copernicuslaan 50 2018 Antwerp、ベルギー
EMail: sven.ooghe@alcatel-lucent.com
Wojciech Dec Cisco Systems Haarlerberdweg 13-19 1101 CH Amsterdam, The Netherlands
Wojciech Dec Cisco Systems haarlerberdweg 13-19 1101 ch amsterdam、オランダ
EMail: wdec@cisco.com
Suresh Krishnan Ericsson 8400 Blvd. Decarie Town of Mount Royal, Quebec Canada
Suresh Krishnan Ericsson 8400 Blvd.カナダケベック州マウントロイヤルのデカリータウン
EMail: suresh.krishnan@ericsson.com
Alan Kavanagh Ericsson 8400 Blvd. Decarie Town of Mount Royal, Quebec Canada
Alan Kavanagh Ericsson 8400 Blvd.カナダケベック州マウントロイヤルのデカリータウン
EMail: alan.kavanagh@ericsson.com