Network Working Group J. Korhonen, Ed.
Request for Comments: 5729 Nokia Siemens Networks
Updates: 3588 M. Jones
Category: Standards Track Bridgewater Systems
L. Morand
Orange Labs
T. Tsou
Huawei
December 2009
Network Working Group J. Korhonen, Ed.
Request for Comments: 5729 Nokia Siemens Networks
Updates: 3588 M. Jones
Category: Standards Track Bridgewater Systems
L. Morand
Orange Labs
T. Tsou
Huawei
December 2009
Clarifications on the Routing of Diameter Requests Based on the Username and the Realm
基于用户名和领域的Diameter请求路由说明
Abstract
摘要
This specification defines the behavior required of Diameter agents to route requests when the User-Name Attribute Value Pair contains a Network Access Identifier formatted with multiple realms. These multi-realm, or "Decorated", Network Access Identifiers are used in order to force the routing of request messages through a predefined list of mediating realms.
当用户名属性值对包含使用多个域格式化的网络访问标识符时，此规范定义Diameter代理路由请求所需的行为。这些多域或“修饰的”网络访问标识符用于强制请求消息通过预定义的中介域列表进行路由。
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) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括《信托法律条款》第4.e节中所述的简化BSD许可文本，并且提供BSD许可中所述的代码组件时不提供任何担保。
Table of Contents
目录
1. Introduction ....................................................2
2. Terminology and Abbreviations ...................................2
3. Problem Overview ................................................3
4. Solution Overview ...............................................5
4.1. Interpretation of Decorated NAIs ...........................5
4.2. Internationalization of Decorated NAIs .....................5
4.3. Ensuring Backwards Compatibility ...........................6
4.4. Enhanced Request Routing Solution ..........................7
5. Security Considerations .........................................8
6. Acknowledgements ................................................8
7. References ......................................................9
7.1. Normative References .......................................9
7.2. Informative References .....................................9
1. Introduction ....................................................2
2. Terminology and Abbreviations ...................................2
3. Problem Overview ................................................3
4. Solution Overview ...............................................5
4.1. Interpretation of Decorated NAIs ...........................5
4.2. Internationalization of Decorated NAIs .....................5
4.3. Ensuring Backwards Compatibility ...........................6
4.4. Enhanced Request Routing Solution ..........................7
5. Security Considerations .........................................8
6. Acknowledgements ................................................8
7. References ......................................................9
7.1. Normative References .......................................9
7.2. Informative References .....................................9
This specification defines the behavior required of Diameter agents to route requests when the User-Name Attribute Value Pair (AVP) contains a Network Access Identifier (NAI) formatted with multiple realms (hereafter referred to as a Decorated NAI). Decorated NAIs are used in order to force the routing of request messages through a predefined list of mediating realms. This specification does not define a new Diameter application but instead defines behaviour that would be common across all new Diameter applications that require request routing based on Decorated NAI.
本规范定义了当用户名属性值对（AVP）包含使用多个域（以下称为修饰NAI）格式化的网络访问标识符（NAI）时，Diameter代理路由请求所需的行为。修饰的NAI用于通过预定义的中介领域列表强制路由请求消息。本规范没有定义新的Diameter应用程序，而是定义了所有需要基于NAI的请求路由的新Diameter应用程序中常见的行为。
The Diameter Base Protocol [RFC3588] NAI usage is originally based on [RFC2486], which has since been revised to [RFC4282]. While the use of multiple realms is generally discouraged, RFC 4282 does allow multiple realms. The use of this facility appears in, for instance, [RFC4284]. However, RFC 4282 does not define how the Decorated NAIs should be handled by Diameter agents, so this specification was written to capture those requirements.
Diameter Base Protocol[RFC3588]NAI的使用最初基于[RFC2486]，后来修改为[RFC4282]。虽然通常不鼓励使用多个领域，但RFC 4282允许使用多个领域。例如，[RFC4284]中显示了此功能的使用。但是，RFC 4282没有定义直径代理应如何处理装饰的NAI，因此编写本规范是为了满足这些要求。
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]中所述进行解释。
Network Access Identifier (NAI):
网络访问标识符（NAI）：
The user identity submitted by the client during access authentication. In roaming, the purpose of the NAI is to identify the user as well as to assist in the routing of the authentication request.
客户端在访问身份验证期间提交的用户标识。在漫游中，NAI的目的是识别用户以及协助认证请求的路由。
Decorated NAI:
NAI：
An NAI containing multiple realms used to specify a source route and formatted according to Section 2.7 in RFC 4282.
一种NAI，包含多个域，用于指定源路由，并根据RFC 4282第2.7节进行格式化。
Network Access Provider (NAP):
网络访问提供商（NAP）：
A business entity that provides network access infrastructure to one or more realms. A NAP infrastructure comprises one or more network access servers.
向一个或多个领域提供网络访问基础设施的业务实体。NAP基础设施包括一个或多个网络访问服务器。
Network Access Server (NAS):
网络访问服务器（NAS）：
The device to which peers connect in order to obtain access to the network.
对等方为了访问网络而连接到的设备。
Section 6.1 of "The Diameter Base Protocol" (RFC 3588) defines the request routing in detail. That specification concerns only the cases where a Destination-Realm AVP is included in a Diameter request message. As described in RFC 3588 Section 6.1, a Diameter peer originating a request message MAY retrieve the realm information from the User-Name AVP and use that realm to populate the Destination-Realm AVP. In that case, the User-Name AVP is in form of an NAI including the realm part.
“Diameter基本协议”（RFC 3588）第6.1节详细定义了请求路由。该规范仅涉及Diameter请求消息中包含目标领域AVP的情况。如RFC 3588第6.1节所述，发起请求消息的Diameter对等方可从用户名AVP检索领域信息，并使用该领域填充目标领域AVP。在这种情况下，用户名AVP是包括领域部分的NAI的形式。
Decorated NAIs are used to force routing of messages through a predefined list of realms and, in that way, force certain inter-realm roaming arrangements; see Section 2.7 of RFC 4282. For example, a terminal (e.g., a mobile host) may learn, based on some application-or implementation-specific manner, that its network access authentication signaling must traverse certain realms in order to reach the home realm. In this case, the terminal would decorate its NAI during the network access authentication with the list of intermediating realms and the home realm. As a result, the network access server (NAS) and intermediating Diameter agents would make sure that all Diameter request messages traverse through the desired realms as long as the request messages contain the User-Name AVP with a Decorated NAI.
修饰的NAI用于强制消息通过预定义的域列表进行路由，并以这种方式强制某些域间漫游安排；参见RFC 4282第2.7节。例如，终端（例如，移动主机）可以基于某种特定于应用或实现的方式了解到，其网络接入认证信令必须穿越某些领域才能到达归属领域。在这种情况下，终端将在网络接入认证期间用中间领域和归属领域的列表装饰其NAI。因此，只要请求消息包含带有修饰NAI的用户名AVP，网络访问服务器（NAS）和中间Diameter代理就会确保所有Diameter请求消息都能通过所需的领域。
NAI decoration has previously been used in RADIUS-based [RFC2865] roaming networks, using RFC 2486 NAIs in a proprietary manner. There is a need to replicate the same NAI-based routing enforcement functionality in Diameter-based roaming networks. Moreover, there are publicly available specifications (e.g., see [3GPP.23.234], [3GPP.24.234], [3GPP.23.003], [3GPP.29.273], and [WiMAX]) that assume NAI-decoration-based request routing enforcement is fully supported
NAI装饰先前已用于基于RADIUS的[RFC2865]漫游网络，以专有方式使用RFC2486 NAI。需要在基于Diameter的漫游网络中复制相同的基于NAI的路由实施功能。此外，还有公开可用的规范（例如，请参见[3GPP.23.234]、[3GPP.24.234]、[3GPP.23.003]、[3GPP.29.273]和[WiMAX]），这些规范假定完全支持基于NAI修饰的请求路由实施
by RFC 3588. The same assumption is carried over to Network Server Application Requirements (NASREQ) [RFC4005] and Extensible Authentication Protocol (EAP) [RFC4072] Diameter applications.
通过RFC3588。同样的假设也适用于网络服务器应用程序需求（NASREQ）[RFC4005]和可扩展身份验证协议（EAP）[RFC4072]Diameter应用程序。
Figure 1 illustrates an example deployment scenario where Decorated NAIs would be used to force a certain route through desired realms. A roaming terminal (e.g., a mobile host) discovers a number of Network Access Providers (NAP): NAP A and NAP B. None of the NAPs are able to provide direct connectivity to the roaming terminal's home realm (i.e., h.example.com). However, the roaming terminal learns, somehow, that NAP B is able to provide connectivity to h.example.com through x.example.com (i.e., the visited realm from the roaming terminal point of view). During the network access authentication, the roaming terminal would decorate its NAI as h.example.com!username@x.example.com. The roaming terminal has also an alternative route to its home realm through NAP A: z.example.com and x.example.com. If the roaming terminal were to choose to use NAP A, then it would decorate its NAI as x.example.com!h.example.com!username@z.example.com. Diameter agents would now be able to route the request message through desired realms using the Decorated NAI originally found in the User-Name AVP.
图1展示了一个示例部署场景，其中装饰的NAI将用于强制某条路线通过所需领域。漫游终端（例如，移动主机）发现多个网络接入提供商（NAP）：NAP A和NAP B。没有一个NAP能够提供到漫游终端的主域（即h.example.com）的直接连接。然而，漫游终端不知何故获悉，NAP B能够通过x.example.com（即，从漫游终端的角度来看，访问的领域）提供到h.example.com的连接。在网络接入认证期间，漫游终端将其NAI装饰为h.example.com！username@x.example.com. 漫游终端还有一条通过NAP A:z.example.com和x.example.com到达其主域的替代路线。如果漫游终端选择使用NAP A，那么它将把NAI装饰成x.example.com！h、 example.com！username@z.example.com. Diameter代理现在可以使用最初在用户名AVP中找到的修饰NAI，将请求消息路由到所需的领域。
.--. .--. .--.
_(. `) _(. `) _(. `)
_( Visited`)_ _( Visited`)_ _( Home `)_
(z.example.com`)<---->(x.example.com`)<------>(h.example.com`)
( ` . ) ) ( ` . ) ) ( ` . ) )
`--(_______)---' `--(_______)---' `--(_______)---'
| __ /
| /
.--. .--.
_( `. _( `.
( NAP A ) ( NAP B )
( ` . ) ) ( ` . ) )
`--(___.-' `--(___.-'
)
( ( )
( |
+-+
|M|
+-+
.--. .--. .--.
_(. `) _(. `) _(. `)
_( Visited`)_ _( Visited`)_ _( Home `)_
(z.example.com`)<---->(x.example.com`)<------>(h.example.com`)
( ` . ) ) ( ` . ) ) ( ` . ) )
`--(_______)---' `--(_______)---' `--(_______)---'
| __ /
| /
.--. .--.
_( `. _( `.
( NAP A ) ( NAP B )
( ` . ) ) ( ` . ) )
`--(___.-' `--(___.-'
)
( ( )
( |
+-+
|M|
+-+
Figure 1: Example roaming scenario with intermediating realms. The mobile host authenticates to the home realm through one or more visited realms.
图1：具有中间领域的漫游场景示例。移动主机通过一个或多个访问的域对归属域进行身份验证。
NAI decoration is not limited to the network access authentication and authorization procedures. It can be used with any Diameter application whose commands are proxiable and include the User-Name AVP with an NAI. Generally, the NAI decoration can be used to force a certain route for all Diameter request messages at a realm granularity.
NAI装修不限于网络接入认证和授权程序。它可以与任何Diameter应用程序一起使用，这些应用程序的命令是可代理的，并且包括带有NAI的用户名AVP。通常，NAI装饰可用于以领域粒度强制所有Diameter请求消息的特定路由。
As a problem summary, we have two main issues:
作为问题总结，我们有两个主要问题：
o Updating both Destination-Realm and User-Name AVPs based on the Decorated NAI extracted from the User-Name AVP. The update would be done by intermediating Diameter agents that participate in realm-based request routing. Specifically, this would concern Diameter proxies.
o 基于从用户名AVP提取的修饰NAI更新目标领域和用户名AVP。更新将通过中介参与基于领域的请求路由的Diameter代理来完成。具体来说，这将涉及直径代理。
o How Diameter agents could implement the handling of the NAI-decoration-based routing enforcement in a way that is still backwards compatible with RFC 3588.
o Diameter代理如何以与RFC 3588向后兼容的方式实施基于NAI装饰的路由执行处理。
Section 2.3 of [RFC5113] also discusses NAI-decoration-related issues with EAP [RFC3748] in general.
[RFC5113]第2.3节还讨论了与EAP[RFC3748]一般相关的NAI装修问题。
This specification defines a solution for Diameter realm-based request routing with routing enforcement using the User-Name AVP NAI decoration. Diameter proxy agent implementations can claim compliance using the solution described in this specification. The Diameter answer processing is left unmodified and follows the procedures described in Section 6.2 of RFC 3588.
本规范定义了一种基于Diameter领域的请求路由解决方案，该解决方案使用用户名AVP NAI强制路由。Diameter代理实现可以使用本规范中描述的解决方案声明遵从性。直径应答处理保持不变，并遵循RFC 3588第6.2节中描述的程序。
Implementations compliant to this specification MUST have a uniform way of interpreting decorated NAIs. That is, in the case of decoration, the character '!' (hexadecimal 0x21) is used to separate realms in the list of decorated realms in the NAI (as shown in examples in [RFC4282]).
符合本规范的实现必须有一种统一的解释NAI的方法。也就是说，在装饰的情况下，字符“！”（十六进制0x21）用于分隔NAI中装饰领域列表中的领域（如[RFC4282]中的示例所示）。
RFC 3588, Section 1.3 states that NAI realm names are required to be unique and are piggybacked on the administration of the Domain Name System (DNS) ([RFC1034], [RFC1035]) namespace. However, an NAI, with or without decoration, may contain international characters as allowed by RFC 4282. This causes problems, as international characters as such are not supported by RFC 1034 and RFC 1035. The
RFC 3588第1.3节规定，NAI域名必须是唯一的，并由域名系统（DNS）（[RFC1034]，[RFC1035]）名称空间的管理支持。但是，根据RFC 4282的规定，NAI（带或不带装饰）可能包含国际字符。这会导致问题，因为RFC 1034和RFC 1035不支持国际字符。这个
conversion of International Domain Names (IDN), which in this document's scope are NAI realms, are discussed in [RFC3490] and are further to be revised in [IDNA].
[RFC3490]中讨论了国际域名（IDN）的转换（本文件范围内为NAI领域），并将在[IDNA]中进一步修订。
The general guidance for handling NAI realms with international characters is described in Section 2.4 of RFC 4282 and discussed more in [NAI] based on recent operational experiences. This specification does not attempt to fix the issue with the internationalization of NAIs, as the problem space is large and concerns much more than just NAI realms and NAI decoration. However, this specification has the following assumptions:
RFC 4282第2.4节描述了处理具有国际特征的NAI领域的一般指南，并根据最近的运营经验在[NAI]中进行了详细讨论。本规范并不试图解决NAI国际化的问题，因为问题空间很大，并且不仅仅涉及NAI领域和NAI装饰。但是，本规范有以下假设：
o The conversion from a realm name that includes international characters to ASCII-compatible encoding should only take place when DNS infrastructure needs to be queried and not, for example, during the realm-placement processing of Decorated NAIs. The conversion is normally handled by a DNS resolver library on the local Diameter agent or, when not available in the resolver library, by the Diameter agent. In both cases, the realm in the NAI remains unchanged.
o 仅当需要查询DNS基础设施时，才应将包含国际字符的域名转换为ASCII兼容编码，例如，在修饰NAI的域名放置处理期间，不应进行转换。转换通常由本地Diameter代理上的DNS解析程序库处理，或者在解析程序库中不可用时，由Diameter代理处理。在这两种情况下，NAI中的领域保持不变。
o It is the responsibility of the operators administrating their realm and domain name spaces to ensure that the DNS is provisioned properly for all realms that may appear in Decorated NAIs. This implicitly requires that the conversion from any realm with international characters to a domain name cannot fail (i.e., the realms conform to the preconditions for internationalized domain names).
o 管理其领域和域名空间的运营商有责任确保为NAI中可能出现的所有领域正确配置DNS。这隐含地要求从具有国际字符的任何领域到域名的转换不能失败（即，领域符合国际化域名的先决条件）。
From the above discussion, it can be concluded that avoiding international characters in realms contained in NAIs is the best way to avoid problems with internationalized domain names and Decorated NAI handling in general.
从以上讨论可以得出结论，避免NAI中包含的领域中的国际字符是避免国际化域名和一般NAI处理问题的最佳方法。
The handling of the NAI-decoration-based routing enforcement as described in this specification will be supported by any new Diameter application. Therefore, backwards compatibility with existing Diameter implementations, applications, and deployments will be guaranteed. Existing Diameter agents not compliant with this specification will not advertise support for these new applications that implement the enhanced routing solution based on Decorated NAIs, and will therefore be bypassed.
任何新的直径应用程序都将支持本规范中所述的基于NAI装饰的路由执行处理。因此，将保证与现有Diameter实现、应用程序和部署的向后兼容性。不符合本规范的现有Diameter代理不会宣传对这些新应用程序的支持，这些新应用程序实现了基于修饰NAI的增强路由解决方案，因此将被绕过。
When a Diameter client originates a request message, the Destination-Realm AVP is populated with the realm part of the NAI available in the User-Name AVP (the realm given after the '@' character of the NAI). The NAI in the User-Name AVP may or may not be decorated.
当Diameter客户端发起请求消息时，目标领域AVP将填充用户名AVP中可用NAI的领域部分（NAI的“@”字符后给出的领域）。用户名AVP中的NAI可以装饰也可以不装饰。
When a Diameter agent receives a request message containing the Destination-Realm AVP with a realm that the agent is configured to process locally (and, in the case of proxies, the Diameter application is locally supported), it MUST do the following further processing before handling the message locally:
当Diameter代理接收到包含目标领域AVP的请求消息时，该领域的代理配置为本地处理（对于代理，Diameter应用程序在本地受支持），它必须在本地处理该消息之前执行以下进一步处理：
o If the User-Name AVP is available in the request message, then the Diameter agent MUST inspect whether the User-Name AVP contains a Decorated NAI. If the NAI is not decorated, then the Diameter agent proceeds with a normal RFC 3588 message processing.
o 如果用户名AVP在请求消息中可用，则Diameter代理必须检查用户名AVP是否包含修饰的NAI。如果未修饰NAI，则Diameter代理继续进行正常的RFC 3588消息处理。
o If the User-Name AVP contains a Decorated NAI, then the Diameter agent MUST process the NAI as defined in RFC 4282 and update the value of the User-Name AVP accordingly. Furthermore, the Diameter agent MUST update the Destination-Realm AVP to match the new realm in the User-Name AVP.
o 如果用户名AVP包含修饰的NAI，则Diameter代理必须按照RFC 4282中的定义处理NAI，并相应地更新用户名AVP的值。此外，Diameter代理必须更新目标领域AVP，以匹配用户名AVP中的新领域。
o The request message is then sent to the next hop using the normal request routing rules as defined in RFC 3588.
o 然后，使用RFC 3588中定义的正常请求路由规则将请求消息发送到下一跳。
Figure 2 illustrates an example of a roaming terminal that originates signaling with the home realm (h.example.com), through a NAP and two intermediating realms (z.example.com, x.example.com) before reaching the home realm (h.example.com). The example shows how the User-Name AVP and the Destination-Realm AVP change at each realm before reaching the final destination. If the signaling were originated from the NAS/NAP only, then step 1 can be omitted.
图2展示了一个漫游终端的示例，该终端在到达归属域（h.example.com）之前，通过NAP和两个中间域（z.example.com，x.example.com）与归属域（h.example.com）发起信令。该示例显示了在到达最终目的地之前，用户名AVP和目的地领域AVP在每个领域的变化情况。如果信令仅来自NAS/NAP，则可以省略步骤1。
1) Roaming Terminal -> NAS/NAP
Identity/NAI = x.example.com!h.example.com!username@z.example.com
1) Roaming Terminal -> NAS/NAP
Identity/NAI = x.example.com!h.example.com!username@z.example.com
2) NAS/NAP -> z.example.com
User-Name = x.example.com!h.example.com!username@z.example.com
Destination-Realm = z.example.com
2) NAS/NAP -> z.example.com
User-Name = x.example.com!h.example.com!username@z.example.com
Destination-Realm = z.example.com
3) Realm-Z -> x.example.com
User-Name = h.example.com!username@x.example.com
Destination-Realm = x.example.com
3) Realm-Z -> x.example.com
User-Name = h.example.com!username@x.example.com
Destination-Realm = x.example.com
4) Realm-X -> h.example.com
User-Name = username@h.example.com
Destination-Realm = h.example.com
4) Realm-X -> h.example.com
User-Name = username@h.example.com
Destination-Realm = h.example.com
Figure 2: The roaming terminal decides that the Diameter messages must be routed via z.example.com and x.example.com to h.example.com.
图2：漫游终端决定Diameter消息必须通过z.example.com和x.example.com路由到h.example.com。
A malicious node initiating (or indirectly causing initiation of) a Diameter request may purposely create a malformed list of realms in the NAI. This may cause the routing of requests through realms that would normally have nothing to do with the initiated Diameter message exchange. Furthermore, a malformed list of realms may contain non-existing realms, causing the routing of Diameter messages that cannot ultimately be routed anywhere. However, the request message might get routed several hops before such non-existent realms are discovered, thus creating unnecessary overhead to the routing system in general.
发起（或间接导致发起）Diameter请求的恶意节点可能故意在NAI中创建格式错误的领域列表。这可能会导致请求通过通常与启动的Diameter消息交换无关的领域进行路由。此外，格式错误的领域列表可能包含不存在的领域，从而导致Diameter消息的路由最终无法路由到任何地方。然而，在发现这些不存在的领域之前，请求消息可能会被路由几个跃点，因此通常会给路由系统造成不必要的开销。
The NAI decoration is used in Authentication, Authorization, and Accounting (AAA) infrastructures where the Diameter messages are transported between the NAS and the Diameter server via one or more AAA brokers or Diameter proxies. In this case, the NAS to Diameter server AAA communication relies on the security properties of the intermediate AAA brokers and Diameter proxies.
NAI装饰用于身份验证、授权和计费（AAA）基础架构，其中Diameter消息通过一个或多个AAA代理或Diameter代理在NAS和Diameter服务器之间传输。在这种情况下，NAS到Diameter服务器AAA通信依赖于中间AAA代理和Diameter代理的安全属性。
The authors would like to thank Victor Fajardo, Stefan Winter, Jari Arkko, and Avi Lior for their detailed comments on this document.
作者感谢Victor Fajardo、Stefan Winter、Jari Arkko和Avi Lior对本文件的详细评论。
Jouni Korhonen would like to thank the TEKES WISEciti project for providing funding to work on this document while he was at TeliaSonera's employ.
Jouni Korhonen感谢TEKES WISEciti项目在他受雇于TeliaSonera期间为编写本文件提供资金。
[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月。
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3588]Calhoun，P.，Loughney，J.，Guttman，E.，Zorn，G.，和J.Arkko，“直径基础协议”，RFC 3588，2003年9月。
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005.
[RFC4282]Aboba，B.，Beadles，M.，Arkko，J.，和P.Erenen，“网络访问标识符”，RFC 42822005年12月。
[3GPP.23.003] 3GPP, "Numbering, addressing and identification", 3GPP TS 23.003 8.5.0, June 2009.
[3GPP.23.003]3GPP，“编号、寻址和标识”，3GPP TS 23.003 8.5.02009年6月。
[3GPP.23.234] 3GPP, "3GPP system to Wireless Local Area Network (WLAN) interworking; System description", 3GPP TS 23.234 6.10.0, October 2006.
[3GPP.23.234]3GPP，“3GPP系统到无线局域网（WLAN）的互通；系统描述”，3GPP TS 23.234 6.10.012006年10月。
[3GPP.24.234] 3GPP, "3GPP system to Wireless Local Area Network (WLAN) interworking; WLAN User Equipment (WLAN UE) to network protocols; Stage 3", 3GPP TS 24.234 6.7.0, October 2006.
[3GPP.24.234]3GPP，“3GPP系统到无线局域网（WLAN）的互通；WLAN用户设备（WLAN UE）到网络协议；第3阶段”，3GPP TS 24.234 6.7.012006年10月。
[3GPP.29.273] 3GPP, "Evolved Packet System (EPS); 3GPP EPS AAA interfaces", 3GPP TS 29.273 8.3.0, September 2009.
[3GPP.29.273]3GPP，“演进分组系统（EPS）；3GPP EPS AAA接口”，3GPP TS 29.273 8.3.02009年9月。
[NAI] DeKok, A., "The Network Access Identifier", Work in Progress, September 2009.
[NAI]DeKok，A.，“网络访问标识符”，正在进行的工作，2009年9月。
[IDNA] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", Work in Progress, October 2009.
[IDNA]Klensin，J.，“应用程序中的国际化域名（IDNA）：协议”，正在进行的工作，2009年10月。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，1987年11月。
[RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999.
[RFC2486]Aboba，B.和M.Beadles，“网络接入标识符”，RFC 2486，1999年1月。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2865]Rigney，C.，Willens，S.，Rubens，A.，和W.Simpson，“远程认证拨入用户服务（RADIUS）”，RFC 28652000年6月。
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[RFC3490]Faltstrom，P.，Hoffman，P.，和A.Costello，“应用程序中的域名国际化（IDNA）”，RFC 34902003年3月。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[RFC3748]Aboba，B.，Blunk，L.，Vollbrecht，J.，Carlson，J.，和H.Levkowetz，Ed.，“可扩展认证协议（EAP）”，RFC 3748，2004年6月。
[RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter Network Access Server Application", RFC 4005, August 2005.
[RFC4005]Calhoun，P.，Zorn，G.，Spence，D.，和D.Mitton，“Diameter网络访问服务器应用”，RFC 4005，2005年8月。
[RFC4072] Eronen, P., Ed., Hiller, T., and G. Zorn, "Diameter Extensible Authentication Protocol (EAP) Application", RFC 4072, August 2005.
[RFC4072]Eronen，P.，Ed.，Hiller，T.，和G.Zorn，“直径可扩展认证协议（EAP）应用”，RFC 4072，2005年8月。
[RFC4284] Adrangi, F., Lortz, V., Bari, F., and P. Eronen, "Identity Selection Hints for the Extensible Authentication Protocol (EAP)", RFC 4284, January 2006.
[RFC4284]Adrangi，F.，Lortz，V.，Bari，F.，和P.Ernen，“可扩展身份验证协议（EAP）的身份选择提示”，RFC 4284，2006年1月。
[RFC5113] Arkko, J., Aboba, B., Korhonen, J., Ed., and F. Bari, "Network Discovery and Selection Problem", RFC 5113, January 2008.
[RFC5113]Arkko，J.，Aboba，B.，Korhonen，J.，Ed.，和F.Bari，“网络发现和选择问题”，RFC 5113，2008年1月。
[WiMAX] WiMAX Forum, "WiMAX Forum Network Architecture (Stage 2: Architecture Tenets, Reference Model and Reference Points)", Release 1 Version 1.2, January 2008.
[WiMAX]WiMAX论坛，“WiMAX论坛网络架构（第2阶段：架构原则、参考模型和参考点）”，第1版，1.2版，2008年1月。
Authors' Addresses
作者地址
Jouni Korhonen (editor) Nokia Siemens Networks Linnoitustie 6 Espoo FIN-02600 Finland
Jouni Korhonen（编辑）诺基亚西门子网络公司Linnoitustie 6 Espoo FIN-02600芬兰
EMail: jouni.nospam@gmail.com
EMail: jouni.nospam@gmail.com
Mark Jones Bridgewater Systems 303 Terry Fox Drive Ottawa, Ontario K2K 3J1 Canada
加拿大安大略省渥太华Terry Fox大道303号Mark Jones Bridgewater Systems K2K 3J1
EMail: Mark.Jones@bridgewatersystems.com
EMail: Mark.Jones@bridgewatersystems.com
Lionel Morand Orange Labs 38-40 rue du general Leclerc Issy-moulineaux Cedex 9, 92794 France
莱克勒将军街38-40号莱昂内尔·莫兰·奥兰治实验室，法国，92794
EMail: Lionel.morand@orange-ftgroup.com
EMail: Lionel.morand@orange-ftgroup.com
Tina Tsou (Ting ZOU) Huawei R&D Center, Huawei Technologies Co., Ltd Bantian, Shenzhen P.R. China
Tina Tsou（邹婷）华为研发中心，华为技术有限公司，中国深圳半天
EMail: tena@huawei.com
EMail: tena@huawei.com