Internet Engineering Task Force (IETF) S. Sakane
Request for Comments: 6784 Cisco Systems
Category: Standards Track M. Ishiyama
ISSN: 2070-1721 Toshiba Corporation
November 2012
Internet Engineering Task Force (IETF) S. Sakane
Request for Comments: 6784 Cisco Systems
Category: Standards Track M. Ishiyama
ISSN: 2070-1721 Toshiba Corporation
November 2012
Kerberos Options for DHCPv6
DHCPv6的Kerberos选项
Abstract
摘要
This document defines four new options for the Dynamic Host Configuration Protocol for IPv6 (DHCPv6). These options are used to carry configuration information for Kerberos.
本文档为IPv6动态主机配置协议（DHCPv6）定义了四个新选项。这些选项用于携带Kerberos的配置信息。
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/rfc6784.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6784.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 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许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................3
2. Conventions Used in This Document ...............................4
3. Kerberos Options ................................................4
3.1. Kerberos Principal Name Option .............................4
3.2. Kerberos Realm Name Option .................................5
3.3. Kerberos Default Realm Name Option .........................6
3.4. Kerberos KDC Option ........................................6
4. Client and Server Operation .....................................7
4.1. KDC Discovery for a Client .................................8
5. IANA Considerations .............................................8
6. Security Considerations .........................................9
7. Acknowledgments .................................................9
8. References .....................................................10
8.1. Normative References ......................................10
8.2. Informative References ....................................10
Appendix A. An Example of the Operation of the Client .............11
1. Introduction ....................................................3
2. Conventions Used in This Document ...............................4
3. Kerberos Options ................................................4
3.1. Kerberos Principal Name Option .............................4
3.2. Kerberos Realm Name Option .................................5
3.3. Kerberos Default Realm Name Option .........................6
3.4. Kerberos KDC Option ........................................6
4. Client and Server Operation .....................................7
4.1. KDC Discovery for a Client .................................8
5. IANA Considerations .............................................8
6. Security Considerations .........................................9
7. Acknowledgments .................................................9
8. References .....................................................10
8.1. Normative References ......................................10
8.2. Informative References ....................................10
Appendix A. An Example of the Operation of the Client .............11
Kerberos Version 5 [RFC4120] is a trusted third-party authentication system. Each organization wishing to use Kerberos establishes its own "realm", and each client is registered as part of that realm. At least one Key Distribution Center (KDC) is required for the operation of a Kerberos realm.
Kerberos版本5[RFC4120]是一个受信任的第三方身份验证系统。希望使用Kerberos的每个组织都建立自己的“领域”，并且每个客户机都注册为该领域的一部分。Kerberos领域的操作至少需要一个密钥分发中心（KDC）。
When a client wishes to communicate with, and be authenticated to, a Kerberos application server (also a client of the KDC), the client identifies itself, and its realm, to the KDC and acquires a credential from the KDC. The client then presents the credential to the Kerberos application server, which can use the credential to authenticate the client. The client needs to know at least one IP address for a KDC in order to initiate this process.
当客户机希望与Kerberos应用程序服务器（也是KDC的客户机）通信并进行身份验证时，客户机向KDC标识自身及其领域，并从KDC获取凭据。然后，客户机向Kerberos应用程序服务器提供凭据，该服务器可以使用该凭据对客户机进行身份验证。客户端需要知道KDC的至少一个IP地址才能启动此过程。
One example of the application of this protocol is as follows. A student might want to use a shared, public workstation, one that is not configured for Kerberos. If there is a mechanism for the workstation to obtain a realm name and IP address for a KDC, then a student need only input a user-id and pass phrase to be able to use Kerberos.
该协议的应用示例如下。学生可能希望使用未配置Kerberos的共享公共工作站。如果工作站有一种机制来获取KDC的域名和IP地址，那么学生只需输入用户id和密码就可以使用Kerberos。
The Kerberos V5 specification [RFC4120] defines the use of DNS SRV records [RFC2782] for KDC discovery. Some systems, such as industrial systems, do not use DNS. Such systems already have their own name spaces and their own name resolution systems, including preconfigured mapping tables for devices, and do not use Fully Qualified Domain Names. However, many of these systems do use DHCP.
Kerberos V5规范[RFC4120]定义了使用DNS SRV记录[RFC2782]进行KDC发现。某些系统（如工业系统）不使用DNS。这类系统已经有自己的名称空间和名称解析系统，包括设备的预配置映射表，并且不使用完全限定的域名。然而，这些系统中的许多确实使用DHCP。
Adding a DNS server to such systems may decrease the reliability of the system and increase the management cost. In such an environment, another mechanism is needed to provide an IP address for the KDC. For the PacketCable Architecture [PCARCH], RFC 3634 [RFC3634] defines the KDC Server Address sub-option for the DHCPv4 CableLabs Client Configuration option. However, a mechanism is still needed to provide a realm name and an IPv6 address -- one that does not depend on any external architecture.
向此类系统添加DNS服务器可能会降低系统的可靠性并增加管理成本。在这样的环境中，需要另一种机制为KDC提供IP地址。对于PacketCable体系结构[PCARCH]，RFC 3634[RFC3634]定义了DHCPv4 CableLabs客户端配置选项的KDC服务器地址子选项。然而，仍然需要一种机制来提供域名和IPv6地址——一种不依赖于任何外部体系结构的机制。
This document defines a Kerberos option for DHCPv6 that provides a realm name and/or a list of KDC IP addresses. This option does not replace or modify any of the existing methods for obtaining this information.
本文档为DHCPv6定义了一个Kerberos选项，该选项提供领域名称和/或KDC IP地址列表。此选项不会替换或修改获取此信息的任何现有方法。
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 RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
It is assumed that the readers are familiar with the terms and concepts described in DHCPv6 [RFC3315], Kerberos V5 [RFC4120], and DNS SRV [RFC2782].
假设读者熟悉DHCPv6[RFC3315]、Kerberos V5[RFC4120]和DNS SRV[RFC2782]中描述的术语和概念。
This document defines four DHCPv6 configuration parameters for Kerberos.
本文档为Kerberos定义了四个DHCPv6配置参数。
Kerberos Principal Name Option
Kerberos主体名称选项
Kerberos Realm Name Option
Kerberos领域名称选项
Kerberos Default Realm Name Option
Kerberos默认领域名称选项
Kerberos KDC Option
Kerberos KDC选项
This section describes the format of each option and the usage of each field in that option.
本节介绍每个选项的格式以及该选项中每个字段的用法。
These options, except for the Kerberos KDC Option, MUST NOT appear more than once in a DHCPv6 message.
这些选项（Kerberos KDC选项除外）在DHCPv6消息中不得出现多次。
The Kerberos Principal Name Option carries the name of a Kerberos principal. This is sent by the client to the DHCPv6 server, which MAY use it to select a specific set of configuration parameters, either for a client or for a Kerberos application server.
Kerberos主体名称选项包含Kerberos主体的名称。这由客户机发送到DHCPv6服务器，该服务器可以使用它为客户机或Kerberos应用程序服务器选择一组特定的配置参数。
The format of the Kerberos Principal Name Option is:
Kerberos主体名称选项的格式为：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_KRB_PRINCIPAL_NAME | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: principal-name :
: (variable length) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_KRB_PRINCIPAL_NAME | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: principal-name :
: (variable length) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o option-code (16 bits): OPTION_KRB_PRINCIPAL_NAME (75)
o 选项代码（16位）：选项名称（75位）
o option-len (16 bits): length of the principal-name field.
o 选项len（16位）：主体名称字段的长度。
o principal-name (variable): a client principal name. The encoding of the principal-name field MUST conform to the definition of "PrincipalName" in Section 5.2.2 of RFC 4120 [RFC4120].
o 主体名称（变量）：客户端主体名称。主体名称字段的编码必须符合RFC 4120[RFC4120]第5.2.2节中“主体名称”的定义。
The Kerberos Realm Name Option carries a Kerberos realm name. A DHCPv6 client uses this option to specify to a DHCPv6 server which realm the client wants to access.
Kerberos领域名称选项带有Kerberos领域名称。DHCPv6客户端使用此选项向DHCPv6服务器指定客户端要访问的域。
The format of the Kerberos Realm Name Option is:
Kerberos领域名称选项的格式为：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_KRB_REALM_NAME | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: realm-name :
: (variable length) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_KRB_REALM_NAME | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: realm-name :
: (variable length) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o option-code (16 bits): OPTION_KRB_REALM_NAME (76)
o 选项代码（16位）：选项名称（76位）
o option-len (16 bits): the length of the realm-name field in octets.
o 选项len（16位）：领域名称字段的长度（以八位字节为单位）。
o realm-name (variable): a realm-name. The encoding of the realm-name field MUST conform to the definition of "Realm" in Section 5.2.2 of RFC 4120 [RFC4120].
o 领域名称（变量）：领域名称。领域名称字段的编码必须符合RFC 4120[RFC4120]第5.2.2节中“领域”的定义。
The Kerberos Default Realm Name Option is used to specify a default realm name for the Kerberos system. A DHCPv6 server uses this option to specify the default realm name to both clients and Kerberos application servers.
Kerberos默认领域名称选项用于为Kerberos系统指定默认领域名称。DHCPv6服务器使用此选项为客户端和Kerberos应用程序服务器指定默认领域名称。
The option-code of this option is OPTION_KRB_DEFAULT_REALM_NAME (77). The format and usage of the option-len and realm-name fields are identical to those for the Kerberos Realm Name Option.
此选项的选项代码是option_KRB_DEFAULT_REALM_NAME（77）。选项len和领域名称字段的格式和用法与Kerberos领域名称选项的格式和用法相同。
The Kerberos KDC Option is used to provide configuration information about a KDC.
Kerberos KDC选项用于提供有关KDC的配置信息。
The format of the Kerberos KDC Option is:
Kerberos KDC选项的格式为：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_KRB_KDC | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Priority | Weight |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transport Type| Port Number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| |
| KDC IPv6 address +---------------+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ :
: :
: realm-name :
: (variable length) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_KRB_KDC | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Priority | Weight |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transport Type| Port Number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| |
| KDC IPv6 address +---------------+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ :
: :
: realm-name :
: (variable length) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o option-code (16 bits): OPTION_KRB_KDC (78)
o 选项代码（16位）：选项KRB KDC（78）
o option-len (16 bits): 23 + the length of the realm-name field in octets.
o 选项len（16位）：23+领域名称字段的长度（以八位字节为单位）。
o Priority (16 bits): see the description of the Weight field.
o 优先级（16位）：请参阅权重字段的说明。
o Weight (16 bits): the Priority and Weight fields provide a hint to the client as to which KDC to select. The usage of the Priority and Weight values MUST follow the specification for DNS SRV [RFC2782].
o 权重（16位）：优先级和权重字段向客户机提供关于选择哪个KDC的提示。优先级和权重值的使用必须遵循DNS SRV[RFC2782]的规范。
o Transport Type (8 bits): The Transport Type specifies the transport protocol used for Kerberos. Kerberos [RFC4120] defines UDP and TCP transports. Exchanges over TCP are further described in [RFC5021], while the transport of Kerberos over Transport Layer Security (TLS) is described in [RFC6251].
o 传输类型（8位）：传输类型指定用于Kerberos的传输协议。Kerberos[RFC4120]定义UDP和TCP传输。[RFC5021]中进一步描述了TCP上的交换，而[RFC6251]中描述了传输层安全性（TLS）上的Kerberos传输。
The transport type is defined below.
传输类型定义如下。
Value Transport Type
---- --------------
0 Reserved
1 UDP
2 TCP
3 TLS
4-254 Unassigned
255 Reserved
Value Transport Type
---- --------------
0 Reserved
1 UDP
2 TCP
3 TLS
4-254 Unassigned
255 Reserved
o Port Number (16 bits): the port number on which the KDC listens.
o 端口号（16位）：KDC侦听的端口号。
o KDC IPv6 address (128 bits): the IPv6 address of the KDC.
o KDC IPv6地址（128位）：KDC的IPv6地址。
o realm-name (variable): the name of the realm for which the specified KDC provides service. The encoding of the realm-name field MUST conform to the definition of "Realm" in Section 5.2.2 of RFC 4120 [RFC4120].
o 领域名称（变量）：指定KDC为其提供服务的领域的名称。领域名称字段的编码必须符合RFC 4120[RFC4120]第5.2.2节中“领域”的定义。
This section describes the operations of the client and server. It assumes that the client has been configured with a principal name.
本节介绍客户端和服务器的操作。它假定客户端已配置了主体名称。
If a client requires a realm name, the client sends a DHCPv6 Option Request Option (ORO) specifying the Kerberos Default Realm Name Option. The DHCPv6 server responds with a Reply message containing a Kerberos Default Realm Name Option.
如果客户机需要领域名称，则客户机将发送一个DHCPv6选项请求选项（ORO），指定Kerberos默认领域名称选项。DHCPv6服务器响应一条包含Kerberos默认领域名称选项的回复消息。
If a client requires configuration parameters for a KDC, the client sends a DHCPv6 ORO specifying the Kerberos KDC Option. The client MAY include a Kerberos Principal Name Option. The client MAY include a Kerberos Realm Name Option.
如果客户机需要KDC的配置参数，则客户机将发送一个指定Kerberos KDC选项的DHCPv6 ORO。客户端可能包括Kerberos主体名称选项。客户端可能包括Kerberos领域名称选项。
The DHCPv6 server replies with one or more sets of configuration parameters for a Kerberos KDC. If the client has specified either a
DHCPv6服务器使用Kerberos KDC的一组或多组配置参数进行响应。如果客户端指定了
Kerberos Principal Name Option or a Kerberos Realm Name Option, then the DHCPv6 server MAY use those parameters to select specific sets of configuration parameters.
Kerberos主体名称选项或Kerberos领域名称选项，则DHCPv6服务器可以使用这些参数来选择特定的配置参数集。
Where the server replies with more than one set of configuration parameters, the usage of the Priority and Weight fields by the client MUST follow the specification for DNS SRV [RFC2782].
如果服务器使用多组配置参数进行响应，则客户端对优先级和权重字段的使用必须遵循DNS SRV[RFC2782]的规范。
The client MAY include other options with data values as hints to the DHCPv6 server about parameter values the client would like to have returned; this is specified in Section 18.1.5 of RFC 3315 [RFC3315].
客户机可能包括其他选项，其中数据值作为向DHCPv6服务器提示客户机希望返回的参数值的提示；RFC 3315[RFC3315]第18.1.5节对此进行了规定。
When a client implements both the DNS method defined by Section 7.2.3.2 of [RFC4120] and the DHCP method defined by this document, the choice of method is determined by local policy. The administrator of the realm usually defines the method as part of the configuration of the client before the client is installed.
当客户端同时实现[RFC4120]第7.2.3.2节定义的DNS方法和本文档定义的DHCP方法时，方法的选择由本地策略决定。领域管理员通常在安装客户端之前将该方法定义为客户端配置的一部分。
When no criteria have been specified and the client could get the Kerberos information from either the DNS server or the DHCPv6 server, then the information from DNS SHOULD be preferred.
如果未指定任何条件，并且客户端可以从DNS服务器或DHCPv6服务器获取Kerberos信息，则应首选来自DNS的信息。
IANA has assigned four option codes from the DHCPv6 Option Codes registry for the following:
IANA已从DHCPv6选项代码注册表中为以下各项分配了四个选项代码：
75 OPTION_KRB_PRINCIPAL_NAME
75选项\u KRB\u主体\u名称
76 OPTION_KRB_REALM_NAME
76选项\u KRB\u领域\u名称
77 OPTION_KRB_DEFAULT_REALM_NAME
77选项\u KRB\u默认\u领域\u名称
78 OPTION_KRB_KDC
78方案KRB KDC
IANA has created the Kerberos Message Transport Types sub-registry, under the Kerberos Parameters registry. The initial entries are described in Section 3.4.
IANA在Kerberos参数注册表下创建了Kerberos消息传输类型子注册表。第3.4节描述了初始条目。
The assignment of future entries is by "IETF Review" policy as described in BCP 26 [RFC5226]. Per that policy, a document specifies the symbolic name of such entries, which are assigned numeric codes by IANA once publication is approved.
按照BCP 26[RFC5226]中所述的“IETF审查”政策分配未来条目。根据该政策，文件指定了此类条目的符号名称，一旦发布获得批准，IANA将为这些条目分配数字代码。
The security considerations in RFC 3315 [RFC3315] apply.
RFC 3315[RFC3315]中的安全注意事项适用。
DHCPv6 messages can be modified in transit. If an adversary modifies the response from a DHCPv6 server or injects its own response, a client may be led into contacting a malicious KDC. Both cases are categorized as a Denial-of-Service (DoS) attack. However, a malicious KDC does not know the shared key and so is unable to proceed any further with the exchange. If a client receives a response from such a KDC, the client can use the shared key to detect that the message originates from a malicious KDC.
DHCPv6消息可以在传输过程中进行修改。如果对手修改来自DHCPv6服务器的响应或注入其自己的响应，则可能会导致客户端联系恶意KDC。这两种情况都属于拒绝服务（DoS）攻击。但是，恶意KDC不知道共享密钥，因此无法进一步进行交换。如果客户端收到来自此类KDC的响应，则客户端可以使用共享密钥检测消息是否源自恶意KDC。
A shared, unconfigured workstation may obtain its KDC information, and default realm, via DHCPv6. Such a workstation may not have a host or other service key, and thus it may be unable to validate the Ticket-Granting Ticket issued by the KDC. A modified DHCPv6 response would then result in the workstation talking to a malicious KDC, and the workstation would not be able to detect that this has happened. This in turn could allow access by unauthorized users.
共享的、未配置的工作站可以通过DHCPv6获取其KDC信息和默认域。这样的工作站可能没有主机或其他服务密钥，因此可能无法验证KDC颁发的票证授予票证。修改后的DHCPv6响应将导致工作站与恶意KDC对话，并且工作站将无法检测到发生了这种情况。这反过来可能允许未经授权的用户访问。
To minimize potential vulnerabilities, a client SHOULD use DHCPv6 authentication as defined in Section 21 of RFC 3315 [RFC3315].
为了最大限度地减少潜在漏洞，客户端应使用RFC 3315[RFC3315]第21节中定义的DHCPv6身份验证。
Kerberos information may be manually configured on the client before requesting information from DHCPv6. Manual configuration of the device SHOULD be preferred to configuration via the DHCPv6 server.
在从DHCPv6请求信息之前，可以在客户端上手动配置Kerberos信息。手动配置设备应优先于通过DHCPv6服务器进行配置。
The authors are very grateful to Nobuo Okabe and Shigeya Suzuki. They contributed the explanation as to why DNS is inappropriate for some industry networks. Ted Lemon made many suggestions to improve DHCP aspects of this specification. Ken'ichi Kamada and Yukiyo Akisada contributed to the initial work on this document. Tom Petch helped to improve the readability of this document. The authors also thank Jeffrey Hutzelman, Kazunori Miyazawa, Kensuke Hosoya, Nicolas Williams, Nobumichi Ozoe, Sam Hartman, and Stephen Farrell. They made valuable comments and suggestions.
作者非常感谢冈部信夫和铃木茂。他们解释了为什么DNS不适合某些行业网络。Ted Lemon提出了许多建议来改进该规范的DHCP方面。Kamada Ken'ichi和秋田由纪夫对本文件的初始工作做出了贡献。Tom Petch帮助提高了本文档的可读性。作者还感谢杰弗里·哈泽尔曼、宫泽一郎、细谷健介、尼古拉斯·威廉姆斯、小泽信一、萨姆·哈特曼和斯蒂芬·法雷尔。他们提出了宝贵的意见和建议。
[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月。
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[RFC2782]Gulbrandsen，A.，Vixie，P.和L.Esibov，“用于指定服务位置（DNS SRV）的DNS RR”，RFC 2782，2000年2月。
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315]Droms，R.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC3315，2003年7月。
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005.
[RFC4120]Neuman，C.，Yu，T.，Hartman，S.，和K.Raeburn，“Kerberos网络身份验证服务（V5）”，RFC41202005年7月。
[RFC5021] Josefsson, S., "Extended Kerberos Version 5 Key Distribution Center (KDC) Exchanges over TCP", RFC 5021, August 2007.
[RFC5021]Josefsson，S.，“通过TCP的扩展Kerberos版本5密钥分发中心（KDC）交换”，RFC 50212007年8月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[PCARCH] CableLabs, "PacketCable 1.0(TM) Architecture Framework Technical Report", December 1999, <http://www.packetcable.com/downloads/specs/ pkt-tr-arch-v01-991201.pdf>.
[PCARCH]CableLabs，“PacketCable 1.0（TM）体系结构框架技术报告”，1999年12月<http://www.packetcable.com/downloads/specs/ pkt-tr-arch-v01-991201.pdf>。
[RFC3634] Luehrs, K., Woundy, R., Bevilacqua, J., and N. Davoust, "Key Distribution Center (KDC) Server Address Sub-option for the Dynamic Host Configuration Protocol (DHCP) CableLabs Client Configuration (CCC) Option", RFC 3634, December 2003.
[RFC3634]Luehrs，K.，Woundy，R.，Bevilacqua，J.，和N.Davoust，“动态主机配置协议（DHCP）CableLabs客户端配置（CCC）选项的密钥分发中心（KDC）服务器地址子选项”，RFC 3634，2003年12月。
[RFC6251] Josefsson, S., "Using Kerberos Version 5 over the Transport Layer Security (TLS) Protocol", RFC 6251, May 2011.
[RFC6251]Josefsson，S.，“在传输层安全（TLS）协议上使用Kerberos版本5”，RFC 6251，2011年5月。
When no criteria have been specified and the client could get the Kerberos information from either the DNS server or the DHCPv6 server, then the information from DNS SHOULD be preferred. The following is an informational guide for the client in such an environment.
如果未指定任何条件，并且客户端可以从DNS服务器或DHCPv6服务器获取Kerberos信息，则应首选来自DNS的信息。以下是针对此类环境中的客户机的信息指南。
No Resp. or
+------------+ DNS Info. +-----------+ No Resp.
Start --> | Ask DHCP(1)| ---------> | Ask DNS(3)| ------>
+------------+ +-----------+ Terminate(4)
/ \ \
Only KRB / \ DNS and \ KRB Info.
Info. / \ KRB Info. \
/ \ \
| | |
| V |
V No Ans. +-----------+ KRB Info. V
Use Info. <-------- | Ask DNS(6)| ---------> Use Info.
from DHCP +-----------+ from DNS
(2), (7) (5), (8)
No Resp. or
+------------+ DNS Info. +-----------+ No Resp.
Start --> | Ask DHCP(1)| ---------> | Ask DNS(3)| ------>
+------------+ +-----------+ Terminate(4)
/ \ \
Only KRB / \ DNS and \ KRB Info.
Info. / \ KRB Info. \
/ \ \
| | |
| V |
V No Ans. +-----------+ KRB Info. V
Use Info. <-------- | Ask DNS(6)| ---------> Use Info.
from DHCP +-----------+ from DNS
(2), (7) (5), (8)
Abbreviations: Resp.: Response Info.: Information KRB : Kerberos
缩写：Resp.：响应信息：信息KRB:Kerberos
1) Initially, the client requests both DNS and Kerberos information from the DHCPv6 server.
1) 最初，客户机从DHCPv6服务器请求DNS和Kerberos信息。
2) If the DHCPv6 server replies with Kerberos information and not with DNS information, then the client uses that information.
2) 如果DHCPv6服务器使用Kerberos信息而不是DNS信息进行回复，则客户端将使用该信息。
3) If the DHCPv6 server does not reply or replies with only DNS information, then the client requests Kerberos information from the DNS server.
3) 如果DHCPv6服务器不回复或只回复DNS信息，则客户端从DNS服务器请求Kerberos信息。
4) If the client gets no response or no Kerberos information from the DNS server, then the client terminates the process.
4) 如果客户端没有从DNS服务器获得响应或Kerberos信息，则客户端终止该进程。
5) If the client gets Kerberos information from the DNS server, then the client uses that information.
5) 如果客户端从DNS服务器获取Kerberos信息，则客户端将使用该信息。
6) If, as the result of (1), the DHCPv6 server replies with both DNS and Kerberos information, then the client requests Kerberos information from the DNS server.
6) 如果作为（1）的结果，DHCPv6服务器使用DNS和Kerberos信息进行应答，则客户端从DNS服务器请求Kerberos信息。
7) If the client gets no response from the DNS server, then the client uses the Kerberos information from the DHCPv6 server.
7) 如果客户端没有从DNS服务器获得响应，则客户端使用来自DHCPv6服务器的Kerberos信息。
8) If, as the result of (6), the DNS server replies with Kerberos information, then the client uses the information from the DNS server and not that from the DHCPv6 server.
8) 如果作为（6）的结果，DNS服务器使用Kerberos信息进行响应，则客户端使用来自DNS服务器的信息，而不是来自DHCPv6服务器的信息。
Authors' Addresses
作者地址
Shoichi Sakane Cisco Systems 9-7-1 Akasaka Minato-ku, Tokyo 107-6227 Japan
坂根昭一思科系统公司9-7-1赤坂Minato ku，东京107-6227日本
EMail: ssakane@cisco.com
EMail: ssakane@cisco.com
Masahiro Ishiyama Toshiba Corporation 1, Komukai-toshiba-cho, Saiwai-ku, Kawasaki, Kanagawa 212-8582 Japan
石山正彦东芝株式会社1号，日本神奈川市西围谷小井东芝町212-8582
EMail: masahiro.ishiyama@toshiba.co.jp
EMail: masahiro.ishiyama@toshiba.co.jp