Independent Submission B. Sarikaya
Request for Comments: 6653 F. Xia
Category: Informational Huawei USA
ISSN: 2070-1721 T. Lemon
Nominum
July 2012
Independent Submission B. Sarikaya
Request for Comments: 6653 F. Xia
Category: Informational Huawei USA
ISSN: 2070-1721 T. Lemon
Nominum
July 2012
DHCPv6 Prefix Delegation in Long-Term Evolution (LTE) Networks
长期演进（LTE）网络中的DHCPv6前缀委派
Abstract
摘要
As interest in IPv6 deployment in cellular networks increases, several migration issues have been being raised; IPv6 prefix management is the issue addressed in this document. Based on the idea that DHCPv6 servers can manage prefixes, we use DHCPv6 Prefix Delegation to address such prefix management issues as an access router offloading delegation of prefixes and release tasks to a DHCPv6 server. The access router first requests a prefix for an incoming mobile node from the DHCPv6 server. The access router may next do stateless or stateful address allocation to the mobile node, e.g., with a Router Advertisement or using DHCP. We also describe prefix management using Authentication, Authorization, and Accounting (AAA) servers.
随着人们对在蜂窝网络中部署IPv6的兴趣的增加，人们提出了几个迁移问题；IPv6前缀管理是本文档中讨论的问题。基于DHCPv6服务器可以管理前缀的思想，我们使用DHCPv6前缀委派来解决诸如访问路由器卸载前缀委派和向DHCPv6服务器释放任务等前缀管理问题。接入路由器首先从DHCPv6服务器请求传入移动节点的前缀。接入路由器接下来可以对移动节点进行无状态或有状态地址分配，例如，使用路由器广告或使用DHCP。我们还描述了使用身份验证、授权和记帐（AAA）服务器的前缀管理。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
这是对RFC系列的贡献，独立于任何其他RFC流。RFC编辑器已选择自行发布此文档，并且未声明其对实现或部署的价值。RFC编辑批准发布的文件不适用于任何级别的互联网标准；见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/rfc6653.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6653.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction ....................................................3
2. Terminology and Acronyms ........................................4
3. Prefix Delegation Using DHCPv6 ..................................5
3.1. Prefix Request Procedure for Stateless Address
Configuration ..............................................5
3.2. Prefix Request Procedure for Stateful Address
Configuration ..............................................7
3.3. The MN as Requesting Router in Prefix Delegation ...........8
3.4. Prefix Release Procedure ...................................9
3.5. Miscellaneous Considerations ...............................9
3.5.1. How to Generate an IAID .............................9
3.5.2. Policy to Delegate Prefixes ........................10
4. Prefix Delegation Using RADIUS and Diameter ....................10
5. Security Considerations ........................................11
6. Acknowledgements ...............................................12
7. Informative References .........................................12
1. Introduction ....................................................3
2. Terminology and Acronyms ........................................4
3. Prefix Delegation Using DHCPv6 ..................................5
3.1. Prefix Request Procedure for Stateless Address
Configuration ..............................................5
3.2. Prefix Request Procedure for Stateful Address
Configuration ..............................................7
3.3. The MN as Requesting Router in Prefix Delegation ...........8
3.4. Prefix Release Procedure ...................................9
3.5. Miscellaneous Considerations ...............................9
3.5.1. How to Generate an IAID .............................9
3.5.2. Policy to Delegate Prefixes ........................10
4. Prefix Delegation Using RADIUS and Diameter ....................10
5. Security Considerations ........................................11
6. Acknowledgements ...............................................12
7. Informative References .........................................12
Figure 1 illustrates the key elements of a typical cellular access network. In a Long-Term Evolution (LTE) network, the Access Router (AR) is the Packet Data Network (PDN) Gateway [3GPP-23401].
图1说明了典型蜂窝接入网络的关键要素。在长期演进（LTE）网络中，接入路由器（AR）是分组数据网络（PDN）网关[3GPP-23401]。
+-------------+
| +------+ |
| |DHCP | |
+-----+ +-----+ +------+ +------+ | |Server| | +------+
| MN |--| BS |--+Access+--+Access+-+ +------+ +-+Border|
+-----+ +-----+ | GW | |Router| |IP Network(s)| |Router+-Internet
+--+---+ +--+---+ | | +------+
| | +-------------+
+-----+ +-----+ | | +------+
| MN |--| BS |-----+ | |AAA |
+-----+ +-----+ +--- |Server|
+------+
+-------------+
| +------+ |
| |DHCP | |
+-----+ +-----+ +------+ +------+ | |Server| | +------+
| MN |--| BS |--+Access+--+Access+-+ +------+ +-+Border|
+-----+ +-----+ | GW | |Router| |IP Network(s)| |Router+-Internet
+--+---+ +--+---+ | | +------+
| | +-------------+
+-----+ +-----+ | | +------+
| MN |--| BS |-----+ | |AAA |
+-----+ +-----+ +--- |Server|
+------+
Figure 1: Key Elements of a Typical Cellular Network
图1：典型蜂窝网络的关键要素
The Mobile Node (MN) attaches to a Base Station (BS) through an LTE air interface. A BS manages connectivity of User Equipment (UE) and extends connections to an Access Gateway (GW), e.g., the Serving Gateway (S-GW) in an LTE network. The access GW and the AR are connected via an IP network. The AR is the first-hop router of the MNs and is in charge of address/prefix management.
移动节点（MN）通过LTE空中接口连接到基站（BS）。BS管理用户设备（UE）的连接并扩展到接入网关（GW）的连接，例如LTE网络中的服务网关（S-GW）。接入GW和AR通过IP网络连接。AR是MNs的第一跳路由器，负责地址/前缀管理。
The AR is connected to an IP network that is owned by the operator; this network is connected to the public Internet via a border router. The network contains servers for subscriber management, including Quality of Service, billing, and accounting, as well as a Dynamic Host Configuration Protocol (DHCP) server [RFC6342].
AR连接到运营商拥有的IP网络；该网络通过边界路由器连接到公共互联网。该网络包含用于用户管理的服务器，包括服务质量、计费和记帐，以及动态主机配置协议（DHCP）服务器[RFC6342]。
With IPv6 addressing, because mobile network links are point-to-point (P2P), the per-MN interface prefix model is used [RFC3314] [RFC3316]. In the per-MN interface prefix model, prefix management is an issue.
对于IPv6寻址，由于移动网络链路是点对点（P2P），因此使用每MN接口前缀模型[RFC3314][RFC3316]。在per MN接口前缀模型中，前缀管理是一个问题。
When an MN attaches to an AR, the AR requests one or more prefixes for the MN. When the MN detaches from the AR, the prefixes should be released. When the MN becomes idle, the AR should keep (i.e., not release) the allocated prefixes.
当MN连接到AR时，AR为MN请求一个或多个前缀。当MN从AR分离时，前缀应该被释放。当MN变为空闲时，AR应保持（即，不释放）分配的前缀。
This document describes how to use DHCPv6 Prefix Delegation (DHCPv6-PD) in mobile networks, such as networks based on standards developed by the 3rd Generation Partnership Project (3GPP) and it could easily be adopted by the Worldwide Interoperability for Microwave Access (WiMAX) Forum as well. In view of migration to
本文档描述了如何在移动网络中使用DHCPv6前缀委派（DHCPv6 PD），例如基于第三代合作伙伴关系项目（3GPP）开发的标准的网络，它也可以很容易地被全球微波接入互操作性（WiMAX）论坛采用。鉴于移民到
IPv6, the number of MNs connected to the network at a given time may become very high. Traditional techniques such as prefix pools are not scalable. In such cases, DHCPv6-PD becomes the viable approach to take.
在IPv6中，在给定时间连接到网络的MN数量可能会非常高。前缀池等传统技术是不可伸缩的。在这种情况下，DHCPv6 PD成为可行的方法。
The techniques described in this document have not been approved by the IETF or the 3GPP, except for those techniques described below in Section 3.3. This document is not a Standard or Best Current Practice. This document is published only for possible consideration by operators.
本文件中描述的技术尚未得到IETF或3GPP的批准，以下第3.3节中描述的技术除外。本文件不是标准或最佳现行做法。本文件仅供运营商参考。
This document is useful when address space needs to be managed by DHCPv6-PD. There are obviously other means of managing address space, including having the AR track internally what address space is used by what mobile.
当地址空间需要由DHCPv6 PD管理时，本文档非常有用。显然还有其他管理地址空间的方法，包括让AR在内部跟踪移动设备使用的地址空间。
3GPP - 3rd Generation Partnership Project
3GPP-第三代合作伙伴项目
AAA - Authentication, Authorization, and Accounting
AAA-身份验证、授权和记帐
AR - Access Router
接入路由器
BS - Base Station
基站
DHCP - Dynamic Host Configuration Protocol
动态主机配置协议
E-UTRAN - Evolved Universal Terrestrial Radio Access Network
E-UTRAN-演进的通用地面无线接入网
GPRS - General Packet Radio Service
通用分组无线业务
LTE - Long-Term Evolution
LTE-长期演进
MN - Mobile Node
移动节点
P2P - Point-to-Point
点对点
PD - Prefix Delegation
PD-前缀委托
PDN - Packet Data Network
分组数据网
S-GW - Serving Gateway
服务网关
WiMAX - Worldwide Interoperability for Microwave Access
WiMAX-微波接入的全球互操作性
"Access router" refers to the cellular network entity that has a DHCP client. According to [3GPP-23401], the DHCP client is located in the PDN Gateway, and so the AR is the PDN Gateway in the LTE architecture.
“接入路由器”指具有DHCP客户端的蜂窝网络实体。根据[3GPP-23401]，DHCP客户端位于PDN网关中，因此AR是LTE架构中的PDN网关。
There are two function modules in the AR: the DHCP client and the DHCP relay. DHCP messages should be relayed if the AR and a DHCP server are not directly connected; otherwise, the DHCP relay function in the AR is not necessary. Figure 2 illustrates a scenario in which the AR and the DHCP server aren't directly connected:
AR中有两个功能模块：DHCP客户端和DHCP中继。如果AR和DHCP服务器未直接连接，则应中继DHCP消息；否则，AR中的DHCP中继功能是不必要的。图2说明了AR和DHCP服务器不直接连接的场景：
+-------+ +----------------------+ +-----------+
| MN | | AR | |DHCP Server|
+-------+ |DHCP | Relay | +-----------+
| |Client | Agent | |
| +----------------------+ |
|1 Initial NW entry | |
|or attach procedure| |
|<----------------->| |
| |2 Solicit |
| |---------> Relay-forward |
| | --------------->|
| | 3 Relay-reply |
| |Advertise <---------------|
| |<-------- |
| |4 Request |
| |---------> Relay-forward |
| | --------------->|
| | 5 Relay-reply |
| |Reply <---------------|
| |<-------- |
|6 Attach | |
| Completed | |
|<----------------->| |
|7 Router | |
| Solicitation | |
|------------------>| |
| 8 Router | |
| Advertisement | |
|<------------------| |
+-------+ +----------------------+ +-----------+
| MN | | AR | |DHCP Server|
+-------+ |DHCP | Relay | +-----------+
| |Client | Agent | |
| +----------------------+ |
|1 Initial NW entry | |
|or attach procedure| |
|<----------------->| |
| |2 Solicit |
| |---------> Relay-forward |
| | --------------->|
| | 3 Relay-reply |
| |Advertise <---------------|
| |<-------- |
| |4 Request |
| |---------> Relay-forward |
| | --------------->|
| | 5 Relay-reply |
| |Reply <---------------|
| |<-------- |
|6 Attach | |
| Completed | |
|<----------------->| |
|7 Router | |
| Solicitation | |
|------------------>| |
| 8 Router | |
| Advertisement | |
|<------------------| |
Figure 2: Prefix Request
图2：前缀请求
1. An MN (also referred to as UE, or User Equipment, by the 3GPP) performs initial network entry and authentication procedures, a.k.a. the attach procedure.
1. MN（3GPP也称为UE或用户设备）执行初始网络进入和认证过程，即连接过程。
2. On successful completion of Step 1, the AR initiates the DHCP Solicit procedure to request prefixes for the MN. The DHCP client in the AR creates and transmits a Solicit message as described in Sections 17.1.1 ("Creation of Solicit Messages") and 17.1.2 ("Transmission of Solicit Messages") of [RFC3315]. The DHCP client in an AR that supports DHCPv6 Prefix Delegation [RFC3633] creates an Identity Association for Prefix Delegation (IA_PD) and assigns it an Identity Association IDentifier (IAID). The client must include the IA_PD option in the Solicit message. The DHCP client as Requesting Router (RR) must set the prefix-length field to a value less than, e.g., 48 or equal to 64 to request a /64 prefix. Next, the relay agent in the AR sends to the DHCP server a Relay-forward message in which a Solicit message is encapsulated.
2. 在成功完成步骤1时，AR启动DHCP请求过程以请求MN的前缀。AR中的DHCP客户端创建并传输请求消息，如[RFC3315]第17.1.1节（“请求消息的创建”）和第17.1.2节（“请求消息的传输”）所述。支持DHCPv6前缀委派[RFC3633]的AR中的DHCP客户端为前缀委派创建标识关联（IA_PD），并为其分配标识关联标识符（IAID）。客户机必须在请求消息中包含IA_PD选项。DHCP客户端作为请求路由器（RR）必须将前缀长度字段设置为小于，例如48或等于64的值，才能请求/64前缀。接下来，AR中的中继代理向DHCP服务器发送中继转发消息，其中封装了请求消息。
3. The DHCP server sends an Advertise message to the AR in the same way as that described in Section 17.2.2 ("Creation and Transmission of Advertise Messages") of [RFC3315]. An Advertise message with the IA_PD shows that the DHCP server is capable of delegating prefixes. This message is received encapsulated in a Relay-reply message by the relay agent in the AR and is sent as an Advertise message to the DHCP client in the AR.
3. DHCP服务器向AR发送播发消息的方式与[RFC3315]第17.2.2节（“播发消息的创建和传输”）中所述的方式相同。带有IA_PD的播发消息表明DHCP服务器能够委派前缀。此消息由AR中的中继代理接收并封装在中继回复消息中，并作为播发消息发送到AR中的DHCP客户端。
4. The AR (DHCP client and relay agent) uses the same message exchanges as those described in Section 18 ("DHCP Client-Initiated Configuration Exchange") of [RFC3315] and in [RFC3633] to obtain or update prefixes from the DHCP server. The AR (DHCP client and relay agent) and the DHCP server use the IA_PD Prefix option to exchange information about prefixes in much the same way as IA Address options are used for assigned addresses. This is accomplished by the AR sending a DHCP Request message and the DHCP server sending a DHCP Reply message.
4. AR（DHCP客户端和中继代理）使用与[RFC3315]第18节（“DHCP客户端启动的配置交换”）和[RFC3633]中所述相同的消息交换来从DHCP服务器获取或更新前缀。AR（DHCP客户端和中继代理）和DHCP服务器使用IA_PD Prefix选项交换有关前缀的信息，其方式与IA Address选项用于分配地址的方式大致相同。这是通过AR发送DHCP请求消息和DHCP服务器发送DHCP回复消息来实现的。
5. The AR stores the prefix information it received in the Reply message.
5. AR将收到的前缀信息存储在回复消息中。
6. A connection between the MN and AR is established, and the link becomes active. This step completes the Packet Data Protocol (PDP) Context Activation Procedure in Universal Mobile Telecommunications System (UMTS) and PDN connection establishment in LTE networks.
6. 在MN和AR之间建立连接，并且链路变为活动的。此步骤完成通用移动通信系统（UMTS）中的分组数据协议（PDP）上下文激活过程和LTE网络中的PDN连接建立。
7. The MN may send a Router Solicitation message to solicit the AR to send a Router Advertisement (RA) message.
7. MN可以发送路由器请求消息以请求AR发送路由器广告（RA）消息。
8. The AR advertises the prefixes received in the IA_PD option to the MN via an RA once the PDP Context/PDN connection is established, or in response to a Router Solicitation message sent from the MN.
8. 一旦PDP上下文/PDN连接建立，或者响应于从MN发送的路由器请求消息，AR通过RA向MN播发在IA_PD选项中接收的前缀。
The 4-way exchange between the AR as RR and the DHCP server as Delegating Router (DR), as shown in Figure 2, may be reduced to a two-message exchange by using the Rapid Commit option [RFC3315]. The DHCP client in the AR acting as RR includes a Rapid Commit option in the Solicit message. The DR then sends a Reply message containing one or more prefixes.
如图2所示，AR as RR和DHCP服务器as委派路由器（DR）之间的4路交换可以通过使用快速提交选项[RFC3315]简化为两条消息交换。AR中充当RR的DHCP客户端在请求消息中包含一个快速提交选项。DR然后发送包含一个或多个前缀的回复消息。
Stateful address configuration requires a different architecture than that shown in Figure 2; in this type of configuration, there are two function modules in the AR: the DHCP server and the DHCP client.
有状态地址配置需要与图2所示不同的体系结构；在这种类型的配置中，AR中有两个功能模块：DHCP服务器和DHCP客户端。
After the initial attach is completed, a connection to the AR is established for the MN. The DHCP client function at the AR as RR and the DHCP server as DR follow Steps 2 through 5 of the procedure shown in Figure 2 to get the new prefix for this interface of the MN from the IA_PD option exchange defined in [RFC3633].
初始连接完成后，将为MN建立到AR的连接。AR as RR和DHCP服务器as DR上的DHCP客户端功能遵循图2所示过程的步骤2至步骤5，从[RFC3633]中定义的IA_PD选项交换中获取MN此接口的新前缀。
The DHCPv6 client at the MN sends the DHCP Request to the AR. The DHCP server function at the AR must use the IA_PD option received in the DHCPv6-PD exchange to assign an address to the MN. The IA_PD option must contain the prefix. The AR sends to the MN a DHCP Reply message containing the IA address option (IAADDR). Figure 3 shows the message sequence.
MN处的DHCPv6客户端向AR发送DHCP请求。AR处的DHCP服务器功能必须使用DHCPv6 PD交换中接收到的IA_PD选项为MN分配地址。IA_PD选项必须包含前缀。AR向MN发送包含IA地址选项（IAADDR）的DHCP回复消息。图3显示了消息序列。
The MN configures its interface with the address assigned by the DHCP server in the DHCP Reply message.
MN使用DHCP服务器在DHCP应答消息中分配的地址配置其接口。
In Figure 3, the AR may be the home gateway of a fixed network to which the MN gets connected during the MN's handover.
在图3中，AR可以是在MN的切换期间MN连接到的固定网络的家庭网关。
+----------+ +--------------+ +-----------+
| MN | | AR | |DHCP Server|
| |DHCP | | DHCP |DHCP | +-----------+
| |Client| |Server|Client |
+----------+ +--------------+
| Initial NW entry | |
|or attach procedure | |
|<-----------------> | |
| | DHCPv6-PD exchange |
| | similar to Steps 2-5 |
| Solicit | of Figure 2 (IA_PD) |
|---------------------->| |
| Advertise | |
|<----------------------| |
| Request | |
|---------------------->| |
| | |
| | |
| | Use prefix in IA_PD |
| Reply | to assign IAADDR |
|<--------------------- | |
+----------+ +--------------+ +-----------+
| MN | | AR | |DHCP Server|
| |DHCP | | DHCP |DHCP | +-----------+
| |Client| |Server|Client |
+----------+ +--------------+
| Initial NW entry | |
|or attach procedure | |
|<-----------------> | |
| | DHCPv6-PD exchange |
| | similar to Steps 2-5 |
| Solicit | of Figure 2 (IA_PD) |
|---------------------->| |
| Advertise | |
|<----------------------| |
| Request | |
|---------------------->| |
| | |
| | |
| | Use prefix in IA_PD |
| Reply | to assign IAADDR |
|<--------------------- | |
Figure 3: Stateful Address Configuration Following PD
图3:PD后的有状态地址配置
The AR may use a DHCPv6 Prefix Delegation exchange to get a delegated prefix shorter than /64 by setting the prefix-length field to a value less than 64, e.g., 56 to get a /56 prefix. Each newly attaching MN first goes through the steps in Figure 2, in which the AR requests a shorter prefix to establish a default connection with the MN.
AR可以通过将前缀长度字段设置为小于64的值（例如，56以获得/56前缀），使用DHCPv6前缀委派交换来获得短于/64的委派前缀。每个新连接的MN首先经历图2中的步骤，其中AR请求一个较短的前缀以建立与MN的默认连接。
The MN may next request additional prefixes (/64 or shorter) from the AR using DHCPv6 Prefix Delegation, where the MN is the RR and the AR is the DR (see [RFC6459] and Section 5.3.1.2.6 of [3GPP-23401]). In this case, the call flow is similar to that shown in Figure 3. The Solicit message must include the IA_PD option with the prefix-length field set to 64. The MN may request more than one /64 prefix. The AR as DR must delegate these prefixes, excluding the prefix assigned to the default connection.
MN接下来可以使用DHCPv6前缀委托从AR请求附加前缀（/64或更短），其中MN是RR，AR是DR（参见[RFC6459]和[3GPP-23401]第5.3.1.2.6节）。在这种情况下，调用流类似于图3所示。请求消息必须包含IA_PD选项，前缀长度字段设置为64。MN可以请求多于一个/64前缀。AR as DR必须委派这些前缀，不包括分配给默认连接的前缀。
Prefixes can be released in two ways: via prefix aging, or via the DHCP release procedure. In prefix aging, a prefix should not be used by an MN when the prefix ages, and the DHCP server can delegate it to another MN. A prefix lifetime is delivered from the DHCPv6 server to the MN via the DHCP IA_PD Prefix option [RFC3633] and the RA Prefix Information option [RFC4861]. Figure 4 illustrates how the AR releases prefixes to a DHCP server that isn't directly connected to the AR:
前缀可以通过两种方式释放：通过前缀老化，或通过DHCP释放过程。在前缀老化中，当前缀老化时，MN不应使用前缀，DHCP服务器可以将其委托给另一个MN。前缀生存期通过DHCP IA_PD前缀选项[RFC3633]和RA前缀信息选项[RFC4861]从DHCPv6服务器传递到MN。图4说明了AR如何向未直接连接到AR的DHCP服务器释放前缀：
1. A signal that an MN has detached, such as switch-off or handover, triggers the prefix release procedure.
1. MN已分离的信号（如关闭或切换）触发前缀释放过程。
2. The AR initiates a Release message to give the prefixes back to the DHCP server.
2. AR启动一条释放消息，将前缀返回给DHCP服务器。
3. The server responds with a Reply message. The prefixes can then be reused by other MNs.
3. 服务器以回复消息进行响应。然后，前缀可以被其他MN重用。
+-------+ +-------+ +-----------+
| MN | | AR | |DHCP Server|
+-------+ +-------+ +-----------+
| | |
| 1 De-registration | |
| handover, or other | |
|<--------------------->| |
| |2 Relay-forward/Release|
| |---------------------->|
| | |
| |3 Relay-reply/Reply |
| |<--------------------- |
| | |
| | |
+-------+ +-------+ +-----------+
| MN | | AR | |DHCP Server|
+-------+ +-------+ +-----------+
| | |
| 1 De-registration | |
| handover, or other | |
|<--------------------->| |
| |2 Relay-forward/Release|
| |---------------------->|
| | |
| |3 Relay-reply/Reply |
| |<--------------------- |
| | |
| | |
Figure 4: Prefix Release
图4：前缀释放
The IAID is 4 bytes in length and should be unique in the scope of an AR. The prefix table should be maintained; this table contains the IAID, the Media Access Control (MAC) address, and the prefix(es) assigned to the MN. In LTE networks, the International Mobile Equipment Identity (IMEI) uniquely identifies the MN's interface and
IAID的长度为4字节，在AR范围内应是唯一的。应维护前缀表；此表包含分配给MN的IAID、媒体访问控制（MAC）地址和前缀。在LTE网络中，国际移动设备标识（IMEI）唯一地标识MN的接口和端口
thus corresponds to the MAC address. The MAC address of the interface should be stored in the prefix table and is used as the key for searching the table.
因此对应于MAC地址。接口的MAC地址应存储在前缀表中，并用作搜索表的键。
The IAID should be set to Start_IAID; Start_IAID is an integer of 4 octets. The following algorithm is used to generate the IAID:
IAID应设置为Start_IAID；Start_IAID是4个八位字节的整数。以下算法用于生成IAID：
1. Set this IAID value in the IA_PD Prefix option. Request a prefix for this MN as described in Section 3.1 or Section 3.2.
1. 在IA_PD Prefix选项中设置此IAID值。如第3.1节或第3.2节所述，请求此MN的前缀。
2. Store the IAID, MAC address, and received prefix(es) in the next entry of the prefix table.
2. 将IAID、MAC地址和接收到的前缀存储在前缀表的下一个条目中。
3. Increment the IAID.
3. 增加IAID。
A prefix table entry for an MN that hands over to another AR must be removed. The IAID value is released and can then be reused.
必须删除移交给另一AR的MN的前缀表项。IAID值被释放，然后可以重新使用。
In P2P links, if /64 prefixes of all MNs connected to one or more ARs are broadcast dynamically upstream as route information, high routing-protocol traffic (IGP, OSPF, etc.) due to per-MN interface prefixes will result. There are two solutions to this problem. One solution is to use static configuration, which would be preferable in many cases. No routing protocols are needed, because each AR has a known piece of address space. If the DHCP servers also know that address space, then they will assign to a particular AR a prefix from that space.
在P2P链路中，如果连接到一个或多个ar的所有MN的/64前缀作为路由信息被动态地向上游广播，则会由于每个MN接口前缀而导致高路由协议流量（IGP、OSPF等）。这个问题有两种解决方案。一种解决方案是使用静态配置，这在许多情况下更可取。不需要路由协议，因为每个AR都有一个已知的地址空间。如果DHCP服务器也知道该地址空间，则它们将从该空间向特定AR分配前缀。
The other solution is to use route aggregation. For example, each AR can be assigned a /48 or /32 prefix (an aggregate prefix, a.k.a service provider common prefix), while each interface of an MN can be assigned a /64 prefix. The /64 prefix is an extension of the /48 prefix -- for example, an AR's /48 prefix is 2001:db8:0::/48 -- while an interface of the MN is assigned a 2001:db8:0:2::/64 prefix. The border router in Figure 1 may be manually configured to broadcast only an individual AR's /48 or /32 prefix information to the Internet.
另一种解决方案是使用路由聚合。例如，可以为每个AR分配/48或/32前缀（聚合前缀，也称为服务提供商公共前缀），而为MN的每个接口分配/64前缀。/64前缀是/48前缀的扩展，例如，AR的/48前缀是2001:db8:0:：/48，而MN的接口被分配了2001:db8:0:2:：/64前缀。图1中的边界路由器可以手动配置为仅向互联网广播单个AR的/48或/32前缀信息。
In the initial network entry procedure shown in Figure 2, the AR as Remote Authentication Dial In User Service (RADIUS) client sends an Access-Request message with MN information to the RADIUS server. If the MN passes the authentication, the RADIUS server may send an Access-Accept message with prefix information to the AR using the Framed-IPv6-Prefix attribute. The AAA server also provides routing
在图2所示的初始网络进入过程中，AR as远程身份验证拨入用户服务（RADIUS）客户端向RADIUS服务器发送带有MN信息的访问请求消息。如果MN通过认证，RADIUS服务器可以使用Framed-IPv6-prefix属性向AR发送带有前缀信息的访问接受消息。AAA服务器还提供路由
information to be configured for the MN on the AR using the Framed-IPv6-Route attribute. Using such a process, the AR can handle initial prefix assignments to MNs, but managing the lifetime of the prefixes is totally left to the AR. The Framed-IPv6-Prefix is not designed to support delegation of IPv6 prefixes. For this situation, the Delegated-IPv6-Prefix attribute, which is discussed below, can be used.
要使用Framed-IPv6-Route属性为AR上的MN配置的信息。使用这种过程，AR可以处理到MNs的初始前缀分配，但前缀的生存期完全由AR管理。Framed-IPv6-prefix的设计不支持IPv6前缀的委派。对于这种情况，可以使用下面讨论的Delegated-IPv6-Prefix属性。
[RFC4818] defines a RADIUS attribute, Delegated-IPv6-Prefix, which carries an IPv6 prefix to be delegated. This attribute is usable within either RADIUS or Diameter. [RFC4818] recommends that the DR use the AAA server to receive the prefixes to be delegated, by using the Delegated-IPv6-Prefix attribute/Attribute-Value Pair (AVP).
[RFC4818]定义RADIUS属性Delegated-IPv6-Prefix，该属性携带要委派的IPv6前缀。此属性在半径或直径范围内可用。[RFC4818]建议DR使用AAA服务器，通过使用delegated-IPv6-Prefix属性/属性值对（AVP）来接收要委派的前缀。
The DHCP server as DR, as shown in Figure 2, may send an Access-Request packet containing the Delegated-IPv6-Prefix attribute to the RADIUS server to request prefixes. In the Access-Request message, the DR may provide a hint that it would prefer a prefix -- for example, a /48 prefix. As the RADIUS server is not required to honor the hint, the server may delegate a longer prefix -- e.g., /56 or /64 -- in an Access-Accept message containing the Delegated-IPv6-Prefix attribute [RFC4818]. The attribute can appear multiple times when the RADIUS server delegates multiple prefixes to the DR. The DR sends the prefixes to the RR using the IA_PD option, and the AR as RR uses them for MNs, as described in Section 3.
如图2所示，作为DR的DHCP服务器可以向RADIUS服务器发送包含Delegated-IPv6-Prefix属性的访问请求数据包，以请求前缀。在访问请求消息中，DR可能会提供一个提示，表示它更喜欢前缀——例如，a/48前缀。由于RADIUS服务器不需要接受提示，因此服务器可以在包含Delegated-IPv6-prefix属性[RFC4818]的访问接受消息中委托更长的前缀，例如/56或/64。当RADIUS服务器将多个前缀委托给DR时，该属性可能会出现多次。DR使用IA_PD选项将前缀发送给RR，AR as RR将前缀用于MNs，如第3节所述。
When Diameter is used, the DHCP server as DR, as shown in Figure 2, sends an AA-Request message. The AA-Request message may contain a Delegated-IPv6-Prefix AVP. The Diameter server replies with an AA-Answer message. The AA-Answer message may contain a Delegated-IPv6-Prefix AVP. The AVP can appear multiple times when the Diameter server assigns multiple prefixes to an MN. The Delegated-IPv6-Prefix AVP may appear in an AA-Request packet as a hint from the AR to the Diameter server that it would prefer a prefix -- for example, a /48 prefix. The Diameter server may delegate in the AA-Answer message a /64 prefix, which is an extension of the /48 prefix. As in the case of RADIUS, the DR sends the prefixes to the RR using the IA_PD option, and the AR as RR uses them for the MNs as described in Section 3.
当使用Diameter时，DHCP服务器作为DR发送一条AA请求消息，如图2所示。AA请求消息可能包含委派的IPv6前缀AVP。Diameter服务器回复AA应答消息。AA应答消息可能包含委派的IPv6前缀AVP。当Diameter服务器为MN分配多个前缀时，AVP可能会出现多次。Delegated-IPv6-Prefix AVP可能出现在AA请求数据包中，作为AR向Diameter服务器发出的提示，表示它更喜欢前缀，例如/48前缀。Diameter服务器可以在AA应答消息中委派/64前缀，这是/48前缀的扩展。与RADIUS的情况一样，DR使用IA_PD选项将前缀发送给RR，AR As RR将前缀用于MNs，如第3节所述。
This document does not introduce any additional message types and therefore does not introduce any additional threats. The security procedures for DHCPv6 [RFC3633], RADIUS [RFC2865], and Diameter [RFC3588] apply.
本文档不会引入任何其他消息类型，因此不会引入任何其他威胁。DHCPv6[RFC3633]、半径[RFC2865]和直径[RFC3588]的安全程序适用。
We are grateful to Suresh Krishnan, Hemant Singh, Qiang Zhao, Ole Troan, Qin Wu, Jouni Korhonen, Cameron Byrne, Brian Carpenter, Jari Arkko, and Jason Lin, whose in-depth reviews of this document led to several improvements.
我们感谢Suresh Krishnan、Hemant Singh、Zhaang Zhao、Ole Troan、Qin Wu、Jouni Korhonen、Cameron Byrne、Brian Carpenter、Jari Arkko和Jason Lin，他们对本文件的深入审查带来了几项改进。
[3GPP-23401] 3GPP, "General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access (Release 11)", TS 23.401 V11.0.0, December 2011.
[3GPP-23401]3GPP，“通用分组无线业务（GPRS）对演进型通用地面无线接入网（E-UTRAN）接入的增强（第11版）”，TS 23.401 V11.0.012011年12月。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2865]Rigney，C.，Willens，S.，Rubens，A.，和W.Simpson，“远程认证拨入用户服务（RADIUS）”，RFC 28652000年6月。
[RFC3314] Wasserman, M., "Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards", RFC 3314, September 2002.
[RFC3314]Wasserman，M.，“第三代合作伙伴项目（3GPP）标准中IPv6的建议”，RFC 3314，2002年9月。
[RFC3315] Droms, R., 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.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC3315，2003年7月。
[RFC3316] Arkko, J., Kuijpers, G., Soliman, H., Loughney, J., and J. Wiljakka, "Internet Protocol Version 6 (IPv6) for Some Second and Third Generation Cellular Hosts", RFC 3316, April 2003.
[RFC3316]Arkko，J.，Kuijpers，G.，Soliman，H.，Loughney，J.，和J.Wiljakka，“一些第二代和第三代蜂窝主机的互联网协议版本6（IPv6）”，RFC 3316，2003年4月。
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3588]Calhoun，P.，Loughney，J.，Guttman，E.，Zorn，G.，和J.Arkko，“直径基础协议”，RFC 3588，2003年9月。
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003.
[RFC3633]Troan，O.和R.Droms，“动态主机配置协议（DHCP）版本6的IPv6前缀选项”，RFC 3633，2003年12月。
[RFC4818] Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix Attribute", RFC 4818, April 2007.
[RFC4818]Salowey，J.和R.Droms，“RADIUS-IPv6-Prefix属性”，RFC 4818，2007年4月。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861]Narten，T.，Nordmark，E.，Simpson，W.，和H.Soliman，“IP版本6（IPv6）的邻居发现”，RFC 48612007年9月。
[RFC6342] Koodli, R., "Mobile Networks Considerations for IPv6 Deployment", RFC 6342, August 2011.
[RFC6342]Koodli，R.，“IPv6部署的移动网络注意事项”，RFC 63422011年8月。
[RFC6459] Korhonen, J., Ed., Soininen, J., Patil, B., Savolainen, T., Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Packet System (EPS)", RFC 6459, January 2012.
[RFC6459]Korhonen，J.，Ed.，Soininen，J.，Patil，B.，Savolainen，T.，Bajko，G.，和K.Iisakkila，“第三代合作伙伴关系项目（3GPP）中的IPv6演进包系统（EPS）”，RFC 6459，2012年1月。
Authors' Addresses
作者地址
Behcet Sarikaya Huawei USA 5340 Legacy Dr. Plano, TX 75074
Behcet Sarikaya华为美国5340 Legacy Dr.Plano，德克萨斯州75074
EMail: sarikaya@ieee.org
EMail: sarikaya@ieee.org
Frank Xia Huawei USA 1700 Alma Drive, Suite 500 Plano, TX 75075
美国德克萨斯州普莱诺市阿尔玛大道1700号500室华为Frank Xia 75075
Phone: +1 972-509-5599
EMail: xiayangsong@huawei.com
Phone: +1 972-509-5599
EMail: xiayangsong@huawei.com
Ted Lemon Nominum 2000 Seaport Blvd. Redwood City, CA 94063
泰德·莱蒙·诺米姆海港大道2000号。加利福尼亚州红木市，94063
EMail: mellon@nominum.com
EMail: mellon@nominum.com