Internet Engineering Task Force (IETF) B. Carpenter
Request for Comments: 9844 Univ. of Auckland
Obsoletes: 6874 R. Hinden
Updates: 4007, 7622, 8089 Check Point Software
Category: Standards Track August 2025
ISSN: 2070-1721
This document describes how the zone identifier of an IPv6 scoped address, defined in the IPv6 Scoped Address Architecture specification (RFC 4007), should be entered into a user interface. This document obsoletes RFC 6874 and updates RFCs 4007, 7622, and 8089.
このドキュメントでは、IPv6スコープアドレスアーキテクチャ仕様（RFC 4007）で定義されているIPv6スコープアドレスのゾーン識別子がユーザーインターフェイスにどのように入力されるかについて説明します。このドキュメントは、RFC 6874を廃止し、RFCS 4007、7622、および8089を更新します。
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 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 7841のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9844.
このドキュメントの現在のステータス、任意のERRATA、およびそれに関するフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9844で取得できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2025 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
2. Use Cases
3. Relationship to Other Documents
4. Requirements Language
5. Specification
6. Security Considerations
7. IANA Considerations
8. References
8.1. Normative References
8.2. Informative References
Acknowledgements
Authors' Addresses
A number of software tools require or permit the user to enter an IPv6 address via a user interface (UI). The standard literal text format for an IPv6 address is defined by [RFC4291] and [RFC5952]. The IPv6 Scoped Address Architecture specification [RFC4007] extends the text representation of limited-scope IPv6 addresses, in particular link-local unicast addresses and multicast addresses with less than global scope, such that a zone identifier may be concatenated to an address. Note that [RFC5952] does not mention this extension.
多くのソフトウェアツールでは、ユーザーがユーザーインターフェイス（UI）を介してIPv6アドレスを入力する必要があります。IPv6アドレスの標準文字通りテキスト形式は、[RFC4291]および[RFC5952]で定義されます。IPv6スコープアドレスアーキテクチャ仕様[RFC4007]は、限られたスコープIPv6アドレス、特にリンクローカルユニキャストアドレスとグローバルスコープ未満のマルチキャストアドレスのテキスト表現を拡張し、ゾーン識別子をアドレスに連結することができます。[RFC5952]はこの拡張機能に言及していないことに注意してください。
Zone identifiers are especially useful in contexts in which literal addresses are typically used, for example, during fault diagnosis or device configuration (where a device may be physical or virtual) 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, usually being the same as IPv6 interface names. They are completely meaningless for any other node. At the time of writing, they are meaningful only when attached to link-local unicast and scoped multicast addresses, but it is possible that other uses might be defined in the future.
ゾーン識別子は、障害診断またはデバイス構成（デバイスが物理的または仮想的である場合がある場合）で、リテラルアドレスが通常使用される場合に通常使用されるコンテキストで特に役立ちます。ゾーン識別子は、通常IPv6インターフェイス名と同じであり、定義されているノード内で純粋にローカルな意味を持つことに注意する必要があります。それらは他のノードにとって完全に無意味です。執筆時点では、リンクローカルユニキャストとスコープマルチキャストアドレスに取り付けられた場合にのみ意味がありますが、他の用途が将来定義される可能性があります。
Examples of a link-local unicast address qualified by a zone identifier are "fe80::1234%eth0" on a Linux host or "fe80::4321%7" on a Microsoft Windows host.
ゾーン識別子によって適格なリンクローカルユニキャストアドレスの例は、Linuxホストの「Fe80 :: 1234％ETH0」またはMicrosoft Windowsホストの「Fe80 :: 4321％7」です。
Such addresses are directly supported by socket API calls including "getaddrinfo()" [RFC3493].
このようなアドレスは、「getaddrinfo（）」[RFC3493]を含むソケットAPI呼び出しによって直接サポートされています。
Devices whose network stack does not support the model of a human-readable zone identifier described in [RFC4007] are out of scope for this document.
ネットワークスタックが[RFC4007]で説明されている人間が読み取るゾーン識別子のモデルをサポートしていないデバイスは、このドキュメントの範囲外です。
Some examples of use cases for entering an address that includes a zone identifier into a UI are as follows:
ゾーン識別子をUIに含むアドレスを入力するためのユースケースのいくつかの例は次のとおりです。
1. A software tool may be used for simple debugging actions involving link-local addresses on a host with more than one active link interface. For example, the functioning of an interface and the existence of a device may be checked via "ping fe80::1234%eth0". If this succeeds, the user learns that the other device is reachable via the interface named "eth0".
1. ソフトウェアツールは、複数のアクティブリンクインターフェイスを持つホストのリンクローカルアドレスを含む単純なデバッグアクションに使用できます。たとえば、インターフェイスの機能とデバイスの存在は、「Ping Fe80 :: 1234％ETH0」を介してチェックすることができます。これが成功した場合、ユーザーは他のデバイスが「ETH0」という名前のインターフェイスを介して到達可能であることを知ります。
2. A software tool must sometimes be used to configure or reconfigure a device that only has a link-local address, again in a host with more than one active link interface. For example, a typical home router may be configured via a well-known private address [RFC1918] such as "192.168.178.1" but not via "fe80::1%eth0", if the tool in use does not support the input of zone identifiers. More generally, link-local addresses need to be entered in network management UIs for use in formats such as YANG [RFC6991].
2. ソフトウェアツールを使用して、複数のアクティブリンクインターフェイスを持つホストで、リンクローカルアドレスのみを持つデバイスを構成または再構成するために使用する必要があります。たとえば、典型的なホームルーターは、「192.168.178.1」などのよく知られているプライベートアドレス[RFC1918]を介して構成できますが、使用中のツールがゾーン識別子の入力をサポートしていない場合、「Fe80 :: 1％ETH0」を介してはなりません。より一般的には、Yang [RFC6991]などの形式で使用するために、ネットワーク管理UISにリンクローカルアドレスを入力する必要があります。
3. Using a monitoring tool such as a network sniffer, the user may need to specify a given link-local address on a given interface whose traffic is of interest. (For example, at the time of writing, Wireshark supports capture from multiple interfaces but does not appear to support the zone identifier in a display filter.)
3. ネットワークスニファーなどの監視ツールを使用すると、ユーザーは、トラフィックが関心のある特定のインターフェイスに特定のリンクローカルアドレスを指定する必要があります。（たとえば、執筆時点では、Wiresharkは複数のインターフェイスからのキャプチャをサポートしていますが、ディスプレイフィルターのゾーン識別子をサポートしていないようです。）
4. The Microsoft Web Services for Devices (WSD) virtual printer port mechanism can present the user with an IPv6 link-local address such as "fe80::823b:f9ff:fe7b:d9dc%10" in which the zone identifier is present but is not recognized by appropriate software.
4. デバイス用のMicrosoft Webサービス（WSD）仮想プリンターポートメカニズムは、ゾーン識別子が存在するが適切なソフトウェアによって認識されない「Fe80 :: 823B：F9FF：FE7B：D9DC％10」などのIPv6リンクローカルアドレスをユーザーに提示できます。
5. The National Marine Electronics Association (NMEA) has defined the "OneNet Marine IPv6 Ethernet Networking Standard" [ONE-NET], which uses IPv6 link-local addresses exclusively. Proposed improvements to the standard include a web page for device configuration using link-local addresses.
5. National Marine Electronics Association（NMEA）は、IPv6 Link-Localアドレスを独占的に使用する「Onenet Marine IPv6 Ethernet Networking Standard」[One-Net] [One-Net]を定義しました。標準の提案された改善には、Link-Localアドレスを使用したデバイス構成のWebページが含まれます。
Such requirements have already spawned hacks to work around current limitations (e.g., the hack described in [LL-HACK], which is no longer maintained and has been archived).
このような要件は、現在の制限を回避するためにすでにハックを生み出しています（たとえば、[ll-hack]に記載されているハックは、もはや維持されておらず、アーカイブされています）。
For all such use cases, it is highly desirable that a complete IPv6 link-local address can be cut and pasted from one UI (such as the output from a system command) to another. Since such addresses may include quite long hexadecimal strings, for example, "fe80::8d0f:7f26:f5c8:780b%enx525400d5e0fb", any solution except cut-and-paste is highly error prone.
そのようなすべてのユースケースでは、完全なIPv6リンクローカルアドレスを1つのUI（システムコマンドからの出力など）から別のUIから別のUIに貼り付けることができることが非常に望ましいです。このようなアドレスには、たとえば「Fe80 :: 8D0F：7F26：F5C8：780B％ENX525400D5E0FB」など、非常に長い16進列の文字列が含まれる可能性があるため、カットアンドペースト以外のソリューションは非常にエラーが発生します。
The use cases listed above apply to relatively simple actions on end systems. The zone identifiers that can be used are limited by the host operating system, since [RFC4007] only specifies that they are text strings, without specifying a maximum length or syntax. As [RFC4007] explains, each zone identifier corresponds to a numerical zone index that qualifies a link-local address.
上記のユースケースは、エンドシステム上の比較的単純なアクションに適用されます。[RFC4007]は、最大長または構文を指定せずにテキスト文字列であることのみを指定するため、使用できるゾーン識別子はホストオペレーティングシステムによって制限されます。[RFC4007]が説明するように、各ゾーン識別子は、Link-Localアドレスを修飾する数値ゾーンインデックスに対応しています。
It should be noted that whereas some operating systems and network APIs support a default zone identifier as recommended by [RFC4007], others, including Linux, do not, and for them a solution is particularly important, since a link-local address without a zone index cannot be used in the Linux socket API.
一部のオペレーティングシステムとネットワークAPIは[RFC4007]が推奨するデフォルトゾーン識別子をサポートしているのに対し、Linuxを含む他のオペレーティングゾーン識別子は、LinuxソケットAPIでゾーンインデックスのないリンクローカルアドレスを使用できないため、解決策は特に重要ではありません。
The model in [RFC4007] assumes that the human-readable zone identifier is mapped by the operating system into a numeric interface index. Typically, this mapping is performed by the socket API, e.g., by "getaddrinfo()". 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 that is typically displayed in an operating system's user interface. However, in most operating systems, it is possible to use the underlying interface number, represented as a decimal integer, as an equivalent to the human-readable string. This is recommended by Section 11.2 of [RFC4007], but it is not required. This possibility does not affect the UI requirement given in this document.
[RFC4007]のモデルは、人間の読み取り可能なゾーン識別子がオペレーティングシステムによって数値インターフェイスインデックスにマッピングされることを前提としています。通常、このマッピングは、「getaddrinfo（）」などのソケットAPIによって実行されます。人間の読み取り可能なゾーン識別子文字列と数値のマッピングは、オペレーティングシステム間で異なるホスト固有の関数です。現在のドキュメントは、通常、オペレーティングシステムのユーザーインターフェイスに表示される人間の読み取り可能な文字列にのみ関係しています。ただし、ほとんどのオペレーティングシステムでは、10進整数として表される基礎となるインターフェイス番号を、人間の読み取り可能な文字列に相当するものとして使用することができます。これは[RFC4007]のセクション11.2で推奨されますが、必要ありません。この可能性は、このドキュメントに記載されているUI要件には影響しません。
As IPv6 deployment becomes more widespread, the lack of a solution for handling complete link-local addresses in all tools is becoming an acute problem for increasing numbers of operational and support personnel. It will become critical as IPv6-only or IPv6-mostly networks [RFC8925] [IPv6-MOSTLY], with nodes lacking native IPv4 support, appear. For example, the NMEA use case mentioned above is an immediate requirement. This is the principal reason for documenting this requirement now.
IPv6の展開がより広くなるにつれて、すべてのツールで完全なリンクローカルアドレスを処理するためのソリューションの欠如は、運用およびサポート担当者の数を増やすための鋭い問題になりつつあります。IPv6のみまたはIPv6-Mostlyネットワーク[RFC8925] [IPv6-Mostly]が重要になり、ノードがネイティブIPv4サポートを欠いているようになります。たとえば、上記のNMEAユースケースは即時の要件です。これが、この要件を文書化する主な理由です。
This document completely obsoletes [RFC6874], which implementors of web browsers have determined is impracticable to support [LINK-LOCAL-URI], and replaces it with a generic UI requirement. Note that obsoleting [RFC6874] reverts the change that it made to the URI syntax defined by [RFC3986], so [RFC3986] is no longer updated by [RFC6874]. As far as is known, this change will have no significant impact on non-browser deployments of URIs.
このドキュメントは、Webブラウザーの実装者が[Link-Local-URI]をサポートすることは実行不可能であると判断したと判断したと判断したと判断したと判断し、一般的なUI要件に置き換えられたと完全に廃止され[RFC6874]。Obereting [RFC6874]は、[RFC3986]で定義されたURI構文に加えた変化を戻し、[RFC3986]は[RFC6874]によって更新されなくなったことに注意してください。知られている限り、この変更は、URIの非ブラウザー展開に大きな影響を与えません。
This document also updates [RFC7622] and [RFC8089] by deleting their references to [RFC6874].
このドキュメントは、[RFC6874]への参照を削除することにより、[RFC7622]および[RFC8089]を更新します。
It also updates [RFC4007] by adding a new requirement that user interfaces support the zone identifier as described in Section 5.
また、セクション5で説明されているように、ユーザーインターフェイスがゾーン識別子をサポートするという新しい要件を追加することにより、[RFC4007]を更新します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
このドキュメント内のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
A user interface (UI) that allows or requires the user to enter an IPv6 address other than a global unicast address MUST provide a means for entering a link-local address or a scoped multicast address and selecting a zone identifier as specified by [RFC4007] (typically, an interface identifier as defined by the operating system).
ユーザーがグローバルユニキャストアドレス以外のIPv6アドレスを入力できるか要求するユーザーインターフェイス（UI）は、リンクローカルアドレスまたはスコープ付きマルチキャストアドレスを入力し、[RFC4007]で指定されているゾーン識別子を選択するための手段を提供する必要があります（通常、オペレーティングシステムによって定義されたインターフェイス識別子）。
In this case, the UI SHOULD support the complete format specified by [RFC4007] (e.g., "fe80::1%eth0").
この場合、UIは[RFC4007]で指定された完全な形式をサポートする必要があります（たとえば、「Fe80 :: 1％ETH0」）。
If this is impossible for practical reasons, the UI MAY support an alternative delimiter in place of "%". The hyphen ("-") is suggested (e.g., "fe80::1-eth0").
これが実際的な理由で不可能である場合、UIは「％」の代わりに代替の区切り文字をサポートする場合があります。ハイフン（ " - "）が提案されています（例： "fe80 :: 1-eth0"）。
If this too is impossible for practical reasons, the UI MAY provide two separate input fields (e.g., "fe80::1" in one box and "eth0" in another), selection from a list of active zone identifiers, or a separate command-line parameter for the zone identifier.
これも実際的な理由で不可能な場合、UIは2つの個別の入力フィールド（たとえば、1つのボックスに「Fe80 :: 1」、別のボックスに「ETH0」）を提供し、アクティブゾーン識別子のリストから選択、またはゾーン識別子の個別のコマンドラインパラメーターを提供できます。
The program providing the UI will then store the address and the zone identifier, converting the latter to an interface index (typically via the socket API). A faulty zone identifier will be detected when attempting to convert it, and this should be reported to the user as an error. The resulting interface index will be used for any subsequent socket calls using the link-local address.
UIを提供するプログラムは、アドレスとゾーン識別子を保存し、後者をインターフェイスインデックスに変換します（通常はソケットAPIを介して）。故障したゾーン識別子がそれを変換しようとするときに検出され、これはエラーとしてユーザーに報告する必要があります。結果のインターフェイスインデックスは、リンクローカルアドレスを使用して、後続のソケットコールに使用されます。
Note that an address string such as "fe80::1%eth0" cannot be converted to binary by the POSIX socket API function "inet_pton()" [POSIX]. It must be converted either by using "getaddrinfo()" or by splitting it into two strings and using "inet_pton()" and "if_nametoindex()" successively, in order to obtain the required interface index value.
「Fe80 :: 1％ETH0」などのアドレス文字列は、POSIXソケットAPI関数「INET_PTON（）」でバイナリに変換できないことに注意してください。「getaddrinfo（）」を使用するか、2つの文字列に分割し、「inet_pton（）」と「if_nametoindex（）」を使用して、必要なインターフェイスインデックス値を取得することで変換する必要があります。
In this model, the zone identifier is considered independently of the IPv6 address itself. However, this does not in itself resolve the difficulties in considering the zone identifier as part of the HTTP origin model [RFC6454]. Therefore, this approach does not resolve the issue of how browsers should support link-local addresses, which is discussed further in [LINK-LOCAL-URI]. Because of this, the recommendations and normative statements in this document do not apply to URIs fetched by web browsers.
このモデルでは、ゾーン識別子はIPv6アドレス自体とは独立して見られます。ただし、これは、ゾーン識別子をHTTP起源モデル[RFC6454]の一部として考慮することの難しさを解決するものではありません。したがって、このアプローチは、[Link-Local-URI]でさらに説明するリンクローカルアドレスをブラウザがどのようにサポートするかという問題を解決するものではありません。このため、このドキュメントの推奨事項と規範的な声明は、WebブラウザーによってフェッチされたURISには適用されません。
As explained in [RFC4007], zone identifiers are of local significance only and must not be sent on the wire. In particular, see the final security consideration of [RFC4007], which indicates that software should not trust packets that contain textual non-global addresses as data. Therefore, software that obtains a zone identifier through a UI should not transmit it further.
[RFC4007]で説明されているように、ゾーン識別子は局所的な重要性のみであり、ワイヤーに送信してはなりません。特に、[RFC4007]の最終的なセキュリティ考慮事項を参照してください。これは、テキストの非グロバルアドレスをデータとして含むパケットを信頼してはならないことを示しています。したがって、UIを介してゾーン識別子を取得するソフトウェアは、それをさらに送信するべきではありません。
There is no formal limit on the length of the zone identifier string in [RFC4007]. A UI implementation should apply an appropriate length limit when inputting a zone identifier, in order to minimize the risk of a buffer overrun. Typically, this limit would be the same as the host operating system's limit on interface names.
[RFC4007]のゾーン識別子文字列の長さに正式な制限はありません。UIの実装は、バッファオーバーランのリスクを最小限に抑えるために、ゾーン識別子を入力するときに適切な長さ制限を適用する必要があります。通常、この制限は、インターフェイス名に対するホストオペレーティングシステムの制限と同じです。
[RFC4007] does not specify or restrict the character set allowed in a zone identifier. Therefore, each implementation processing zone identifiers needs to make checks appropriate for the environment it is used in. For example, a UI implementation should not allow ASCII NUL characters in a zone identifier string as this could cause inconsistencies in subsequent string processing.
[RFC4007]は、ゾーン識別子で許可されている文字セットを指定または制限しません。したがって、各実装処理ゾーン識別子は、使用されている環境に適切なチェックを行う必要があります。たとえば、UIの実装では、ゾーン識別子文字列内のascii nul文字を許可してはなりません。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and
B. Zill, "IPv6 Scoped Address Architecture", RFC 4007,
DOI 10.17487/RFC4007, March 2005,
<https://www.rfc-editor.org/info/rfc4007>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
Address Text Representation", RFC 5952,
DOI 10.17487/RFC5952, August 2010,
<https://www.rfc-editor.org/info/rfc5952>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[IPv6-MOSTLY]
Buraglio, N., Caletka, O., and J. Linkova, "IPv6-Mostly
Networks: Deployment and Operations Considerations", Work
in Progress, Internet-Draft, draft-ietf-v6ops-6mops-01, 3
March 2025, <https://datatracker.ietf.org/doc/html/draft-
ietf-v6ops-6mops-01>.
[LINK-LOCAL-URI]
Schinazi, D., "Best Practices for Link-Local Connectivity
in URI-Based Protocols", Work in Progress, Internet-Draft,
draft-schinazi-httpbis-link-local-uri-bcp-03, 22 February
2024, <https://datatracker.ietf.org/doc/html/draft-
schinazi-httpbis-link-local-uri-bcp-03>.
[LL-HACK] Jin, P., "Snippets: IPv6 link-local connect hack", 2021,
<https://web.archive.org/web/20210725030713/
https://website.peterjin.org/wiki/
Snippets:IPv6_link_local_connect_hack>.
[ONE-NET] NMEA, "OneNet Marine IPv6 Ethernet Networking Standard",
2025, <https://www.nmea.org/nmea-onenet.html>.
[POSIX] IEEE, "IEEE/Open Group Standard for Information
Technology--Portable Operating System Interface
(POSIX(TM)) Base Specifications, Issue 8", IEEE
Std 1003.1-2024, DOI 10.1109/IEEESTD.2024.10555529, June
2024, <https://doi.org/10.1109/IEEESTD.2024.10555529>.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.
J., and E. Lear, "Address Allocation for Private
Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918,
February 1996, <https://www.rfc-editor.org/info/rfc1918>.
[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W.
Stevens, "Basic Socket Interface Extensions for IPv6",
RFC 3493, DOI 10.17487/RFC3493, February 2003,
<https://www.rfc-editor.org/info/rfc3493>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>.
[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454,
DOI 10.17487/RFC6454, December 2011,
<https://www.rfc-editor.org/info/rfc6454>.
[RFC6874] Carpenter, B., Cheshire, S., and R. Hinden, "Representing
IPv6 Zone Identifiers in Address Literals and Uniform
Resource Identifiers", RFC 6874, DOI 10.17487/RFC6874,
February 2013, <https://www.rfc-editor.org/info/rfc6874>.
[RFC6874bis]
Carpenter, B., Cheshire, S., and R. Hinden, "Representing
IPv6 Zone Identifiers in Address Literals and Uniform
Resource Identifiers", Work in Progress, Internet-Draft,
draft-ietf-6man-rfc6874bis-09, 2 July 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-6man-
rfc6874bis-09>.
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
RFC 6991, DOI 10.17487/RFC6991, July 2013,
<https://www.rfc-editor.org/info/rfc6991>.
[RFC7622] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Address Format", RFC 7622,
DOI 10.17487/RFC7622, September 2015,
<https://www.rfc-editor.org/info/rfc7622>.
[RFC8089] Kerwin, M., "The "file" URI Scheme", RFC 8089,
DOI 10.17487/RFC8089, February 2017,
<https://www.rfc-editor.org/info/rfc8089>.
[RFC8925] Colitti, L., Linkova, J., Richardson, M., and T.
Mrugalski, "IPv6-Only Preferred Option for DHCPv4",
RFC 8925, DOI 10.17487/RFC8925, October 2020,
<https://www.rfc-editor.org/info/rfc8925>.
This document owes a lot to the previous discussions that led to [RFC6874] and to the expired Internet-Draft [RFC6874bis].
このドキュメントは、[RFC6874]につながった以前の議論と、期限切れのインターネットドラフト[RFC6874BIS]につながっていることに大きく依存しています。
Useful comments were received from Erik Auerswald, Nick Buraglio, Martin J. Dürst, Toerless Eckert, David Farmer, Brian Haberman, Nate Karstens, Tero Kivinen, Erik Kline, Jen Linkova, Eduard Metz, Gyan Mishra, David Schinazi, Jürgen Schönwälder, Michael Sweet, Martin Thomson, Ole Troan, Éric Vyncke, Magnus Westerlund, and other participants in the 6MAN WG.
エリック・アウアーズワルド、ニック・ブラグリオ、マーティン・J・デュルスト、トアーレス・エッカート、デビッド・ファーマー、ブライアン・ハーバーマン、ネイト・カルステン、テロ・キビネン、エリック・クライン、ジェン・リンカバ、エドゥアルド・メッツ、ギャン・ミシュラ、デビッド・シナジー、ジュルゲン・シェンワル・トレール、マルタン・スイープ、エアンワン・スイート、マルタンVyncke、Magnus Westerlund、および6man WGの他の参加者。
Brian Carpenter
School of Computer Science
University of Auckland
PB 92019
Auckland 1142
New Zealand
Email: brian.e.carpenter@gmail.com
Robert M. Hinden
Check Point Software
959 Skyway Road
San Carlos, CA 94070
United States of America
Email: bob.hinden@gmail.com