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
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中继代理（LDRA），用于在识别面向客户端接口的DHCPv6消息交换中插入中继代理选项。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信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第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
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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照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节点聚合到一个或多个路由器中。在单个链路上有多个节点的第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.
接入节点将多个接口组合到一个链路上的设备。访问节点在数据路径中不支持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 Internet协议版本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.
链路本地地址只有本地作用域的IP地址，由地址前缀fe80:：/10表示，可用于到达连接到同一链路的相邻节点。每个接口都有一个链接本地地址。
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:
本文档更新了DHCP for IPv6[RFC3315]第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].
中继转发消息由任何DHCPv6中继代理（包括LDRA）创建，用于在客户端和服务器或其他中继代理之间转发消息。这些消息按照[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.
中继回复消息由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 接口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
服务器可以将接口ID用于参数分配策略。接口ID的格式超出了本文的范围。接口ID应被视为不透明值；i、 例如，服务器不应尝试解析接口ID选项的内容。LDRA应使用相同的接口ID值
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更改，服务器将无法在参数分配策略中可靠地使用它。
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 目标IP地址设置为所有\u DHCP\u中继\u代理\u和\u服务器（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.
轻量级中继代理添加其配置的或需要包含在中继转发消息中的任何其他选项。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 继电器-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.
LDRA不得验证DHCPv6消息中包含的选项，因此DHCP服务器有责任检查消息选项的有效性，并允许在不更改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地址相同，当LDRA上没有配置IP地址时，它是链路本地作用域地址；和
- the link-address is the Unspecified Address when no IP address is configured on the LDRA.
- 当LDRA上没有配置IP地址时，链路地址是未指定的地址。
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源地址复制到转发到客户端的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 -------| |
+--------+
+--------+
Client -------| |
| Access |
Client -------| Node |-----+
| (LDRA) | |
Client -------| | |
+--------+ |
| +--------+
|------| Server |
| +--------+
+--------+ |
Client -------| | |
| Access | |
Client -------| Node |-----+
| (LDRA) |
Client -------| |
+--------+
<--------- IPv6 Link -------->
<--------- 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：所有DHCP中继代理和服务器
msg-type: RELAY-FORW
消息类型：继电器-FORW
hop-count: 0
跃点计数：0
link-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
消息类型：征求
Solicit Message Options: <from client>
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链路上，由一个或多个中继代理（通常用作路由器）分隔。LDRA将向第二个中继代理向上游发送中继转发消息，第二个中继代理将依次处理这些消息。
+--------+
Client -------| |
| Access |
Client -------| Node |-----+
| (LDRA) | |
Client -------| | |
+--------+ |
| +--------+ +--------+
|------| RelayB |-------| Server |
| +--------+ +--------+
+--------+ |
Client -------| | |
| Access | |
Client -------| Node |-----+
| (LDRA) |
Client -------| |
+--------+
+--------+
Client -------| |
| Access |
Client -------| Node |-----+
| (LDRA) | |
Client -------| | |
+--------+ |
| +--------+ +--------+
|------| RelayB |-------| Server |
| +--------+ +--------+
+--------+ |
Client -------| | |
| Access | |
Client -------| Node |-----+
| (LDRA) |
Client -------| |
+--------+
<------- IPv6 Link A -------> <--IPv6 Link B-->
<------- 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:
例如，如果客户端发送了一条DHCP请求消息，该消息由LDRA中继到另一个中继代理，然后再中继到服务器，则服务器将从LDRA接收以下中继转发消息：
src-ip: relayB
src-ip:relayB
dst-ip: server
dst ip:服务器
msg-type: RELAY-FORW
消息类型：继电器-FORW
hop-count: 1
跳数：1
link-address: relayB address from link A
链路地址：来自链路A的中继地址
peer-address: client link-local address
对等地址：客户端链接本地地址
Relay-Message Option, which contains:
中继消息选项，其中包含：
msg-type: RELAY-FORW
消息类型：继电器-FORW
hop-count: 0
跃点计数：0
link-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
消息类型：征求
Solicit Message Options: <from client>
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链路上，由一个或多个中继代理（通常用作路由器）分隔，LDRA面向客户端的接口上有一个[RFC3315]中继代理。LDRA将向第二个中继代理向上游发送中继转发消息，第二个中继代理将依次处理这些消息。
+--------+
RelayC -------| |
| Access |
RelayC -------| Node |-----+
| (LDRA) | |
RelayC -------| | |
+--------+ |
| +--------+ +--------+
|------| RelayB |-------| Server |
| +--------+ +--------+
+--------+ |
RelayC -------| | |
| Access | |
RelayC -------| Node |-----+
| (LDRA) |
RelayC -------| |
+--------+
+--------+
RelayC -------| |
| Access |
RelayC -------| Node |-----+
| (LDRA) | |
RelayC -------| | |
+--------+ |
| +--------+ +--------+
|------| RelayB |-------| Server |
| +--------+ +--------+
+--------+ |
RelayC -------| | |
| Access | |
RelayC -------| Node |-----+
| (LDRA) |
RelayC -------| |
+--------+
<------- IPv6 Link A -------> <--IPv6 Link B-->
<------- 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:
例如，如果客户端发送了一条DHCP请求消息，该消息由RelayC和LDRA中继到另一个中继代理RelayB，然后发送到服务器，则服务器将收到以下中继转发消息：
src-ip: relayB
src-ip:relayB
dst-ip: server
dst ip:服务器
msg-type: RELAY-FORW
消息类型：继电器-FORW
hop-count: 2
跳数：2
link-address: relayB address from link A
链路地址：来自链路A的中继地址
peer-address: relayC
对等地址：relayC
Relay-Message Option, which contains:
中继消息选项，其中包含：
msg-type: RELAY-FORW
消息类型：继电器-FORW
hop-count: 1
跳数：1
link-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
消息类型：继电器-FORW
hop-count: 0
跃点计数：0
link-address: global or Unspecified_Address
链接地址：全局或未指定的\u地址
peer-address: end client address
对等地址：终端客户端地址
Interface-ID Option: (if required)
接口ID选项：（如果需要）
interface-id: relayC-inserted Interface-ID
接口id:relayC插入的接口id
Relay-Message Option, which contains:
中继消息选项，其中包含：
msg-type: SOLICIT
消息类型：征求
Solicit Message Options: <from end client>
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工作组邮件列表(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上的所有_DHCPv6_服务器_和_中继_代理地址的源自客户端的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]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的动态主机配置协议（DHCPv6）”，RFC3315，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中继代理信息选项”，RFC3046，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（编辑）阿尔卡特朗讯L3/215澳大利亚维多利亚州墨尔本斯普林街3000号
Phone: +61 3 9664 3308
EMail: david.miles@alcatel-lucent.com
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比利时安特卫普
EMail: sven.ooghe@alcatel-lucent.com
EMail: sven.ooghe@alcatel-lucent.com
Wojciech Dec Cisco Systems Haarlerberdweg 13-19 1101 CH Amsterdam, The Netherlands
Wojciech Dec思科系统哈勒贝德韦格13-19 1101荷兰阿姆斯特丹
EMail: wdec@cisco.com
EMail: wdec@cisco.com
Suresh Krishnan Ericsson 8400 Blvd. Decarie Town of Mount Royal, Quebec Canada
Suresh Krishnan Ericsson 8400大道。加拿大魁北克皇家山的迪克里镇
EMail: suresh.krishnan@ericsson.com
EMail: suresh.krishnan@ericsson.com
Alan Kavanagh Ericsson 8400 Blvd. Decarie Town of Mount Royal, Quebec Canada
艾伦·卡瓦纳·爱立信8400大道。加拿大魁北克皇家山的迪克里镇
EMail: alan.kavanagh@ericsson.com
EMail: alan.kavanagh@ericsson.com