Internet Engineering Task Force (IETF) V. Gurbani, Ed.
Request for Comments: 5954 Bell Laboratories, Alcatel-Lucent
Updates: 3261 B. Carpenter, Ed.
Category: Standards Track Univ. of Auckland
ISSN: 2070-1721 B. Tate, Ed.
BroadSoft
August 2010
Internet Engineering Task Force (IETF) V. Gurbani, Ed.
Request for Comments: 5954 Bell Laboratories, Alcatel-Lucent
Updates: 3261 B. Carpenter, Ed.
Category: Standards Track Univ. of Auckland
ISSN: 2070-1721 B. Tate, Ed.
BroadSoft
August 2010
Essential Correction for IPv6 ABNF and URI Comparison in RFC 3261
RFC 3261中IPv6 ABNF和URI比较的基本更正
Abstract
摘要
This document corrects the Augmented Backus-Naur Form (ABNF) production rule associated with generating IPv6 literals in RFC 3261. It also clarifies the rule for Uniform Resource Identifier (URI) comparison when the URIs contain textual representation of IP addresses.
本文档更正了与在RFC 3261中生成IPv6文本相关联的增广的Backus Naur Form（ABNF）生成规则。它还阐明了当URI包含IP地址的文本表示时，统一资源标识符（URI）比较的规则。
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/rfc5954.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5954.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 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 . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 2
3.1. Extra Colon in IPv4-Mapped IPv6 Address . . . . . . . . . . 2
3.2. Comparing URIs with Textual Representation of IP
Addresses . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Resolution for Extra Colon in IPv4-Mapped IPv6 Address . . 4
4.2. Clarification for Comparison of URIs with Textual
Representation of IP Addresses . . . . . . . . . . . . . . 5
5. Generating a Canonical IPv6 Textual Representation . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . . 6
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 2
3.1. Extra Colon in IPv4-Mapped IPv6 Address . . . . . . . . . . 2
3.2. Comparing URIs with Textual Representation of IP
Addresses . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Resolution for Extra Colon in IPv4-Mapped IPv6 Address . . 4
4.2. Clarification for Comparison of URIs with Textual
Representation of IP Addresses . . . . . . . . . . . . . . 5
5. Generating a Canonical IPv6 Textual Representation . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . . 6
This document corrects the Augmented Backus-Naur Form (ABNF) production rule associated with generating IPv6 literals in RFC 3261 [1]. It also clarifies the rule for Uniform Resource Identifier (URI) comparison when the URIs contain textual representation of IP addresses.
本文档更正了与RFC 3261[1]中生成IPv6文本相关的增广巴科斯诺尔形式（ABNF）生成规则。它还阐明了当URI包含IP地址的文本表示时，统一资源标识符（URI）比较的规则。
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 [2].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[2]中所述进行解释。
The ABNF [4] for generating IPv6 literals in RFC 3261 [1] is incorrect. When generating IPv4-mapped IPv6 addresses, the production rule may actually generate the following construct:
RFC 3261[1]中用于生成IPv6文本的ABNF[4]不正确。生成IPv4映射的IPv6地址时，生产规则可能实际生成以下构造：
[2001:db8:::192.0.2.1] - Note the extra colon before the IPv4 address.
[2001:db8:：：192.0.2.1]-请注意IPv4地址前的额外冒号。
The correct construct, of course, would only include two colons before the IPv4 address.
当然，正确的构造只会在IPv4地址前包含两个冒号。
Historically, the ABNF pertaining to IPv6 references in RFC 3261 was derived from Appendix B of RFC 2373 [7], which was flawed to begin with (see errata for RFC 2373 [8]). RFC 2373 has been subsequently obsoleted by RFC 4291 [6].
从历史上看，RFC 3261中与IPv6引用相关的ABNF源自RFC 2373[7]的附录B，该附录一开始就存在缺陷（参见RFC 2373[8]的勘误表）。RFC 2373随后被RFC 4291淘汰[6]。
The ABNF for IPv6reference is reproduced from RFC 3261 below:
IPV6参考的ABNF复制自以下RFC 3261：
IPv6reference = "[" IPv6address "]"
IPv6address = hexpart [ ":" IPv4address ]
IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT
hexpart = hexseq / hexseq "::" [ hexseq ] / "::" [ hexseq ]
hexseq = hex4 *( ":" hex4)
hex4 = 1*4HEXDIG
IPv6reference = "[" IPv6address "]"
IPv6address = hexpart [ ":" IPv4address ]
IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT
hexpart = hexseq / hexseq "::" [ hexseq ] / "::" [ hexseq ]
hexseq = hex4 *( ":" hex4)
hex4 = 1*4HEXDIG
Note that the ambiguity occurs in the <IPv6address> production rule where the <IPv4address> non-terminal is prefixed by the ":" token. Because the <hexpart> production rule is defined such that two of its alternatives already include the "::" token, this may yield to the faulty construction of an IPv6-mapped IPv4 address with an extra colon when expanding those alternatives.
请注意，<IPv6address>产生式规则中出现歧义，其中<IPv4address>非终端前缀为“：”标记。由于<hexpart>产生式规则的定义使得其两个备选方案已经包含“：：”令牌，因此在扩展这些备选方案时，这可能会导致错误地构造带有额外冒号的IPv6映射IPv4地址。
In SIP, URIs are compared for a variety of reasons. Registrars compare URIs when they receive a binding update request, for instance. Section 19.1.4 of RFC 3261 [1] provides the rules for comparing URIs. Among other rules, it states that:
在SIP中，由于各种原因对URI进行了比较。例如，注册器在收到绑定更新请求时比较URI。RFC 3261[1]第19.1.4节提供了比较URI的规则。除其他规则外，它规定：
For two URIs to be equal, the user, password, host, and port components must match.
要使两个URI相等，用户、密码、主机和端口组件必须匹配。
Does the above rule then imply that the following URIs are equal:
那么，上述规则是否意味着以下URI相等：
sip:bob@[::ffff:192.0.2.128] = sip:bob@[::ffff:c000:280]?
sip:bob@[::ffff:192.0.2.128] = sip:bob@[::ffff:c000:280]?
sip:bob@[2001:db8::9:1] = sip:bob@[2001:db8::9:01]?
sip:bob@[2001:db8::9:1] = sip:bob@[2001:db8::9:01]?
sip:bob@[0:0:0:0:0:FFFF:129.144.52.38] = sip:bob@
[::FFFF:129.144.52.38]?
sip:bob@[0:0:0:0:0:FFFF:129.144.52.38] = sip:bob@
[::FFFF:129.144.52.38]?
In all of the above examples, the textual representation of the IPv6 address is different, but these addresses are binary equivalents (implementers are also urged to consult Section 5 of this document for recommendations on IPv6 address text representations). Section 19.1.4 of RFC 3261 does not provide any rule for URIs containing different textual representations of IPv6 addresses that all correspond to the same binary equivalent.
在上述所有示例中，IPv6地址的文本表示形式不同，但这些地址是二进制等价物（还敦促实施者参考本文档第5节，以了解有关IPv6地址文本表示形式的建议）。RFC 3261的第19.1.4节没有为包含IPv6地址的不同文本表示的URI提供任何规则，这些地址都对应于相同的二进制等价物。
Note that the same ambiguity occurs for IPv4 addresses, i.e., is 192.0.2.128 = 192.00.02.128? However, IPv6, with its compressed notation and the need to represent hybrid addresses (like IPv4- mapped IPv6 addresses) makes the representation issue more acute. The resolution discussed in Section 4.2 applies to textual representations of both IPv6 and IPv4 addresses.
请注意，IPv4地址也会出现同样的歧义，即is 192.0.2.128=192.00.02.128？然而，IPv6及其压缩表示法和表示混合地址（如IPv4映射的IPv6地址）的需要使得表示问题更加尖锐。第4.2节中讨论的解决方案适用于IPv6和IPv4地址的文本表示。
The resolution to this ambiguity is simply to use the correct ABNF for the <IPv6address> production rule from Appendix A of RFC 3986 [3]. For the sake of completeness, it is reproduced below:
解决这一歧义的方法只是使用RFC 3986[3]附录A中的<IPv6address>产生式规则的正确ABNF。为完整起见，现将其复制如下：
IPv6address = 6( h16 ":" ) ls32
/ "::" 5( h16 ":" ) ls32
/ [ h16 ] "::" 4( h16 ":" ) ls32
/ [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32
/ [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32
/ [ *3( h16 ":" ) h16 ] "::" h16 ":" ls32
/ [ *4( h16 ":" ) h16 ] "::" ls32
/ [ *5( h16 ":" ) h16 ] "::" h16
/ [ *6( h16 ":" ) h16 ] "::"
IPv6address = 6( h16 ":" ) ls32
/ "::" 5( h16 ":" ) ls32
/ [ h16 ] "::" 4( h16 ":" ) ls32
/ [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32
/ [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32
/ [ *3( h16 ":" ) h16 ] "::" h16 ":" ls32
/ [ *4( h16 ":" ) h16 ] "::" ls32
/ [ *5( h16 ":" ) h16 ] "::" h16
/ [ *6( h16 ":" ) h16 ] "::"
h16 = 1*4HEXDIG
ls32 = ( h16 ":" h16 ) / IPv4address
IPv4address = dec-octet "." dec-octet "." dec-octet "." dec-octet
dec-octet = DIGIT ; 0-9
/ %x31-39 DIGIT ; 10-99
/ "1" 2DIGIT ; 100-199
/ "2" %x30-34 DIGIT ; 200-249
/ "25" %x30-35 ; 250-255
h16 = 1*4HEXDIG
ls32 = ( h16 ":" h16 ) / IPv4address
IPv4address = dec-octet "." dec-octet "." dec-octet "." dec-octet
dec-octet = DIGIT ; 0-9
/ %x31-39 DIGIT ; 10-99
/ "1" 2DIGIT ; 100-199
/ "2" %x30-34 DIGIT ; 200-249
/ "25" %x30-35 ; 250-255
Accordingly, this document updates RFC 3261 as follows: the <IPv6address> and <IPv4address> production rules from RFC 3261 MUST NOT be used and instead, the production rules of the same name in RFC 3986 (and reproduced above) MUST be used. This will render <hexpart>, <hexseq>, and <hex4> production rules in RFC 3261 obsolete; as such, these three production rules -- namely, <hexpart>, <hexseq>, and <hex4> -- from RFC 3261 MUST NOT be used.
因此，本文档将RFC 3261更新如下：不得使用RFC 3261中的<IPv6address>和<IPv4address>产生式规则，而必须使用RFC 3986中同名的产生式规则（如上所述）。这将使RFC 3261中的<hexpart>、<hexseq>和<hex4>生产规则过时；因此，不能使用RFC 3261中的这三条生成规则，即<hexpart>、<hexseq>和<hex4>。
The use of the <IPv4address> production rule from RFC 3986 no longer allows syntactically valid -- though semantically invalid -- SIP URIs of the form "sip:bob@444.555.666.777".
使用RFC 3986中的<IPv4address>产生式规则不再允许语法上有效（尽管语义上无效）“SIP:bob@444.555.666.777".
4.2. Clarification for Comparison of URIs with Textual Representation of IP Addresses
4.2. 对URI与IP地址的文本表示进行比较的说明
The resolution to this ambiguity is a simple clarification acknowledging that the textual representation of an IP address varies, but it is the binary equivalence of the IP address that must be taken into consideration when comparing two URIs that contain varying textual representations of an IP address.
解决这一歧义的方法很简单，即承认IP地址的文本表示形式不同，但在比较包含IP地址不同文本表示形式的两个URI时，必须考虑IP地址的二进制等价性。
Accordingly, the existing rule from the bulleted list in Section 19.1.4 of RFC 3261 MUST be modified as follows:
因此，RFC 3261第19.1.4节项目符号列表中的现有规则必须修改如下：
OLD:
旧的：
o For two URIs to be equal, the user, password, host, and port components must match.
o 要使两个URI相等，用户、密码、主机和端口组件必须匹配。
NEW:
新的：
o For two URIs to be equal, the user, password, host, and port components must match. If the host component contains a textual representation of IP addresses, then the representation of those IP addresses may vary. If so, the host components are considered to match if the different textual representations yield the same binary IP address.
o 要使两个URI相等，用户、密码、主机和端口组件必须匹配。如果主机组件包含IP地址的文本表示，则这些IP地址的表示可能会有所不同。如果是这样，如果不同的文本表示产生相同的二进制IP地址，则主机组件被视为匹配。
In addition, the text in the following paragraph MUST be added to the existing list of examples in Section 19.1.4 of RFC 3261 in order to demonstrate the intent of the modified rule:
此外，以下段落中的文本必须添加到RFC 3261第19.1.4节中的现有示例列表中，以证明修改规则的意图：
The following URIs are equivalent because the underlying binary representation of the IP addresses are the same although their textual representations vary:
以下URI是等效的，因为IP地址的基本二进制表示形式是相同的，尽管它们的文本表示形式不同：
sip:bob@[::ffff:192.0.2.128]
sip:bob@[::ffff:c000:280]
sip:bob@[::ffff:192.0.2.128]
sip:bob@[::ffff:c000:280]
sip:bob@[2001:db8::9:1]
sip:bob@[2001:db8::9:01]
sip:bob@[2001:db8::9:1]
sip:bob@[2001:db8::9:01]
sip:bob@[0:0:0:0:0:FFFF:129.144.52.38]
sip:bob@[::FFFF:129.144.52.38]
sip:bob@[0:0:0:0:0:FFFF:129.144.52.38]
sip:bob@[::FFFF:129.144.52.38]
Implementers SHOULD generate IPv6 text representation as defined in RFC 5952 [5].
实施者应生成RFC 5952[5]中定义的IPv6文本表示。
This document does not introduce any new security considerations beyond those described in RFC 3261 [1].
除RFC 3261[1]中所述的安全注意事项外，本文件未引入任何新的安全注意事项。
The ABNF for IPv6 was developed by Roy T. Fielding and Andrew Main and published in RFC 3986.
IPv6的ABNF由Roy T.Fielding和Andrew Main开发，并发表在RFC 3986上。
Jeroen van Bemmel, Peter Blatherwick, Gonzalo Camarillo, Paul Kyzivat, Jonathan Rosenberg, Michael Thomas, and Dale Worley provided invaluable discussion points on the SIP WG mailing list on the URI equivalency problem. Alfred Hoenes urged the use of angle brackets (as specified in Section 2.1 of RFC 5234 [4]) to denote productions.
Jeroen van Bemmel、Peter Blatherwick、Gonzalo Camarillo、Paul Kyzivat、Jonathan Rosenberg、Michael Thomas和Dale Worley在SIP工作组邮件列表中就URI等效性问题提供了宝贵的讨论点。Alfred Hoenes敦促使用尖括号（如RFC 5234[4]第2.1节所述）来表示产品。
[1] 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.
[1] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[3] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[3] Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[4] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[4] Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[5] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, August 2010.
[5] Kawamura，S.和M.Kawashima，“IPv6地址文本表示的建议”，RFC 59522010年8月。
[6] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[6] Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 42912006年2月。
[7] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[7] Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 23731998年7月。
[8] "RFC Editor Errata", <http://www.rfc-editor.org/errata.php>.
[8] “RFC编辑器勘误表”<http://www.rfc-editor.org/errata.php>.
Authors' Addresses
作者地址
Vijay K. Gurbani (editor) Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane Room 9C-533 Naperville, IL 60563 USA
Vijay K.Gurbani（编辑）贝尔实验室，阿尔卡特朗讯1960朗讯巷，美国伊利诺伊州纳珀维尔9C-533室，邮编60563
Phone: +1 630 224-0216
EMail: vkg@bell-labs.com
Phone: +1 630 224-0216
EMail: vkg@bell-labs.com
Brian E. Carpenter (editor) Department of Computer Science University of Auckland PB 92019 Auckland, 1142 New Zealand
Brian E. Carpenter（编辑）奥克兰大学计算机科学系，奥克兰92019，新西兰1142
EMail: brian.e.carpenter@gmail.com
EMail: brian.e.carpenter@gmail.com
Brett Tate (editor) BroadSoft
布雷特·泰特（编辑）博德软
EMail: brett@broadsoft.com
EMail: brett@broadsoft.com