[要約] RFC 5954は、RFC 3261のIPv6 ABNFとURI比較に関する重要な修正を提供しています。その目的は、IPv6アドレスの表現とURIの比較に関する正確な仕様を提供することです。
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リテラルの生成に関連する拡張されたバックナウルフォーム（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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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
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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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-Mapped 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アドレスの前に2つのコロンのみが含まれます。
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はその後、RFC 4291 [6]によって廃止されました。
The ABNF for IPv6reference is reproduced from RFC 3261 below:
IPv6Referenceの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
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.
あいまいさは、<ipv4Address>非末端に「：」トークンが付けられている<ipv6Address>生産ルールで発生することに注意してください。<hexpart>の生産ルールは、その2つの代替案に「::」トークンが既に含まれているように定義されているため、これらの代替案を拡張するときに追加のコロンを持つ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.
2つの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@[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]?
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アドレスのテキスト表現は異なりますが、これらのアドレスはバイナリ等価物です（実装者は、IPv6アドレステキスト表現に関する推奨事項については、このドキュメントのセクション5を参照することも求められます）。RFC 3261のセクション19.1.4は、すべて同じバイナリ等価に対応するIPv6アドレスの異なるテキスト表現を含むURISのルールを提供しません。
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アドレスでも同じあいまいさが発生することに注意してください。つまり、192.0.2.128 = 192.00.02.128ですか？ただし、その圧縮表記とハイブリッドアドレス（IPv4マッピングIPv6アドレスなど）を表す必要性がある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の付録Aの<IPv6Address>生産ルールに正しいABNFを使用することです[3]。完全性のために、それは以下に再現されています：
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
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を次のように更新します。RFC3261の<IPV6Address>および<IPV4Address>生産ルールを使用する必要はなく、代わりにRFC 3986（および上記の複製）の同じ名前の生産ルールを使用する必要があります。これにより、RFC 3261廃止の<hexpart>、<hexseq>、および<hex4>生産ルールが廃止されます。そのため、RFC 3261からのこれらの3つの生産ルール（<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」という形式のsip uris。
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アドレスのさまざまなテキスト表現を含む2つの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 2つの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 2つの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:
IPアドレスの基礎となるバイナリ表現は同じであるため、次のURIは同等です。
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@[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は、URI同等の問題に関するSIP WGメーリングリストで非常に貴重な議論ポイントを提供しました。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：SESSION INITIATION Protocol」、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] 川村、S。およびM.川島、「IPv6アドレステキスト表現の推奨」、RFC 5952、2010年8月。
[6] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[6] Hinden、R。and S. Deering、「IPバージョン6アドレス指定アーキテクチャ」、RFC 4291、2006年2月。
[7] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[7] Hinden、R。and S. Deering、「IPバージョン6アドレス指定アーキテクチャ」、RFC 2373、1998年7月。
[8] "RFC Editor Errata", <http://www.rfc-editor.org/errata.php>.
[8] 「RFCエディターERRATA」、<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（編集者）Bell Laboratories、Alcatel-Lucent 1960 Lucent Lane Room 9C-533 Naperville、IL 60563 USA
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
ブライアンE.カーペンター（編集者）オークランドのコンピュータサイエンス大学PB 92019オークランド、1142ニュージーランド
EMail: brian.e.carpenter@gmail.com
Brett Tate (editor) BroadSoft
Brett Tate（編集者）Broadsoft
EMail: brett@broadsoft.com