Internet Engineering Task Force (IETF) T. Tsou
Request for Comments: 7075 Huawei Technologies (USA)
Updates: 6733 R. Hao
Category: Standards Track Comcast Cable
ISSN: 2070-1721 T. Taylor, Ed.
Huawei Technologies
November 2013
Internet Engineering Task Force (IETF) T. Tsou
Request for Comments: 7075 Huawei Technologies (USA)
Updates: 6733 R. Hao
Category: Standards Track Comcast Cable
ISSN: 2070-1721 T. Taylor, Ed.
Huawei Technologies
November 2013
Realm-Based Redirection In Diameter
基于领域的直径重定向
Abstract
摘要
The Diameter protocol includes a capability for message redirection, controlled by an application-independent "redirect agent". In some circumstances, an operator may wish to redirect messages to an alternate domain without specifying individual hosts. This document specifies an application-specific mechanism by which a Diameter server or proxy (node) can perform such a redirection when the Straightforward-Naming Authority Pointer (S-NAPTR) is not used for dynamic peer discovery. A node performing this new function is referred to as a "Realm-based Redirect Server".
Diameter协议包括消息重定向功能，由独立于应用程序的“重定向代理”控制。在某些情况下，操作员可能希望在不指定单个主机的情况下将消息重定向到备用域。本文档指定了一种特定于应用程序的机制，当直接命名机构指针（S-NAPTR）不用于动态对等发现时，Diameter服务器或代理（节点）可以通过该机制执行此类重定向。执行此新功能的节点称为“基于领域的重定向服务器”。
This memo updates Sections 6.13 and 6.14 of RFC 6733 with respect to the usage of the Redirect-Host-Usage and Redirect-Max-Cache-Time Attribute-Value Pairs (AVPs).
本备忘录更新了RFC 6733第6.13节和第6.14节中有关重定向主机使用和重定向最大缓存时间属性值对（AVP）的使用情况。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7075.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7075.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 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 Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Support of Realm-Based Redirection Within Applications . . . 4
3. Realm-Based Redirection . . . . . . . . . . . . . . . . . . . 5
3.1. Configuration of the Realm-Based Redirect Server . . . . 5
3.2. Behavior of Diameter Nodes . . . . . . . . . . . . . . . 6
3.2.1. Behavior at the Realm-Based Redirect Server . . . . . 6
3.2.2. Proxy Behavior . . . . . . . . . . . . . . . . . . . 6
3.2.3. Client Behavior . . . . . . . . . . . . . . . . . . . 7
3.3. The Redirect-Realm AVP . . . . . . . . . . . . . . . . . 7
3.4. DIAMETER_REALM_REDIRECT_INDICATION Protocol Error Code . 7
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Normative References . . . . . . . . . . . . . . . . . . 9
7.2. Informative References . . . . . . . . . . . . . . . . . 9
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Support of Realm-Based Redirection Within Applications . . . 4
3. Realm-Based Redirection . . . . . . . . . . . . . . . . . . . 5
3.1. Configuration of the Realm-Based Redirect Server . . . . 5
3.2. Behavior of Diameter Nodes . . . . . . . . . . . . . . . 6
3.2.1. Behavior at the Realm-Based Redirect Server . . . . . 6
3.2.2. Proxy Behavior . . . . . . . . . . . . . . . . . . . 6
3.2.3. Client Behavior . . . . . . . . . . . . . . . . . . . 7
3.3. The Redirect-Realm AVP . . . . . . . . . . . . . . . . . 7
3.4. DIAMETER_REALM_REDIRECT_INDICATION Protocol Error Code . 7
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Normative References . . . . . . . . . . . . . . . . . . 9
7.2. Informative References . . . . . . . . . . . . . . . . . 9
The Diameter base protocol [RFC6733] specifies a basic redirection service provided by a redirect agent. The redirect indication returned by the redirect agent is described in Section 6.1.8 and Sections 6.12 through 6.14 of [RFC6733]. It provides one or more individual hosts to the message sender as the destination of the redirected message.
Diameter基本协议[RFC6733]指定由重定向代理提供的基本重定向服务。[RFC6733]的第6.1.8节和第6.12至6.14节描述了重定向代理返回的重定向指示。它向消息发送者提供一个或多个单独的主机作为重定向消息的目的地。
However, consider the case where an operator has offered a specific service but no longer wishes to do so. The operator has arranged for an alternative domain to provide the service. To aid in the transition to the new arrangement, the original operator maintains a redirect server to indicate to the message sender the alternative domain to which the redirect the request should be sent. However, the original operator should not have to configure the redirect server with a list of hosts to contact in the alternative operator's domain; the original operator should simply be able to provide redirect indications to the domain as a whole.
然而，考虑操作员提供特定服务但不再希望这样做的情况。运营商已安排另一个域名提供服务。为了帮助过渡到新的安排，原始操作员维护一个重定向服务器，以向消息发送者指示请求应发送到的重定向的替代域。但是，原始运营商不必为重定向服务器配置备用运营商域中要联系的主机列表；原始操作员应该能够简单地向整个域提供重定向指示。
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]中所述进行解释。
Within this specification, the term "realm-based redirection" is used to refer to a mode of operation where a realm, rather than an individual host, is returned as the redirect indication.
在本规范中，术语“基于领域的重定向”用于指一种操作模式，其中返回领域而不是单个主机作为重定向指示。
The term "Realm-based Redirect Server" denotes the Diameter node (Diameter server or proxy) that returns the realm-based redirection. The behavior of the Realm-based Redirect Server itself is a slight modification to the behavior of a basic redirect agent as described in Section 6.1.8 of [RFC6733].
术语“基于领域的重定向服务器”表示返回基于领域的重定向的Diameter节点（Diameter服务器或代理）。基于领域的重定向服务器本身的行为是对[RFC6733]第6.1.8节所述基本重定向代理行为的轻微修改。
The use of a number of terms in this document is consistent with the usage in [RFC6733]: "Diameter client", "Diameter node", "Diameter peer", "Diameter server", "proxy", "realm" or "domain", "redirect agent", and "session" as defined in Section 1.2, and "application" as defined implicitly by Sections 1.3.4, 2.3, and 2.4.
本文件中许多术语的使用与[RFC6733]中的用法一致：第1.2节中定义的“Diameter客户端”、“Diameter节点”、“Diameter对等体”、“Diameter服务器”、“代理”、“领域”或“域”、“重定向代理”和“会话”，以及第1.3.4、2.3和2.4节中隐含定义的“应用程序”。
The DNS-based dynamic peer discovery mechanism defined in the Diameter base protocol [RFC6733] provides a simple mechanism for realm-based redirection using the S-NAPTR DDDS application [RFC3958]. When S-NAPTR is used for peer discovery, redirection of Diameter requests from the original realm to a new realm may be performed by updating the existing NAPTR resource records (RRs) for the original realm as follows: the NAPTR RR for the desired application(s) and supported application protocol(s) provided by the new realm will have an empty FLAG field and the REPLACEMENT field will contain the new realm to use for the next DNS lookup. The new realm can be arbitrary; the restriction in [RFC6733] that the NAPTR replacement field match the domain of the original query does not apply for realm-based redirect purposes.
Diameter基本协议[RFC6733]中定义的基于DNS的动态对等发现机制为使用S-NAPTR DDDS应用程序[RFC3958]进行基于领域的重定向提供了一种简单的机制。当S-NAPTR用于对等发现时，可通过如下方式更新原始领域的现有NAPTR资源记录（RRs），将Diameter请求从原始领域重定向到新领域：所需应用程序的NAPTR RR和支持的应用程序协议由新域提供的将有一个空标志字段，替换字段将包含用于下一个DNS查找的新域。新领域可以是任意的；[RFC6733]中关于NAPTR替换字段与原始查询的域匹配的限制不适用于基于领域的重定向目的。
However, the use of DNS-based dynamic peer discovery is optional for Diameter implementations. For deployments that do not make use of S-NAPTR peer discovery, support of realm-based redirection needs to be specified as part of the functionality supported by a Diameter application. In this way, support of the considered Diameter application (discovered during capabilities exchange phase as defined in Diameter base protocol [RFC6733]) indicates implicit support of the realm-based redirection mechanism. A new application specification can incorporate the mechanism specified here by making it mandatory to implement for the application and referencing this specification normatively.
但是，对于Diameter实现，使用基于DNS的动态对等发现是可选的。对于不使用S-NAPTR对等发现的部署，需要将基于领域的重定向支持指定为Diameter应用程序支持的功能的一部分。这样，对所考虑的Diameter应用程序的支持（在Diameter基本协议[RFC6733]中定义的功能交换阶段发现）表明对基于领域的重定向机制的隐式支持。新的应用程序规范可以通过强制应用程序实现并规范地引用此规范来合并此处指定的机制。
The result of making realm-based redirection an application-specific behavior is that it cannot be performed by a redirect agent as defined in [RFC6733], but MUST be performed instead by an application-aware Diameter node (Diameter server or proxy) (hereafter called a "Realm-based Redirect Server").
使基于领域的重定向成为特定于应用程序的行为的结果是，它不能由[RFC6733]中定义的重定向代理执行，而必须由应用程序感知的Diameter节点（Diameter服务器或代理）（以下称为“基于领域的重定向服务器”）执行。
An application can specify that realm-based redirection operates only on complete sessions beginning with the initial message or on every message within the application, even if earlier messages of the same session were not redirected. This distinction matters only when realm-based redirection is first initiated. In the former case, existing sessions will not be disrupted by the deployment of realm-based redirection. In the latter case, existing sessions will be disrupted if they are stateful.
应用程序可以指定基于领域的重定向仅在从初始消息开始的完整会话上或在应用程序中的每条消息上运行，即使同一会话的早期消息没有重定向。只有在首次启动基于领域的重定向时，这种区别才起作用。在前一种情况下，现有会话不会因部署基于领域的重定向而中断。在后一种情况下，如果现有会话是有状态的，它们将被中断。
This section specifies an extension of the Diameter base protocol [RFC6733] to achieve realm-based redirection. The elements of this solution are:
本节指定Diameter基本协议[RFC6733]的扩展，以实现基于领域的重定向。该解决方案的要素包括：
o a new result code, DIAMETER_REALM_REDIRECT_INDICATION (3011);
o 一个新的结果代码，直径\领域\重定向\指示（3011）；
o a new attribute-value pair (AVP), Redirect-Realm (620); and
o 一种新的属性值对（AVP），重定向域（620）；和
o associated behavior at Diameter nodes implementing this specification.
o 实现此规范的Diameter节点上的关联行为。
This behavior includes the optional use of the Redirect-Host-Usage and Redirect-Max-Cache-Time AVPs. In this document, these AVPs apply to the peer discovered by a node acting on the redirect server's response, an extension to their normal usage as described in Sections 6.13 and 6.14 of [RFC6733].
此行为包括可选使用重定向主机使用和重定向最大缓存时间AVP。在本文档中，这些AVP适用于节点根据重定向服务器的响应发现的对等方，这是[RFC6733]第6.13节和第6.14节所述正常使用的扩展。
Section 3.2.2 and Section 3.2.3 describe how a proxy or client may update its routing table for the application and initial realm as a result of selecting a peer in the new realm after realm-based redirection. Note that as a result, the proxy or client will automatically route subsequent requests for that application to the new realm (with the possible exception of requests within sessions already established with the initial realm) until the cached routing entry expires. This should be borne in mind if the rerouting is intended to be temporary.
第3.2.2节和第3.2.3节描述了代理或客户端如何在基于领域的重定向后在新领域中选择对等方，从而更新其应用程序和初始领域的路由表。请注意，因此，代理或客户端将自动将该应用程序的后续请求路由到新领域（与初始领域已建立的会话中的请求可能除外），直到缓存的路由条目过期。如果改道是临时性的，则应记住这一点。
A Diameter node (Diameter server or proxy) acting as a Realm-based Redirect Server MUST be configured as follows to execute realm-based redirection:
作为基于领域的重定向服务器的Diameter节点（Diameter服务器或代理）必须按以下方式配置以执行基于领域的重定向：
o configured with an application that incorporates realm-based redirection;
o 配置了一个包含基于领域的重定向的应用程序；
o the Local Action field of the routing table described in Section 2.7 of [RFC6733] is set to LOCAL;
o [RFC6733]第2.7节所述路由表的本地操作字段设置为本地；
o an application-specific field is set to indicate that the required local action is to perform realm-based redirection;
o 设置特定于应用程序的字段，以指示所需的本地操作是执行基于领域的重定向；
o an associated application-specific field is configured with the identities of one or more realms to which the request should be redirected.
o 关联的特定于应用程序的字段配置有请求应重定向到的一个或多个领域的标识。
As mentioned in Section 2, an application can specify that realm-based redirection operates only on complete sessions beginning with the initial message (i.e., to prevent disruption of established sessions) or on every message within the application, even if earlier messages of the same session were not redirected.
如第2节所述，应用程序可以指定基于领域的重定向仅在从初始消息开始的完整会话（即，防止中断已建立的会话）或应用程序内的每条消息上运行，即使相同会话的早期消息未重定向。
If a Realm-based Redirect Server configured as described in Section 3.1 receives a request to which realm-based redirection applies, the Realm-based Redirect Server MUST reply with an answer message with the 'E' bit set, while maintaining the Hop-by-Hop Identifier in the header. The Realm-based Redirect Server MUST include the Result-Code AVP set to DIAMETER_REALM_REDIRECT_INDICATION. The Realm-based Redirect Server MUST also include the alternate realm identifier(s) with which it has been configured, each in a separate Redirect-Realm AVP instance.
如果按照第3.1节所述配置的基于领域的重定向服务器接收到应用基于领域的重定向的请求，则基于领域的重定向服务器必须使用设置了“E”位的应答消息进行回复，同时在标头中保留逐跳标识符。基于领域的重定向服务器必须包括设置为DIAMETER\u Realm\u Redirect\u指示的结果代码AVP。基于领域的重定向服务器还必须包括已配置的备用领域标识符，每个标识符位于单独的重定向领域AVP实例中。
The Realm-based Redirect Server MAY include a copy of the Redirect-Host-Usage AVP, which SHOULD be set to REALM_AND_APPLICATION. If this AVP is added, the Redirect-Max-Cache-Time AVP MUST also be included. Note that these AVPs apply to the peer discovered by a node acting on the Realm-based Redirect Server's response as described in the next section. This is an extension of their normal usage as described by Sections 6.13 and 6.14 of [RFC6733].
基于领域的重定向服务器可能包括重定向主机使用AVP的副本，该副本应设置为领域\和\应用程序。如果添加了此AVP，则还必须包括重定向最大缓存时间AVP。请注意，这些AVP适用于节点在基于领域的重定向服务器响应上发现的对等方，如下一节所述。这是[RFC6733]第6.13节和第6.14节所述正常使用的扩展。
Realm-based redirection MAY be applied even if a Destination-Host AVP is present in the request, depending on the operator-based policy.
根据基于运营商的策略，即使请求中存在目标主机AVP，也可以应用基于领域的重定向。
A proxy conforming to this specification that receives an answer message with the Result-Code AVP set to DIAMETER_REALM_REDIRECT_INDICATION MUST attempt to reroute the original request to a server in a realm identified by a Redirect-Realm AVP instance in the answer message, and if it fails MUST forward the indication toward the client. To reroute the request, it MUST take the following actions:
符合本规范的代理收到应答消息，且结果代码AVP设置为DIAMETER_REALM_REDIRECT_指示，必须尝试将原始请求重新路由到应答消息中重定向领域AVP实例标识的领域中的服务器，如果失败，必须将指示转发给客户端。要重新路由请求，它必须执行以下操作：
1. Select a specific realm from amongst those identified in instances of the Redirect-Realm AVP in the answer message.
1. 从应答消息中重定向领域AVP实例中标识的领域中选择特定领域。
2. If successful, locate and establish a route to a peer in the realm given by the Redirect-Realm AVP, using normal discovery procedures as described in Section 5.2 of [RFC6733].
2. 如果成功，使用[RFC6733]第5.2节所述的正常发现程序，在重定向领域AVP给定的领域中定位并建立到对等方的路由。
3. If again successful:
3. 如果再次成功：
A. update its cache of routing entries for the realm and application to which the original request was directed, taking into account the Redirect-Host-Usage and Redirect-Max-Cache-Time AVPs, if present in the answer.
A.更新原始请求指向的领域和应用程序的路由项缓存，考虑重定向主机使用情况和重定向最大缓存时间AVP（如果答案中存在）。
B. Remove the Destination-Host (if present) and Destination-Realm AVPs from the original request and add a new Destination-Realm AVP containing the realm selected in the initial step.
B.从原始请求中删除目标主机（如果存在）和目标域AVP，并添加一个新的目标域AVP，其中包含在初始步骤中选择的域。
C. Forward the modified request.
C.转发修改后的请求。
4. If either of the preceding steps 2-3 fail and additional realms have been identified in the original answer, select another instance of the Redirect-Realm AVP in that answer and repeat steps 2-3 for the realm that it identifies.
4. 如果前面的步骤2-3中的任何一个失败，并且在原始答案中标识了其他领域，请在该答案中选择重定向领域AVP的另一个实例，并对其标识的领域重复步骤2-3。
A client conforming to this specification MUST be prepared to receive either an answer message containing a Result-Code AVP set to DIAMETER_REALM_REDIRECT_INDICATION, or, as the result of proxy action, some other result from a realm differing from the one to which it sent the original request. In the case where it receives DIAMETER_REALM_REDIRECT_INDICATION, the client SHOULD follow the same steps prescribed in the previous section for a proxy, in order to both update its routing table and obtain service for the original request.
符合本规范的客户机必须准备好接收应答消息，该消息包含设置为DIAMETER_REALM_REDIRECT_指示的结果代码AVP，或者作为代理操作的结果，接收来自不同于其发送原始请求的领域的某个其他结果。在接收到DIAMETER\u REALM\u REDIRECT\u指示的情况下，客户机应遵循上一节中为代理规定的相同步骤，以便更新其路由表并获得原始请求的服务。
The Redirect-Realm AVP (620) is of type DiameterIdentity. It specifies a realm to which a node receiving a redirect indication containing the result code value DIAMETER_REALM_REDIRECT_INDICATION and the Redirect-Realm AVP SHOULD route the original request.
AVP（620）为直径型。它指定一个域，接收到重定向指示（包含结果代码值DIAMETER\u realm\u redirect\u指示）的节点应将原始请求路由到该域。
The DIAMETER_REALM_REDIRECT_INDICATION (3011) Protocol error code indicates that a server has determined that the request within an application supporting realm-based redirection could not be satisfied locally, and the initiator of the request SHOULD direct the request directly to a peer within a realm that has been identified in the response. When set, the Redirect-Realm AVP MUST be present.
DIAMETER_REALM_REDIRECT_INDICATION（3011）协议错误代码表示服务器已确定本地无法满足支持基于领域的重定向的应用程序内的请求，请求的发起方应将请求直接指向响应中标识的领域内的对等方。设置时，重定向域AVP必须存在。
The general recommendations given in Section 13 of the Diameter base protocol [RFC6733] apply. Specific security recommendations related to the realm-based redirection defined in this document are described below.
Diameter基础协议[RFC6733]第13节中给出的一般建议适用。与本文档中定义的基于领域的重定向相关的特定安全建议如下所述。
Realm-based redirection implies a change in the business relationship between organizations. Before redirecting a request towards a realm different from the initial realm, the client or proxy MUST ensure that the authorization checks have been performed at each connection along the path toward the realm identified in the realm-based redirect indication. Details on Diameter authorization path set-up are given in Section 2.9 of [RFC6733]. Section 13 of [RFC6733] provides recommendations on how to authenticate and secure each peer-to-peer connection (using TLS, DTLS, or IPsec) along the way, thus permitting the necessary hop-by-hop authorization checks.
基于领域的重定向意味着组织之间业务关系的改变。在将请求重定向到与初始域不同的域之前，客户端或代理必须确保已在每个连接上沿指向基于域的重定向指示中标识的域的路径执行授权检查。[RFC6733]第2.9节给出了直径授权路径设置的详细信息。[RFC6733]的第13节提供了如何认证和保护每个对等连接（使用TLS、DTL或IPsec）的建议，从而允许进行必要的逐跳授权检查。
Although it is assumed that the administrative domains are secure, a compromised Diameter node acting as a Realm-based Redirect Server would be able to redirect a large number of Diameter requests towards a victim domain that would then be flooded with undesired Diameter requests. Such an attack is nevertheless discouraged by the use of secure Diameter peer-to-peer connections and authorization checks, since these would enable a potential victim domain to discover from where an attack is coming. That in itself, however, does not prevent such a DoS attack.
尽管假定管理域是安全的，但作为基于领域的重定向服务器的受损Diameter节点将能够将大量Diameter请求重定向到受害者域，然后受害者域将充满不希望的Diameter请求。然而，使用安全的对等连接和授权检查可以阻止此类攻击，因为这将使潜在的受害者域能够发现攻击来自何处。然而，这本身并不能阻止这种拒绝服务攻击。
Because realm-based redirection defined in this document implies that the Destination-Realm AVP in a client-initiated request can be changed by a Diameter proxy in the path between the client and the server, any cryptographic algorithm that would use the Destination-Realm AVP as input to the calculation performed by the client and the server would be broken by this form of redirection. Application specifications that would rely on such cryptographic algorithms SHOULD NOT incorporate this realm-based redirection.
因为本文档中定义的基于领域的重定向意味着客户端发起的请求中的目标领域AVP可以通过客户端和服务器之间路径中的Diameter代理进行更改，任何使用目标域AVP作为客户端和服务器执行的计算输入的加密算法都会被这种形式的重定向破坏。依赖于此类加密算法的应用程序规范不应包含这种基于领域的重定向。
This specification allocates a new AVP code Redirect-Realm (620) in the "AVP Codes" registry under "Authentication, Authorization, and Accounting (AAA) Parameters".
本规范在“验证、授权和记帐（AAA）参数”下的“AVP代码”注册表中分配新的AVP代码重定向域（620）。
This specification allocates a new Result-Code value DIAMETER_REALM_REDIRECT_INDICATION (3011) in the "Result-Code AVP Values (code 268) - Protocol Errors" registry under "Authentication, Authorization, and Accounting (AAA) Parameters".
本规范在“验证、授权和记帐（AAA）参数”下的“结果代码AVP值（代码268）-协议错误”注册表中分配新的结果代码值DIAMETER\u REALM\u REDIRECT\u指示（3011）。
Glen Zorn, Sebastien Decugis, Wolfgang Steigerwald, Mark Jones, Victor Fajardo, Jouni Korhonen, Avi Lior, and Lionel Morand contributed comments that helped to shape this document. As shepherd, Lionel contributed a second set of comments that added polish to the document before it was submitted to the IESG. Benoit Claise picked up additional points that were quickly resolved with Lionel's help. During IETF Last Call Review, Enrico Marocco picked up some important editorial corrections. Stefan Winter contributed text on the use of S-NAPTR as an alternative method of realm-based redirection already specified in [RFC6733]. Derek Atkins performed a review on behalf of the Security Directorate. Lionel noted one more correction.
格伦·佐恩（Glen Zorn）、塞巴斯蒂安·德库吉斯（Sebastien Decugis）、沃尔夫冈·施泰格瓦尔德（Wolfgang Steigerwald）、马克·琼斯（Mark Jones）、维克多·法哈多（Victor Fajardo）、朱尼·科霍宁（Jouni Korhonen）、阿维·利奥（Avi Lior）和莱昂内尔·。作为shepherd，莱昂内尔在提交给IESG之前提供了第二组评论，为文件添加了波兰语。贝诺特·克莱斯得到了更多的分数，在莱昂内尔的帮助下很快得到了解决。在IETF上次通话回顾期间，Enrico Marocco进行了一些重要的编辑更正。Stefan Winter提供了关于使用S-NAPTR作为[RFC6733]中已经指定的基于领域的重定向的替代方法的文本。德里克·阿特金斯代表安全理事会进行了审查。莱昂内尔又注意到一处更正。
Finally, this document benefited from comments and discussion raised by IESG members Stewart Bryant, Stephen Farrell, Barry Leiba, Pete Resnick, Jari Arkko, and Sean Turner during IESG review.
最后，本文件得益于IESG成员Stewart Bryant、Stephen Farrell、Barry Leiba、Pete Resnick、Jari Arkko和Sean Turner在IESG审查期间提出的评论和讨论。
The authors are very grateful to Lionel Morand for his active role as document shepherd. At each stage, he worked to summarize and resolve comments, making the editor's role easy. Thank you.
作者非常感谢莱昂内尔·莫兰德（Lionel Morand）作为文件守护者的积极作用。在每个阶段，他都努力总结和解决评论，使编辑的角色变得简单。非常感谢。
[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月。
[RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, "Diameter Base Protocol", RFC 6733, October 2012.
[RFC6733]Fajardo，V.，Arkko，J.，Loughney，J.，和G.Zorn，“直径基准协议”，RFC 67332012年10月。
[RFC3958] Daigle, L. and A. Newton, "Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)", RFC 3958, January 2005.
[RFC3958]Daigle，L.和A.Newton，“使用SRV RRs和动态委托发现服务（DDDS）的基于域的应用程序服务定位”，RFC 3958，2005年1月。
Authors' Addresses
作者地址
Tina Tsou Huawei Technologies (USA) 2330 Central Expressway Santa Clara, CA 95050 USA
Tina Tsou Huawei Technologies（美国）美国加利福尼亚州圣克拉拉中央高速公路2330号，邮编95050
Phone: +1 408 330 4424
EMail: Tina.Tsou.Zouting@huawei.com
URI: http://tinatsou.weebly.com/contact.html
Phone: +1 408 330 4424
EMail: Tina.Tsou.Zouting@huawei.com
URI: http://tinatsou.weebly.com/contact.html
Ruibing Hao Comcast Cable One Comcast Center Philadelphia, PA 19103 USA
美国宾夕法尼亚州费城康卡斯特中心一号康卡斯特电缆（邮编：19103）
Phone: +1 215 286 3991(O)
EMail: Ruibing_Hao@cable.comcast.com
Phone: +1 215 286 3991(O)
EMail: Ruibing_Hao@cable.comcast.com
Tom Taylor (editor) Huawei Technologies Ottawa Canada
汤姆泰勒（编辑）华为技术加拿大渥太华
EMail: tom.taylor.stds@gmail.com
EMail: tom.taylor.stds@gmail.com