RFC 6874 - Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc6874
タイトル : RFC 6874 - アドレスリテラルとユニフォームリソース識別子でのIPv6ゾーン識別子の表現
翻訳編集 : 自動生成

[要約] RFC 6874は、IPv6アドレスリテラルとUniform Resource Identifiers（URI）でIPv6ゾーン識別子を表現する方法についての規格です。このRFCの目的は、IPv6アドレスのゾーン識別子を正確に表現し、URIの一貫性と互換性を確保することです。

Internet Engineering Task Force (IETF)                      B. Carpenter
Request for Comments: 6874                             Univ. of Auckland
Updates: 3986                                                S. Cheshire
Category: Standards Track                                     Apple Inc.
ISSN: 2070-1721                                                R. Hinden
                                                             Check Point
                                                           February 2013

Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers

アドレスリテラルとユニフォームリソース識別子でのIPv6ゾーン識別子の表現

Abstract

概要

This document describes how the zone identifier of an IPv6 scoped address, defined as <zone_id> in the IPv6 Scoped Address Architecture (RFC 4007), can be represented in a literal IPv6 address and in a Uniform Resource Identifier that includes such a literal address. It updates the URI Generic Syntax specification (RFC 3986) accordingly.

このドキュメントでは、IPv6スコープアドレスアーキテクチャ（RFC 4007）で<zone_id>として定義されているIPv6スコープアドレスのゾーン識別子を、リテラルIPv6アドレスおよびそのようなリテラルアドレスを含むUniform Resource Identifierで表す方法について説明します。 URIジェネリック構文仕様（RFC 3986）を適宜更新します。

Status of This Memo

本文書の状態

This is an Internet Standards Track document.

これはInternet Standards Trackドキュメントです。

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（Internet Engineering Task Force）の製品です。これは、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/rfc6874.

このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6874で入手できます。

著作権表示

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）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2
   2.  Specification . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Web Browsers  . . . . . . . . . . . . . . . . . . . . . . . . . 5
   4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 6
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
     6.1.  Normative References  . . . . . . . . . . . . . . . . . . . 7
     6.2.  Informative References  . . . . . . . . . . . . . . . . . . 7
   Appendix A.  Options Considered . . . . . . . . . . . . . . . . . . 8

1. Introduction

1. はじめに

The Uniform Resource Identifier (URI) syntax specification [RFC3986] defined how a literal IPv6 address can be represented in the "host" part of a URI. Two months later, the IPv6 Scoped Address Architecture specification [RFC4007] extended the text representation of limited-scope IPv6 addresses such that a zone identifier may be concatenated to a literal address, for purposes described in that specification. Zone identifiers are especially useful in contexts in which literal addresses are typically used, for example, during fault diagnosis, when it may be essential to specify which interface is used for sending to a link-local address. It should be noted that zone identifiers have purely local meaning within the node in which they are defined, often being the same as IPv6 interface names. They are completely meaningless for any other node. Today, they are meaningful only when attached to addresses with less than global scope, but it is possible that other uses might be defined in the future.

Uniform Resource Identifier（URI）構文仕様[RFC3986]は、URIの「ホスト」部分でリテラルIPv6アドレスを表す方法を定義しました。 2か月後、IPv6 Scoped Address Architecture仕様[RFC4007]は、範囲指定IPv6アドレスのテキスト表現を拡張し、その仕様で説明されている目的のために、ゾーン識別子をリテラルアドレスに連結できるようにしました。ゾーン識別子は、たとえば障害診断中にリテラルアドレスが通常使用されるコンテキストで、リンクローカルアドレスへの送信に使用するインターフェイスを指定することが不可欠な場合に特に役立ちます。ゾーン識別子は、それらが定義されているノード内で純粋にローカルな意味を持ち、多くの場合IPv6インターフェース名と同じであることに注意してください。それらは他のノードに対しては完全に無意味です。今日、これらはグローバルスコープよりも小さいアドレスに接続されている場合にのみ意味がありますが、将来、他の用途が定義される可能性があります。

The IPv6 Scoped Address Architecture specification [RFC4007] does not specify how zone identifiers are to be represented in URIs. Practical experience has shown that this feature is useful, in particular when using a web browser for debugging with link-local addresses, but because it is undefined, it is not implemented consistently in URI parsers or in browsers.

IPv6スコープアドレスアーキテクチャ仕様[RFC4007]では、ゾーン識別子をURIで表す方法は指定されていません。実際の経験では、この機能は特にリンクローカルアドレスでデバッグするためにWebブラウザーを使用する場合に便利ですが、未定義であるため、URIパーサーやブラウザーに一貫して実装されていません。

Some versions of some browsers directly accept the IPv6 Scoped Address syntax [RFC4007] for scoped IPv6 addresses embedded in URIs, i.e., they have been coded to interpret a "%" sign following the literal address as introducing a zone identifier [RFC4007], instead of introducing two hexadecimal characters representing some percent-encoded octet [RFC3986]. Clearly, interpreting the "%" sign as introducing a zone identifier is very convenient for users, although it formally breaches the established URI syntax [RFC3986]. This document defines an alternative approach that respects and extends the rules of URI syntax, and IPv6 literals in general, to be consistent.

一部のブラウザの一部のバージョンは、URIに埋め込まれたスコープIPv6アドレスのIPv6スコープアドレス構文[RFC4007]を直接受け入れます。つまり、リテラルアドレスに続く「％」記号をゾーン識別子の導入として解釈するようにコード化されています[RFC4007]。パーセントでエンコードされたオクテットを表す2つの16進文字を導入する方法[RFC3986]。明らかに、「％」記号をゾーン識別子の導入として解釈することは、確立されたURI構文[RFC3986]に正式に違反しますが、ユーザーにとって非常に便利です。このドキュメントでは、一貫性を保つために、URI構文のルールとIPv6リテラル全般を尊重および拡張する代替アプローチを定義しています。

Thus, this document updates the URI syntax specification [RFC3986] by adding syntax to allow a zone identifier to be included in a literal IPv6 address within a URI.

したがって、このドキュメントでは、URI内のリテラルIPv6アドレスにゾーン識別子を含めることができるように構文を追加することにより、URI構文仕様[RFC3986]を更新しています。

It should be noted that in contexts other than a user interface, a zone identifier is mapped into a numeric zone index or interface number. The MIB textual convention InetZoneIndex [RFC4001] and the socket interface [RFC3493] define this as a 32-bit unsigned integer. The mapping between the human-readable zone identifier string and the numeric value is a host-specific function that varies between operating systems. The present document is concerned only with the human-readable string.

ユーザーインターフェイス以外のコンテキストでは、ゾーン識別子が数値のゾーンインデックスまたはインターフェイス番号にマップされることに注意してください。 MIBテキスト表記規則InetZoneIndex [RFC4001]およびソケットインターフェイス[RFC3493]は、これを32ビットの符号なし整数として定義します。人間が読み取れるゾーン識別子の文字列と数値の間のマッピングは、オペレーティングシステムによって異なるホスト固有の機能です。現在のドキュメントは、人間が読める文字列のみに関係しています。

Several alternative solutions were considered while this document was developed. Appendix A briefly describes the various options and their advantages and disadvantages.

このドキュメントの作成中に、いくつかの代替ソリューションが検討されました。付録Aでは、さまざまなオプションとその長所と短所について簡単に説明します。

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 "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119].

このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、「要件レベルを示すためのRFCで使用するキーワード」[RFC2119]で説明されているように解釈されます。

2. Specification

2. 仕様

According to IPv6 Scoped Address syntax [RFC4007], a zone identifier is attached to the textual representation of an IPv6 address by concatenating "%" followed by <zone_id>, where <zone_id> is a string identifying the zone of the address. However, the IPv6 Scoped Address Architecture specification gives no precise definition of the character set allowed in <zone_id>. There are no rules or de facto standards for this. For example, the first Ethernet interface in a host might be called %0, %1, %en1, %eth0, or whatever the implementer happened to choose.

IPv6 Scoped Address構文[RFC4007]によれば、ゾーン識別子は、「％」とそれに続く<zone_id>を連結することにより、IPv6アドレスのテキスト表現に付加されます。<zone_id>は、アドレスのゾーンを識別する文字列です。ただし、IPv6スコープアドレスアーキテクチャの仕様では、<zone_id>で許可されている文字セットを正確に定義していません。これにはルールや事実上の標準はありません。たとえば、ホストの最初のイーサネットインターフェイスは、％0、％1、％en1、％eth0、または実装者がたまたま選択したものと呼ばれます。

In a URI, a literal IPv6 address is always embedded between "[" and "]". This document specifies how a <zone_id> can be appended to the address. According to URI syntax [RFC3986], "%" is always treated as an escape character in a URI, so, according to the established URI syntax [RFC3986] any occurrences of literal "%" symbols in a URI MUST be percent-encoded and represented in the form "%25". Thus, the scoped address fe80::a%en1 would appear in a URI as http://[fe80::a%25en1].

URIでは、リテラルIPv6アドレスは常に「[」と「]」の間に埋め込まれます。このドキュメントでは、<zone_id>をアドレスに追加する方法を指定します。 URI構文[RFC3986]によると、「％」は常にURIのエスケープ文字として扱われるため、確立されたURI構文[RFC3986]に従って、URI内のリテラル「％」記号の出現はパーセントエンコードされなければならず、「％25」の形式で表されます。したがって、スコープ付きアドレスfe80 :: a％en1は、URIではhttp：// [fe80 :: a％25en1]として表示されます。

A <zone_id> SHOULD contain only ASCII characters classified as "unreserved" for use in URIs [RFC3986]. This excludes characters such as "]" or even "%" that would complicate parsing. However, the syntax described below does allow such characters to be percent-encoded, for compatibility with existing devices that use them.

<zone_id>は、URI [RFC3986]で使用するために「未予約」として分類されたASCII文字のみを含む必要があります（SHOULD）。これには、解析を複雑にする「]」や「％」などの文字は含まれません。ただし、以下に説明する構文では、そのような文字を使用する既存のデバイスとの互換性のために、そのような文字をパーセントエンコードすることができます。

If an operating system uses any other characters in zone or interface identifiers that are not in the "unreserved" character set, they MUST be represented using percent encoding [RFC3986].

オペレーティングシステムが「予約されていない」文字セットに含まれていないゾーンまたはインターフェイス識別子で他の文字を使用する場合、パーセントエンコーディング[RFC3986]を使用して表現する必要があります。

We now present the necessary formal syntax.

次に、必要な正式な構文を示します。

The URI syntax specification [RFC3986] formally defined the IPv6 literal format in ABNF [RFC5234] by the following rule:

URI構文仕様[RFC3986]は、次の規則によってABNF [RFC5234]でIPv6リテラル形式を正式に定義しました。

IP-literal = "[" ( IPv6address / IPvFuture ) "]"

IP-literal = "["（IPv6address / IPvFuture） "]"

To provide support for a zone identifier, the existing syntax of IPv6address is retained, and a zone identifier may be added optionally to any literal address. This syntax allows flexibility for unknown future uses. The rule quoted above from the previous URI syntax specification [RFC3986] is replaced by three rules:

ゾーン識別子をサポートするために、IPv6addressの既存の構文が保持され、ゾーン識別子を任意のリテラルアドレスにオプションで追加できます。この構文により、未知の将来の使用に柔軟に対応できます。上記の前のURI構文仕様[RFC3986]から引用されたルールは、次の3つのルールに置き換えられます。

      IP-literal = "[" ( IPv6address / IPv6addrz / IPvFuture  ) "]"

      ZoneID = 1*( unreserved / pct-encoded )

IPv6addrz = IPv6address "%25" ZoneID

IPv6addrz = IPv6アドレス "％25" ZoneID

This syntax fills the gap that is described at the end of Section 11.7 of the IPv6 Scoped Address Architecture specification [RFC4007].

この構文は、IPv6 Scoped Address Architecture仕様[RFC4007]のセクション11.7の最後に記載されているギャップを埋めます。

The established rules for textual representation of IPv6 addresses [RFC5952] SHOULD be applied in producing URIs.

IPv6アドレスのテキスト表現のための確立されたルール[RFC5952]は、URIの生成に適用されるべきです（SHOULD）。

The URI syntax specification [RFC3986] states that URIs have a global scope, but that in some cases their interpretation depends on the end-user's context. URIs including a ZoneID are to be interpreted only in the context of the host at which they originate, since the ZoneID is of local significance only.

URI構文仕様[RFC3986]には、URIにはグローバルスコープがあると記載されていますが、その解釈はエンドユーザーのコンテキストによって異なる場合があります。 ZoneIDはローカルでのみ意味があるため、ZoneIDを含むURIは、それらが発生したホストのコンテキストでのみ解釈されます。

The IPv6 Scoped Address Architecture specification [RFC4007] offers guidance on how the ZoneID affects interface/address selection inside the IPv6 stack. Note that the behaviour of an IPv6 stack, if it is passed a non-null zone index for an address other than link-local, is undefined.

IPv6 Scoped Address Architecture仕様[RFC4007]は、ZoneIDがIPv6スタック内のインターフェース/アドレス選択にどのように影響するかについてのガイダンスを提供しています。 IPv6スタックの動作に、リンクローカル以外のアドレスの非nullゾーンインデックスが渡された場合の動作は定義されていないことに注意してください。

3. Web Browsers

3. ウェブブラウザー

This section discusses how web browsers might handle this syntax extension. Unfortunately, there is no formal distinction between the syntax allowed in a browser's input dialogue box and the syntax allowed in URIs. For this reason, no normative statements are made in this section.

このセクションでは、Webブラウザーがこの構文拡張を処理する方法について説明します。残念ながら、ブラウザーの入力ダイアログボックスで許可されている構文とURIで許可されている構文の間には正式な区別はありません。このため、このセクションでは規範的な記述はありません。

Due to the lack of defined syntax, web browsers have been inconsistent in providing for ZoneIDs. Many have no support, but there are examples of ad hoc support. For example, some versions of Firefox allowed the use of a ZoneID preceded by a bare "%" character, but this feature was removed for consistency with established syntax [RFC3986]. As another example, some versions of Internet Explorer allow use of a ZoneID preceded by a "%" character encoded as "%25", still beyond the syntax allowed by the established rules [RFC3986]. This syntax extension is in fact used internally in the Windows operating system and some of its APIs.

定義された構文がないため、WebブラウザーはZoneIDの提供に一貫性がありません。多くはサポートがありませんが、アドホックサポートの例があります。たとえば、Firefoxの一部のバージョンでは、裸の「％」文字が前に付いたZoneIDの使用が許可されていましたが、この機能は、確立された構文[RFC3986]との一貫性を保つために削除されました。別の例として、Internet Explorerの一部のバージョンでは、「％25」としてエンコードされた「％」文字が前に付いたZoneIDの使用を許可していますが、確立されたルール[RFC3986]で許可されている構文を超えています。この構文拡張は、実際にはWindowsオペレーティングシステムとそのAPIの一部で内部的に使用されています。

It is desirable for all browsers to recognise a ZoneID preceded by a percent-encoded "%". In the spirit of "be liberal with what you accept", we also suggest that URI parsers accept bare "%" signs when possible (i.e., a "%" not followed by two valid and meaningful hexadecimal characters). This would make it possible for a user to copy and paste a string such as "fe80::a%en1" from the output of a "ping" command and have it work. On the other hand, "%ee1" would need to be manually rewritten to "fe80::a%25ee1" to avoid any risk of misinterpretation.

すべてのブラウザは、パーセントエンコードされた「％」が前に付いたZoneIDを認識することが望ましいです。「受け入れるものに寛大になる」という精神で、URIパーサーは可能な限り裸の「％」記号を受け入れることをお勧めします（つまり、「％」の後に2つの有効で意味のある16進文字が続いていない）。これにより、ユーザーは、「ping」コマンドの出力から「fe80 :: a％en1」などの文字列をコピーして貼り付け、機能させることができます。一方、「％ee1」は、誤って解釈されるリスクを回避するために、手動で「fe80 :: a％25ee1」に書き換える必要があります。

Such bare "%" signs are for user interface convenience, and need to be turned into properly encoded characters (where "%25" encodes "%") before the URI is used in any protocol or HTML document. However, URIs including a ZoneID have no meaning outside the originating node. It would therefore be highly desirable for a browser to remove the ZoneID from a URI before including that URI in an HTTP request.

このような裸の「％」記号はユーザーインターフェースの便宜のためのものであり、URIがプロトコルまたはHTMLドキュメントで使用される前に、適切にエンコードされた文字（「％25」は「％」をエンコード）に変換する必要があります。ただし、ZoneIDを含むURIは、元のノードの外では意味がありません。したがって、ブラウザーがURIからZoneIDを削除してから、そのURIをHTTPリクエストに含めることが強く望まれます。

The normal diagnostic usage for the ZoneID syntax will cause it to be entered in the browser's input dialogue box. Thus, URIs including a ZoneID are unlikely to be encountered in HTML documents. However, if they do (for example, in a diagnostic script coded in HTML), it would be appropriate to treat them exactly as above.

ZoneID構文の通常の診断使用法では、ブラウザの入力ダイアログボックスに入力されます。したがって、ZoneIDを含むURIは、HTMLドキュメントで発生する可能性はほとんどありません。ただし、それらが（たとえば、HTMLでコード化された診断スクリプトで）実行する場合は、上記とまったく同じように扱うことが適切です。

4. Security Considerations

4. セキュリティに関する考慮事項

The security considerations from the URI syntax specification [RFC3986] and the IPv6 Scoped Address Architecture specification [RFC4007] apply. In particular, this URI format creates a specific pathway by which a deceitful zone index might be communicated, as mentioned in the final security consideration of the Scoped Address Architecture specification. It is emphasised that the format is intended only for debugging purposes, but of course this intention does not prevent misuse.

URI構文仕様[RFC3986]およびIPv6スコープアドレスアーキテクチャ仕様[RFC4007]のセキュリティに関する考慮事項が適用されます。特に、スコープアドレスアーキテクチャ仕様の最終的なセキュリティの考慮事項で述べたように、このURI形式は、偽のゾーンインデックスが通信される可能性がある特定の経路を作成します。このフォーマットはデバッグのみを目的としていることを強調しますが、もちろんこの意図は誤用を防ぐものではありません。

To limit this risk, implementations MUST NOT allow use of this format except for well-defined usages, such as sending to link-local addresses under prefix fe80::/10. At the time of writing, this is the only well-defined usage known.

このリスクを制限するために、実装は、接頭辞fe80 :: / 10の下のリンクローカルアドレスへの送信など、明確に定義された使用法を除いて、この形式の使用を許可してはなりません。これを書いている時点では、これは既知の唯一明確に定義された使用法です。

An HTTP client, proxy, or other intermediary MUST remove any ZoneID attached to an outgoing URI, as it has only local significance at the sending host.

HTTPクライアント、プロキシ、またはその他の仲介者は送信URIにアタッチされたすべてのZoneIDを削除する必要があります。これは、送信ホストでローカルな意味しかないためです。

5. Acknowledgements

5. 謝辞

The lack of this format was first pointed out by Margaret Wasserman some years ago, and more recently by Kerry Lynn. A previous draft document by Martin Duerst and Bill Fenner [LITERAL-ZONE] discussed this topic but was not finalised.

このフォーマットの欠如は、数年前にマーガレットワッサーマンによって最初に指摘され、最近ではケリーリンによって指摘されました。 Martin DuerstとBill Fenner [LITERAL-ZONE]による以前のドラフトドキュメントはこのトピックについて説明しましたが、確定されていません。

Valuable comments and contributions were made by Karl Auer, Carsten Bormann, Benoit Claise, Stephen Farrell, Brian Haberman, Ted Hardie, Tatuya Jinmei, Yves Lafon, Barry Leiba, Radia Perlman, Tom Petch, Tomoyuki Sahara, Juergen Schoenwaelder, Dave Thaler, Martin Thomson, and Ole Troan.

貴重なコメントと寄稿は、カールアウアー、カーステンボルマン、ブノワクレイズ、スティーブンファレル、ブライアンハーバーマン、テッドハーディ、タトゥヤジンメイ、イヴラフォン、バリーレイバ、ラディアパールマン、トムペッチ、サモラトモユキ、ユルゲンシェーンヴェルダー、デイブタラー、マーティントムソン、オレ・トローン。

Brian Carpenter was a visitor at the Computer Laboratory, Cambridge University during part of this work.

ブライアンカーペンターは、この作業の一環として、ケンブリッジ大学のコンピューターラボの訪問者でした。

6. References

6. 参考文献

6.1. Normative References

6.1. 引用文献

[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月。

[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.

[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、STD 66、RFC 3986、2005年1月。

[RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, March 2005.

[RFC4007] Deering、S.、Haberman、B.、Jinmei、T.、Nordmark、E。、およびB. Zill、「IPv6 Scoped Address Architecture」、RFC 4007、2005年3月。

[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.

[RFC5234]クロッカー、D。、エド。およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、2008年1月。

[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, August 2010.

[RFC5952] Kawamura、S. and M. Kawashima、 "A Recommendation for IPv6 Address Text Representation"、RFC 5952、August 2010。

6.2. Informative References

6.2. 参考引用

[LITERAL-ZONE] Fenner, B. and M. Duerst, "Formats for IPv6 Scope Zone Identifiers in Literal Address Formats", Work in Progress, October 2005.

[LITERAL-ZONE] Fenner、B。およびM. Duerst、「リテラルアドレス形式のIPv6スコープゾーン識別子の形式」、作業中、2005年10月。

[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493, February 2003.

[RFC3493] Gilligan、R.、Thomson、S.、Bound、J.、McCann、J.、and W. Stevens、 "Basic Socket Interface Extensions for IPv6"、RFC 3493、2003年2月。

[RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005.

[RFC4001] Daniele、M.、Haberman、B.、Routhier、S。、およびJ. Schoenwaelder、「インターネットネットワークアドレスのテキスト表記法」、RFC 4001、2005年2月。

Appendix A. Options Considered

付録A.考慮されるオプション

The syntax defined above allows a ZoneID to be added to any IPv6 address. The 6man WG discussed and rejected an alternative in which the existing syntax of IPv6address would be extended by an option to add the ZoneID only for the case of link-local addresses. It was felt that the solution presented in this document offers more flexibility for future uses and is more straightforward to implement.

上で定義した構文により、ゾーンIDを任意のIPv6アドレスに追加できます。 6man WGは、リンクローカルアドレスの場合にのみゾーンIDを追加するオプションによってIPv6addressの既存の構文が拡張される代替案を検討して拒否しました。このドキュメントに示されているソリューションは、将来の使用のためのより多くの柔軟性を提供し、実装がより簡単であると感じました。

The various syntax options considered are now briefly described.

検討されているさまざまな構文オプションについて簡単に説明します。

1. Leave the problem unsolved.

1. 問題を未解決のままにします。

This would mean that per-interface diagnostics would still have to be performed using ping or ping6:

これは、インターフェイスごとの診断を引き続きpingまたはping6を使用して実行する必要があることを意味します。

ping fe80::a%en1

ping fe80 :: a％en1

Advantage: works today.

利点：今日でも機能します。

Disadvantage: less convenient than using a browser.

欠点：ブラウザーを使用するよりも不便です。

2. Simply use the percent character:

2. 単にパーセント文字を使用します：

       http://[fe80::a%en1]

Advantage: allows use of browser; allows cut and paste.

利点：ブラウザーの使用を許可します。カットアンドペーストが可能です。

Disadvantage: invalid syntax under RFC 3986; not acceptable to URI community.

欠点：RFC 3986に基づく無効な構文。 URIコミュニティでは受け入れられません。

3. Simply use an alternative separator:

3. 別のセパレータを使用するだけです：

       http://[fe80::a-en1]

Advantage: allows use of browser; simple syntax.

利点：ブラウザーの使用を許可します。単純な構文。

Disadvantage: Requires all IPv6 address literal parsers and generators to be updated in order to allow simple cut and paste; inconsistent with existing tools and practice.

短所：単純なカットアンドペーストを可能にするために、すべてのIPv6アドレスリテラルパーサーおよびジェネレーターを更新する必要があります。既存のツールや実践と矛盾しています。

Note: The initial proposal for this choice was to use an underscore as the separator, but it was noted that this becomes effectively invisible when a user interface automatically underlines URLs.

注：この選択の最初の提案では、下線を区切り記号として使用していましたが、ユーザーインターフェイスが自動的にURLに下線を引くと、これは事実上見えなくなることに注意してください。

4. Simply use the "IPvFuture" syntax left open in RFC 3986:

4. RFC 3986で開いたままの「IPvFuture」構文を使用するだけです。

       http://[v6.fe80::a_en1]

Advantage: allows use of browser.

利点：ブラウザの使用を許可します。

Disadvantage: ugly and redundant; doesn't allow simple cut and paste.

欠点：醜く冗長です。単純なカットアンドペーストはできません。

5. Retain the percent character already specified for introducing zone identifiers for IPv6 Scoped Addresses [RFC4007], and then percent-encode it when it appears in a URI, according to the already-established URI syntax rules [RFC 3986]:

5. IPv6 Scoped Addresses [RFC4007]のゾーン識別子を導入するためにすでに指定されているパーセント文字を保持し、URIに表示されるときに、すでに確立されているURI構文規則[RFC 3986]に従ってパーセントエンコードします。

       http://[fe80::a%25en1]

Advantage: allows use of browser; consistent with general URI syntax.

利点：ブラウザーの使用を許可します。一般的なURI構文と一致しています。

Disadvantage: somewhat ugly and confusing; doesn't allow simple cut and paste.

短所：やや醜くて混乱します。単純なカットアンドペーストはできません。

This is the option chosen for standardisation.

これは、標準化のために選択されたオプションです。

Authors' Addresses

著者のアドレス

Brian Carpenter Department of Computer Science University of Auckland PB 92019 Auckland, 1142 New Zealand

ブライアンカーペンターコンピュータサイエンス学部オークランド大学PB 92019オークランド、1142ニュージーランド

   EMail: brian.e.carpenter@gmail.com

Stuart Cheshire Apple Inc. 1 Infinite Loop Cupertino, CA 95014 United States

Stuart Cheshire Apple Inc. 1 Infinite Loop Cupertino、CA 95014アメリカ合衆国

   EMail: cheshire@apple.com

Robert M. Hinden Check Point Software Technologies, Inc. 800 Bridge Parkway Redwood City, CA 94065 United States

Robert M. Hinden Check Point Software Technologies、Inc. 800 Bridge Parkway Redwood City、CA 94065アメリカ合衆国

   EMail: bob.hinden@gmail.com