Network Working Group A. Yegin, Ed.
Request for Comments: 4058 Samsung AIT
Category: Informational Y. Ohba
Toshiba
R. Penno
Juniper Networks
G. Tsirtsis
Flarion
C. Wang
ARO/NCSU
May 2005
Network Working Group A. Yegin, Ed.
Request for Comments: 4058 Samsung AIT
Category: Informational Y. Ohba
Toshiba
R. Penno
Juniper Networks
G. Tsirtsis
Flarion
C. Wang
ARO/NCSU
May 2005
Protocol for Carrying Authentication for Network Access (PANA) Requirements
承载网络访问认证（PANA）要求的协议
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
It is expected that future IP devices will have a variety of access technologies to gain network connectivity. Currently there are access-specific mechanisms for providing client information to the network for authentication and authorization purposes. In addition to being limited to specific access media (e.g., 802.1X for IEEE 802 links), some of these protocols are limited to specific network topologies (e.g., PPP for point-to-point links). The goal of this document is to identify the requirements for a link-layer agnostic protocol that allows a host and a network to authenticate each other for network access. This protocol will run between a client's device and an agent in the network where the agent might be a client of the AAA infrastructure.
预计未来的IP设备将拥有多种接入技术以获得网络连接。目前，有一些特定于访问的机制，用于向网络提供客户端信息以进行身份验证和授权。除了限于特定的接入媒体（例如，IEEE 802链路的802.1X），其中一些协议还限于特定的网络拓扑（例如，点到点链路的PPP）。本文档的目标是确定链路层不可知协议的要求，该协议允许主机和网络相互验证网络访问。此协议将在客户端设备和网络中的代理之间运行，该代理可能是AAA基础设施的客户端。
Table of Contents
目录
1. Introduction ....................................................3
2. Requirements Notation ...........................................3
3. Terminology .....................................................4
4. Requirements ....................................................4
4.1. Authentication .............................................4
4.1.1. Authentication of Client ............................4
4.1.2. Authorization, Accounting, and Access Control .......6
4.1.3. Authentication Backend ..............................7
4.1.4. Identifiers .........................................7
4.2. IP Address Assignment ......................................7
4.3. EAP Lower Layer Requirements ...............................7
4.4. PAA-to-EP Protocol .........................................8
4.5. Network ....................................................8
4.5.1. Multi-access ........................................8
4.5.2. Disconnect Indication ...............................8
4.5.3. Location of PAA .....................................9
4.5.4. Secure Channel ......................................9
4.6. Interaction with Other Protocols ..........................10
4.7. Performance ...............................................10
4.8. Congestion Control ........................................10
4.9. IP Version Independence ...................................10
4.10. Denial of Service Attacks ................................10
4.11. Client Identity Privacy ..................................10
5. Security Considerations ........................................11
6. Acknowledgements ...............................................11
A. Problem Statement ..............................................12
B. Usage Scenarios ................................................13
References ........................................................16
Normative References ...........................................16
Informative References .........................................16
1. Introduction ....................................................3
2. Requirements Notation ...........................................3
3. Terminology .....................................................4
4. Requirements ....................................................4
4.1. Authentication .............................................4
4.1.1. Authentication of Client ............................4
4.1.2. Authorization, Accounting, and Access Control .......6
4.1.3. Authentication Backend ..............................7
4.1.4. Identifiers .........................................7
4.2. IP Address Assignment ......................................7
4.3. EAP Lower Layer Requirements ...............................7
4.4. PAA-to-EP Protocol .........................................8
4.5. Network ....................................................8
4.5.1. Multi-access ........................................8
4.5.2. Disconnect Indication ...............................8
4.5.3. Location of PAA .....................................9
4.5.4. Secure Channel ......................................9
4.6. Interaction with Other Protocols ..........................10
4.7. Performance ...............................................10
4.8. Congestion Control ........................................10
4.9. IP Version Independence ...................................10
4.10. Denial of Service Attacks ................................10
4.11. Client Identity Privacy ..................................10
5. Security Considerations ........................................11
6. Acknowledgements ...............................................11
A. Problem Statement ..............................................12
B. Usage Scenarios ................................................13
References ........................................................16
Normative References ...........................................16
Informative References .........................................16
Secure network access service requires access control based on the authentication and authorization of the clients and the access networks. Initial and subsequent client-to-network authentication provides parameters that are needed to police the traffic flow through the enforcement points. A protocol is needed to carry authentication parameters between the client and the access network. See Appendix A for the associated problem statement.
安全网络访问服务要求基于客户端和访问网络的身份验证和授权进行访问控制。初始和后续客户端到网络身份验证提供了监控通过实施点的流量所需的参数。在客户端和接入网络之间需要一个协议来承载身份验证参数。有关相关问题说明，请参见附录A。
The protocol design will be limited to defining a messaging protocol (i.e., a carrier) that will allow authentication payload to be carried between the host/client and an agent/server in the access network for authentication and authorization purposes regardless of the AAA infrastructure that may (or may not) reside on the network. As a network-layer protocol, it will be independent of the underlying access technologies and applicable to any network topology.
协议设计将限于定义消息传递协议（即，载波），该协议将允许出于认证和授权目的在接入网络中的主机/客户端和代理/服务器之间携带认证有效载荷，而不管网络上可能（或可能不）驻留的AAA基础设施。作为网络层协议，它将独立于底层访问技术，并适用于任何网络拓扑。
The intent is not to invent new security protocols and mechanisms but to reuse existing mechanisms such as EAP [RFC3748]. In particular, the requirements do not mandate the need to define new authentication protocols (e.g., EAP-TLS [RFC2716]), key distribution or key agreement protocols, or key derivation methods. The desired protocol can be viewed as the front-end of the AAA protocol or any other protocol/mechanisms the network is running at the background to authenticate its clients. It will act as a carrier for an already defined security protocol or mechanism.
其目的不是发明新的安全协议和机制，而是重用现有机制，如EAP[RFC3748]。具体而言，这些要求并不要求定义新的认证协议（例如EAP-TLS[RFC2716]）、密钥分发或密钥协议协议或密钥派生方法。所需的协议可以被视为AAA协议的前端或网络在后台运行以验证其客户端的任何其他协议/机制。它将作为已经定义的安全协议或机制的载体。
An example of a protocol being extended for use in authenticating a host for network access is Mobile IPv4. A Mobile IPv4 registration request message is used as a carrier for authentication extensions (MN-FA [RFC3344] or MN-AAA [RFC3012]) that allows a foreign agent to authenticate mobile nodes before providing forwarding service. The goal of PANA is similar in that it aims to define a network-layer transport for authentication information. However, PANA will be decoupled from mobility management and will rely on other specifications for the definition of authentication payloads.
移动IPv4是一个扩展协议的示例，用于对主机进行网络访问身份验证。移动IPv4注册请求消息用作身份验证扩展（MN-FA[RFC3344]或MN-AAA[RFC3012]）的载体，该扩展允许外部代理在提供转发服务之前对移动节点进行身份验证。PANA的目标类似，其目的是为身份验证信息定义网络层传输。然而，PANA将与移动性管理分离，并将依赖其他规范来定义认证有效负载。
This document defines common terminology and identifies requirements of a protocol for PANA that will be used to define and limit the scope of the work to be done in this group.
本文件定义了通用术语，并确定了PANA协议的要求，该协议将用于定义和限制本组工作的范围。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
PANA Client (PaC)
泛亚客户（PaC）
The client side of the protocol that resides in the host device which is responsible for providing the credentials to prove its identity for network access authorization.
驻留在主机设备中的协议客户端，负责提供凭据以证明其网络访问授权的身份。
PANA Client Identifier (PaCI)
PANA客户端标识符（PaCI）
The identifier that is presented by the PaC to the PAA for network access authentication. A simple username and NAI [RFC2794] are examples of PANA client identifiers.
PaC向PAA提供的用于网络访问身份验证的标识符。简单用户名和NAI[RFC2794]是PANA客户端标识符的示例。
Device Identifier (DI)
设备标识符（DI）
The identifier used by the network as a handle to control and police the network access of a client. Depending on the access technology, this identifier might contain an IP address, a link-layer address, or a switch port number, etc. of a connected device.
网络用作句柄的标识符，用于控制和监控客户端的网络访问。根据访问技术，此标识符可能包含所连接设备的IP地址、链路层地址或交换机端口号等。
PANA Authentication Agent (PAA)
PANA身份验证代理（PAA）
The access network side entity of the protocol whose responsibility is to verify the credentials provided by a PANA client and grant network access service to the device associated with the client and identified by a DI.
协议的接入网端实体，其职责是验证PANA客户端提供的凭据，并向与客户端关联并由DI标识的设备授予网络接入服务。
Enforcement Point (EP)
执行点（EP）
A node on the access network where per-packet enforcement policies (i.e., filters) are applied on the inbound and outbound traffic of client devices. Information such as DI and (optionally) cryptographic keys are provided by PAA per client for constructing filters on the EP.
接入网络上的一种节点，其中对客户端设备的入站和出站流量应用每包强制策略（即过滤器）。PAA为每个客户端提供DI和（可选）加密密钥等信息，用于在EP上构建过滤器。
PANA MUST enable authentication of PaCs for network access. A PaC's identity can be authenticated by verifying the credentials (e.g., identifier, authenticator) supplied by one of the users of the device or the device itself. PANA MUST only grant network access service to the device identified by the DI, rather than separate access to
PANA必须为网络访问启用PaCs身份验证。PaC的身份可以通过验证设备的一个用户或设备本身提供的凭据（例如，标识符、验证器）来进行身份验证。PANA必须仅向DI标识的设备授予网络访问服务，而不是单独访问
multiple simultaneous users of the device. Once network access is granted to the device, methods used by the device on arbitrating which user can access the network is outside the scope of PANA.
设备的多个同时用户。一旦设备被授予网络访问权，设备在仲裁哪个用户可以访问网络时使用的方法就不在PANA的范围之内。
PANA MUST NOT define new security protocols or mechanisms. Instead, it MUST be defined as a "carrier" for such protocols. PANA MUST identify which specific security protocol(s) or mechanism(s) it can carry (the "payload"). EAP is a candidate protocol that satisfies many requirements for authentication. PANA would be a carrier protocol for EAP. If the PANA Working Group decides that extensions to EAP are needed, it will define requirements for the EAP WG instead of designing such extensions.
PANA不得定义新的安全协议或机制。相反，它必须被定义为此类协议的“载体”。PANA必须确定它可以携带哪些特定的安全协议或机制（“有效载荷”）。EAP是一种候选协议，它满足许多身份验证要求。PANA将是EAP的运营商协议。如果PANA工作组决定需要对EAP进行扩展，它将定义EAP工作组的要求，而不是设计此类扩展。
Providing authentication, integrity and replay protection for data traffic after a successful PANA exchange is outside the scope of this protocol. In networks where physical layer security is not present, link-layer or network-layer ciphering (e.g., IPsec) can be used to provide such security. These mechanisms require the presence of cryptographic keying material at PaC and EP. Although PANA does not deal with key derivation or distribution, it enables this by carrying EAP and allowing appropriate EAP method selection. Various EAP methods are capable of generating basic keying material that cannot be directly used with IPsec because it lacks the properties of an IPsec SA (security association) including secure cipher suite negotiation, mutual proof of possession of keying material, freshness of transient session keys, key naming, etc. These basic (initial) EAP keys can be used with an IPsec key management protocol, like IKE, to generate the required security associations. A separate protocol, called secure association protocol, is required to generate IPsec SAs based on the basic EAP keys. This protocol MUST be capable of enabling IPsec-based access control on the EPs. IPsec SAs MUST enable authentication, integrity and replay protection of data packets as they are sent between the EP and PaC.
在成功的PANA交换后为数据流量提供身份验证、完整性和重播保护不在本协议的范围之内。在不存在物理层安全性的网络中，可以使用链路层或网络层加密（例如，IPsec）来提供此类安全性。这些机制要求在PaC和EP处存在加密密钥材料。尽管PANA不处理密钥派生或分发，但它通过携带EAP并允许选择适当的EAP方法来实现这一点。各种EAP方法能够生成不能直接与IPsec一起使用的基本密钥材料，因为它缺乏IPsec SA（安全关联）的属性，包括安全密码套件协商、密钥材料拥有的相互证明、临时会话密钥的新鲜度、密钥命名等。这些基本（初始）EAP密钥可与IPsec密钥管理协议（如IKE）一起使用，以生成所需的安全关联。根据基本EAP密钥生成IPsec SAs需要一个称为安全关联协议的单独协议。此协议必须能够在EPs上启用基于IPsec的访问控制。IPsec SAs必须在EP和PaC之间发送数据包时启用数据包的身份验证、完整性和重播保护。
Providing a complete secure network access solution by securing router discovery [RFC1256], neighbor discovery [RFC2461], and address resolution protocols [RFC826] is outside the scope as well.
通过保护路由器发现[RFC1256]、邻居发现[RFC2461]和地址解析协议[RFC826]来提供完整的安全网络访问解决方案也不在范围之内。
Some access networks might require or allow their clients to get authenticated and authorized by the network access provider (NAP) and ISP before the clients gain network access. NAP is the owner of the access network who provides physical and link-layer connectivity to the clients. PANA MUST be capable of enabling two independent authentication operations (i.e., execution of two separate EAP methods) for the same client. Determining the authorization parameters as a result of two separate authentications is an operational issue and therefore outside the scope of PANA.
某些接入网络可能要求或允许其客户端在获得网络接入之前获得网络接入提供商（NAP）和ISP的身份验证和授权。NAP是接入网络的所有者，为客户端提供物理和链路层连接。PANA必须能够为同一客户机启用两个独立的身份验证操作（即，执行两个单独的EAP方法）。通过两次单独的身份验证确定授权参数是一个操作问题，因此超出了PANA的范围。
Both the PaC and the PAA MUST be able to perform mutual authentication for network access. Providing only the capability of a PAA authenticating the PaC is not sufficient. Mutual authentication capability is required in some environments but not in all of them. For example, clients might not need to authenticate the access network when physical security is available (e.g., dial-up networks).
PaC和PAA都必须能够对网络访问执行相互身份验证。仅提供PAA认证PaC的能力是不够的。在某些环境中需要相互身份验证功能，但并非所有环境都需要。例如，当物理安全性可用时（例如拨号网络），客户端可能不需要对接入网络进行身份验证。
PANA MUST be capable of carrying out both periodic and on-demand re-authentication. Both the PaC and the PAA MUST be able to initiate both the initial authentication and the re-authentication process.
PANA必须能够执行定期和按需重新认证。PaC和PAA必须能够启动初始身份验证和重新身份验证过程。
Certain types of service theft are possible when the DI is not protected during or after the PANA exchange [RFC4016]. PANA MUST have the capability to exchange DI securely between the PaC and PAA where the network is vulnerable to man-in-the-middle attacks. While PANA MUST provide such a capability, its utility relies on the use of an authentication method that can generate keys for cryptographic computations on PaC and PAA.
当DI在PANA交换期间或之后未受到保护时，可能会发生某些类型的服务盗窃[RFC4016]。PANA必须能够在网络易受中间人攻击的PaC和PAA之间安全地交换DI。虽然PANA必须提供这样的功能，但其实用程序依赖于使用身份验证方法，该方法可以为PaC和PAA上的加密计算生成密钥。
After a device is authenticated by using PANA, it MUST be authorized for "network access." That is, the core requirement of PANA is to verify the authorization of a PaC so that PaC's device may send and receive any IP packets. It may also be possible to provide finer granularity authorization, such as authorization for QoS or individual services (e.g., http vs. ssh). However, while a backend authorization infrastructure (e.g., RADIUS or Diameter based AAA infra) might provide such indications to the PAA, explicit support for them is outside the scope of PANA. For instance, PANA is not required to carry any indication of the services authorized for the authenticated device.
使用PANA对设备进行身份验证后，必须对其进行“网络访问”授权。也就是说，PANA的核心要求是验证PaC的授权，以便PaC的设备可以发送和接收任何IP数据包。还可以提供更细粒度的授权，例如对QoS或单个服务（例如http与ssh）的授权。然而，尽管后端授权基础设施（例如，基于半径或直径的AAA infra）可能会向PAA提供此类指示，但对它们的明确支持不在PANA的范围之内。例如，PANA不需要携带任何为认证设备授权的服务指示。
Providing access control functionality in the network is outside the scope of PANA. Client access authentication SHOULD be followed by access control to make sure only authenticated and authorized clients can send and receive IP packets via the access network. Access control can involve setting access control lists on the EPs. PANA protocol exchange identifies clients that are authorized to access the network. If IPsec-based access control is deployed in an access network, PaC and EPs should have the required IPsec SA in place. Generating the IPsec SAs based on EAP keys is outside the scope of PANA protocol. This transformation MUST be handled by a separate secure association protocol (see section 4.1.1).
在网络中提供访问控制功能超出了PANA的范围。客户端访问身份验证之后应进行访问控制，以确保只有经过身份验证和授权的客户端才能通过访问网络发送和接收IP数据包。访问控制包括在EPs上设置访问控制列表。PANA协议交换标识有权访问网络的客户端。如果在访问网络中部署了基于IPsec的访问控制，则PaC和EPs应具有所需的IPsec SA。基于EAP密钥生成IPsec SAs超出了PANA协议的范围。此转换必须由单独的安全关联协议处理（见第4.1.1节）。
Carrying accounting data is outside the scope of PANA.
携带会计数据不属于PANA的范围。
PANA protocol MUST NOT make any assumptions on the backend authentication protocol or mechanisms. A PAA MAY interact with backend AAA infrastructures such as RADIUS or Diameter, but it is not a requirement. When the access network does not rely on an IETF-defined AAA protocol (e.g., RADIUS, Diameter), it can still use a proprietary backend system, or rely on the information locally stored on the authentication agents.
PANA协议不得对后端身份验证协议或机制做出任何假设。PAA可以与后端AAA基础设施（如RADIUS或Diameter）交互，但这不是一项要求。当接入网络不依赖IETF定义的AAA协议（例如RADIUS、Diameter）时，它仍然可以使用专有的后端系统，或者依赖本地存储在认证代理上的信息。
The interaction between the PAA and the backend authentication entities is outside the scope of PANA.
PAA和后端身份验证实体之间的交互不在PANA的范围之内。
PANA SHOULD allow various types of identifiers to be used as the PaCI (e.g., username, Network Access Identifier (NAI), Fully Qualified Domain Name (FQDN), etc.). This requirement generally relies on the client identifiers supported by various EAP methods.
PANA应允许各种类型的标识符用作PaCI（例如用户名、网络访问标识符（NAI）、完全限定域名（FQDN）等）。此要求通常依赖于各种EAP方法支持的客户端标识符。
PANA SHOULD allow various types of identifiers to be used as the DI (e.g., IP address, link-layer address, port number of a switch, etc.).
PANA应允许各种类型的标识符用作DI（例如，IP地址、链路层地址、交换机端口号等）。
A PAA MUST be able to create a binding between the PaCI and the associated DI upon successful PANA exchange. This can be achieved by PANA communicating the PaCI and DI to the PAA during the protocol exchange. The DI can be carried either explicitly as part of the PANA payload, or implicitly as the source of the PANA message, or both. Multi-access networks also require use of a cryptographic protection along with DI filtering to prevent unauthorized access [RFC4016]. The keying material required by the cryptographic methods needs to be indexed by the DI. As described in section 4.1.2, the binding between DI and PaCI is used for access control and accounting in the network.
PAA必须能够在PANA交换成功后在PaCI和相关DI之间创建绑定。这可以通过PANA在协议交换期间将PaCI和DI与PAA通信来实现。DI可以显式地作为PANA有效负载的一部分携带，也可以隐式地作为PANA消息的源携带，或者两者都携带。多址网络还需要使用加密保护和DI过滤，以防止未经授权的访问[RFC4016]。加密方法所需的密钥材料需要由DI编制索引。如第4.1.2节所述，DI和PaCI之间的绑定用于网络中的访问控制和计费。
Assigning an IP address to the client is outside the scope of PANA. PaC MUST configure an IP address before running PANA.
将IP地址分配给客户端超出了PANA的范围。PaC必须在运行PANA之前配置IP地址。
The EAP protocol imposes various requirements on its transport protocols that are based on the nature of the EAP protocol, and need to be satisfied for correct operation. Please see [RFC3748] for the generic transport requirements that MUST be satisfied by PANA.
EAP协议根据EAP协议的性质对其传输协议提出了各种要求，并且需要满足这些要求才能正确运行。请参阅[RFC3748]了解泛亚必须满足的通用运输要求。
PANA does not assume that the PAA is always co-located with the EP(s). Network access enforcement can be provided by one or more nodes on the same IP subnet as the client (e.g., multiple routers), or on another subnet in the access domain (e.g., gateway to the Internet, depending on the network architecture). When the PAA and the EP(s) are separated, another transport for client provisioning is necessary. This transport is needed to create access control lists in order to allow authenticated and authorized clients' traffic through the EPs. PANA Working Group will preferably identify an existing protocol solution that allows the PAA to deliver the authorization information to one or more EPs when the PAA is separated from EPs. Possible candidates include, but are not limited to COPS, SNMP, Diameter, etc.
PANA不认为PAA始终与EP位于同一地点。网络访问强制可由与客户端位于同一IP子网上的一个或多个节点（例如，多个路由器）或访问域中的另一个子网上的一个或多个节点（例如，互联网网关，取决于网络体系结构）提供。当PAA和EP分离时，需要另一个用于客户端资源调配的传输。这种传输需要创建访问控制列表，以便允许通过EPs的经过身份验证和授权的客户端通信。PANA工作组最好确定一个现有的协议解决方案，当PAA与EPs分离时，该解决方案允许PAA将授权信息传递给一个或多个EPs。可能的候选者包括但不限于COP、SNMP、Diameter等。
The communication between PAA and EP(s) MUST be secure. The objective of using a PAA-to-EP protocol is to provide filtering rules to EP(s) for allowing network access of a recently authenticated and authorized PaC. The chosen protocol MUST be capable of carrying DI and cryptographic keys for a given PaC from PAA to EP. Depending on the PANA protocol design, support for either of the pull model (i.e., EP initiating the PAA-to-EP protocol exchange per PaC) or the push model (i.e., PAA initiating the PAA-to-EP protocol exchange per PaC), or both may be required. For example, if the design is such that the EP allows the PANA traffic to pass through even for unauthenticated PaCs, the EP should also allow and expect the PAA to send the filtering information at the end of a successful PANA exchange without the EP ever sending a request.
PAA和EP之间的通信必须安全。使用PAA-to-EP协议的目的是为EP提供过滤规则，以允许最近认证和授权的PaC的网络访问。所选协议必须能够将给定PaC的DI和加密密钥从PAA传输到EP。根据PANA协议设计，可能需要支持拉模式（即，EP根据PaC启动PAA到EP协议交换）或推模式（即，PAA根据PaC启动PAA到EP协议交换），或两者兼有。例如，如果设计使得EP允许PANA流量通过，即使对于未经验证的PAC，EP也应允许并期望PAA在成功的PANA交换结束时发送过滤信息，而EP从不发送请求。
PANA MUST support PaCs with multiple interfaces, and networks with multiple routers on multi-access links. In other words, PANA MUST NOT assume that the PaC has only one network interface, that the access network has only one first hop router, or that the PaC is using a point-to-point link.
PANA必须支持具有多个接口的PAC，以及在多访问链路上具有多个路由器的网络。换句话说，PANA不能假设PaC只有一个网络接口，接入网络只有一个第一跳路由器，或者PaC使用点对点链路。
PANA MUST NOT assume that the link is connection-oriented. Links may or may not provide disconnect indication. Such notification is desirable in order for the PAA to clean up resources when a client moves away from the network (e.g., inform the enforcement points that the client is no longer connected). PANA SHOULD have a mechanism to
PANA不能假定链接是面向连接的。链路可能提供也可能不提供断开指示。这样的通知是可取的，以便PAA在客户端离开网络时清理资源（例如，通知实施点客户端不再连接）。PANA应该有一个机制来
provide disconnect indication. PANA MUST be capable of securing disconnect messages in order to prevent malicious nodes from leveraging this extension for DoS attacks.
提供断开指示。PANA必须能够保护断开连接消息，以防止恶意节点利用此扩展进行DoS攻击。
This mechanism MUST allow the PAA to be notified about the departure of a PaC from the network. This mechanism MUST also allow a PaC to be notified about the discontinuation of the network access service. Access discontinuation can occur due to various reasons such as network systems going down or a change in the access policy.
该机制必须允许PAA收到PaC离开网络的通知。该机制还必须允许PaC收到网络访问服务中断的通知。访问中断可能是由于各种原因造成的，例如网络系统故障或访问策略的更改。
In case the clients cannot send explicit disconnect messages to the PAA, it can still detect their departure by relying on periodic authentication requests.
如果客户端无法向PAA发送显式断开连接消息，它仍然可以通过依赖定期身份验证请求来检测它们的离开。
The PAA and PaC MUST be exactly one IP hop away from each other. That is, there must be no IP routers between the two. Note that this does not mean they are on the same physical link. Bridging and tunneling (e.g., IP-in-IP, GRE, L2TP, etc.) techniques can place two nodes just exactly one IP hop away from each other although they might be connected to separate physical links. A PAA can be on the network access server (NAS) or WLAN access point or first hop router. The use of PANA when the PAA is multiple IP hops away from the PaC is outside the scope of PANA.
PAA和PaC之间必须正好有一个IP跃点。也就是说，两者之间必须没有IP路由器。请注意，这并不意味着它们位于同一物理链路上。桥接和隧道（例如，IP-in-IP、GRE、L2TP等）技术可以使两个节点彼此仅相隔一个IP跃点，尽管它们可能连接到单独的物理链路。PAA可以位于网络访问服务器（NAS）或WLAN访问点或第一跳路由器上。当PAA距离PaC有多个IP跃点时，PANA的使用超出了PANA的范围。
A PaC may or may not be pre-configured with the IP address of PAA. Therefore the PANA protocol MUST define a dynamic discovery method. Given that the PAA is one hop away from the PaC, there are a number of discovery techniques that could be used (e.g., multicast or anycast) by the PaC to find out the address of the PAA.
PaC可以预先配置PAA的IP地址，也可以不预先配置。因此，PANA协议必须定义一种动态发现方法。鉴于PAA距离PaC只有一个跃点，PaC可以使用许多发现技术（例如，多播或选播）来查找PAA的地址。
PANA MUST NOT assume the presence of a secure channel between the PaC and the PAA. PANA MUST be able to provide authentication especially in networks which are not protected against eavesdropping and spoofing. PANA MUST enable protection against replay attacks on both PaCs and PAAs.
PANA不得假设PaC和PAA之间存在安全通道。PANA必须能够提供身份验证，尤其是在不受窃听和欺骗保护的网络中。PANA必须针对PaCs和PAAs上的重播攻击启用保护。
This requirement partially relies on the EAP protocol and the EAP methods carried over PANA. Use of EAP methods that provide mutual authentication and key derivation/distribution is essential for satisfying this requirement. EAP does not make a secure channel assumption, and supports various authentication methods that can be used in such environments. Additionally, PANA MUST ensure that its design does not contain vulnerabilities that can be exploited when it is used over insecure channels. PANA MAY provide a secure channel by
该要求部分依赖于PANA上的EAP协议和EAP方法。使用提供相互认证和密钥派生/分发的EAP方法对于满足这一要求至关重要。EAP不进行安全通道假设，并支持可在此类环境中使用的各种身份验证方法。此外，PANA必须确保其设计不包含在不安全通道上使用时可能被利用的漏洞。PANA可通过以下方式提供安全通道：
deploying a two-phase authentication. The first phase can be used for creation of the secure channel, and the second phase for client and network authentication.
部署两阶段身份验证。第一阶段可用于创建安全通道，第二阶段用于客户端和网络身份验证。
Mobility management is outside the scope of PANA. However, PANA MUST be able to co-exist and MUST NOT unintentionally interfere with various mobility management protocols, such as Mobile IPv4 [RFC3344], Mobile IPv6 [RFC3775], fast handover protocols [FMIPv6] [FMIPv4], and other standard protocols like IPv6 stateless address auto-configuration [RFC2461] (including privacy extensions [RFC3041]), and DHCP [RFC2131] [RFC3315]. PANA MUST NOT make any assumptions on the protocols or mechanisms used for IP address configuration of the PaC.
移动性管理不属于PANA的范围。但是，PANA必须能够共存，并且不得无意中干扰各种移动性管理协议，例如移动IPv4[RFC3344]、移动IPv6[RFC3775]、快速切换协议[FMIPv6][FMIPv4]，以及其他标准协议，如IPv6无状态地址自动配置[RFC2461]（包括隐私扩展[RFC3041]），和DHCP[RFC2131][RFC3315]。PANA不得对用于PaC IP地址配置的协议或机制做出任何假设。
PANA design SHOULD efficiently handle the authentication process in order to gain network access with minimum latency. For example, it may minimize the protocol signaling by creating local security associations.
PANA设计应有效地处理身份验证过程，以便以最小的延迟获得网络访问。例如，它可以通过创建本地安全关联来最小化协议信令。
PANA MUST provide congestion control for the protocol messaging. Under certain conditions PaCs might unintentionally get synchronized when sending their requests to the PAA (e.g., upon recovering from a power outage on the access network). The network congestion generated from such events can be avoided by using techniques like delayed initialization and exponential back off.
PANA必须为协议消息传递提供拥塞控制。在某些情况下，PAC在向PAA发送请求时（例如，从接入网络上的断电恢复时）可能会无意中同步。通过使用延迟初始化和指数退避等技术，可以避免由此类事件产生的网络拥塞。
PANA MUST work with both IPv4 and IPv6.
PANA必须同时使用IPv4和IPv6。
PANA MUST be robust against a class of DoS attacks such as blind masquerade attacks through IP spoofing. These attacks would swamp the PAA, causing it to spend resources and prevent network access by legitimate clients.
PANA必须能够抵御一类DoS攻击，例如通过IP欺骗的盲伪装攻击。这些攻击将淹没PAA，导致其花费资源并阻止合法客户端访问网络。
Some clients might prefer hiding their identity from visited access networks for privacy reasons. Providing identity protection for clients is outside the scope of PANA. Note that some authentication
出于隐私原因，一些客户端可能更喜欢在访问的访问网络中隐藏自己的身份。为客户提供身份保护不属于PANA的范围。请注意，某些身份验证
methods may already have this capability. Where necessary, identity protection can be achieved by letting PANA carry such authentication methods.
方法可能已经具有此功能。必要时，可以通过让PANA携带此类身份验证方法来实现身份保护。
This document identifies requirements for the PANA protocol design. Due to the nature of this protocol, most of the requirements are security related. The actual protocol design is not specified in this document. A thorough discussion on PANA security threats can be found in PANA Threat Analysis and Security Requirements [RFC4016]. Security threats identified in that document are already included in this general PANA requirements document.
本文件确定了PANA协议设计的要求。由于本协议的性质，大多数要求与安全相关。本文件未规定实际的协议设计。有关PANA安全威胁的详细讨论，请参见PANA威胁分析和安全需求[RFC4016]。该文件中确定的安全威胁已包含在本通用PANA要求文件中。
Authors would like to thank Bernard Aboba, Derek Atkins, Steven Bellovin, Julien Bournelle, Subir Das, Francis Dupont, Dan Forsberg, Pete McCann, Lionel Morand, Thomas Narten, Mohan Parthasarathy, Basavaraj Patil, Hesham Soliman, and the PANA Working Group members for their valuable contributions to the discussions and preparation of this document.
作者要感谢Bernard Aboba、Derek Atkins、Steven Bellovin、Julien Bournelle、Subir Das、Francis Dupont、Dan Forsberg、Pete McCann、Lionel Morand、Thomas Narten、Mohan Parthasarathy、Basavaraj Patil、Hesham Soliman、，感谢PANA工作组成员对本文件的讨论和编写做出的宝贵贡献。
Access networks in most cases require some form of authentication in order to prevent unauthorized usage. In the absence of physical security (and sometimes in addition to it) a higher layer (L2+) access authentication mechanism is needed. Depending on the deployment scenarios, a number of features are expected from the authentication mechanism. For example, support for various authentication methods (e.g., MD5, TLS, SIM, etc.), network roaming, network service provider discovery and selection, separate authentication for access (L1+L2) service provider and ISP (L3), etc. In the absence of a link-layer authentication mechanism that can satisfy these needs, operators are forced to either use non-standard ad-hoc solutions at layers above the link, insert additional shim layers for authentication, or misuse some of the existing protocols in ways that were not intended by design. PANA will be developed to fill this gap by defining a standard network-layer access authentication protocol. As a network-layer access authentication protocol, PANA can be used over any link-layer that supports IP.
在大多数情况下，接入网络需要某种形式的身份验证，以防止未经授权的使用。在缺乏物理安全性的情况下（有时还需要附加物理安全性），需要更高层（L2+）访问身份验证机制。根据部署场景的不同，身份验证机制将提供许多功能。例如，在缺乏能够满足这些需求的链路层认证机制的情况下，支持各种认证方法（例如MD5、TLS、SIM等）、网络漫游、网络服务提供商发现和选择、接入（L1+L2）服务提供商和ISP（L3）的单独认证等，运营商被迫在链路上方的各层使用非标准的即席解决方案，插入额外的垫片层进行身份验证，或者以设计不希望的方式滥用某些现有协议。PANA将通过定义标准的网络层访问认证协议来填补这一空白。作为网络层访问认证协议，PANA可以在支持IP的任何链路层上使用。
DSL networks are a specific example where PANA has the potential for addressing some of the deployment scenarios. Some DSL deployments do not use PPP [RFC1661] as the access link-layer (IP is carried over ATM and the subscriber device is either statically or DHCP-configured). The operators of these networks are left either using an application-layer web-based login (captive portal) scheme for subscriber authentication, or providing a best-effort service only as they cannot perform subscriber authentication required for the differentiated services. The captive portal scheme is a non-standard solution that has various limitations and security flaws.
DSL网络是PANA有潜力解决某些部署场景的一个具体示例。一些DSL部署不使用PPP[RFC1661]作为接入链路层（IP通过ATM承载，订户设备静态或DHCP配置）。这些网络的运营商要么使用应用层基于web的登录（捕获门户）方案进行订户身份验证，要么只提供尽力而为的服务，因为他们无法执行区分服务所需的订户身份验证。捕获门户方案是一种非标准解决方案，具有各种限制和安全缺陷。
PPP-based authentication can provide some of the required functionality. But using PPP only for authentication is not a good choice, as it incurs additional messaging during the connection setup and extra per-packet processing. It also forces the network topology to a point-to-point model. Aside from resistance to incorporating PPP into an architecture unless it is absolutely necessary, there is even interest in the community in removing PPP from some of the existing architectures and deployments (e.g., 3GPP2, DSL).
基于PPP的身份验证可以提供一些必需的功能。但仅将PPP用于身份验证并不是一个好的选择，因为它会在连接设置期间产生额外的消息传递和额外的每个数据包处理。它还将网络拓扑强制为点到点模型。除了在绝对必要的情况下抵制将PPP纳入架构之外，社区甚至对从一些现有架构和部署（例如3GPP2、DSL）中移除PPP感兴趣。
Using Mobile IPv4 authentication with a foreign agent instead of proper network access authentication is an example of protocol misuse. The Registration Required flag allows a foreign agent to force authentication even when the agent is not involved in any Mobile IPv4 signalling (co-located care-of address case). This enables the use of a mobility-specific protocol for an unrelated functionality.
使用带有外部代理的移动IPv4身份验证而不是正确的网络访问身份验证是协议误用的一个例子。注册要求标志允许外部代理强制进行身份验证，即使该代理未参与任何移动IPv4信令（共址转交地址情况）。这使得能够针对不相关的功能使用特定于移动性的协议。
PANA will carry EAP above IP in order to enable any authentication method on any link-layer. EAP can already be carried by [IEEE-802.1X] and PPP. IEEE 802.1X can only be used on unbridged IEEE 802 links, hence it only applies to limited link types. Inserting PPP between IP and a link-layer can be perceived as a way to enable EAP over that particular link-layer, but using PPP for this reason has the aforementioned drawbacks and is not a good choice. While IEEE 802.1X and PPP can continue to be used in their own domains, they do not take away the need to have a protocol like PANA.
PANA将在IP上携带EAP，以便在任何链路层上启用任何身份验证方法。EAP已经可以由[IEEE-802.1X]和PPP承载。IEEE 802.1X只能用于无桥IEEE 802链路，因此它仅适用于有限的链路类型。在IP和链路层之间插入PPP可以被认为是在该特定链路层上启用EAP的一种方法，但是出于这个原因使用PPP具有上述缺点，并且不是一个好的选择。虽然IEEE 802.1X和PPP可以继续在它们自己的域中使用，但它们并没有消除像PANA这样的协议的需要。
PANA will be applicable to various types of networks. Based on the presence of lower-layer security prior to running PANA, the following types cover all possibilities:
PANA将适用于各种类型的网络。基于运行PANA之前存在的低层安全性，以下类型涵盖了所有可能性：
a) Physically secured networks (e.g., DSL networks). Although data traffic is always carried over a physically secured link, the client might need to be authenticated and authorized when accessing the IP services.
a) 物理安全网络（例如DSL网络）。尽管数据流量始终通过物理安全链路传输，但在访问IP服务时，客户端可能需要进行身份验证和授权。
b) Networks where L1-L2 is already cryptographically secured before enabling IP (e.g., cdma2000 networks). Although the client is authenticated on the radio link before enabling ciphering, it additionally needs to get authenticated and authorized for accessing the IP services.
b) 在启用IP之前，L1-L2已经加密安全的网络（例如，cdma2000网络）。尽管客户端在启用加密之前在无线链路上进行了身份验证，但它还需要获得访问IP服务的身份验证和授权。
c) No lower-layer security present before enabling IP. PANA is run in an insecure network. PANA-based access authentication is used to bootstrap cryptographic per-packet authentication and integrity protection.
c) 在启用IP之前，不存在较低层的安全性。PANA在不安全的网络中运行。基于PANA的访问身份验证用于引导加密每包身份验证和完整性保护。
PANA is applicable to not only large-scale operator deployments with full AAA infrastructure, but also to small disconnected deployments like home networks and personal area networks.
PANA不仅适用于具有完整AAA基础设施的大规模运营商部署，也适用于小型断开连接的部署，如家庭网络和个人区域网络。
Since PANA enables decoupling AAA from the link-layer procedures, network access authentication does not have to take place during the link establishment. This allows deferring client authentication until the client attempts to access differentiated services (e.g., high bandwidth, unlimited access, etc.) in some deployments. Additionally, multiple simultaneous network access sessions over the same link-layer connection can occur as well.
由于PANA允许将AAA与链路层过程分离，因此在链路建立期间不必进行网络访问身份验证。这允许延迟客户端身份验证，直到客户端尝试在某些部署中访问差异化服务（例如，高带宽、无限制访问等）。此外，也可以在同一链路层连接上同时进行多个网络访问会话。
The following five scenarios capture the PANA usage model in different network architectures with reference to its placement of logical elements such as the PANA Client (PaC) and the PANA Authentication Agent (PAA) with respect to the Enforcement Point (EP) and the Access Router (AR). Note that PAA may or may not use AAA infrastructure to verify the credentials of PaC in order to authorize network access.
以下五个场景根据逻辑元素（如PANA客户端（PaC）和PANA身份验证代理（PAA））相对于实施点（EP）和接入路由器（AR）的位置，捕获不同网络体系结构中的PANA使用模型。请注意，PAA可能会也可能不会使用AAA基础设施来验证PaC的凭据，以便授权网络访问。
Scenario 1: PAA co-located with EP but separated from AR
情景1：PAA与EP位于同一地点，但与AR分离
In this scenario (Figure 1), PAA is co-located with the enforcement point on which access control is performed. This might be the case where PAA is co-located with the L2 access device (e.g., an IP-capable switch).
在此场景中（图1），PAA与执行访问控制的实施点位于同一位置。这可能是PAA与L2接入设备（例如，支持IP的交换机）位于同一位置的情况。
PaC -----EP/PAA--+
|
+------ AR ----- (AAA)
|
PaC -----EP/PAA--+
PaC -----EP/PAA--+
|
+------ AR ----- (AAA)
|
PaC -----EP/PAA--+
Figure 1: PAA co-located with EP but separated from AR.
图1:PAA与EP位于同一位置，但与AR分离。
Scenario 2: PAA co-located with AR but separated from EP
情景2：PAA与AR位于同一位置，但与EP分离
In this scenario, PAA is not co-located with EPs but is placed on the AR. Although we have shown only one AR here, there could be multiple ARs, one of which is co-located with the PAA. Access control parameters have to be distributed to the respective enforcement points so that the corresponding device on which PaC is authenticated can access the network. A separate protocol is needed between PAA and EP to carry access control parameters.
在这种情况下，PAA与EPs不在同一位置，而是放在AR上。虽然我们这里只显示了一个AR，但可能有多个AR，其中一个AR与PAA在同一位置。访问控制参数必须分配到各个实施点，以便PaC认证的相应设备可以访问网络。PAA和EP之间需要一个单独的协议来携带访问控制参数。
PaC ----- EP --+
|
+------ AR/PAA --- (AAA)
|
PaC ----- EP --+
PaC ----- EP --+
|
+------ AR/PAA --- (AAA)
|
PaC ----- EP --+
Figure 2: PAA co-located with AR but separated from EP
图2:PAA与AR位于同一位置，但与EP分离
Scenario 3: PAA co-located with EP and AR
情景3：PAA与EP和AR同处一地
In this scenario (Figure 3), PAA is co-located with the EP and AR on which access control and routing are performed.
在这个场景中（图3），PAA与EP和AR位于同一位置，在这两个位置上执行访问控制和路由。
PaC ----- EP/PAA/AR--+
|
+-------(AAA)
|
PaC ----- EP/PAA/AR--+
PaC ----- EP/PAA/AR--+
|
+-------(AAA)
|
PaC ----- EP/PAA/AR--+
Figure 3: PAA co-located with EP and AR.
图3:PAA与EP和AR位于同一地点。
Scenario 4: Separated PAA, EP, and AR
场景4：分离的PAA、EP和AR
In this scenario, PAA is neither co-located with EPs nor with ARs. It still resides on the same IP link as ARs. After successful authentication, access control parameters will be distributed to respective enforcement points via a separate protocol and PANA does not play any explicit role in this.
在这种情况下，PAA既不与EPs共存，也不与ARs共存。它仍然驻留在与ARs相同的IP链路上。认证成功后，访问控制参数将通过单独的协议分发到各个实施点，PANA在此过程中不起任何明确作用。
PaC ----- EP -----+--- AR ---+
| |
PaC ----- EP --- -+ |
| |
PaC ----- EP -----+--- AR -- + ----(AAA)
|
+--- PAA
PaC ----- EP -----+--- AR ---+
| |
PaC ----- EP --- -+ |
| |
PaC ----- EP -----+--- AR -- + ----(AAA)
|
+--- PAA
Figure 4: PAA, EP and AR separated.
图4：PAA、EP和AR分离。
Scenario 5: PAA separated from co-located EP and AR
情景5：PAA与同一地点的EP和AR分离
In this scenario, EP and AR are co-located with each other but separated from PAA. PAA still resides on the same IP link as ARs. After successful authentication, access control parameters will be distributed to respective enforcement points via a separate protocol and PANA does not play any explicit role in this.
在这种情况下，EP和AR彼此位于同一位置，但与PAA分离。PAA仍然与ARs驻留在同一IP链路上。认证成功后，访问控制参数将通过单独的协议分发到各个实施点，PANA在此过程中不起任何明确作用。
PaC --------------+--- AR/EP ---+
| |
PaC --------------+ |
| |
PaC --------------+--- AR/EP -- + ----(AAA)
|
+--- PAA
PaC --------------+--- AR/EP ---+
| |
PaC --------------+ |
| |
PaC --------------+--- AR/EP -- + ----(AAA)
|
+--- PAA
Figure 5: PAA separated from EP and AR.
图5：从EP和AR中分离的PAA。
References
工具书类
Normative References
规范性引用文件
[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月。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[RFC3748]Aboba，B.，Blunk，L.，Vollbrecht，J.，Carlson，J.，和H.Levkowetz，“可扩展身份验证协议（EAP）”，RFC 3748，2004年6月。
[RFC4016] Parthasarathy, M., "Protocol for Carrying Authentication and Network Access (PANA) Threat Analysis and Security Requirements", RFC 4016, March 2005.
[RFC4016]Parthasarathy，M.“承载身份验证和网络访问协议（PANA）威胁分析和安全要求”，RFC4016，2005年3月。
Informative References
资料性引用
[FMIPv4] Malki, K., "Low Latency Handoffs in Mobile IPv4", Work in Progress, June 2004.
[FMIPv4]Malki，K.，“移动IPv4中的低延迟切换”，正在进行的工作，2004年6月。
[IEEE-802.1X] Institute of Electrical and Electronics Engineers, "Local and Metropolitan Area Networks: Port-Based Network Access Control", IEEE Standard 802.1X, September 2001.
[IEEE-802.1X]电气和电子工程师协会，“局域网和城域网：基于端口的网络访问控制”，IEEE标准802.1X，2001年9月。
[RFC826] Plummer, D., "Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware", STD 37, RFC 826, November 1982.
[RFC826]Plummer，D.，“以太网地址解析协议：或将网络协议地址转换为48位以太网地址，以便在以太网硬件上传输”，STD 37，RFC 826，1982年11月。
[RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256, September 1991.
[RFC1256]Deering，S.，“ICMP路由器发现消息”，RFC 12561991年9月。
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC1661]辛普森，W.“点对点协议（PPP）”，标准51，RFC1661，1994年7月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131]Droms，R.，“动态主机配置协议”，RFC21311997年3月。
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[RFC2461]Narten，T.，Nordmark，E.，和W.Simpson，“IP版本6（IPv6）的邻居发现”，RFC2461，1998年12月。
[RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS Authentication Protocol", RFC 2716, October 1999.
[RFC2716]Aboba，B.和D.Simon，“PPP EAP TLS认证协议”，RFC 2716，1999年10月。
[RFC2794] Calhoun, P. and C. Perkins, "Mobile IP Network Access Identifier Extension for IPv4", RFC 2794, March 2000.
[RFC2794]Calhoun，P.和C.Perkins，“IPv4移动IP网络访问标识符扩展”，RFC 27942000年3月。
[RFC3012] Perkins, C. and P. Calhoun, "Mobile IPv4 Challenge/ Response Extensions", RFC 3012, November 2000.
[RFC3012]Perkins，C.和P.Calhoun，“移动IPv4挑战/响应扩展”，RFC3012，2000年11月。
[RFC3041] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[RFC3041]Narten，T.和R.Draves，“IPv6中无状态地址自动配置的隐私扩展”，RFC 3041，2001年1月。
[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月。
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[RFC3344]Perkins，C.，“IPv4的IP移动支持”，RFC 3344，2002年8月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775]Johnson，D.，Perkins，C.，和J.Arkko，“IPv6中的移动支持”，RFC 37752004年6月。
[FMIPv6] Koodli, R., Ed., "Fast Handovers for Mobile IPv6", Work in Progress.
[FMIPv6]Koodli，R.，Ed.“移动IPv6的快速切换”，正在进行中。
Authors' Addresses
作者地址
Alper E. Yegin (editor) Samsung Advanced Institute of Technology 75 West Plumeria Drive San Jose, CA 95134 USA
Alper E.Yegin（编辑）三星高级技术学院美国加利福尼亚州圣何塞西普洛玛丽亚大道75号，邮编95134
Phone: +1 408 544 5656
EMail: alper.yegin@samsung.com
Phone: +1 408 544 5656
EMail: alper.yegin@samsung.com
Yoshihiro Ohba Toshiba America Research, Inc. 1 Telcordia Drive Piscataway, NJ 08854 USA
美国新泽西州皮斯卡塔韦Telcordia Drive 1号东芝美国研究有限公司，邮编：08854
Phone: +1 732 699 5305
EMail: yohba@tari.toshiba.com
Phone: +1 732 699 5305
EMail: yohba@tari.toshiba.com
Reinaldo Penno Juniper Networks 10 Technology Park Drive Westford, MA 01886-3146 USA
雷纳尔多·佩诺·朱尼珀网络美国马萨诸塞州韦斯特福德科技园大道10号01886-3146
EMail: rpenno@juniper.net
EMail: rpenno@juniper.net
George Tsirtsis Flarion Bedminster One 135 Route 202/206 South Bedminster, NJ 07921 USA
George Tsirtsis Flarion Bedminster One 135号公路202/206南贝德明斯特，美国新泽西州07921
Phone: +44 20 88260073
EMail: G.Tsirtsis@Flarion.com
Phone: +44 20 88260073
EMail: G.Tsirtsis@Flarion.com
Cliff Wang ARO/NCSU 316 Riggsbee Farm Morrisville, NC 27560 USA
Cliff Wang ARO/NCSU 316美国北卡罗来纳州莫里斯维尔里格斯比农场27560
Phone: +1 919 548 4207
EMail: cliffwangmail@yahoo.com
Phone: +1 919 548 4207
EMail: cliffwangmail@yahoo.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。