Network Working Group A. Patel, Ed.
Request for Comments: 4640 Cisco
Category: Informational G. Giaretta, Ed.
Telecom Italia
September 2006
Network Working Group A. Patel, Ed.
Request for Comments: 4640 Cisco
Category: Informational G. Giaretta, Ed.
Telecom Italia
September 2006
Problem Statement for Bootstrapping Mobile IPv6 (MIPv6)
引导移动IPv6（MIPv6）的问题陈述
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 (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
A mobile node needs at least the following information: a home address, a home agent address, and a security association with home agent to register with the home agent. The process of obtaining this information is called bootstrapping. This document discusses issues involved with how the mobile node can be bootstrapped for Mobile IPv6 (MIPv6) and various potential deployment scenarios for mobile node bootstrapping.
移动节点至少需要以下信息：家庭地址、家庭代理地址以及与家庭代理的安全关联，以便向家庭代理注册。获取此信息的过程称为引导。本文档讨论了如何为移动IPv6（MIPv6）引导移动节点以及移动节点引导的各种潜在部署场景所涉及的问题。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Overview of the Problem ....................................3
1.2. Bootstrapping ..............................................3
1.3. Terminology ................................................4
2. Assumptions .....................................................5
3. Design Goals ....................................................6
4. Non-goals .......................................................7
5. Motivation for bootstrapping ....................................7
5.1. Addressing .................................................7
5.1.1. Dynamic Home Address Assignment .....................7
5.1.2. Dynamic Home Agent Assignment .......................9
5.1.3. "Opportunistic" or "Local" Discovery ................9
5.1.4. Management Requirements .............................9
5.2. Security Infrastructure ...................................10
5.2.1. Integration with AAA Infrastructure ................10
5.3. Topology Change ...........................................10
1. Introduction ....................................................2
1.1. Overview of the Problem ....................................3
1.2. Bootstrapping ..............................................3
1.3. Terminology ................................................4
2. Assumptions .....................................................5
3. Design Goals ....................................................6
4. Non-goals .......................................................7
5. Motivation for bootstrapping ....................................7
5.1. Addressing .................................................7
5.1.1. Dynamic Home Address Assignment .....................7
5.1.2. Dynamic Home Agent Assignment .......................9
5.1.3. "Opportunistic" or "Local" Discovery ................9
5.1.4. Management Requirements .............................9
5.2. Security Infrastructure ...................................10
5.2.1. Integration with AAA Infrastructure ................10
5.3. Topology Change ...........................................10
5.3.1. Dormant Mode Mobile Nodes ..........................10
6. Network Access and Mobility Services ...........................11
7. Deployment Scenarios ...........................................13
7.1. Mobility Service Subscription Scenario ....................13
7.2. Integrated ASP Network Scenario ...........................14
7.3. Third-Party MSP Scenario ..................................14
7.4. Infrastructure-less Scenario ..............................15
8. Parameters for Authentication ..................................15
9. Security Considerations ........................................17
9.1. Security Requirements of Mobile IPv6 ......................17
9.2. Threats to the Bootstrapping Process ......................18
10. Contributors ..................................................19
11. Acknowledgements ..............................................20
12. Informative References ........................................20
5.3.1. Dormant Mode Mobile Nodes ..........................10
6. Network Access and Mobility Services ...........................11
7. Deployment Scenarios ...........................................13
7.1. Mobility Service Subscription Scenario ....................13
7.2. Integrated ASP Network Scenario ...........................14
7.3. Third-Party MSP Scenario ..................................14
7.4. Infrastructure-less Scenario ..............................15
8. Parameters for Authentication ..................................15
9. Security Considerations ........................................17
9.1. Security Requirements of Mobile IPv6 ......................17
9.2. Threats to the Bootstrapping Process ......................18
10. Contributors ..................................................19
11. Acknowledgements ..............................................20
12. Informative References ........................................20
Mobile IPv6 [RFC3775] specifies mobility support based on the assumption that a mobile node (MN) has a trust relationship with an entity called the home agent. Once the home agent address has been learned (for example, via manual configuration, anycast discovery mechanisms, or DNS lookup), Mobile IPv6 signaling messages between the mobile node and the home agent are secured with IPsec or with the authentication protocol, as defined in [RFC4285]. The requirements for this security architecture are created with [RFC3775], and the details of this procedure are described in [RFC3776].
移动IPv6[RFC3775]基于移动节点（MN）与称为归属代理的实体具有信任关系的假设来指定移动支持。一旦了解到归属代理地址（例如，通过手动配置、选播发现机制或DNS查找），移动节点和归属代理之间的移动IPv6信令消息将通过IPsec或身份验证协议进行保护，如[RFC4285]中所定义。此安全体系结构的要求由[RFC3775]创建，此过程的详细信息在[RFC3776]中描述。
In [RFC3775], there is an implicit requirement that the MN be provisioned with enough information that will permit it to register successfully with its home agent. However, having this information statically provisioned creates practical deployment issues.
在[RFC3775]中，有一个隐含的要求，即为MN提供足够的信息，使其能够成功地向其归属代理注册。但是，静态配置这些信息会产生实际的部署问题。
This document serves to define the problem of bootstrapping. Bootstrapping is defined as the process of obtaining enough information at the mobile node that it can successfully register with an appropriate home agent.
本文档用于定义引导问题。引导被定义为在移动节点上获取足够信息的过程，以使其能够成功地向适当的归属代理注册。
The requirements for bootstrapping could consider various scenarios/network deployment issues. It is the basic assumption of this document that certain minimal parameters (seed information) are available to the mobile node to aid in bootstrapping. The exact seed information available differs depending on the deployment scenario. This document describes various deployment scenarios and provides a set of minimal parameters that are available in each deployment scenario.
自举的要求可以考虑各种场景/网络部署问题。本文档的基本假设是，移动节点可以使用某些最小参数（种子信息）来帮助引导。可用的确切种子信息因部署场景而异。本文档描述了各种部署场景，并提供了一组在每个部署场景中可用的最小参数。
This document stops short of suggesting the preferred solutions for how the mobile node should obtain information. Such details will be available from separate documents.
本文档没有就移动节点应如何获取信息提出首选解决方案。这些细节将从单独的文件中提供。
Mobile IPv6 [RFC3775] expects the mobile node to have a static home address, a home agent address (which can be derived from an anycast address), and a security association with a home agent (or multiple home agents).
移动IPv6[RFC3775]期望移动节点具有静态归属地址、归属代理地址（可从选播地址派生）以及与归属代理（或多个归属代理）的安全关联。
This static provisioning of information has various problems, as discussed in Section 5.
如第5节所述，这种静态信息提供存在各种问题。
The aim of this document is:
本文件的目的是：
o To define bootstrapping;
o 定义引导；
o To identify sample deployment scenarios where Mobile Internet Protocol version 6 (MIPv6) will be deployed, taking into account the relationship between the subscriber and the service provider; and
o 考虑到用户和服务提供商之间的关系，确定将部署移动互联网协议版本6（MIPv6）的示例部署场景；和
o To identify the minimal set of information required on the Mobile Node and in the network in order for the mobile node to obtain address and security credentials, to register with the home agent.
o 为了识别移动节点和网络上所需的最小信息集，以便移动节点获得地址和安全凭据，向归属代理注册。
Bootstrapping is defined as obtaining enough information at the mobile node that the mobile node can successfully register with an appropriate home agent. Specifically, this means obtaining the home agent address and home address, and for the mobile node and home agent to authenticate and mutually construct security credentials for Mobile IPv6.
引导被定义为在移动节点处获得足够的信息，以便移动节点能够成功地向适当的归属代理注册。具体地说，这意味着获得归属代理地址和归属地址，并让移动节点和归属代理对移动IPv6进行身份验证和相互构造安全凭据。
Typically, bootstrapping happens when a mobile node does not have all the information it needs to set up the Mobile IPv6 service. This includes, but is not limited to, situations in which the mobile node does not having any information when it boots up for the first time (out of the box), or does not retain any information during reboots.
通常，当移动节点没有设置移动IPv6服务所需的所有信息时，会发生引导。这包括但不限于以下情况：移动节点第一次启动时（开箱即用）没有任何信息，或者在重新启动期间没有保留任何信息。
Also, in certain scenarios, after the MN bootstraps for the first time (out of the box), the need for subsequent bootstrapping is implementation dependent. For instance, the MN may bootstrap every time it boots, bootstrap every time on prefix change, or bootstrap periodically to anchor to an optimal HA (based on distance, load, etc.).
此外，在某些场景中，在首次（开箱即用）MN引导之后，后续引导的需要取决于实现。例如，MN可以每次引导时引导，每次前缀更改时引导，或者周期性引导以锚定到最佳HA（基于距离、负载等）。
General mobility terminology can be found in [RFC3753]. The following additional terms are used here:
通用机动性术语可在[RFC3753]中找到。此处使用以下附加术语：
Trust relationship
信任关系
In the context of this document, trust relationship means that the two parties in question, typically the user of the mobile host and the mobility or access service authorizer, have some sort of prior contact in which the mobile node was provisioned with credentials. These credentials allow the mobile node to authenticate itself to the mobility or access service provider and to prove its authorization to obtain service.
在本文档的上下文中，信任关系意味着所讨论的双方，通常是移动主机的用户和移动或接入服务授权人，具有某种事先联系，其中移动节点被提供了凭证。这些凭证允许移动节点向移动或接入服务提供商认证自身，并证明其获得服务的授权。
Infrastructureless relationship
无基础设施关系
In the context of this document, an infrastructureless relationship is one in which the user of the mobile node and the mobility or access service provider have no previous contact and the mobile node is not required to supply credentials to authenticate and prove authorization for service. Mobility and/or network access service is provided without any authentication or authorization. Infrastructureless in this context does not mean that there is no network infrastructure, such as would be the case for an ad hoc network.
在本文档的上下文中，无基础设施关系是指移动节点的用户和移动或接入服务提供商之前没有联系，并且移动节点不需要提供凭证来认证和证明服务授权的关系。提供移动性和/或网络接入服务时无需任何认证或授权。在这种情况下，无基础设施并不意味着没有网络基础设施，如adhoc网络。
Credentials
资格证书
Data used by a mobile node to authenticate itself to a mobility or access network service authorizer and to prove authorization to receive service. User name/passwords, one time password cards, public/private key pairs with certificates, and biometric information are some examples.
移动节点使用的数据，用于向移动或接入网络服务授权方认证自身，并证明接收服务的授权。例如，带有一次/一次密码的生物识别卡，以及一些带有公钥/密码的生物识别卡。
ASA
ASA
Access Service Authorizer. A network operator that authenticates a mobile node and establishes the mobile node's authorization to receive Internet service.
访问服务授权程序。一种网络运营商，对移动节点进行认证，并建立移动节点接收互联网服务的授权。
ASP
ASP
Access Service Provider. A network operator that provides direct IP packet forwarding to and from the end host.
访问服务提供商。提供与终端主机之间的直接IP数据包转发的网络运营商。
Serving Network Access Provider
服务网络接入提供商
A network operator that is the mobile node's ASP but not its ASA. The serving network access provider may or may not additionally provide mobility service.
作为移动节点的ASP而不是其ASA的网络运营商。服务网络接入提供商可以也可以不另外提供移动服务。
Home Network Access Provider
家庭网络接入提供商
A network operator that is both the mobile node's ASP and ASA. The home network access provider may or may not additionally provide mobility service (note that this is a slightly different definition from that in RFC 3775).
同时作为移动节点的ASP和ASA的网络运营商。家庭网络接入提供商可以或不可以另外提供移动性服务（注意，这与RFC 3775中的定义稍有不同）。
IASP
IASP
Integrated Access Service Provider. A service provider that provides both authorization for network access and mobility service.
综合接入服务提供商。提供网络访问授权和移动服务的服务提供商。
MSA
硕士学位
Mobility Service Authorizer. A service provider that authorizes Mobile IPv6 service.
移动服务授权者。授权移动IPv6服务的服务提供商。
MSP
MSP
Mobility Service Provider. A service provider that provides Mobile IPv6 service. In order to obtain such service, the mobile node must be authenticated and prove authorization to obtain the service. Home Mobility Service Provider
移动服务提供商。提供移动IPv6服务的服务提供商。为了获得这样的服务，必须对移动节点进行身份验证并证明其获得服务的授权。家庭移动服务提供商
A MSP that both provides mobility service and authorizes it.
提供移动服务并对其进行授权的MSP。
Serving Mobility Service Provider
服务移动服务提供商
A MSP that provides mobility service but depends on another service provider to authorize it.
提供移动服务但依赖另一个服务提供商授权的MSP。
o A basic assumption in Mobile IPv6 [RFC3775] is that there is a trust relationship between the mobile node and its home agent(s). This trust relationship can be direct, or indirect through, for instance, an ASP that has a contract with the MSP. This trust relationship can be used to bootstrap the MN.
o 移动IPv6[RFC3775]中的一个基本假设是移动节点与其归属代理之间存在信任关系。这种信任关系可以是直接的，也可以是通过与MSP签订合同的ASP间接的。此信任关系可用于引导MN。
One typical way of verifying the trust relationship is using authentication, authorization, and accounting (AAA) infrastructure. In this document, two distinct uses of AAA are considered:
验证信任关系的一种典型方法是使用身份验证、授权和记帐（AAA）基础设施。本文件考虑了AAA的两种不同用途：
AAA for Network Access
AAA网络接入
This functionality provides authentication and authorization to access the network (obtain address and send/receive packets).
此功能提供访问网络的身份验证和授权（获取地址和发送/接收数据包）。
AAA for Mobility Service
移动服务AAA
This functionality provides authentication and authorization for mobility services.
此功能为移动服务提供身份验证和授权。
These functionalities may be implemented in a single entity or in different entities, depending on the service models described in Section 6 or deployment scenarios as described in Section 7.
这些功能可以在单个实体或不同实体中实现，具体取决于第6节中描述的服务模型或第7节中描述的部署场景。
o Some identifier, such as an Network Access Identifier (NAI), as defined in [RFC4283] or [RFC2794], is provisioned on the MN that permits the MN to identify itself to the ASP and MSP.
o 如[RFC4283]或[RFC2794]中所定义的一些标识符（例如网络访问标识符（NAI））被设置在MN上，其允许MN向ASP和MSP标识自己。
A solution to the bootstrapping problem has the following design goals:
引导问题的解决方案具有以下设计目标：
o The following information must be available at the end of bootstrapping, to enable the MN to register with the HA.
o 以下信息必须在引导结束时可用，以使MN能够向HA注册。
* MN's home agent address
* MN的国内代理地址
* MN's home address
* MN的家庭住址
* IPsec Security Association (SA) between MN and HA, Intenet Key Exchange Protocol (IKE) pre-shared secret between MN and HA
* MN和HA之间的IPsec安全关联（SA），MN和HA之间的Intenet密钥交换协议（IKE）预共享秘密
o The bootstrapping procedure can be triggered at any time, either by the MN or by the network. Bootstrapping can occur, for instance, due to administrative action, information going stale, or HA indicating the MN. Bootstrapping may be initiated even when the MN is registered with the HA and has all the required credentials. This may typically happen to refresh/renew the credentials.
o 可以随时由MN或网络触发引导过程。例如，由于管理操作、信息过时或指示MN的HA，可能会发生引导。即使MN已向HA注册并具有所有必需的凭据，也可以启动引导。通常，刷新/续订凭据时可能会发生这种情况。
o Subsequent protocol interaction (for example, updating the IPsec SA) can be executed between the MN and the HA itself without involving the infrastructure that was used during bootstrapping.
o 可以在MN和HA本身之间执行后续协议交互（例如，更新IPsec SA），而不涉及引导期间使用的基础设施。
o Solutions to the bootstrapping problem should enable storage of user-specific information on entities other than the home agent.
o 引导问题的解决方案应支持在除归属代理以外的实体上存储用户特定的信息。
o Solutions to the bootstrapping problem should not exclude storage of user-specific information on entities other than the home agent.
o 引导问题的解决方案不应排除在除归属代理以外的实体上存储用户特定信息。
o Configuration information which is exchanged between the mobile node and the home agent must be secured using integrity and replay protection. Confidentiality protection should be provided if necessary.
o 必须使用完整性和重播保护来保护移动节点和归属代理之间交换的配置信息。如有必要，应提供保密保护。
o The solution should be applicable to all feasible deployment scenarios that can be envisaged, along with the relevant authentication/authorization models.
o 该解决方案应适用于可以设想的所有可行部署场景，以及相关的身份验证/授权模型。
This following issues are clearly outside the scope of bootstrapping:
以下问题显然超出了引导的范围：
o Home prefix renumbering is not explicitly supported as part of bootstrapping. If the MN executes the bootstrap procedures every time it powers on (as opposed to caching state information from previous bootstrap process), then home network renumbering is taken care of automatically.
o 引导过程中不明确支持主前缀重新编号。如果MN在每次通电时都执行引导过程（与缓存以前引导过程中的状态信息相反），则家庭网络重新编号将自动完成。
o Bootstrapping in the absence of a trust relationship between MN and any provider is not considered.
o 在MN和任何提供者之间没有信任关系的情况下，不考虑引导。
The default bootstrapping described in the Mobile IPv6 base specification [RFC3775] has a tight binding to the home addresses and home agent addresses.
移动IPv6基本规范[RFC3775]中描述的默认引导与主地址和主代理地址紧密绑定。
In this section, we discuss the problems caused by the currently tight binding to home addresses and home agent addresses.
在本节中，我们将讨论当前与家庭地址和家庭代理地址紧密绑定所导致的问题。
Currently, the home agent uses the mobile node's home address for authorization. When manual keying is used, this happens through the
目前，归属代理使用移动节点的归属地址进行授权。使用手动键控时，通过
security policy database, which specifies that a certain security association may only be used for a specific home address. When dynamic keying is used, the home agent ensures that the IKE Phase 1 identity is authorized to request security associations for the given home address. Mobile IPv6 uses IKEv1, which is unable to update the security policy database according to a dynamically assigned home address. As a result, static home address assignment is really the only home address configuration technique compatible with the base specification.
安全策略数据库，它指定某个安全关联只能用于特定的家庭地址。当使用动态密钥时，归属代理确保IKE阶段1身份被授权为给定的归属地址请求安全关联。移动IPv6使用IKEv1，它无法根据动态分配的家庭地址更新安全策略数据库。因此，静态家庭地址分配实际上是唯一与基本规范兼容的家庭地址配置技术。
However, support for dynamic home address assignment would be desirable for the following reasons:
但是，出于以下原因，支持动态家庭地址分配是可取的：
Dynamic Host Configuration Protocol (DHCP)-based address assignment. Some providers may want to use DHCPv6 or other dynamic address assignment (e.g., IKEv2) from the home network to configure home addresses.
基于动态主机配置协议（DHCP）的地址分配。一些提供商可能希望使用DHCPv6或来自家庭网络的其他动态地址分配（例如，IKEv2）来配置家庭地址。
Recovery from a duplicate address collision. It may be necessary to recover from a collision of addresses on the home network by one of the mobile nodes changing its home address.
从重复地址冲突中恢复。可能需要通过移动节点之一改变其归属地址来从归属网络上的地址冲突中恢复。
Addressing privacy. It may be desirable to establish randomly generated addresses as in [RFC3041] and use them for a short period of time. Unfortunately, current protocols make it possible to use such addresses only from the visited network. As a result, these addresses cannot be used for communications lasting longer than the attachment to a particular visited network.
解决隐私问题。可能需要建立[RFC3041]中所述的随机生成的地址，并在短时间内使用它们。不幸的是，目前的协议使得只能从访问的网络使用这些地址成为可能。因此，这些地址不能用于比连接到特定访问网络的时间更长的通信。
Ease of deployment. In order to simplify the deployment of Mobile IPv6, it is desirable to free users and administrators from the task of allocating home addresses and specifying them in the security policy database. This is consistent with the general IPv6 design goal of using autoconfiguration wherever possible.
易于部署。为了简化移动IPv6的部署，希望用户和管理员不再需要分配家庭地址并在安全策略数据库中指定它们。这与尽可能使用自动配置的一般IPv6设计目标是一致的。
Prefix changes in the home network. The Mobile IPv6 specification contains support for a mobile node to autoconfigure a home address as based on its discovery of prefix information on the home subnet [RFC3775]. Autoconfiguration in case of network renumbering is done by replacing the existing network prefix with the new network prefix.
家庭网络中的前缀更改。移动IPv6规范支持移动节点根据其在归属子网上发现的前缀信息自动配置归属地址[RFC3775]。网络重新编号时的自动配置是通过将现有网络前缀替换为新网络前缀来完成的。
Subsequently, the MN needs to update the mobility binding in the HA to register the newly configured Home Address. However, the MN may not be able to register the newly configured address with the HA if a security association related to that reconfigured Home Address does not exist in the MN and the HA. This situation is not handled in the current MIPv6 specification [RFC3775].
随后，MN需要更新HA中的移动性绑定以注册新配置的家庭地址。然而，如果MN和HA中不存在与重新配置的家庭地址相关的安全关联，则MN可能无法向HA注册新配置的地址。当前的MIPv6规范[RFC3775]没有处理这种情况。
Currently, the address of the home agent is specified in the security policy database. Support for multiple home agents requires the configuration of multiple security policy database entries.
目前，归属代理的地址在安全策略数据库中指定。支持多个主代理需要配置多个安全策略数据库条目。
However, support for dynamic home agent assignment would be desirable for the following reasons:
但是，出于以下原因，需要支持动态归属代理分配：
Home agent discovery. The Mobile IPv6 specification contains support for a mobile node to autoconfigure a home agent address as based on a discovery protocol [RFC3775].
Home agent discovery。移动IPv6规范支持移动节点根据发现协议自动配置归属代理地址[RFC3775]。
Independent network management. An MSP may want to assign home agents dynamically in different subnets; for instance, not require that a roaming mobile node have a fixed home subnet.
独立的网络管理。MSP可能希望在不同的子网中动态地分配归属代理；例如，不要求漫游移动节点具有固定的归属子网。
Local home agents. The mobile node's MSP may want to allow the serving MSP to assign a local home agent for the mobile node. This is useful from the point of view of communications efficiency and has also been mentioned as one approach to support location privacy.
当地家庭代理。移动节点的MSP可能希望允许服务MSP为移动节点分配本地归属代理。从通信效率的角度来看，这是有用的，并且也被作为支持位置隐私的一种方法提到。
Ease of deployment. In order to simplify the deployment of Mobile IPv6, it is desirable to free users and administrators from the task of allocating home agent addresses in a static manner. Moreover, an MSP may want to have a dynamic home agent assignment mechanism to load balance users among home agents located on different links.
易于部署。为了简化移动IPv6的部署，希望用户和管理员不必以静态方式分配归属代理地址。此外，MSP可能希望具有动态归属代理分配机制，以在位于不同链路上的归属代理之间负载平衡用户。
The home agent discovery protocol does not support an "opportunistic" or local discovery mechanisms in an ASP's local access network. It is expected that the mobile node must know the prefix of the home subnet in order to be able to discover a home agent. It must either obtain that information through prefix update or have it statically configured. A more typical pattern for inter-domain service discovery in the Internet is that the client (mobile node in this case) knows the domain name of the service and uses DNS to find the server in the visited domain. For local service discovery, DHCP is typically used.
归属代理发现协议不支持ASP的本地访问网络中的“机会主义”或本地发现机制。期望移动节点必须知道归属子网的前缀，以便能够发现归属代理。它必须通过前缀更新获取该信息，或者对其进行静态配置。Internet中域间服务发现的更典型模式是，客户端（本例中为移动节点）知道服务的域名，并使用DNS在访问的域中查找服务器。对于本地服务发现，通常使用DHCP。
As described earlier, new addresses invalidate configured security policy databases and authorization tables. Regardless of the specific protocols used, there is a need for either an automatic system for updating the security policy entries or manual configuration. These requirements apply to both home agents and
如前所述，新地址使配置的安全策略数据库和授权表无效。无论使用何种特定协议，都需要自动系统更新安全策略条目或手动配置。这些要求适用于家庭代理和家庭代理
mobile nodes, but it cannot be expected that mobile node users are capable of performing the required tasks.
移动节点，但不能期望移动节点用户能够执行所需的任务。
The current IKEv1-based dynamic key exchange protocol, described in [RFC3776], has no integration with backend authentication, authorization, and accounting techniques unless the authentication credentials and trust relationships use certificates or pre-shared secrets.
[RFC3776]中描述的当前基于IKEv1的动态密钥交换协议未与后端身份验证、授权和记帐技术集成，除非身份验证凭据和信任关系使用证书或预共享机密。
Certificates are not easily supported by traditional AAA infrastructures. Where a traditional AAA infrastructure is used, the home agent is not able to leverage authentication and authorization information established between the mobile node, the foreign AAA server, and the home AAA server. This would be desirable when the mobile node gains access to the foreign network, in order to authenticate the mobile node's identity and determine whether the mobile node is authorized for mobility service.
传统AAA基础架构不容易支持证书。在使用传统AAA基础设施的情况下，归属代理无法利用移动节点、外部AAA服务器和归属AAA服务器之间建立的身份验证和授权信息。当移动节点获得对外部网络的访问时，这将是期望的，以便认证移动节点的身份并确定移动节点是否被授权用于移动服务。
The lack of connection to the AAA infrastructure also means that the home agent does not know where to send accounting records at appropriate times during the mobile node's session, as determined by the business relationship between the MSP and the mobile node's owner.
缺少与AAA基础设施的连接还意味着归属代理不知道在移动节点会话期间的适当时间向何处发送记帐记录，这由MSP和移动节点的所有者之间的业务关系确定。
Presumably, some backend AAA protocol between the home agent and home AAA could be utilized, but IKEv1 does not contain support for exchanging full AAA credentials with the mobile node. It is worthwhile to note that IKEv2 provides this feature.
据推测，可以使用归属代理和归属AAA之间的一些后端AAA协议，但IKEv1不支持与移动节点交换完整的AAA凭据。值得注意的是，IKEv2提供了此功能。
The description of the protocol to push prefix information to mobile nodes in Section 10.6 of [RFC3775] has an implicit assumption that the mobile node is active and taking IP traffic. In fact, many, if not most, mobile devices will be in a low power "dormant mode" to save battery power, or will even be switched off, so they will miss any propagation of prefix information. As a practical matter, if this protocol is used, an MSP will need to keep the old prefix around and handle any queries to the old home agent anycast address on the old subnet, whereby the mobile node asks for a new home agent as described in Section 11.4, until all mobile nodes are accounted for. Even then, since some mobile nodes are likely to be turned off for
[RFC3775]第10.6节中对将前缀信息推送到移动节点的协议的描述隐含了一个假设，即移动节点处于活动状态并接受IP流量。事实上，许多（如果不是大多数的话）移动设备将处于低功耗“休眠模式”以节省电池电量，甚至将被关闭，因此它们将错过前缀信息的任何传播。实际上，如果使用此协议，MSP将需要保留旧前缀，并处理对旧子网上旧归属代理选播地址的任何查询，从而移动节点按照第11.4节中的描述请求新归属代理，直到所有移动节点都被计算在内。即使如此，由于某些移动节点可能会因以下原因而关闭：
long periods, some owners would need to be contacted by other means, reducing the utility of the protocol.
长期以来，需要通过其他方式联系某些所有者，从而降低协议的效用。
Bootstrapping does not explicitly try to solve this problem of home network renumbering when MN is in dormant mode. If the MN can configure itself after it 'comes back on' by reinitiating the bootstrapping process, then network renumbering problem is fixed as a side effect.
当MN处于休眠模式时，引导并没有明确尝试解决家庭网络重新编号的问题。如果MN可以在“重新启动”后通过重新启动引导过程进行自我配置，则网络重新编号问题作为副作用得到修复。
This section defines some terms as they pertain to authentication and practical network deployment/roaming scenarios. This description lays the groundwork for Section 7. The focus is on the 'service' model since, ultimately, it is the provider providing the service that wants to authenticate the mobile (and vice versa for mutual authentication between provider and the user of the service).
本节定义了一些与身份验证和实际网络部署/漫游场景相关的术语。本说明为第7节奠定了基础。重点在于“服务”模型，因为最终是提供服务的提供商想要对移动设备进行身份验证（反之亦然，服务提供商和用户之间的相互身份验证）。
Network access service enables a host to send and receive IP packets on the Internet or an intranet. IP address configuration and IP packet forwarding capabilities are required to deliver this service. A network operator providing this service is called an access service provider (ASP). An ASP can, for example, be a commercial ASP, the IT department of an enterprise network, or the maintainer of a home (residential) network.
网络访问服务使主机能够在Internet或intranet上发送和接收IP数据包。提供此服务需要IP地址配置和IP数据包转发功能。提供此服务的网络运营商称为访问服务提供商（ASP）。例如，ASP可以是商业ASP、企业网络的IT部门或家庭（住宅）网络的维护者。
If the mobile node is not directly usable for communication at the current location of the MN in which network access service is provided by its home ASP, the mobile node is roaming. In this case, the home ASP acts as the access service authorizer, but the actual network access is provided by the serving network access provider. During the authentication and authorization prior to the mobile nodes having Internet access, the serving network access provider may simply act as a routing agent for authentication and authorization back to the access service authorizer, or it may require an additional authentication and authorization step itself. An example of a roaming situation is when a business person is using a hotspot service in an airport and the hotspot service provider has a roaming agreement with the business person's cellular provider. In that case, the hotspot network is acting as the serving network access provider, and the cellular network is acting as the access service authorizer. When the business person moves from the hotspot network to the cellular network, the cellular network is both the home access service provider and the access service authorizer.
如果移动节点在其归属ASP提供网络接入服务的MN的当前位置处不能直接用于通信，则移动节点正在漫游。在这种情况下，家庭ASP充当访问服务授权人，但实际网络访问由服务网络访问提供商提供。在移动节点具有因特网接入之前的认证和授权期间，服务网络接入提供商可以简单地充当路由代理，用于将认证和授权返回到接入服务授权者，或者其本身可能需要额外的认证和授权步骤。漫游情况的一个示例是，当业务人员在机场使用热点服务，并且热点服务提供商与业务人员的蜂窝服务提供商有漫游协议时。在这种情况下，热点网络充当服务网络接入提供商，蜂窝网络充当接入服务授权者。当业务人员从热点网络移动到蜂窝网络时，蜂窝网络既是家庭接入服务提供商又是接入服务授权人。
Mobility service using Mobile IPv6 is conceptually and possibly also in practice separate from network access service, though of course network access is required prior to providing mobility. Mobile IPv6
使用移动IPv6的移动服务在概念上是独立于网络访问服务的，在实践中也可能是独立于网络访问服务的，尽管在提供移动之前当然需要网络访问。移动IPv6
service enables an IPv6 host to maintain its reachability despite changing its network attachment point (subnets). A network operator providing Mobile IPv6 service is called a mobility service provider (MSP). Granting Mobile IPv6 service requires that a host authenticate and prove authorization for the service. A network operator that authenticates a mobile node and authorizes mobility service is called a mobility service authorizer (MSA). If both types of operation are performed by the same operator, that operator is called a home mobility service provider. If authentication and authorization is provided by one operator and the actual service is provided by another, the operator providing the service is called the serving mobility service provider. The serving MSP must contact the mobile node's mobility service authorizer to check the mobile node's authorization prior to granting mobility service.
该服务使IPv6主机能够在更改其网络连接点（子网）的情况下保持其可访问性。提供移动IPv6服务的网络运营商称为移动服务提供商（MSP）。授予移动IPv6服务需要主机对该服务进行身份验证和证明授权。对移动节点进行认证并授权移动服务的网络运营商称为移动服务授权人（MSA）。如果两种类型的操作都由同一运营商执行，则该运营商称为家庭移动服务提供商。如果认证和授权由一个运营商提供，而实际服务由另一个运营商提供，则提供服务的运营商称为服务移动服务提供商。在授予移动服务之前，服务MSP必须联系移动节点的移动服务授权人以检查移动节点的授权。
The service model defined here clearly separates the entity providing the service from the entity that authenticates and authorizes the service. In the case of basic network access, this supports the traditional and well-known roaming model, in which inter-operator roaming agreements allow a host to obtain network access in areas where their home network access provider does not have coverage. In the case of mobility service, this allows a roaming mobile node to obtain mobility service in the local operator's network while having that service authorized by the home operator. The service model also allows mobility service and network access service to be provided by different entities. This allows a network operator with no wireless access, such as, for example, an enterprise network operator, to deploy a Mobile IPv6 home agent for mobility service while the actual wireless network access is provided by the serving network access providers with which the enterprise operator has a contract. Here are some other possible combinations of ASPs and MSPs:
这里定义的服务模型清楚地将提供服务的实体与认证和授权服务的实体分开。在基本网络接入的情况下，这支持传统的和众所周知的漫游模式，在这种模式中，运营商间漫游协议允许主机在其家庭网络接入提供商不覆盖的区域获得网络接入。在移动服务的情况下，这允许漫游移动节点在本地运营商的网络中获得移动服务，同时由归属运营商授权该服务。该服务模型还允许不同实体提供移动服务和网络接入服务。这允许不具有无线接入的网络运营商（例如，企业网络运营商）部署用于移动服务的移动IPv6归属代理，而实际无线网络接入由与企业运营商有合同的服务网络接入提供商提供。以下是ASP和MSP的一些其他可能组合：
o The serving ASP might be the home ASP. Similarly, the serving MSP might be the home MSP.
o 服务ASP可能是主ASP。类似地，服务MSP可以是主MSP。
o The home ASP and the home MSP may be the same operator, or not. When they are the same, the same set of credentials may be used for both services.
o 家庭ASP和家庭MSP可能是同一个操作员，也可能不是。当它们相同时，两个服务可以使用相同的凭据集。
o The serving ASP and the serving MSP may be the same operator, or not.
o 服务ASP和服务MSP可以是相同的操作员，也可以不是。
o It is possible that serving ASP and home MSP are the same operator.
o 服务ASP和家庭MSP可能是同一个操作员。
Similarly the home ASP and serving MSP may be the same. Also, the ASA and MSA may be the same.
类似地，家庭ASP和服务MSP可以是相同的。此外，ASA和MSA可能相同。
These entities and all combinations that are reasonable from a deployment perspective must be taken into consideration to solve the Mobile IPv6 bootstrapping problem. They impact home agent discovery, home address configuration, and mobile node-to-home agent authentication aspects.
为了解决移动IPv6引导问题，必须考虑这些实体以及从部署角度来看合理的所有组合。它们影响归属代理发现、归属地址配置和移动节点到归属代理身份验证方面。
This section describes the various network deployment scenarios. The various combinations of service providers described in Section 6 are considered.
本节介绍各种网络部署场景。考虑第6节中描述的各种服务提供商组合。
For each scenario, the underlying assumptions are described. The basic assumption is that there is a trust relationship between mobile user and the MSA. Typically, this trust relationship is between the mobile user and AAA in the MSA's network. Seed information needed to bootstrap the mobile node is considered in two cases:
对于每个场景，描述了基本假设。基本假设是移动用户和MSA之间存在信任关系。通常，这种信任关系在移动用户和MSA网络中的AAA之间。在两种情况下考虑引导移动节点所需的种子信息：
o AAA authentication is mandatory for network access.
o AAA身份验证对于网络访问是强制性的。
o AAA authentication is not part of network access.
o AAA身份验证不是网络访问的一部分。
The seed information is described further in Section 8.
第8节将进一步描述种子信息。
Many commercial deployments are based on the assumption that mobile nodes have a subscription with a service provider. In this scenario the MN has a subscription with an MSA, also called the home MSP, for Mobile IPv6 service. As stated in Section 6, the MSP is responsible for setting up a home agent on a subnet that acts as a Mobile IPv6 home link. As a consequence, the home MSP should explicitly authorize and control the whole bootstrapping procedure.
许多商业部署都基于这样的假设，即移动节点与服务提供商进行了订阅。在这种情况下，MN有一个MSA（也称为家庭MSP）订阅，用于移动IPv6服务。如第6节所述，MSP负责在作为移动IPv6家庭链路的子网上设置家庭代理。因此，家庭MSP应该明确授权并控制整个引导过程。
Since the MN is assumed to have a pre-established trust relationship with its home provider, it must be configured with an identity and credentials; for instance, an NAI and a shared secret by some out-of-band means (i.e., manual configuration) before bootstrapping.
由于假定MN与其归属提供商具有预先建立的信任关系，因此必须使用身份和凭证对其进行配置；例如，在引导之前，通过一些带外方式（即，手动配置）获取NAI和共享秘密。
In order to guarantee ubiquitous service, the MN should be able to bootstrap MIPv6 operations with its home MSP from any possible access location, such as an open network or a network managed by an ASP, that may be different from the MSP and that may not have any pre-established trust relationship with it.
为了保证无处不在的服务，MN应该能够从任何可能的访问位置（例如开放网络或由ASP管理的网络）用其主MSP引导MIPv6操作，这些位置可能不同于MSP，并且可能与MSP没有任何预先建立的信任关系。
In this scenario, the ASA and MSA are the same entity. The MN has security credentials for access to the network, and these credentials can also be used to bootstrap MIPv6.
在这种情况下，ASA和MSA是同一个实体。MN具有访问网络的安全凭据，这些凭据还可用于引导MIPv6。
Figure 1 describes an AAA design example for integrated ASP scenario.
图1描述了集成ASP场景的AAA设计示例。
+----------------------------+
| IASP(ASA+MSA) |
+----+ +-----+ +----+ |
| MN |--- | NAS | | HA | |
+----+ +-----+ +----+ |
| \ \ |
| \ +------+ \ +-------+ |
| -|AAA-NA| -|AAA-MIP| |
| +------+ +-------+ |
+----------------------------+
+----------------------------+
| IASP(ASA+MSA) |
+----+ +-----+ +----+ |
| MN |--- | NAS | | HA | |
+----+ +-----+ +----+ |
| \ \ |
| \ +------+ \ +-------+ |
| -|AAA-NA| -|AAA-MIP| |
| +------+ +-------+ |
+----------------------------+
NAS: Network Access Server AAA-NA: AAA for network access AAA-MIP: AAA for Mobile IP service
NAS:网络访问服务器AAA-NA:AAA用于网络访问AAA-MIP:AAA用于移动IP服务
Figure 1. Integrated ASP network
图1。集成ASP网络
Mobility service has traditionally been provided by the same entity that authenticates and authorizes the subscriber for network access. This is certainly the only model supported by the base Mobile IPv6 specification.
传统上，移动服务由同一实体提供，该实体对用户进行网络访问的身份验证和授权。这当然是基本移动IPv6规范支持的唯一模型。
In the third-party mobility service provider scenario, the subscription for mobility service is made with one entity (the MSA, is for instance, a corporate), but the actual mobility service is provided by yet another entity (such as an operator specializing in this service, the serving MSP). These two entities have a trust relationship. Transitive trust among the mobile node and these two entities may be used to assure the participants that they are dealing with trustworthy peers.
在第三方移动服务提供商场景中，移动服务的订阅由一个实体（例如，MSA是一家公司）进行，但实际的移动服务由另一个实体（例如专门从事此服务的运营商，服务MSP）提供。这两个实体具有信任关系。移动节点和这两个实体之间的可传递信任可用于向参与者保证他们正在与可信的对等方打交道。
This arrangement is similar to the visited - home operator roaming arrangement for network access.
这种安排类似于到访家庭运营商的网络接入漫游安排。
Figure 2 describes an example of a network for the third-party MSP scenario.
图2描述了第三方MSP场景的网络示例。
+--------------+ +--------+
| | |Serving |
| ASP | | MSP |
+----+ +-----+ | | +----+ |
| MN |--- | NAS | | | | HA | | +-------------------+
+----+ +-----+ |===| +----+ | | MSA |
| \ | | \ || (e.g., corporate NW)|
| \ +------+ | | \ | +-------+ |
| -|AAA-NA| | | -------|AAA-MIP| |
| +------+ | | | | +-------+ |
+------------ + +--------+ +-------------------+
+--------------+ +--------+
| | |Serving |
| ASP | | MSP |
+----+ +-----+ | | +----+ |
| MN |--- | NAS | | | | HA | | +-------------------+
+----+ +-----+ |===| +----+ | | MSA |
| \ | | \ || (e.g., corporate NW)|
| \ +------+ | | \ | +-------+ |
| -|AAA-NA| | | -------|AAA-MIP| |
| +------+ | | | | +-------+ |
+------------ + +--------+ +-------------------+
Figure 2. Third-Party MSP network
图2。第三方MSP网络
Infrastructure refers to network entities like AAA, Public-Key Infrastructure (PKI), and Home Location Register (HLR). "Infrastructure-less" implies that there is no dependency on any elements in the network with which the user has any form of trust relationship.
基础设施是指网络实体，如AAA、公钥基础设施（PKI）和归属位置寄存器（HLR）。“无基础设施”意味着用户与网络中的任何元素没有任何形式的信任关系。
In such a scenario, there is absolutely no relationship between host and infrastructure.
在这种情况下，主机和基础结构之间绝对没有关系。
A good example of infrastructure-less environment for MIPv6 bootstrapping is the IETF network at IETF meetings. It is possible that there could be MIP6 service available on this network (i.e., a MIPv6 HA). However, there is not really any AAA infrastructure or, for that matter, any trust relationship that a user attending the meeting has with any entity in the network.
MIPv6引导的无基础设施环境的一个很好的例子是IETF会议上的IETF网络。此网络上可能有MIP6服务可用（即，MIPv6 HA）。然而，实际上并不存在任何AAA基础设施，或者，就这一点而言，出席会议的用户与网络中的任何实体都没有任何信任关系。
This specific scenario is not supported in this document. The reason for this is described in Section 9.
本文档不支持此特定场景。原因在第9节中描述。
The following is a list of parameters that are used as the seed for the bootstrapping procedure. The parameters vary depending on whether authentication for network access is independent of authentication for mobility services. If different client identities are used for network access and mobility services, authentication for network access is independent of authentication for mobility services.
以下是用作引导过程种子的参数列表。根据网络访问的身份验证参数是否独立，身份验证参数会有所不同。如果网络访问和移动服务使用不同的客户端身份，则网络访问的身份验证独立于移动服务的身份验证。
o Parameter Set 1
o 参数集1
In this case, authentication for network access is independent of authentication for mobility services.
在这种情况下，网络访问的身份验证独立于移动服务的身份验证。
If the home agent address is not known to the mobile node, the following parameter is needed for discovering the home agent address:
如果移动节点不知道归属代理地址，则需要以下参数来查找归属代理地址：
* The domain name or Fully Qualified Domain Name (FQDN) of the home agent
* 归属代理的域名或完全限定域名（FQDN）
This parameter may be derived in various ways, such as (but not limited to) static configuration, use of the domain name from the network access NAI (even if AAA for network access is not otherwise used), or use of the domain name of the serving ASP, where the domain name may be obtained via DHCP in the serving ASP.
该参数可以以各种方式导出，例如（但不限于）静态配置、使用来自网络访问NAI的域名（即使没有使用用于网络访问的AAA），或者使用服务ASP的域名，其中域名可以通过服务ASP中的DHCP获得。
If the home agent address is not known but the home subnet prefix is known, Dynamic Home Agent Address Discovery of Mobile IPv6 may be used for discovering the home agent address, and the above parameter may not be used.
如果归属代理地址未知，但归属子网前缀已知，则可以使用移动IPv6的动态归属代理地址发现来发现归属代理地址，并且可以不使用上述参数。
When the home agent address is known to the mobile node, the following parameter is needed for performing mutual authentication between the mobile node and the home agent by using IKE:
当移动节点知道归属代理地址时，需要以下参数来使用IKE在移动节点和归属代理之间执行相互认证：
* IKE credentials (*)
* IKE凭据（*）
In the case where the home agent does not have the entire set of IKE credentials, the home agent may communicate with another entity (for example, an AAA server) to perform mutual authentication in IKE. In such a case, the IKE credentials include the credentials used between the mobile node and the other entity. In the case where an AAA protocol is used for the communication between the home agent and the other entity during the IKE procedure, AAA for Mobile IPv6 service may be involved in IKE. If the authentication protocol [RFC4285] is used, the shared key-based security association with the home agent is needed.
在归属代理不具有整套IKE凭证的情况下，归属代理可以与另一实体（例如，AAA服务器）通信以在IKE中执行相互认证。在这种情况下，IKE凭证包括移动节点和另一实体之间使用的凭证。在AAA协议用于在IKE过程期间归属代理和其他实体之间的通信的情况下，用于移动IPv6服务的AAA可涉及IKE。如果使用身份验证协议[RFC4285]，则需要与归属代理建立基于共享密钥的安全关联。
o Parameter Set 2
o 参数集2
In this case, some dependency exists between authentication for network access and authentication for mobility services in that a security association that is established as a result of authentication for network access is re-used for authentication for mobility services.
在这种情况下，在网络接入的认证和移动服务的认证之间存在某种依赖性，因为作为网络接入的认证的结果而建立的安全关联被重新用于移动服务的认证。
All required information, including IKE credentials, is bootstrapped from the following parameter:
所有必需的信息（包括IKE凭据）都是从以下参数引导的：
* Network access credentials(*)
* 网络访问凭据（*）
(*) A pair of an NAI and a pre-shared secret is an example of a set of credentials. A pair of an NAI and a public key, which may be provided as a digital certificate, is another example of a set of credentials.
（*）一对NAI和一个预共享密钥是一组凭证的示例。可以作为数字证书提供的一对NAI和公钥是一组凭证的另一个示例。
There are two aspects of security for the Mobile IPv6 bootstrapping problem:
移动IPv6引导问题的安全性有两个方面：
1. The security requirements imposed on the outcome of the bootstrapping process by RFC 3775 and other RFCs used by Mobile IPv6 for security.
1. RFC 3775和移动IPv6用于安全的其他RFC对引导过程结果施加的安全要求。
2. The security of the bootstrapping process itself, in the sense of threats to the bootstrapping process imposed by active or passive attackers.
2. 引导过程本身的安全性，从主动或被动攻击者对引导过程造成威胁的角度来看。
Note that the two are related; if the bootstrapping process is compromised, the level of security required by RFC 3775 may not be achieved.
请注意，这两者是相关的；如果引导过程被破坏，可能无法达到RFC 3775所要求的安全级别。
The following two sections discuss these issues.
以下两节将讨论这些问题。
The Mobile IPv6 specification in RFC 3775 requires the establishment of a collection of IPsec SAs between the home agent and mobile node to secure the signaling traffic for Mobile IP, and, optionally, also to secure data traffic. The security of an IPsec SA required by the relevant IPsec RFCs must be quite strong. Provisioning of keys and other cryptographic material during the establishment of the SA through bootstrapping must be done in a manner such that authenticity is proved and confidentiality is ensured. In addition, the generation of any keying material or other cryptographic material for the SA must be done in a way such that the probability of compromise after the SA is in place is minimized. The best way to minimize the probability of such a compromise is to have the cryptographic material only known or calculable by the two end nodes that share the SA -- in this case, the home agent and mobile node. If other parties are involved in establishing the SA (through key distribution, for example) the process should follow the constraints designed to provide equivalent security.
RFC 3775中的移动IPv6规范要求在归属代理和移动节点之间建立IPsec SA的集合，以保护移动IP的信令流量，并且还可以选择保护数据流量。相关IPsec RFC所要求的IPsec SA的安全性必须非常强。在通过自举建立SA期间，密钥和其他加密材料的提供必须以证明真实性和确保机密性的方式进行。此外，为SA生成任何键控材料或其他密码材料的方式必须确保SA就位后的泄露概率最小化。将这种妥协的可能性降至最低的最佳方法是让共享SA的两个终端节点（在本例中为归属代理和移动节点）只知道或可计算加密材料。如果其他各方参与建立SA（例如，通过密钥分发），则流程应遵循旨在提供同等安全性的约束。
RFC 3775 also requires a trust relationship, as defined in Section 1.3, between the mobile node and its home agent(s). This is necessary, for instance, to ensure that fraudulent mobile nodes that attempt to flood other mobile nodes with traffic be not only shut off but tracked down. An infrastructureless relationship as defined in Section 1.3 does not satisfy this requirement. Any bootstrapping solution must include a trust relationship between mobile node and mobility service provider. Solutions that depend on an infrastructureless relationship are out of scope for bootstrapping.
RFC 3775还要求在移动节点及其归属代理之间建立第1.3节中定义的信任关系。例如，这是必要的，以确保尝试向其他移动节点大量发送流量的欺诈性移动节点不仅被关闭，而且被跟踪。第1.3节中定义的无基础设施关系不满足此要求。任何引导解决方案都必须包括移动节点和移动服务提供商之间的信任关系。依赖于无基础结构关系的解决方案不适用于引导。
Another requirement is that a home address be authorized to one specific host at a time. RFC 3775 requires this so that misbehaving mobile nodes can be shut down. This implies that, in addition to the IPsec SA, the home agent must somehow authorize the mobile node for a home address. The authorization can be either implicit (for example, as a side effect of the authentication for mobility service) or explicit. The authorization can either be done at the time the SA is created or be dynamically managed through a first come, first served allocation policy.
另一个要求是家庭地址必须一次授权给一个特定的主机。RFC3775要求这样才能关闭行为不端的移动节点。这意味着，除了IPsec SA之外，归属代理还必须以某种方式授权移动节点获得归属地址。授权可以是隐式的（例如，作为移动服务认证的副作用），也可以是显式的。授权可以在创建SA时完成，也可以通过先到先服务的分配策略进行动态管理。
Various attacks are possible on the bootstrapping process itself. These attacks can compromise the process such that the RFC 3775 requirements for Mobile IP security are not met, or they can serve simply to disrupt the process such that bootstrapping cannot be completed. Here are some possible attacks:
引导过程本身可能受到各种攻击。这些攻击可能会破坏该过程，从而无法满足RFC 3775对移动IP安全的要求，或者它们可能只是破坏该过程，从而无法完成引导。以下是一些可能的攻击：
o An attacking network entity purporting to offer the mobile node a legitimate home agent address or bootstrapping for the IPsec SAs may instead offer a bogus home agent address or configure bogus SAs that allow the home agent to steal the mobile node's traffic or otherwise disrupt the mobile node's mobility service.
o 声称为移动节点提供合法的归属代理地址或IPsec SAs引导的攻击网络实体可以改为提供虚假的归属代理地址或配置虚假的SAs，以允许归属代理窃取移动节点的流量或以其他方式中断移动节点的移动服务。
o An attacking mobile node may attempt to steal mobility service by offering up fake credentials to a bootstrapping network entity or otherwise disrupting the home agent's ability to offer mobility service.
o 攻击移动节点可能试图通过向自举网络实体提供虚假凭证或以其他方式破坏归属代理提供移动服务的能力来窃取移动服务。
o A man in the middle on the link between the mobile node and the bootstrapping network entity could steal credentials or other sensitive information and use that to steal mobility service or deny it to the legitimate owner of the credentials. Refer to Section 7.15 in [RFC3748] and [AAA-EAP-LLA] for further information.
o 中间人在移动节点和引导网络实体之间的链路上可以窃取凭据或其他敏感信息，并使用该信息来窃取移动性服务或将其拒绝给凭证的合法所有者。更多信息，请参阅[RFC3748]和[AAA-EAP-LLA]中的第7.15节。
o An attacker could arrange for a distributed denial-of-service attack on the bootstrapping entity, to disrupt legitimate users from bootstrapping.
o 攻击者可以在引导实体上安排分布式拒绝服务攻击，以中断合法用户的引导。
In addition to these attacks, there are other considerations that are important in achieving a good security design. As mobility and network access authentication are separate services, keys generated for these services need to be cryptographically separate, to be separately named, and to have separate lifetimes. This needs to be achieved even though the keys are generated from the same authentication credentials. This is necessary because a mobile node must be able to move from one serving (or roaming) network access provider to another without needing to change its mobility access provider. Finally, basic cryptographic processes must provide for multiple algorithms in order to accommodate the widely varying deployment needs; the need for replacement of algorithms when attacks become possible must also be considered in the design.
除了这些攻击之外，在实现良好的安全设计时还有其他重要的考虑因素。由于移动性和网络访问认证是独立的服务，因此为这些服务生成的密钥需要以加密方式分离、单独命名，并且具有单独的生命周期。即使密钥是从相同的身份验证凭据生成的，也需要实现这一点。这是必要的，因为移动节点必须能够从一个服务（或漫游）网络接入提供商移动到另一个，而无需更改其移动接入提供商。最后，基本密码过程必须提供多种算法，以适应广泛变化的部署需求；设计中还必须考虑在可能发生攻击时更换算法的需要。
This contribution is a joint effort of the problem statement design team of the Mobile IPv6 WG. The contributors include Basavaraj Patil, Gerardo Giaretta, Jari Arkko, James Kempf, Yoshihiro Ohba, Ryuji Wakikawa, Hiroyuki Ohnishi, Mayumi Yanagiya Samita Chakrabarti, Gopal Dommety, Kent Leung, Alper Yegin, Hannes Tschofenig, Vijay Devarapalli, and Kuntal Chowdury.
这一贡献是移动IPv6工作组问题陈述设计团队的共同努力。贡献者包括巴萨瓦拉吉·帕蒂尔、杰拉尔多·贾雷塔、贾里·阿尔科、詹姆斯·坎普夫、大叶吉弘、柳川龙二、大西广幸、柳木雅三田·查克拉巴蒂、戈帕尔·多梅蒂、梁肯特、阿尔珀·叶金、汉内斯·茨霍芬尼、维杰·德瓦拉帕利和昆塔尔·乔杜里。
The design team members can be reached at the following email addresses:
可通过以下电子邮件地址联系设计团队成员：
Basavaraj Patil: basavaraj.patil@nokia.com
巴萨瓦拉伊：巴萨瓦拉伊。patil@nokia.com
Gerardo Giaretta: gerardo.giaretta@telecomitalia.it
杰拉尔多·贾莱塔：杰拉尔多。giaretta@telecomitalia.it
Jari Arkko: jari.arkko@kolumbus.fi
雅丽：雅丽。arkko@kolumbus.fi
James Kempf: kempf@docomolabs-usa.com
詹姆斯·坎普夫：kempf@docomolabs-美国网
Yoshihiro Ohba: yohba@tari.toshiba.com
大叶吉弘：yohba@tari.toshiba.com
Ryuji Wakikawa: ryuji@sfc.wide.ad.jp
若川龙治：ryuji@sfc.wide.ad.jp
Hiroyuki Ohnishi: ohnishi.hiroyuki@lab.ntt.co.jp
大西广幸：大西广幸。hiroyuki@lab.ntt.co.jp
Mayumi Yanagiya: yanagiya.mayumi@lab.ntt.co.jp
柳叶真美：柳叶真美。mayumi@lab.ntt.co.jp
Samita Chakrabarti: Samita.Chakrabarti@eng.sun.com
萨米塔脉轮：萨米塔。Chakrabarti@eng.sun.com
Gopal Dommety: gdommety@cisco.com
戈帕尔·多梅蒂：gdommety@cisco.com
Kent Leung: kleung@cisco.com
梁建邦：kleung@cisco.com
Alper Yegin: alper.yegin@samsung.com
阿尔帕·耶金：阿尔帕。yegin@samsung.com
Hannes Tschofenig: hannes.tschofenig@siemens.com
汉内斯：汉内斯。tschofenig@siemens.com
Vijay Devarapalli: vijayd@iprg.nokia.com
维贾伊·德瓦拉帕利：vijayd@iprg.nokia.com
Kuntal Chowdhury: kchowdhury@starentnetworks.com
昆塔尔·乔杜里：kchowdhury@starentnetworks.com
Special thanks to James Kempf and Jari Arkko for writing the initial version of the bootstrapping statement. Thanks to John Loughney and T.J. Kniveton for their detailed reviews.
特别感谢James Kempf和Jari Arkko编写了bootstrapping声明的初始版本。感谢John Loughney和T.J.Kniveton的详细评论。
[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月。
[AAA-EAP-LLA] Mariblanca, D., "EAP lower layer attributes for AAA protocols", Work in Progress, May 2004.
[AAA-EAP-LLA]Mariblanca，D.，“AAA协议的EAP低层属性”，正在进行的工作，2004年5月。
[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月。
[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月。
[RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004.
[RFC3753]Way，J.和M.Kojo，“机动性相关术语”，RFC 3753，2004年6月。
[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月。
[RFC3776] Galvin, J., "IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees", BCP 10, RFC 3777, June 2004.
[RFC3776]Galvin，J.，“IAB和IESG选择、确认和召回流程：提名和召回委员会的运作”，BCP 10，RFC 3777，2004年6月。
[RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury, "Mobile Node Identifier Option for Mobile IPv6 (MIPv6)", RFC 4283, November 2005.
[RFC4283]Patel，A.，Leung，K.，Khalil，M.，Akhtar，H.，和K.Chowdhury，“移动IPv6的移动节点标识符选项（MIPv6）”，RFC 4283，2005年11月。
[RFC4285] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury, "Authentication Protocol for Mobile IPv6", RFC 4285, January 2006.
[RFC4285]Patel，A.，Leung，K.，Khalil，M.，Akhtar，H.，和K.Chowdhury，“移动IPv6认证协议”，RFC 4285，2006年1月。
Authors' Addresses
作者地址
Alpesh Patel Cisco 170 W. Tasman Drive San Jose, CA 95134 USA
美国加利福尼亚州圣何塞塔斯曼大道西170号阿尔佩什·帕特尔·思科，邮编95134
Phone: +1 408 853 9580
EMail: alpesh@cisco.com
Phone: +1 408 853 9580
EMail: alpesh@cisco.com
Gerardo Giaretta Telecom Italia via Reiss Romoli 274 Torino 10148 Italy
Gerardo Giaretta Telecom Italia via Reiss Romoli 274意大利都灵10148
Phone: +39 011 228 6904
EMail: gerardo.giaretta@telecomitalia.it
Phone: +39 011 228 6904
EMail: gerardo.giaretta@telecomitalia.it
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
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 provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。