Network Working Group H. Schulzrinne
Request for Comments: 3361 Columbia University
Category: Standards Track August 2002
Network Working Group H. Schulzrinne
Request for Comments: 3361 Columbia University
Category: Standards Track August 2002
Dynamic Host Configuration Protocol (DHCP-for-IPv4) Option for Session Initiation Protocol (SIP) Servers
会话启动协议（SIP）服务器的动态主机配置协议（DHCP-for-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 (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
Abstract
摘要
This document defines a Dynamic Host Configuration Protocol (DHCP-for-IPv4) option that contains a list of domain names or IPv4 addresses that can be mapped to one or more Session Initiation Protocol (SIP) outbound proxy servers. This is one of the many methods that a SIP client can use to obtain the addresses of such a local SIP server.
本文档定义了一个动态主机配置协议（DHCP-for-IPv4）选项，该选项包含可映射到一个或多个会话启动协议（SIP）出站代理服务器的域名或IPv4地址列表。这是SIP客户端可以用来获取此类本地SIP服务器地址的许多方法之一。
DHCP client: A DHCP [1] client is an Internet host that uses DHCP to obtain configuration parameters such as a network address.
DHCP客户端：DHCP[1]客户端是使用DHCP获取配置参数（如网络地址）的Internet主机。
DHCP server: A DHCP server is an Internet host that returns configuration parameters to DHCP clients.
DHCP服务器：DHCP服务器是向DHCP客户端返回配置参数的Internet主机。
SIP server: As defined in RFC 3261 [2]. This server MUST be an outbound proxy server, as defined in [3]. In the context of this document, a SIP server refers to the host the SIP server is running on.
SIP服务器：如RFC 3261[2]中所定义。此服务器必须是[3]中定义的出站代理服务器。在本文档的上下文中，SIP服务器指运行SIP服务器的主机。
SIP client: As defined in RFC 3261. The client can be a user agent client or the client portion of a proxy server. In the context of this document, a SIP client refers to the host the SIP client is running on.
SIP客户端：如RFC 3261中所定义。客户端可以是用户代理客户端或代理服务器的客户端部分。在本文档的上下文中，SIP客户端指的是SIP客户端运行的主机。
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [4].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[4]中的说明进行解释。
The Session Initiation Protocol (SIP) [2] is an application-layer control protocol that can establish, modify and terminate multimedia sessions or calls. A SIP system has a number of logical components: user agents, proxy servers, redirect servers and registrars. User agents MAY contain SIP clients, proxy servers always do.
会话发起协议（SIP）[2]是一种应用层控制协议，可以建立、修改和终止多媒体会话或呼叫。SIP系统有许多逻辑组件：用户代理、代理服务器、重定向服务器和注册器。用户代理可能包含SIP客户端，代理服务器通常包含SIP客户端。
This document specifies a DHCP option [1,5] that allows SIP clients to locate a local SIP server that is to be used for all outbound SIP requests, a so-called outbound proxy server. (SIP clients MAY contact the address identified in the SIP URL directly, without involving a local SIP server. However in some circumstances, for example, when firewalls are present, SIP clients need to use a local server for outbound requests.) This is one of many possible solutions for locating the outbound SIP server; manual configuration is an example of another.
本文档指定了一个DHCP选项[1,5]，该选项允许SIP客户端定位用于所有出站SIP请求的本地SIP服务器，即所谓的出站代理服务器。（SIP客户端可以直接联系SIP URL中标识的地址，而不涉及本地SIP服务器。但是在某些情况下，例如，当存在防火墙时，SIP客户端需要使用本地服务器进行出站请求。）这是定位出站SIP服务器的许多可能解决方案之一；手动配置是另一个示例。
The SIP server DHCP option carries either a 32-bit (binary) IPv4 address or, preferably, a DNS (RFC 1035 [6]) fully-qualified domain name to be used by the SIP client to locate a SIP server.
SIP服务器DHCP选项携带32位（二进制）IPv4地址，或者优选地，携带由SIP客户端用于定位SIP服务器的DNS（RFC 1035[6]）完全限定域名。
The option has two encodings, specified by the encoding byte ('enc') that follows the code byte. If the encoding byte has the value 0, it is followed by a list of domain names, as described below (Section 3.1). If the encoding byte has the value 1, it is followed by one or more IPv4 addresses (Section 3.2). All implementations MUST support both encodings. The 'Len' field indicates the total number of octets in the option following the 'Len' field, including the encoding byte.
该选项有两种编码，由代码字节后面的编码字节（“enc”）指定。如果编码字节的值为0，则后跟域名列表，如下所述（第3.1节）。如果编码字节的值为1，则后跟一个或多个IPv4地址（第3.2节）。所有实现都必须支持这两种编码。“Len”字段表示“Len”字段后面选项中的八位字节总数，包括编码字节。
A DHCP server MUST NOT mix the two encodings in the same DHCP message, even if it sends two different instances of the same option. Attempts to do so would result in incorrect client behavior as DHCP processing rules call for the concatenation of multiple instances of an option into a single option prior to processing the option [7].
DHCP服务器不得在同一DHCP消息中混合使用这两种编码，即使它发送同一选项的两个不同实例。尝试这样做将导致不正确的客户端行为，因为DHCP处理规则要求在处理选项之前将选项的多个实例连接到单个选项中[7]。
The code for this option is 120.
此选项的代码为120。
If the 'enc' byte has a value of 0, the encoding byte is followed by a sequence of labels, encoded according to Section 3.1 of RFC 1035 [6], quoted below:
如果“enc”字节的值为0，则编码字节后面跟着一系列标签，按照RFC 1035[6]第3.1节进行编码，如下所述：
Domain names in messages are expressed in terms of a sequence of labels. Each label is represented as a one octet length field followed by that number of octets. Since every domain name ends with the null label of the root, a domain name is terminated by a length byte of zero. The high order two bits of every length octet must be zero, and the remaining six bits of the length field limit the label to 63 octets or less. To simplify implementations, the total length of a domain name (i.e., label octets and label length octets) is restricted to 255 octets or less.
消息中的域名用一系列标签表示。每个标签表示为一个八位字节长度字段，后跟该八位字节数。由于每个域名都以根的空标签结尾，因此域名以长度为零的字节结尾。每个长度八位字节的高阶两位必须为零，长度字段的其余六位将标签限制为63个八位字节或更少。为了简化实现，域名的总长度（即标签八位字节和标签长度八位字节）限制为255个八位字节或更少。
RFC 1035 encoding was chosen to accommodate future internationalized domain name mechanisms.
选择RFC1035编码是为了适应未来的国际化域名机制。
The minimum length for this encoding is 3.
此编码的最小长度为3。
The option MAY contain multiple domain names, but these SHOULD refer to different NAPTR records, rather than different A records. The client MUST try the records in the order listed, applying the mechanism described in Section 4.1 of RFC 3263 [3] for each. The client only resolves the subsequent domain names if attempts to contact the first one failed or yielded no common transport protocols between client and server or denote a domain administratively prohibited by client policy.
该选项可能包含多个域名，但这些域名应指向不同的NAPTR记录，而不是不同的A记录。客户必须按照列出的顺序尝试记录，并对每个记录应用RFC 3263[3]第4.1节中描述的机制。如果尝试联系第一个域名失败，或者在客户端和服务器之间未产生公共传输协议，或者表示客户端策略在管理上禁止的域，则客户端仅解析后续域名。
Use of multiple domain names is not meant to replace NAPTR and SRV records, but rather to allow a single DHCP server to indicate outbound proxy servers operated by multiple providers.
使用多个域名并不意味着替换NAPTR和SRV记录，而是允许单个DHCP服务器指示由多个提供商操作的出站代理服务器。
Clients MUST support compression according to the encoding in Section 4.1.4 of "Domain Names - Implementation And Specification" [6].
客户机必须根据“域名-实现和规范”[6]第4.1.4节中的编码支持压缩。
Since the domain names are supposed to be different domains, compression will likely have little effect, however.
但是，由于域名应该是不同的域，因此压缩可能没有什么效果。
If the length of the domain list exceeds the maximum permissible within a single option (254 octets), then the domain list MUST be represented in the DHCP message as specified in [7].
如果域列表的长度超过单个选项内允许的最大值（254个八位字节），则域列表必须按照[7]中的规定在DHCP消息中表示。
The DHCP option for this encoding has the following format:
此编码的DHCP选项具有以下格式：
Code Len enc DNS name of SIP server
+-----+-----+-----+-----+-----+-----+-----+-----+--
| 120 | n | 0 | s1 | s2 | s3 | s4 | s5 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+--
Code Len enc DNS name of SIP server
+-----+-----+-----+-----+-----+-----+-----+-----+--
| 120 | n | 0 | s1 | s2 | s3 | s4 | s5 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+--
As an example, consider the case where the server wants to offer two outbound proxy servers, "example.com" and "example.net". These would be encoded as follows:
作为一个例子，考虑服务器想要提供两个出站代理服务器“示例.com”和“示例.NET”的情况。这些将被编码如下：
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|120|27 | 0 | 7 |'e'|'x'|'a'|'m'|'p'|'l'|'e'| 3 |'c'|'o'|'m'| 0 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+---+---+---+---+---+---+---+---+---+---+---+---+---+ | 7
|'e'|'x'|'a'|'m'|'p'|'l'|'e'| 3 |'n'|'e'|'t'| 0 | +---+---+---
+---+---+---+---+---+---+---+---+---+---+
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|120|27 | 0 | 7 |'e'|'x'|'a'|'m'|'p'|'l'|'e'| 3 |'c'|'o'|'m'| 0 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+---+---+---+---+---+---+---+---+---+---+---+---+---+ | 7
|'e'|'x'|'a'|'m'|'p'|'l'|'e'| 3 |'n'|'e'|'t'| 0 | +---+---+---
+---+---+---+---+---+---+---+---+---+---+
If the 'enc' byte has a value of 1, the encoding byte is followed by a list of IPv4 addresses indicating SIP outbound proxy servers available to the client. Servers MUST be listed in order of preference.
如果“enc”字节的值为1，则编码字节后面会有一个IPv4地址列表，指示客户端可用的SIP出站代理服务器。服务器必须按优先顺序列出。
Its minimum length is 5, and the length MUST be a multiple of 4 plus one. The DHCP option for this encoding has the following format:
它的最小长度是5，长度必须是4加1的倍数。此编码的DHCP选项具有以下格式：
Code Len enc Address 1 Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+--
| 120 | n | 1 | a1 | a2 | a3 | a4 | a1 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+--
Code Len enc Address 1 Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+--
| 120 | n | 1 | a1 | a2 | a3 | a4 | a1 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+--
The security considerations in RFC 2131 [1], RFC 2543 [2] and RFC 3263 [3] apply. If an adversary manages to modify the response from a DHCP server or insert its own response, a SIP user agent could be led to contact a rogue SIP server, possibly one that then intercepts call requests or denies service. A modified DHCP answer could also omit host names that translated to TLS-based SIP servers, thus facilitating intercept.
RFC 2131[1]、RFC 2543[2]和RFC 3263[3]中的安全注意事项适用。如果对手设法修改来自DHCP服务器的响应或插入自己的响应，则SIP用户代理可能会被引导与恶意SIP服务器联系，该服务器可能会拦截呼叫请求或拒绝服务。修改后的DHCP应答还可以省略转换为基于TLS的SIP服务器的主机名，从而便于拦截。
IANA has assigned a DHCP option number of 120 for the "SIP Servers DHCP Option" defined in this document.
IANA已为本文档中定义的“SIP服务器DHCP选项”分配了DHCP选项编号120。
Ralph Droms, Robert Elz, Wenyu Jiang, Peter Koch, Gautam Nair, Thomas Narten, Erik Nordmark, Jonathan Rosenberg, Kundan Singh, Sven Ubik, Bernie Volz and Dean Willis provided useful feedback through the evolution of this document.
拉尔夫·德罗姆斯、罗伯特·埃尔兹、姜文玉、彼得·科赫、乔塔姆·奈尔、托马斯·纳滕、埃里克·诺德马克、乔纳森·罗森博格、昆丹·辛格、斯文·乌比克、伯尼·沃尔兹和迪安·威利斯通过本文件的演变提供了有用的反馈。
[1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[1] Droms，R.，“动态主机配置协议”，RFC 2131，1997年3月。
[2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[2] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[3] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.
[3] Rosenberg，J.和H.Schulzrinne，“会话启动协议（SIP）：定位SIP服务器”，RFC3263，2002年6月。
[4] Bradner, S., "Key words for use in RFCs to indicate requirement levels", BCP 14, RFC 2119, March 1997.
[4] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[5] Alexander, S. and R. Droms, "DHCP options and BOOTP Vendor Extensions", RFC 2132, March 1997.
[5] Alexander，S.和R.Droms，“DHCP选项和BOOTP供应商扩展”，RFC 21321997年3月。
[6] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[6] Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 10351987年11月。
[7] Lemon, T. and S. Cheshire, "Encoding Long DHCP Options", Work in Progress.
[7] Lemon，T.和S.Cheshire，“编码长DHCP选项”，正在进行中。
Henning Schulzrinne Dept. of Computer Science Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY 10027 USA
美国纽约州纽约市阿姆斯特丹大道1214号哥伦比亚大学计算机科学系，邮编：10027
EMail: schulzrinne@cs.columbia.edu
EMail: schulzrinne@cs.columbia.edu
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。