Network Working Group F. Johansson
Request for Comments: 3846 ipUnplugged
Category: Standards Track T. Johansson
Bytemobile
June 2004
Network Working Group F. Johansson
Request for Comments: 3846 ipUnplugged
Category: Standards Track T. Johansson
Bytemobile
June 2004
Mobile IPv4 Extension for Carrying Network Access Identifiers
用于承载网络访问标识符的移动IPv4扩展
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2004).
版权所有（C）互联网协会（2004年）。
Abstract
摘要
When a mobile node moves between two foreign networks, it has to be re-authenticated. If the home network has both multiple Authentication Authorization and Accounting (AAA) servers and Home Agents (HAs) in use, the Home AAA server may not have sufficient information to process the re-authentication correctly (i.e., to ensure that the same HA continues to be used). This document defines a Mobile IP extension that carries identities for the Home AAA and HA servers in the form of Network Access Identifiers (NAIs). The extension allows a Home Agent to pass its identity (and that of the Home AAA server) to the mobile node, which can then pass it on to the local AAA server when changing its point of attachment. This extension may also be used in other situations requiring communication of a NAI between Mobile IP nodes.
当移动节点在两个外部网络之间移动时，必须对其进行重新身份验证。如果家庭网络同时具有多个认证授权和计费（AAA）服务器和家庭代理（has），则家庭AAA服务器可能没有足够的信息来正确处理重新认证（即，确保继续使用相同的HA）。本文档定义了移动IP扩展，该扩展以网络访问标识符（NAI）的形式承载家庭AAA和HA服务器的标识。扩展允许归属代理将其身份（以及归属AAA服务器的身份）传递给移动节点，移动节点可以在更改其连接点时将其传递给本地AAA服务器。该扩展还可用于需要移动IP节点之间的NAI通信的其他情况。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements terminology . . . . . . . . . . . . . . . . . . . 2
3. NAI Carrying Extension . . . . . . . . . . . . . . . . . . . . 3
3.1. Processing of the NAI Carrying Extension . . . . . . . . 3
4. HA Identity subtype . . . . . . . . . . . . . . . . . . . . . 4
5. AAAH Identity subtype . . . . . . . . . . . . . . . . . . . . 4
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements terminology . . . . . . . . . . . . . . . . . . . 2
3. NAI Carrying Extension . . . . . . . . . . . . . . . . . . . . 3
3.1. Processing of the NAI Carrying Extension . . . . . . . . 3
4. HA Identity subtype . . . . . . . . . . . . . . . . . . . . . 4
5. AAAH Identity subtype . . . . . . . . . . . . . . . . . . . . 4
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
9. Normative References . . . . . . . . . . . . . . . . . . . . . 6
10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7
11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 8
9. Normative References . . . . . . . . . . . . . . . . . . . . . 6
10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7
11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 8
When building networks one would like to be able to have redundancy. In order to achieve this, one might place multiple AAA servers in one domain. When a mobile node registers via a visited network, the authentication will be handled by one of the AAA servers in the home domain. At a later point, when the mobile node moves to another visited domain it again has to be authenticated. However, due to the redundancy offered by the AAA protocol, it can not be guaranteed that the authentication will be handled by the same AAAH server as the previous one, which can result in the new AAAH not knowing to which HA the session was assigned. This document defines a Mobile IP extension which can be used to distribute the information needed to resolve this.
在构建网络时，人们希望能够有冗余。为了实现这一点，可以在一个域中放置多个AAA服务器。当移动节点通过访问的网络注册时，身份验证将由归属域中的AAA服务器之一处理。稍后，当移动节点移动到另一个访问的域时，必须再次对其进行身份验证。但是，由于AAA协议提供的冗余，无法保证身份验证将由与前一个相同的AAAH服务器处理，这可能导致新的AAAH不知道会话分配给了哪个HA。本文档定义了一个移动IP扩展，可用于分发解决此问题所需的信息。
Furthermore, the only information that is normally available about the home agent in the registration request is the IP address as defined in RFC 3344 [5]. Unfortunately this may not be enough since some AAA infrastructures (such as Diameter [6]) use realm based routing; such a AAA infrastructure needs to know the FQDN identity of the home agent to be able to correctly handle the assignment of the home agent. A reverse DNS lookup would only disclose the identity of the Mobile IP interface for that HA IP address, which may or may not have a one-to-one correspondence with the home agent FQDN identity. This is a reason for the HA to also include its own identity in the registration reply. The MIP v4 extension defined in this document also has a subtype defined by which this may be done. The HA identity can then be included by the mobile node in later registration requests when changing the point of attachment.
此外，注册请求中通常可获得的关于归属代理的唯一信息是RFC 3344[5]中定义的IP地址。不幸的是，这可能还不够，因为一些AAA基础设施（如Diameter[6]）使用基于领域的路由；这样的AAA基础设施需要知道归属代理的FQDN标识，才能正确处理归属代理的分配。反向DNS查找将仅披露该HA IP地址的移动IP接口的标识，该地址可能与归属代理FQDN标识存在一对一的对应关系，也可能不存在。这是医管局在注册答覆中加入其本身身份的原因。本文档中定义的MIP v4扩展还定义了一个子类型，可通过该子类型执行此操作。然后，移动节点可以在稍后更改连接点时将HA标识包括在注册请求中。
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 BCP 14, RFC 2119 [1].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[1]中的描述进行解释。
The Mobile IP related terminology described in RFC 3344 [5] is used in this document. In addition, the following terms are used:
本文件使用RFC 3344[5]中描述的移动IP相关术语。此外，还使用了以下术语：
AAAH One of several possible AAA Servers in the Home Network
AAAH家庭网络中几种可能的AAA服务器之一
FQDN Fully Qualified Domain Name.
FQDN完全限定域名。
Identity The identity of a node is equal to its FQDN.
标识节点的标识等于其FQDN。
NAI Network Access Identifier [2].
NAI网络访问标识符[2]。
This section defines the NAI Carrying Extension which may be used in Mobile IP Registration Request and Reply messages, and also in Mobile IP Agent Advertisements [5]. The extension may be used by any node that wants to send identity information in the form of a NAI [4]. This document also defines some subtype numbers which identify the specific type of NAI carried in Sections 4 and 5. It is expected that other types of NAI will be defined by other documents in the future.
本节定义了NAI承载扩展，该扩展可用于移动IP注册请求和回复消息，也可用于移动IP代理广告[5]。该扩展可由希望以NAI形式发送身份信息的任何节点使用[4]。本文件还定义了一些子类型编号，用于识别第4节和第5节中携带的特定NAI类型。预计未来其他文件将定义其他类型的NAI。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Sub-Type | NAI ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Sub-Type | NAI ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 136 (skippable) [5].
136型（可跳过）[5]。
Length 8-bit unsigned integer. Length of the extension, in octets, excluding the extension Type and the extension Length fields. This field MUST be set to 1 plus the total length of the NAI field.
长度为8位无符号整数。扩展名的长度，以八位字节为单位，不包括扩展名类型和扩展名长度字段。此字段必须设置为1加上NAI字段的总长度。
Sub-Type This field describes the particular type NAI which is carried in the NAI field.
子类型此字段描述NAI字段中携带的特定类型NAI。
NAI Contains the NAI [2] in a string format.
NAI包含字符串格式的NAI[2]。
When a mobile node or home agent adds a NAI Carrying Extension to a registration message, the extension MUST appear prior to any authentication extensions.
当移动节点或归属代理向注册消息添加携带NAI的扩展时，该扩展必须出现在任何身份验证扩展之前。
In the event the foreign agent adds a NAI Carrying Extension to a registration message, the extension MUST appear prior to any authentication extensions added by the FA.
如果外国代理向注册消息中添加NAI承载扩展，则该扩展必须出现在FA添加的任何身份验证扩展之前。
If an HA has appended a NAI Carrying Extension to a Registration Reply to an MN, and does not receive the NAI extension in subsequent Registration Request messages from the MN, the HA can assume that the MN does not understand this NAI extension. In this case, the HA SHOULD NOT append this NAI extension to further Registration Reply messages to the MN.
如果HA已经将携带NAI的扩展附加到MN的注册回复，并且在来自MN的后续注册请求消息中没有接收到NAI扩展，则HA可以假定MN不理解该NAI扩展。在这种情况下，HA不应将此NAI扩展附加到MN的进一步注册回复消息中。
The HA identity uses subtype 1 of the NAI Carrying Extension. It contains the NAI of the HA in the form hostname@realm. Together the hostname and realm form the complete FQDN (hostname.realm) of the HA.
HA标识使用NAI携带扩展的子类型1。该表格包含医管局的NAIhostname@realm. 主机名和领域一起构成HA的完整FQDN（hostname.realm）。
A Home Agent using this extension MUST provide it in the first Registration Reply sent to a Mobile Node which is not currently registered. The extension only need to be included in subsequent Registration Replies if the same extension is included in Registration Requests received from the same Mobile Node.
使用此扩展的归属代理必须在发送给当前未注册的移动节点的第一个注册回复中提供此扩展。如果从同一移动节点接收的注册请求中包含相同的扩展，则仅需要在后续注册回复中包含该扩展。
A mobile node using this extension MUST, if it receives it in a registration reply message, provide it in every subsequent registration request when re-authentication is needed. Failure to re-authenticate, for instance because no AAAH can be reached, will result in termination of the Mobile-IP session. Upon initiation of a new session a new HA Identity NAI may be provided to the Mobile node, and the requirement above will apply to the newly received NAI.
如果使用此扩展的移动节点在注册回复消息中接收到该扩展，则必须在需要重新认证时在每个后续注册请求中提供该扩展。无法重新验证（例如，因为无法达到AAAH）将导致移动IP会话终止。在发起新会话时，可以向移动节点提供新的HA标识NAI，并且上述要求将适用于新接收到的NAI。
If the mobile node requires a specific home agent and it has the NAI available it MUST provide this extension in its initial registration request.
如果移动节点需要特定的归属代理，并且具有可用的NAI，则必须在其初始注册请求中提供此扩展。
A foreign agent which receives the Home Agent NAI by this extension in a registration request SHOULD include the Home Agent NAI when requesting Mobile Node authentication through the AAA infrastructure if the AAA protocol used can carry the information.
如果所使用的AAA协议可以携带信息，则在注册请求中通过该扩展接收归属代理NAI的外部代理在通过AAA基础设施请求移动节点认证时应包括归属代理NAI。
The AAAH identity uses subtype 2 of the NAI Carrying Extension. It contains the NAI of the home AAA server in the form hostname@realm. Together the hostname and realm form the complete FQDN (hostname.realm) of the home AAA server.
AAAH标识使用NAI携带扩展的子类型2。它包含家庭AAA服务器的NAI，格式为hostname@realm. 主机名和领域一起构成家庭AAA服务器的完整FQDN（hostname.realm）。
If several AAA servers exist in the Home Network, a Home Agent providing AAAH selection support according to this document MUST provide the AAAH identity in the first Registration Reply sent to the Mobile Node. The extension only needs to be included in subsequent Registration Replies if the same extension is included in Registration Requests received from the same Mobile Node.
如果家庭网络中存在多个AAA服务器，则根据本文档提供AAAH选择支持的家庭代理必须在发送给移动节点的第一个注册回复中提供AAAH标识。如果从同一移动节点接收的注册请求中包含相同的扩展，则仅需要在后续注册回复中包含该扩展。
A mobile node SHOULD save the latest AAAH Identity received in a registration reply message and SHOULD provide the AAAH Identity in every registration request sent when re-authenticating, for efficiency reasons. Failure to reach the indicated AAAH during re-authentication will result in a new AAAH Identity NAI being returned (which should then be saved and provided in subsequent registration requests). Similarly, failure to re-authenticate, for instance because no AAAH can be reached, will result in termination of the Mobile-IP session; on initiation of a new session, a new AAAH Identity NAI may be provided to the Mobile Node for re-use during later re-registrations.
出于效率原因，移动节点应保存在注册回复消息中接收到的最新AAAH标识，并应在重新认证时发送的每个注册请求中提供AAAH标识。在重新身份验证过程中未能达到指定的AAAH将导致返回新的AAAH标识NAI（随后应保存该标识并在后续注册请求中提供）。类似地，无法重新认证（例如，因为无法达到AAAH）将导致移动IP会话终止；在发起新会话时，可以向移动节点提供新的AAAH标识NAI，以便在稍后的重新注册期间重新使用。
A foreign agent which receives the AAAH NAI by this extension in a registration request SHOULD include the AAAH NAI provided when requesting Mobile Node authentication through the AAA infrastructure if the AAA protocol used can carry the information.
如果所使用的AAA协议可以携带信息，则在注册请求中通过该扩展接收AAAH NAI的外部代理应包括在通过AAA基础设施请求移动节点认证时提供的AAAH NAI。
This specification introduces new Mobile IP extensions that are used to carry mobility agent and AAA server identities, in the form of Network Access Identifiers. The Mobile IP messages that carry this extension MUST be authenticated as described in [4], unless other authentication methods have been agreed upon. Therefore, this specification does not lessen the security of Mobile IP messages.
本规范引入了新的移动IP扩展，用于以网络访问标识符的形式承载移动代理和AAA服务器身份。携带此扩展的移动IP消息必须按照[4]中所述进行身份验证，除非已商定其他身份验证方法。因此，本规范不会降低移动IP消息的安全性。
It should be noted that the identities sent in the extensions specified herein MAY be sent in the clear over the network. However, the authors do not envision that this information would create security issues.
应当注意，在本文指定的扩展中发送的标识可以通过网络以明文形式发送。然而，作者并不认为这些信息会造成安全问题。
This document defines one new mobile IP extension, and one new Mobile IP extension sub-type numbering space to be managed by IANA.
本文档定义了一个新的移动IP扩展和一个新的移动IP扩展子类型编号空间，由IANA管理。
Section 3 defines a new Mobile IP extension, the Mobile IP NAI Carrying Extension. The type number for this extension is 136. This extension introduces a new sub-type numbering space where the values
第3节定义了一个新的移动IP扩展，即移动IP NAI承载扩展。此扩展的类型号为136。此扩展引入了一个新的子类型编号空间，其中
1 and 2 have been assigned in this document. Approval of new Mobile IP NAI Carrying Extension sub-type numbers is subject to Expert Review, and a specification is required [3].
1和2已在本文件中分配。携带扩展子类型号的新移动IP NAI的批准需经专家审查，且需要规范[3]。
The content and format for this extension is not specific to AAA NAIs, so if in the future new NAIs are defined which do not strictly fall within the category of AAA NAIs, they may nevertheless be accommodated within the subtype numbering space defined for the NAI Carrying Extension defined in this document.
此扩展的内容和格式不是AAA NAI特有的，因此，如果将来定义的新NAI不严格属于AAA NAI类别，则它们可能会被容纳在本文件中定义的NAI承载扩展定义的子类型编号空间内。
The NAI Carrying Extension should be assigned a type value from both the IANA number space for Mobile IPv4 skippable extensions and from the IANA number space for Mobile IPv4 advertisement extensions. Ideally, the numbers assigned from these two numbering spaces should have the same value.
应从移动IPv4可跳过扩展的IANA编号空间和移动IPv4播发扩展的IANA编号空间为NAI承载扩展分配一个类型值。理想情况下，从这两个编号空间分配的编号应具有相同的值。
Thanks to the original authors of the GNAIE document, Mohamed M Khalil, Emad Qaddoura, Haseeb Akhtar, and Pat R. Calhoun. The original document was removed from the MIP WG charter when no use was seen for the extension. The original ideas have been reused in this document. Also thanks to Henrik Levkowetz and Kevin Purser for valuable feedback and help when writing this document.
感谢GNAIE文件的原始作者Mohamed M Khalil、Emad Qaddoura、Haseeb Akhtar和Pat R.Calhoun。原始文件从MIP工作组章程中删除，因为扩展没有任何用处。原始想法已在本文档中重复使用。同时感谢Henrik Levkowetz和Kevin Purser在编写本文档时提供的宝贵反馈和帮助。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999.
[2] Aboba，B.和M.Beadles，“网络接入标识符”，RFC 2486，1999年1月。
[3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[3] Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[4] Calhoun, P. and C. Perkins, "Mobile IP Network Access Identifier Extension for IPv4", RFC 2794, March 2000.
[4] Calhoun，P.和C.Perkins，“IPv4移动IP网络访问标识符扩展”，RFC 27942000年3月。
[5] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[5] Perkins，C.，“IPv4的IP移动支持”，RFC 3344，2002年8月。
[6] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[6] Calhoun，P.，Loughney，J.，Guttman，E.，Zorn，G.和J.Arkko，“直径基准协议”，RFC 3588，2003年9月。
Fredrik Johansson ipUnplugged AB Arenavagen 23 Stockholm S-121 28 SWEDEN
Fredrik Johansson IPAB Arenavagen 23斯德哥尔摩S-121 28瑞典
Phone: +46 8 725 5916
EMail: fredrik@ipunplugged.com
Phone: +46 8 725 5916
EMail: fredrik@ipunplugged.com
Tony Johansson Bytemobile Inc 2029 Stierlin Court Mountain View, CA 94043 USA
托尼·约翰逊·拜特莫比尔公司2029年美国加利福尼亚州山景城斯蒂尔林法院，邮编94043
Phone: +1 650 862 0523
EMail: tony.johansson@bytemobile.com
Phone: +1 650 862 0523
EMail: tony.johansson@bytemobile.com
Copyright (C) The Internet Society (2004). 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.
版权所有（C）互联网协会（2004年）。本文件受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编辑功能的资金目前由互联网协会提供。