[要約] RFC 8504は、IPv6ノードの要件に関するガイドラインであり、IPv6ネットワークの設計と実装における基準を提供します。このRFCの目的は、IPv6ノードの動作と相互運用性を向上させるための指針を提供することです。
Internet Engineering Task Force (IETF) T. Chown
Request for Comments: 8504 Jisc
BCP: 220 J. Loughney
Obsoletes: 6434 Intel
Category: Best Current Practice T. Winters
ISSN: 2070-1721 UNH-IOL
January 2019
IPv6 Node Requirements
IPv6ノードの要件
Abstract
概要
This document defines requirements for IPv6 nodes. It is expected that IPv6 will be deployed in a wide range of devices and situations. Specifying the requirements for IPv6 nodes allows IPv6 to function well and interoperate in a large number of situations and deployments.
このドキュメントでは、IPv6ノードの要件を定義します。 IPv6はさまざまなデバイスと状況で展開されることが期待されています。 IPv6ノードの要件を指定すると、IPv6が適切に機能し、多数の状況や展開で相互運用できます。
This document obsoletes RFC 6434, and in turn RFC 4294.
このドキュメントはRFC 6434を廃止し、次にRFC 4294を廃止します。
Status of This Memo
本文書の状態
This memo documents an Internet Best Current Practice.
このメモは、インターネットの現在のベストプラクティスを文書化したものです。
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 BCPs is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 BCPの詳細については、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/rfc8504.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8504で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2019 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 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トラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Scope of This Document . . . . . . . . . . . . . . . . . 4
1.2. Description of IPv6 Nodes . . . . . . . . . . . . . . . . 5
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5
3. Abbreviations Used in This Document . . . . . . . . . . . . . 5
4. Sub-IP Layer . . . . . . . . . . . . . . . . . . . . . . . . 5
5. IP Layer . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Internet Protocol Version 6 - RFC 8200 . . . . . . . . . 6
5.2. Support for IPv6 Extension Headers . . . . . . . . . . . 7
5.3. Protecting a Node from Excessive Extension Header Options 8
5.4. Neighbor Discovery for IPv6 - RFC 4861 . . . . . . . . . 9
5.5. SEcure Neighbor Discovery (SEND) - RFC 3971 . . . . . . . 11
5.6. IPv6 Router Advertisement Flags Option - RFC 5175 . . . . 11
5.7. Path MTU Discovery and Packet Size . . . . . . . . . . . 11
5.7.1. Path MTU Discovery - RFC 8201 . . . . . . . . . . . . 11
5.7.2. Minimum MTU Considerations . . . . . . . . . . . . . 12
5.8. ICMP for the Internet Protocol Version 6 (IPv6) -
RFC 4443 . . . . . . . . . . . . . . . . . . . . . . . . 12
5.9. Default Router Preferences and More-Specific Routes -
RFC 4191 . . . . . . . . . . . . . . . . . . . . . . . . 12
5.10. First-Hop Router Selection - RFC 8028 . . . . . . . . . . 12
5.11. Multicast Listener Discovery (MLD) for IPv6 - RFC 3810 . 13
5.12. Explicit Congestion Notification (ECN) - RFC 3168 . . . . 13
6. Addressing and Address Configuration . . . . . . . . . . . . 13
6.1. IP Version 6 Addressing Architecture - RFC 4291 . . . . . 13
6.2. Host Address Availability Recommendations . . . . . . . . 13
6.3. IPv6 Stateless Address Autoconfiguration - RFC 4862 . . . 14
6.4. Privacy Extensions for Address Configuration in IPv6 -
RFC 4941 . . . . . . . . . . . . . . . . . . . . . . . . 15
6.5. Stateful Address Autoconfiguration (DHCPv6) - RFC 3315 . 16
6.6. Default Address Selection for IPv6 - RFC 6724 . . . . . . 16
7. DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8. Configuring Non-address Information . . . . . . . . . . . . . 17
8.1. DHCP for Other Configuration Information . . . . . . . . 17
8.2. Router Advertisements and Default Gateway . . . . . . . . 17
8.3. IPv6 Router Advertisement Options for DNS
Configuration - RFC 8106 . . . . . . . . . . . . . . . . 17
8.4. DHCP Options versus Router Advertisement Options for Host
Configuration . . . . . . . . . . . . . . . . . . . . . . 18
9. Service Discovery Protocols . . . . . . . . . . . . . . . . . 18
10. IPv4 Support and Transition . . . . . . . . . . . . . . . . . 18
10.1. Transition Mechanisms . . . . . . . . . . . . . . . . . 19
10.1.1. Basic Transition Mechanisms for IPv6 Hosts and
Routers - RFC 4213 . . . . . . . . . . . . . . . . . 19
11. Application Support . . . . . . . . . . . . . . . . . . . . . 19
11.1. Textual Representation of IPv6 Addresses - RFC 5952 . . 19
11.2. Application Programming Interfaces (APIs) . . . . . . . 19
12. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . 20
13. Security . . . . . . . . . . . . . . . . . . . . . . . . . . 20
13.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 22
13.2. Transforms and Algorithms . . . . . . . . . . . . . . . 22
14. Router-Specific Functionality . . . . . . . . . . . . . . . . 22
14.1. IPv6 Router Alert Option - RFC 2711 . . . . . . . . . . 22
14.2. Neighbor Discovery for IPv6 - RFC 4861 . . . . . . . . . 22
14.3. Stateful Address Autoconfiguration (DHCPv6) - RFC 3315 . 23
14.4. IPv6 Prefix Length Recommendation for Forwarding -
BCP 198 . . . . . . . . . . . . . . . . . . . . . . . . 23
15. Constrained Devices . . . . . . . . . . . . . . . . . . . . . 23
16. IPv6 Node Management . . . . . . . . . . . . . . . . . . . . 24
16.1. Management Information Base (MIB) Modules . . . . . . . 24
16.1.1. IP Forwarding Table MIB . . . . . . . . . . . . . . 24
16.1.2. Management Information Base for the Internet
Protocol (IP) . . . . . . . . . . . . . . . . . . . 24
16.1.3. Interface MIB . . . . . . . . . . . . . . . . . . . 24
16.2. YANG Data Models . . . . . . . . . . . . . . . . . . . . 25
16.2.1. IP Management YANG Model . . . . . . . . . . . . . . 25
16.2.2. Interface Management YANG Model . . . . . . . . . . 25
17. Security Considerations . . . . . . . . . . . . . . . . . . . 25
18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
19. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
19.1. Normative References . . . . . . . . . . . . . . . . . . 25
19.2. Informative References . . . . . . . . . . . . . . . . . 32
Appendix A. Changes from RFC 6434 . . . . . . . . . . . . . . . 38
Appendix B. Changes from RFC 4294 to RFC 6434 . . . . . . . . . 39
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42
This document defines common functionality required by both IPv6 hosts and routers. Many IPv6 nodes will implement optional or additional features, but this document collects and summarizes requirements from other published Standards Track documents in one place.
このドキュメントでは、IPv6ホストとルーターの両方に必要な共通機能を定義します。多くのIPv6ノードはオプションまたは追加の機能を実装しますが、このドキュメントは、他の公開されたスタンダードトラックドキュメントからの要件を1か所に集めて要約します。
This document tries to avoid discussion of protocol details and references RFCs for this purpose. This document is intended to be an applicability statement and to provide guidance as to which IPv6 specifications should be implemented in the general case and which specifications may be of interest to specific deployment scenarios. This document does not update any individual protocol document RFCs.
このドキュメントでは、プロトコルの詳細についての説明を避け、この目的でRFCを参照します。このドキュメントは、適用可能性に関する記述であり、一般的なケースで実装する必要のあるIPv6仕様と、特定の展開シナリオに関係する可能性のある仕様に関するガイダンスを提供することを目的としています。このドキュメントは、個々のプロトコルドキュメントRFCを更新しません。
Although this document points to different specifications, it should be noted that in many cases, the granularity of a particular requirement will be smaller than a single specification, as many specifications define multiple, independent pieces, some of which may not be mandatory. In addition, most specifications define both client and server behavior in the same specification, while many implementations will be focused on only one of those roles.
このドキュメントではさまざまな仕様を示していますが、多くの場合、特定の要件の粒度は単一の仕様よりも小さいことに注意してください。多くの仕様は複数の独立した部分を定義しており、その一部は必須ではない場合があります。さらに、ほとんどの仕様ではクライアントとサーバーの両方の動作が同じ仕様で定義されていますが、多くの実装ではこれらの役割の1つのみに焦点が当てられます。
This document defines a minimal level of requirement needed for a device to provide useful Internet service and considers a broad range of device types and deployment scenarios. Because of the wide range of deployment scenarios, the minimal requirements specified in this document may not be sufficient for all deployment scenarios. It is perfectly reasonable (and indeed expected) for other profiles to define additional or stricter requirements appropriate for specific usage and deployment environments. As an example, this document does not mandate that all clients support DHCP, but some deployment scenarios may deem it appropriate to make such a requirement. As another example, NIST has defined profiles for specialized requirements for IPv6 in target environments (see [USGv6]).
このドキュメントでは、デバイスが有用なインターネットサービスを提供するために必要な最小レベルの要件を定義し、幅広いデバイスタイプと展開シナリオを検討します。さまざまな展開シナリオがあるため、このドキュメントで指定されている最小要件は、すべての展開シナリオに十分ではない場合があります。他のプロファイルが特定の使用および展開環境に適切な追加またはより厳しい要件を定義することは完全に合理的です（そして実際に期待されています）。例として、このドキュメントでは、すべてのクライアントがDHCPをサポートすることを義務付けていませんが、一部の配備シナリオでは、そのような要件を設けることが適切であると見なされている場合があります。別の例として、NISTはターゲット環境でのIPv6の特殊な要件のプロファイルを定義しています（[USGv6]を参照）。
As it is not always possible for an implementer to know the exact usage of IPv6 in a node, an overriding requirement for IPv6 nodes is that they should adhere to Jon Postel's Robustness Principle: "Be conservative in what you do, be liberal in what you accept from others" [RFC793].
実装者がノードでのIPv6の正確な使用法を常に知ることができるとは限らないため、IPv6ノードのオーバーライド要件は、Jon Postelの堅牢性の原則に準拠する必要があることです。他人から受け入れる」[RFC793]。
IPv6 covers many specifications. It is intended that IPv6 will be deployed in many different situations and environments. Therefore, it is important to develop requirements for IPv6 nodes to ensure interoperability.
IPv6は多くの仕様をカバーしています。 IPv6は多くの異なる状況と環境で展開されることを意図しています。したがって、相互運用性を確保するには、IPv6ノードの要件を開発することが重要です。
From "Internet Protocol, Version 6 (IPv6) Specification" [RFC8200], we have the following definitions:
「インターネットプロトコル、バージョン6（IPv6）仕様」[RFC8200]から、次の定義があります。
IPv6 node - a device that implements IPv6. IPv6 router - a node that forwards IPv6 packets not explicitly addressed to itself. IPv6 host - any IPv6 node that is not a router.
IPv6ノード-IPv6を実装するデバイス。 IPv6ルーター-明示的にアドレス指定されていないIPv6パケットを転送するノード。 IPv6ホスト-ルーターではないIPv6ノード。
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]で説明されているように解釈されます。
AH Authentication Header DAD Duplicate Address Detection ESP Encapsulating Security Payload ICMP Internet Control Message Protocol IKE Internet Key Exchange MIB Management Information Base MLD Multicast Listener Discovery MTU Maximum Transmission Unit NA Neighbor Advertisement NBMA Non-Broadcast Multi-Access ND Neighbor Discovery NS Neighbor Solicitation NUD Neighbor Unreachability Detection PPP Point-to-Point Protocol
AH認証ヘッダーDAD重複アドレス検出ESPカプセル化セキュリティペイロードICMPインターネット制御メッセージプロトコルIKEインターネットキー交換MIB管理情報ベースMLDマルチキャストリスナーディスカバリMTU最大伝送ユニットNAネイバーアドバタイズメントNBMA非ブロードキャストマルチアクセスNDネイバーディスカバリNSネイバーソリシテーションNUDネイバー到達不能検出PPPポイントツーポイントプロトコル
An IPv6 node MUST include support for one or more IPv6 link-layer specifications. Which link-layer specifications an implementation should include will depend upon what link layers are supported by the hardware available on the system. It is possible for a conformant IPv6 node to support IPv6 on some of its interfaces and not on others.
IPv6ノードは、1つ以上のIPv6リンク層仕様のサポートを含む必要があります。実装に含める必要のあるリンク層の仕様は、システムで使用可能なハードウェアがサポートするリンク層によって異なります。適合IPv6ノードは、一部のインターフェースでIPv6をサポートし、他のインターフェースではサポートしないことが可能です。
As IPv6 is run over new Layer 2 technologies, it is expected that new specifications will be issued. We list here some of the Layer 2 technologies for which an IPv6 specification has been developed. It is provided for informational purposes only and may not be complete.
IPv6は新しいレイヤー2テクノロジー上で実行されるため、新しい仕様が発行されることが予想されます。ここでは、IPv6仕様が開発されたレイヤ2テクノロジーの一部を示します。これは情報提供のみを目的として提供されており、完全ではない場合があります。
- Transmission of IPv6 Packets over Ethernet Networks [RFC2464]
- イーサネットネットワーク上のIPv6パケットの送信[RFC2464]
- Transmission of IPv6 Packets over Frame Relay Networks Specification [RFC2590]
- フレームリレーネットワーク仕様を介したIPv6パケットの送信[RFC2590]
- Transmission of IPv6 Packets over IEEE 1394 Networks [RFC3146]
- IEEE 1394ネットワークを介したIPv6パケットの送信[RFC3146]
- Transmission of IPv6, IPv4, and Address Resolution Protocol (ARP) Packets over Fibre Channel [RFC4338]
- ファイバーチャネルを介したIPv6、IPv4、およびアドレス解決プロトコル（ARP）パケットの送信[RFC4338]
- Transmission of IPv6 Packets over IEEE 802.15.4 Networks [RFC4944]
- IEEE 802.15.4ネットワークを介したIPv6パケットの送信[RFC4944]
- Transmission of IPv6 via the IPv6 Convergence Sublayer over IEEE 802.16 Networks [RFC5121]
- IEEE 802.16ネットワーク上のIPv6コンバージェンスサブレイヤーを介したIPv6の送信[RFC5121]
- IP version 6 over PPP [RFC5072]
- PPP上のIPバージョン6 [RFC5072]
In addition to traditional physical link layers, it is also possible to tunnel IPv6 over other protocols. Examples include:
従来の物理リンク層に加えて、他のプロトコルでIPv6をトンネリングすることも可能です。例は次のとおりです。
- Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs) [RFC4380]
- Teredo：ネットワークアドレス変換（NAT）によるUDPを介したIPv6のトンネリング[RFC4380]
- Basic Transition Mechanisms for IPv6 Hosts and Routers (see Section 3 of [RFC4213])
- IPv6ホストとルーターの基本的な移行メカニズム（[RFC4213]のセクション3を参照）
The Internet Protocol version 6 is specified in [RFC8200]. This specification MUST be supported.
インターネットプロトコルバージョン6は、[RFC8200]で指定されています。この仕様はサポートされなければなりません。
The node MUST follow the packet transmission rules in RFC 8200.
ノードはRFC 8200のパケット転送ルールに従う必要があります。
All conformant IPv6 implementations MUST be capable of sending and receiving IPv6 packets; forwarding functionality MAY be supported. Nodes MUST always be able to send, receive, and process Fragment headers.
すべての適合IPv6実装は、IPv6パケットを送受信できる必要があります。転送機能がサポートされる場合があります。ノードは常にフラグメントヘッダーを送信、受信、処理できる必要があります。
IPv6 nodes MUST not create overlapping fragments. Also, when reassembling an IPv6 datagram, if one or more of its constituent fragments is determined to be an overlapping fragment, the entire datagram (and any constituent fragments) MUST be silently discarded. See [RFC5722] for more information.
IPv6ノードは重複するフラグメントを作成してはなりません（MUST NOT）。また、IPv6データグラムを再構成するときに、その構成フラグメントの1つ以上が重複フラグメントであると判断された場合、データグラム全体（および構成フラグメント）は警告なしに破棄されなければなりません（MUST）。詳細については、[RFC5722]を参照してください。
As recommended in [RFC8021], nodes MUST NOT generate atomic fragments, i.e., where the fragment is a whole datagram. As per [RFC6946], if a receiving node reassembling a datagram encounters an atomic fragment, it should be processed as a fully reassembled packet, and any other fragments that match this packet should be processed independently.
[RFC8021]で推奨されているように、ノードはアトミックフラグメントを生成してはなりません。つまり、フラグメントはデータグラム全体です。 [RFC6946]によると、データグラムを再構成する受信ノードがアトミックフラグメントに遭遇した場合、それは完全に再構成されたパケットとして処理され、このパケットに一致する他のフラグメントは個別に処理されます。
To mitigate a variety of potential attacks, nodes SHOULD avoid using predictable Fragment Identification values in Fragment headers, as discussed in [RFC7739].
[RFC7739]で説明されているように、ノードはさまざまな潜在的な攻撃を軽減するために、フラグメントヘッダーで予測可能なフラグメント識別値を使用しないようにする必要があります（SHOULD）。
All nodes SHOULD support the setting and use of the IPv6 Flow Label field as defined in the IPv6 Flow Label specification [RFC6437]. Forwarding nodes such as routers and load distributors MUST NOT depend only on Flow Label values being uniformly distributed. It is RECOMMENDED that source hosts support the flow label by setting the Flow Label field for all packets of a given flow to the same value chosen from an approximation to a discrete uniform distribution.
すべてのノードは、IPv6フローラベル仕様[RFC6437]で定義されているIPv6フローラベルフィールドの設定と使用をサポートする必要があります（SHOULD）。ルーターやロードディストリビューターなどの転送ノードは、均一に分散されているフローラベル値のみに依存してはなりません。送信元ホストは、特定のフローのすべてのパケットの[フローラベル]フィールドを、離散均一分布への近似から選択された同じ値に設定することにより、フローラベルをサポートすることをお勧めします。
RFC 8200 specifies extension headers and the processing for these headers.
RFC 8200は、拡張ヘッダーとこれらのヘッダーの処理を指定しています。
Extension headers (except for the Hop-by-Hop Options header) are not processed, inserted, or deleted by any node along a packet's delivery path, until the packet reaches the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field of the IPv6 header.
拡張ヘッダー（ホップバイホップオプションヘッダーを除く）は、パケットがノード（または、ノードのセットのそれぞれ）に到達するまで、パケットの配信パスに沿ったノードによって処理、挿入、または削除されません。マルチキャスト）IPv6ヘッダーの宛先アドレスフィールドで識別されます。
Any unrecognized extension headers or options MUST be processed as described in RFC 8200. Note that where Section 4 of RFC 8200 refers to the action to be taken when a Next Header value in the current header is not recognized by a node, that action applies whether the value is an unrecognized extension header or an unrecognized upper-layer protocol (ULP).
認識されない拡張ヘッダーまたはオプションは、RFC 8200の説明に従って処理する必要があります。RFC8200のセクション4が、現在のヘッダーの次のヘッダー値がノードによって認識されない場合に実行されるアクションを参照している場合、そのアクションは、値は、認識されない拡張ヘッダーまたは認識されない上位層プロトコル（ULP）です。
An IPv6 node MUST be able to process these extension headers. An exception is Routing Header type 0 (RH0), which was deprecated by [RFC5095] due to security concerns and which MUST be treated as an unrecognized routing type.
IPv6ノードはこれらの拡張ヘッダーを処理できなければなりません（MUST）。例外はルーティングヘッダータイプ0（RH0）です。これは、セキュリティ上の理由から[RFC5095]で非推奨になり、認識されないルーティングタイプとして扱われる必要があります。
Further, [RFC7045] adds specific requirements for the processing of extension headers, in particular that any forwarding node along an IPv6 packet's path, which forwards the packet for any reason, SHOULD do so regardless of any extension headers that are present.
さらに、[RFC7045]は、拡張ヘッダーの処理に関する特定の要件を追加します。特に、IPv6パケットのパスに沿った転送ノードは、何らかの理由でパケットを転送するため、存在する拡張ヘッダーに関係なくそうする必要があります。
As per RFC 8200, when a node fragments an IPv6 datagram, it MUST include the entire IPv6 Header Chain in the first fragment. The Per-Fragment headers MUST consist of the IPv6 header plus any extension headers that MUST be processed by nodes en route to the destination, that is, all headers up to and including the Routing header if present, else the Hop-by-Hop Options header if present, else no extension headers. On reassembly, if the first fragment does not include all headers through an upper-layer header, then that fragment SHOULD be discarded and an ICMP Parameter Problem, Code 3, message SHOULD be sent to the source of the fragment, with the Pointer field set to zero. See [RFC7112] for a discussion of why oversized IPv6 Extension Header Chains are avoided.
RFC 8200に従って、ノードがIPv6データグラムをフラグメント化するとき、最初のフラグメントにIPv6ヘッダーチェーン全体を含める必要があります。フラグメントごとのヘッダーは、IPv6ヘッダーと、宛先に向かう途中のノードで処理する必要がある拡張ヘッダー、つまりルーティングヘッダーまでのすべてのヘッダー（存在する場合）から構成する必要があります。それ以外の場合は、ホップバイホップオプション存在する場合はヘッダー、それ以外の場合は拡張ヘッダーはありません。再構成時に、最初のフラグメントに上位層ヘッダーのすべてのヘッダーが含まれていない場合、そのフラグメントは破棄する必要があり（SHOULD）、ICMPパラメーターの問題、コード3、メッセージは、ポインターフィールドを設定してフラグメントのソースに送信する必要があります（SHOULD）ゼロに。特大のIPv6拡張ヘッダーチェーンが回避される理由については、[RFC7112]を参照してください。
Defining new IPv6 extension headers is not recommended, unless there are no existing IPv6 extension headers that can be used by specifying a new option for that IPv6 extension header. A proposal to specify a new IPv6 extension header MUST include a detailed technical explanation of why an existing IPv6 extension header can not be used for the desired new function, and in such cases, it needs to follow the format described in Section 8 of RFC 8200. For further background reading on this topic, see [RFC6564].
そのIPv6拡張ヘッダーに新しいオプションを指定して使用できる既存のIPv6拡張ヘッダーがない場合を除いて、新しいIPv6拡張ヘッダーを定義することはお勧めできません。新しいIPv6拡張ヘッダーを指定する提案には、既存のIPv6拡張ヘッダーを目的の新しい機能に使用できない理由の詳細な技術的説明を含める必要があり、そのような場合は、RFC 8200のセクション8で説明されている形式に従う必要があります。 。このトピックに関する背景知識の詳細については、[RFC6564]を参照してください。
As per RFC 8200, end hosts are expected to process all extension headers, destination options, and hop-by-hop options in a packet. Given that the only limit on the number and size of extension headers is the MTU, the processing of received packets could be considerable. It is also conceivable that a long chain of extension headers might be used as a form of denial-of-service attack. Accordingly, a host may place limits on the number and sizes of extension headers and options it is willing to process.
RFC 8200に従って、エンドホストはパケット内のすべての拡張ヘッダー、宛先オプション、およびホップバイホップオプションを処理することが期待されています。拡張ヘッダーの数とサイズの唯一の制限がMTUであることを考えると、受信パケットの処理はかなりのものになる可能性があります。また、一連の拡張ヘッダーがサービス拒否攻撃の形式として使用される可能性も考えられます。したがって、ホストは、拡張ヘッダーと処理するオプションの数とサイズに制限を設ける場合があります。
A host MAY limit the number of consecutive PAD1 options in destination options or hop-by-hop options to 7. In this case, if there are more than 7 consecutive PAD1 options present, the packet MAY be silently discarded. The rationale is that if padding of 8 or more bytes is required, then the PADN option SHOULD be used.
ホストは、宛先オプションまたはホップバイホップオプションの連続したPAD1オプションの数を7に制限してもよい（MAY）。この場合、7つを超える連続したPAD1オプションが存在する場合、パケットは通知なく破棄される場合があります。その理由は、8バイト以上のパディングが必要な場合、PADNオプションを使用する必要がある（SHOULD）ことです。
A host MAY limit the number of bytes in a PADN option to be less than 8. In such a case, if a PADN option is present that has a length greater than 7, the packet SHOULD be silently discarded. The rationale for this guideline is that the purpose of padding is for alignment and 8 bytes is the maximum alignment used in IPv6.
ホストは、PADNオプションのバイト数を8未満に制限できます（MAY）。そのような場合、長さが7を超えるPADNオプションが存在する場合、パケットは通知なく破棄されるべきです（SHOULD）。このガイドラインの根拠は、パディングの目的がアラインメントのためであり、8バイトがIPv6で使用される最大のアラインメントであることです。
A host MAY disallow unknown options in destination options or hop-by-hop options. This SHOULD be configurable where the default is to accept unknown options and process them per [RFC8200]. If a packet with unknown options is received and the host is configured to disallow them, then the packet SHOULD be silently discarded.
ホストは、宛先オプションまたはホップバイホップオプションで不明なオプションを許可しない場合があります。これは、デフォルトで不明なオプションを受け入れ、[RFC8200]に従って処理するように構成可能である必要があります（SHOULD）。不明なオプションを持つパケットが受信され、ホストがそれらを許可しないように構成されている場合、パケットは警告なしで破棄されるべきです。
A host MAY impose a limit on the maximum number of non-padding options allowed in the destination options and hop-by-hop extension headers. If this feature is supported, the maximum number SHOULD be configurable, and the default value SHOULD be set to 8. The limits for destination options and hop-by-hop options may be separately configurable. If a packet is received and the number of destination or hop-by-hop options exceeds the limit, then the packet SHOULD be silently discarded.
ホストは、宛先オプションとホップバイホップ拡張ヘッダーで許可される非パディングオプションの最大数に制限を課してもよい（MAY）。この機能がサポートされている場合、最大数は構成可能である必要があり（SHOULD）、デフォルト値は8に設定する必要があります（SHOULD）。宛先オプションとホップバイホップオプションの制限は個別に構成可能です。パケットが受信され、宛先オプションまたはホップバイホップオプションの数が制限を超えた場合、パケットは通知なく破棄される必要があります（SHOULD）。
A host MAY impose a limit on the maximum length of Destination Options or Hop-by-Hop Options extension headers. This value SHOULD be configurable, and the default is to accept options of any length. If a packet is received and the length of the Destination or Hop-by-Hop Options extension header exceeds the length limit, then the packet SHOULD be silently discarded.
ホストは、宛先オプションまたはホップバイホップオプション拡張ヘッダーの最大長に制限を課してもよい（MAY）。この値は構成可能である必要があり（SHOULD）、デフォルトでは、任意の長さのオプションを受け入れます。パケットが受信され、DestinationまたはHop-by-Hop Options拡張ヘッダーの長さが長さ制限を超えている場合、パケットは通知なく破棄されるべきです（SHOULD）。
Neighbor Discovery is defined in [RFC4861]; the definition was updated by [RFC5942]. Neighbor Discovery MUST be supported with the noted exceptions below. RFC 4861 states:
近隣探索は[RFC4861]で定義されています。定義は[RFC5942]によって更新されました。近隣探索は、下記の例外を除いてサポートする必要があります。 RFC 4861は次のように述べています：
Unless specified otherwise (in a document that covers operating IP over a particular link type) this document applies to all link types. However, because ND uses link-layer multicast for some of its services, it is possible that on some link types (e.g., Non-Broadcast Multi-Access (NBMA) links), alternative protocols or mechanisms to implement those services will be specified (in the appropriate document covering the operation of IP over a particular link type). The services described in this document that are not directly dependent on multicast, such as Redirects, Next-hop determination, Neighbor Unreachability Detection, etc., are expected to be provided as specified in this document. The details of how one uses ND on NBMA links are addressed in [RFC2491].
特に明記されていない限り（特定のリンクタイプでの動作IPを扱っているドキュメント）、このドキュメントはすべてのリンクタイプに適用されます。ただし、NDは一部のサービスにリンク層マルチキャストを使用するため、一部のリンクタイプ（Non-Broadcast Multi-Access（NBMA）リンクなど）では、これらのサービスを実装するための代替プロトコルまたはメカニズムが指定される可能性があります（特定のリンクタイプを介したIPの操作をカバーする適切なドキュメントで）。このドキュメントで説明されているように、リダイレクト、ネクストホップの決定、近隣到達不能検出など、マルチキャストに直接依存しないサービスは、このドキュメントで指定されているとおりに提供されることが想定されています。 NBMAリンクでNDを使用する方法の詳細は、[RFC2491]で扱われています。
Some detailed analysis of Neighbor Discovery follows:
近隣探索の詳細な分析は次のとおりです。
Router Discovery is how hosts locate routers that reside on an attached link. Hosts MUST support Router Discovery functionality.
ルーター検出は、接続されたリンク上にあるルーターをホストが見つける方法です。ホストはルーター検出機能をサポートする必要があります。
Prefix Discovery is how hosts discover the set of address prefixes that define which destinations are on-link for an attached link. Hosts MUST support Prefix Discovery.
プレフィックスディスカバリは、ホストが、接続されたリンクのリンク上にある宛先を定義するアドレスプレフィックスのセットを検出する方法です。ホストはプレフィックス検出をサポートする必要があります。
Hosts MUST also implement Neighbor Unreachability Detection (NUD) for all paths between hosts and neighboring nodes. NUD is not required for paths between routers. However, all nodes MUST respond to unicast Neighbor Solicitation (NS) messages.
ホストはまた、ホストと隣接ノード間のすべてのパスに対して、Neighbor Unreachability Detection（NUD）を実装する必要があります。ルーター間のパスにNUDは必要ありません。ただし、すべてのノードは、ユニキャスト近隣要請（NS）メッセージに応答する必要があります。
[RFC7048] discusses NUD, in particular cases where it behaves too impatiently. It states that if a node transmits more than a certain number of packets, then it SHOULD use the exponential backoff of the retransmit timer, up to a certain threshold point.
[RFC7048]は、NUDについて、特に動作が短すぎる場合について説明しています。これは、ノードが特定の数を超えるパケットを送信する場合は、特定のしきい値ポイントまで、再送信タイマーの指数バックオフを使用する必要があることを示しています。
Hosts MUST support the sending of Router Solicitations and the receiving of Router Advertisements (RAs). The ability to understand individual RA options is dependent on supporting the functionality making use of the particular option.
ホストは、ルーター要請の送信とルーター通知（RA）の受信をサポートする必要があります。個々のRAオプションを理解する能力は、特定のオプションを利用する機能のサポートに依存しています。
[RFC7559] discusses packet loss resiliency for Router Solicitations and requires that nodes MUST use a specific exponential backoff algorithm for retransmission of Router Solicitations.
[RFC7559]は、ルーター要請のパケット損失回復力について説明し、ノードがルーター要請の再送信に特定の指数バックオフアルゴリズムを使用する必要があることを要求します。
All nodes MUST support the sending and receiving of Neighbor Solicitation (NS) and Neighbor Advertisement (NA) messages. NS and NA messages are required for Duplicate Address Detection (DAD).
すべてのノードは、近隣要請（NS）および近隣アドバタイズ（NA）メッセージの送受信をサポートする必要があります。 NSおよびNAメッセージは、重複アドレス検出（DAD）に必要です。
Hosts SHOULD support the processing of Redirect functionality. Routers MUST support the sending of Redirects, though not necessarily for every individual packet (e.g., due to rate limiting). Redirects are only useful on networks supporting hosts. In core networks dominated by routers, Redirects are typically disabled. The sending of Redirects SHOULD be disabled by default on routers intended to be deployed on core networks. They MAY be enabled by default on routers intended to support hosts on edge networks.
ホストはリダイレクト機能の処理をサポートする必要があります（SHOULD）。ルーターはリダイレクトの送信をサポートする必要がありますが、必ずしもすべての個別のパケットについてではありません（たとえば、レート制限のため）。リダイレクトは、ホストをサポートするネットワークでのみ役立ちます。ルーターが支配するコアネットワークでは、リダイレクトは通常無効になっています。コアネットワークに展開する予定のルーターでは、リダイレクトの送信をデフォルトで無効にする必要があります（SHOULD）。エッジネットワーク上のホストをサポートすることを目的としたルーターでは、デフォルトで有効になっている場合があります。
As specified in [RFC6980], nodes MUST NOT employ IPv6 fragmentation for sending any of the following Neighbor Discovery and SEcure Neighbor Discovery messages: Neighbor Solicitation, Neighbor Advertisement, Router Solicitation, Router Advertisement, Redirect, or Certification Path Solicitation. Nodes MUST silently ignore any of these messages on receipt if fragmented. See RFC 6980 for details and motivation.
[RFC6980]で指定されているように、ノードは次の近隣探索メッセージとSEcure近隣探索メッセージのいずれかを送信するためにIPv6フラグメンテーションを使用してはなりません（近隣要請、近隣アドバタイズ、ルーター要請、ルーターアドバタイズ、リダイレクト、または認証パス要請）。断片化されている場合、ノードは受信時にこれらのメッセージを無視する必要があります。詳細と動機については、RFC 6980を参照してください。
"IPv6 Host-to-Router Load Sharing" [RFC4311] includes additional recommendations on how to select from a set of available routers. [RFC4311] SHOULD be supported.
「IPv6ホストからルーターへの負荷共有」[RFC4311]には、利用可能なルーターのセットから選択する方法に関する追加の推奨事項が含まれています。 [RFC4311]サポートする必要があります。
SEND [RFC3971] and Cryptographically Generated Addresses (CGAs) [RFC3972] provide a way to secure the message exchanges of Neighbor Discovery. SEND has the potential to address certain classes of spoofing attacks, but it does not provide specific protection for threats from off-link attackers.
SEND [RFC3971]および暗号化生成アドレス（CGA）[RFC3972]は、近隣探索のメッセージ交換を保護する方法を提供します。 SENDは、特定のクラスのスプーフィング攻撃に対処する可能性がありますが、オフリンク攻撃者からの脅威に対する特定の保護を提供しません。
There have been relatively few implementations of SEND in common operating systems and platforms since its publication in 2005; thus, deployment experience remains very limited to date.
2005年の公開以来、一般的なオペレーティングシステムおよびプラットフォームでのSENDの実装は比較的少数です。したがって、展開の経験は現在まで非常に限られています。
At this time, support for SEND is considered optional. Due to the complexity in deploying SEND and its heavyweight provisioning, its deployment is only likely to be considered where nodes are operating in a particularly strict security environment.
現時点では、SENDのサポートはオプションと見なされています。 SENDの導入は複雑であり、そのヘビーウェイトプロビジョニングのため、その導入は、ノードが特に厳しいセキュリティ環境で動作している場合にのみ考慮される可能性があります。
Router Advertisements include an 8-bit field of single-bit Router Advertisement flags. The Router Advertisement Flags Option extends the number of available flag bits by 48 bits. At the time of this writing, 6 of the original 8 single-bit flags have been assigned, while 2 remain available for future assignment. No flags have been defined that make use of the new option; thus, strictly speaking, there is no requirement to implement the option today. However, implementations that are able to pass unrecognized options to a higher-level entity that may be able to understand them (e.g., a user-level process using a "raw socket" facility) MAY take steps to handle the option in anticipation of a future usage.
ルーター通知には、シングルビットのルーター通知フラグの8ビットフィールドが含まれます。ルーターアドバタイズメントフラグオプションは、使用可能なフラグビットの数を48ビット拡張します。この記事の執筆時点では、元の8つのシングルビットフラグのうち6つが割り当てられていますが、2つは将来の割り当てに使用できます。新しいオプションを使用するフラグは定義されていません。したがって、厳密に言えば、今日のオプションを実装する必要はありません。ただし、認識できないオプションを、それらを理解できる可能性がある上位エンティティに渡すことができる実装（たとえば、「rawソケット」機能を使用するユーザーレベルのプロセス）は、将来の使用。
"Path MTU Discovery for IP version 6" [RFC8201] SHOULD be supported. From [RFC8200]:
「IPバージョン6のパスMTUディスカバリー」[RFC8201]をサポートする必要があります（SHOULD）。 [RFC8200]から：
It is strongly recommended that IPv6 nodes implement Path MTU Discovery [RFC8201], in order to discover and take advantage of path MTUs greater than 1280 octets. However, a minimal IPv6 implementation (e.g., in a boot ROM) may simply restrict itself to sending packets no larger than 1280 octets, and omit implementation of Path MTU Discovery.
1280オクテットを超えるパスMTUを検出して利用するために、IPv6ノードがパスMTUディスカバリ[RFC8201]を実装することを強くお勧めします。ただし、最小限のIPv6実装（たとえば、ブートROMで）は、それ自体を1280オクテット以下のパケットの送信に制限し、パスMTU検出の実装を省略します。
The rules in [RFC8200] and [RFC5722] MUST be followed for packet fragmentation and reassembly.
[RFC8200]と[RFC5722]のルールは、パケットの断片化と再構成に準拠しなければなりません（MUST）。
As described in RFC 8201, nodes implementing Path MTU Discovery and sending packets larger than the IPv6 minimum link MTU are susceptible to problematic connectivity if ICMPv6 messages are blocked or not transmitted. For example, this will result in connections that complete the TCP three-way handshake correctly but then hang when data is transferred. This state is referred to as a black-hole connection [RFC2923]. Path MTU Discovery relies on ICMPv6 Packet Too Big (PTB) to determine the MTU of the path (and thus these MUST NOT be filtered, as per the recommendation in [RFC4890]).
RFC 8201で説明されているように、ICMPv6メッセージがブロックまたは送信されない場合、パスMTUディスカバリーを実装し、IPv6最小リンクMTUより大きいパケットを送信するノードは、問題のある接続の影響を受けやすくなります。たとえば、これにより、TCPスリーウェイハンドシェイクは正常に完了しますが、データが転送されるとハングする接続になります。この状態は、ブラックホール接続[RFC2923]と呼ばれます。パスMTUディスカバリーはパスのMTUを決定するためにICMPv6パケットが大きすぎます（PTB）に依存します（したがって、これらは[RFC4890]の推奨に従ってフィルター処理してはなりません（MUST））。
An alternative to Path MTU Discovery defined in RFC 8201 can be found in [RFC4821], which defines a method for Packetization Layer Path MTU Discovery (PLPMTUD) designed for use over paths where delivery of ICMPv6 messages to a host is not assured.
RFC 8201で定義されているパスMTUディスカバリーの代替は、[RFC4821]にあります。これは、ホストへのICMPv6メッセージの配信が保証されないパスで使用するために設計されたパケット化レイヤーパスMTUディスカバリー（PLPMTUD）の方法を定義します。
While an IPv6 link MTU can be set to 1280 bytes, it is recommended that for IPv6 UDP in particular, which includes DNS operation, the sender use a large MTU if they can, in order to avoid gratuitous fragmentation-caused packet drops.
IPv6リンクのMTUは1280バイトに設定できますが、特にDNS操作を含むIPv6 UDPの場合は、フラグメンテーションによるパケットの不必要なドロップを回避するために、可能な場合は送信者が大きなMTUを使用することをお勧めします。
ICMPv6 [RFC4443] MUST be supported. "Extended ICMP to Support Multi-Part Messages" [RFC4884] MAY be supported.
ICMPv6 [RFC4443]をサポートする必要があります。 「マルチパートメッセージをサポートするための拡張ICMP」[RFC4884]がサポートされる場合があります。
"Default Router Preferences and More-Specific Routes" [RFC4191] provides support for nodes attached to multiple (different) networks, each providing routers that advertise themselves as default routers via Router Advertisements. In some scenarios, one router may provide connectivity to destinations that the other router does not, and choosing the "wrong" default router can result in reachability failures. In order to resolve this scenario, IPv6 nodes MUST implement [RFC4191] and SHOULD implement the Type C host role defined in RFC 4191.
「デフォルトルーターの設定とより具体的なルート」[RFC4191]は、複数の（異なる）ネットワークに接続されたノードをサポートし、それぞれがルーターアドバタイズを介してデフォルトルーターとしてアドバタイズするルーターを提供します。一部のシナリオでは、1つのルーターが他のルーターが提供しない宛先への接続を提供する場合があり、「間違った」デフォルトルーターを選択すると、到達可能性の障害が発生する可能性があります。このシナリオを解決するために、IPv6ノードは[RFC4191]を実装する必要があり、RFC 4191で定義されているタイプCホストロールを実装する必要があります（SHOULD）。
In multihomed scenarios, where a host has more than one prefix, each allocated by an upstream network that is assumed to implement BCP 38 ingress filtering, the host may have multiple routers to choose from.
ホストに複数のプレフィックスがあり、それぞれがBCP 38入力フィルタリングを実装すると想定されるアップストリームネットワークによって割り当てられているマルチホームシナリオでは、ホストは複数のルーターから選択できます。
Hosts that may be deployed in such multihomed environments SHOULD follow the guidance given in [RFC8028].
このようなマルチホーム環境にデプロイされる可能性のあるホストは、[RFC8028]で提供されているガイダンスに従う必要があります。
Nodes that need to join multicast groups MUST support MLDv2 [RFC3810]. MLD is needed by any node that is expected to receive and process multicast traffic; in particular, MLDv2 is required for support for source-specific multicast (SSM) as per [RFC4607].
マルチキャストグループに参加する必要があるノードは、MLDv2 [RFC3810]をサポートする必要があります。 MLDは、マルチキャストトラフィックを受信して処理することが予想されるすべてのノードで必要です。特に、MLCv2は、[RFC4607]のように、Source-Specific Multicast（SSM）のサポートに必要です。
Previous versions of this specification only required MLDv1 [RFC2710] to be implemented on all nodes. Since participation of any MLDv1-only nodes on a link require that all other nodes on the link then operate in version 1 compatibility mode, the requirement to support MLDv2 on all nodes was upgraded to a MUST. Further, SSM is now the preferred multicast distribution method, rather than Any-Source Multicast (ASM).
この仕様の以前のバージョンでは、MLDv1 [RFC2710]のみをすべてのノードに実装する必要がありました。リンク上のMLDv1のみのノードに参加するには、リンク上の他のすべてのノードがバージョン1互換モードで動作する必要があるため、すべてのノードでMLDv2をサポートする要件が必須にアップグレードされました。さらに、Any-Source Multicast（ASM）ではなく、SSMが優先されるマルチキャスト配信方法になりました。
Note that Neighbor Discovery (as used on most link types -- see Section 5.4) depends on multicast and requires that nodes join Solicited Node multicast addresses.
近隣探索（ほとんどのリンクタイプで使用される-5.4を参照）はマルチキャストに依存し、ノードが要請ノードマルチキャストアドレスに参加する必要があることに注意してください。
An ECN-aware router sets a mark in the IP header in order to signal impending congestion, rather than dropping a packet. The receiver of the packet echoes the congestion indication to the sender, which can then reduce its transmission rate as if it detected a dropped packet.
ECN対応ルーターは、パケットをドロップするのではなく、差し迫った輻輳を通知するためにIPヘッダーにマークを設定します。パケットの受信者は、輻輳の表示を送信者にエコーします。送信者は、ドロップされたパケットを検出したかのように送信レートを下げることができます。
Nodes SHOULD support ECN [RFC3168] by implementing an interface for the upper layer to access and by setting the ECN bits in the IP header. The benefits of using ECN are documented in [RFC8087].
ノードは、上位層がアクセスするインターフェースを実装し、IPヘッダーにECNビットを設定することにより、ECN [RFC3168]をサポートする必要があります（SHOULD）。 ECNを使用する利点は、[RFC8087]に文書化されています。
The IPv6 Addressing Architecture [RFC4291] MUST be supported.
IPv6アドレス指定アーキテクチャ[RFC4291]をサポートする必要があります。
The current IPv6 Address Architecture is based on a 64-bit boundary for subnet prefixes. The reasoning behind this decision is documented in [RFC7421].
現在のIPv6アドレスアーキテクチャは、サブネットプレフィックスの64ビット境界に基づいています。この決定の背後にある理由は[RFC7421]に文書化されています。
Implementations MUST also support the multicast flag updates documented in [RFC7371].
実装は、[RFC7371]に文書化されているマルチキャストフラグの更新もサポートする必要があります。
Hosts may be configured with addresses through a variety of methods, including Stateless Address Autoconfiguration (SLAAC), DHCPv6, or manual configuration.
ホストは、ステートレスアドレス自動構成（SLAAC）、DHCPv6、手動構成など、さまざまな方法でアドレスを構成できます。
[RFC7934] recommends that networks provide general-purpose end hosts with multiple global IPv6 addresses when they attach, and it describes the benefits of and the options for doing so. Routers SHOULD support [RFC7934] for assigning multiple addresses to a host. A host SHOULD support assigning multiple addresses as described in [RFC7934].
[RFC7934]は、ネットワークが接続時に複数のグローバルIPv6アドレスを持つ汎用エンドホストを提供することを推奨し、その利点とそのオプションについて説明します。ルーターは、ホストに複数のアドレスを割り当てるために[RFC7934]をサポートする必要があります（SHOULD）。ホストは、[RFC7934]で説明されているように、複数のアドレスの割り当てをサポートする必要があります（SHOULD）。
Nodes SHOULD support the capability to be assigned a prefix per host as documented in [RFC8273]. Such an approach can offer improved host isolation and enhanced subscriber management on shared network segments.
ノードは、[RFC8273]で文書化されているように、ホストごとにプレフィックスを割り当てる機能をサポートする必要があります（SHOULD）。このようなアプローチにより、共有ネットワークセグメントでのホスト分離が改善され、サブスクライバー管理が強化されます。
Hosts MUST support IPv6 Stateless Address Autoconfiguration. It is RECOMMENDED, as described in [RFC8064], that unless there is a specific requirement for Media Access Control (MAC) addresses to be embedded in an Interface Identifier (IID), nodes follow the procedure in [RFC7217] to generate SLAAC-based addresses, rather than use [RFC4862]. Addresses generated using the method described in [RFC7217] will be the same whenever a given device (re)appears on the same subnet (with a specific IPv6 prefix), but the IID will vary on each subnet visited.
ホストはIPv6ステートレスアドレス自動構成をサポートする必要があります。 [RFC8064]で説明されているように、メディアアクセスコントロール（MAC）アドレスをインターフェイス識別子（IID）に埋め込むための特定の要件がない限り、ノードは[RFC7217]の手順に従ってSLAACベースの生成を行うことをお勧めします。 [RFC4862]を使用するのではなく、アドレス。 [RFC7217]で説明されている方法を使用して生成されたアドレスは、特定のデバイスが（特定のIPv6プレフィックスで）同じサブネット上に（再）出現するときは常に同じですが、IIDは訪問するサブネットごとに異なります。
Nodes that are routers MUST be able to generate link-local addresses as described in [RFC4862].
ルーターであるノードは、[RFC4862]で説明されているように、リンクローカルアドレスを生成できなければなりません（MUST）。
From RFC 4862:
RFC 4862から：
The autoconfiguration process specified in this document applies only to hosts and not routers. Since host autoconfiguration uses information advertised by routers, routers will need to be configured by some other means. However, it is expected that routers will generate link-local addresses using the mechanism described in this document. In addition, routers are expected to successfully pass the Duplicate Address Detection procedure described in this document on all addresses prior to assigning them to an interface.
このドキュメントで指定されている自動設定プロセスはホストにのみ適用され、ルーターには適用されません。ホストの自動構成はルーターによってアドバタイズされた情報を使用するため、ルーターは他の方法で構成する必要があります。ただし、ルーターは、このドキュメントで説明されているメカニズムを使用してリンクローカルアドレスを生成することが予想されます。さらに、ルーターは、インターフェイスに割り当てる前に、すべてのアドレスについて、このドキュメントで説明されている重複アドレス検出手順に合格する必要があります。
All nodes MUST implement Duplicate Address Detection. Quoting from Section 5.4 of RFC 4862:
すべてのノードは重複アドレス検出を実装する必要があります。 RFC 4862のセクション5.4からの引用：
Duplicate Address Detection MUST be performed on all unicast addresses prior to assigning them to an interface, regardless of whether they are obtained through stateless autoconfiguration, DHCPv6, or manual configuration, with the following exceptions [noted therein].
重複アドレス検出は、ステートレス自動構成、DHCPv6、または手動構成のいずれで取得されたかに関係なく、インターフェイスに割り当てる前にすべてのユニキャストアドレスで実行する必要があります。
"Optimistic Duplicate Address Detection (DAD) for IPv6" [RFC4429] specifies a mechanism to reduce delays associated with generating addresses via Stateless Address Autoconfiguration [RFC4862]. RFC 4429 was developed in conjunction with Mobile IPv6 in order to reduce the time needed to acquire and configure addresses as devices quickly move from one network to another, and it is desirable to minimize transition delays. For general purpose devices, RFC 4429 remains optional at this time.
「IPv6の楽観的重複アドレス検出（DAD）」[RFC4429]は、ステートレスアドレス自動構成[RFC4862]によるアドレス生成に関連する遅延を削減するメカニズムを指定しています。 RFC 4429は、デバイスが1つのネットワークから別のネットワークにすばやく移動するときにアドレスを取得および構成するために必要な時間を短縮するためにモバイルIPv6と組み合わせて開発され、移行の遅延を最小限に抑えることが望まれます。汎用デバイスの場合、現時点ではRFC 4429はオプションのままです。
[RFC7527] discusses enhanced DAD and describes an algorithm to automate the detection of looped-back IPv6 ND messages used by DAD. Nodes SHOULD implement this behavior where such detection is beneficial.
[RFC7527]では、拡張DADについて説明し、DADで使用されるループバックIPv6 NDメッセージの検出を自動化するアルゴリズムについて説明しています。ノードは、このような検出が有益な場合にこの動作を実装する必要があります（SHOULD）。
A node using Stateless Address Autoconfiguration [RFC4862] to form a globally unique IPv6 address that uses its MAC address to generate the IID will see that the IID remains the same on any visited network, even though the network prefix part changes. Thus, it is possible for a third-party device to track the activities of the node they communicate with, as that node moves around the network. Privacy Extensions for Stateless Address Autoconfiguration [RFC4941] address this concern by allowing nodes to configure an additional temporary address where the IID is effectively randomly generated. Privacy addresses are then used as source addresses for new communications initiated by the node.
ステートレスアドレス自動構成[RFC4862]を使用して、MACアドレスを使用してIIDを生成するグローバルに一意のIPv6アドレスを形成するノードは、ネットワークプレフィックス部分が変更されても、訪問先ネットワークでIIDが同じままであることを確認します。したがって、ノードがネットワーク上を移動するときに、サードパーティのデバイスが通信するノードのアクティビティを追跡することが可能です。ステートレスアドレス自動構成のプライバシー拡張[RFC4941]は、IIDが効果的にランダムに生成される追加の一時アドレスをノードが構成できるようにすることで、この問題に対処します。プライバシーアドレスは、ノードによって開始された新しい通信の送信元アドレスとして使用されます。
General issues regarding privacy issues for IPv6 addressing are discussed in [RFC7721].
IPv6アドレッシングのプライバシー問題に関する一般的な問題は、[RFC7721]で説明されています。
RFC 4941 SHOULD be supported. In some scenarios, such as dedicated servers in a data center, it provides limited or no benefit, or it may complicate network management. Thus, devices implementing this specification MUST provide a way for the end user to explicitly enable or disable the use of such temporary addresses.
RFC 4941をサポートする必要があります（SHOULD）。データセンター内の専用サーバーなどの一部のシナリオでは、メリットが限定的またはまったくないか、ネットワーク管理が複雑になる場合があります。したがって、この仕様を実装するデバイスは、エンドユーザーがそのような一時アドレスの使用を明示的に有効または無効にする方法を提供する必要があります。
Note that RFC 4941 can be used independently of traditional SLAAC or independently of SLAAC that is based on RFC 7217.
RFC 4941は、従来のSLAACとは関係なく、またはRFC 7217に基づくSLAACとは関係なく使用できることに注意してください。
Implementers of RFC 4941 should be aware that certain addresses are reserved and should not be chosen for use as temporary addresses. Consult "Reserved IPv6 Interface Identifiers" [RFC5453] for more details.
RFC 4941の実装者は、特定のアドレスが予約されており、一時アドレスとして使用するために選択されるべきではないことに注意する必要があります。詳細については、「予約済みIPv6インターフェース識別子」[RFC5453]を参照してください。
DHCPv6 [RFC3315] can be used to obtain and configure addresses. In general, a network may provide for the configuration of addresses through SLAAC, DHCPv6, or both. There will be a wide range of IPv6 deployment models and differences in address assignment requirements, some of which may require DHCPv6 for stateful address assignment. Consequently, all hosts SHOULD implement address configuration via DHCPv6.
DHCPv6 [RFC3315]を使用して、アドレスを取得および構成できます。一般に、ネットワークは、SLAAC、DHCPv6、またはその両方を介してアドレスの構成を提供できます。さまざまなIPv6展開モデルとアドレス割り当て要件の違いがあり、そのうちのいくつかはステートフルアドレス割り当てにDHCPv6を必要とする場合があります。したがって、すべてのホストはDHCPv6を介してアドレス構成を実装する必要があります（SHOULD）。
In the absence of observed Router Advertisement messages, IPv6 nodes MAY initiate DHCP to obtain IPv6 addresses and other configuration information, as described in Section 5.5.2 of [RFC4862].
[RFC4862]のセクション5.5.2で説明されているように、ルーターアドバタイズメッセージが観察されない場合、IPv6ノードはDHCPを開始してIPv6アドレスとその他の構成情報を取得できます。
Where devices are likely to be carried by users and attached to multiple visited networks, DHCPv6 client anonymity profiles SHOULD be supported as described in [RFC7844] to minimize the disclosure of identifying information. Section 5 of RFC 7844 describes operational considerations on the use of such anonymity profiles.
デバイスがユーザーによって運ばれ、複数の訪問先ネットワークに接続されている可能性がある場合、識別情報の開示を最小限に抑えるために、[RFC7844]で説明されているようにDHCPv6クライアント匿名プロファイルをサポートする必要があります。 RFC 7844のセクション5では、このような匿名プロファイルの使用に関する運用上の考慮事項について説明しています。
IPv6 nodes will invariably have multiple addresses configured simultaneously and thus will need to choose which addresses to use for which communications. The rules specified in the Default Address Selection for IPv6 document [RFC6724] MUST be implemented. [RFC8028] updates Rule 5.5 from [RFC6724]; implementations SHOULD implement this rule.
IPv6ノードは常に複数のアドレスを同時に構成するため、どの通信にどのアドレスを使用するかを選択する必要があります。 IPv6ドキュメントのデフォルトアドレス選択[RFC6724]で指定されたルールを実装する必要があります。 [RFC8028]は、[RFC6724]からRule 5.5を更新します。実装はこのルールを実装する必要があります（SHOULD）。
DNS is described in [RFC1034], [RFC1035], [RFC3363], and [RFC3596]. Not all nodes will need to resolve names; those that will never need to resolve DNS names do not need to implement resolver functionality. However, the ability to resolve names is a basic infrastructure capability on which applications rely, and most nodes will need to provide support. All nodes SHOULD implement stub-resolver [RFC1034] functionality, as in Section 5.3.1 of [RFC1034], with support for:
DNSは、[RFC1034]、[RFC1035]、[RFC3363]、および[RFC3596]で説明されています。すべてのノードが名前を解決する必要があるわけではありません。 DNS名を解決する必要がないものは、リゾルバー機能を実装する必要はありません。ただし、名前を解決する機能は、アプリケーションが依存する基本的なインフラストラクチャ機能であり、ほとんどのノードがサポートを提供する必要があります。すべてのノードは、[RFC1034]のセクション5.3.1にあるように、以下をサポートするスタブリゾルバー[RFC1034]機能を実装する必要があります（SHOULD）。
- AAAA type Resource Records [RFC3596];
- AAAAタイプのリソースレコード[RFC3596];
- reverse addressing in ip6.arpa using PTR records [RFC3596]; and
- PTRレコード[RFC3596]を使用したip6.arpaでの逆アドレッシング。そして
- Extension Mechanisms for DNS (EDNS(0)) [RFC6891] to allow for DNS packet sizes larger than 512 octets.
- DNSの拡張メカニズム（EDNS（0））[RFC6891]は、512オクテットより大きいDNSパケットサイズを許可します。
Those nodes are RECOMMENDED to support DNS security extensions [RFC4033] [RFC4034] [RFC4035].
これらのノードは、DNSセキュリティ拡張[RFC4033] [RFC4034] [RFC4035]をサポートするために推奨されています。
A6 Resource Records [RFC2874] are classified as Historic per [RFC6563]. These were defined with Experimental status in [RFC3363].
A6リソースレコード[RFC2874]は、[RFC6563]に従って履歴に分類されます。これらは、[RFC3363]の実験ステータスで定義されました。
DHCP [RFC3315] specifies a mechanism for IPv6 nodes to obtain address configuration information (see Section 6.5) and to obtain additional (non-address) configuration. If a host implementation supports applications or other protocols that require configuration that is only available via DHCP, hosts SHOULD implement DHCP. For specialized devices on which no such configuration need is present, DHCP may not be necessary.
DHCP [RFC3315]は、IPv6ノードがアドレス構成情報（セクション6.5を参照）を取得し、追加（非アドレス）構成を取得するためのメカニズムを指定します。ホスト実装が、DHCP経由でのみ利用可能な構成を必要とするアプリケーションまたは他のプロトコルをサポートする場合、ホストはDHCPを実装する必要があります（SHOULD）。このような構成が不要な特殊なデバイスの場合、DHCPは必要ない場合があります。
An IPv6 node can use the subset of DHCP (described in [RFC3736]) to obtain other configuration information.
IPv6ノードはDHCP（[RFC3736]で説明）のサブセットを使用して、他の構成情報を取得できます。
If an IPv6 node implements DHCP, it MUST implement the DNS options [RFC3646] as most deployments will expect that these options are available.
IPv6ノードがDHCPを実装する場合、ほとんどの展開ではこれらのオプションが使用可能であると想定しているため、DNSオプション[RFC3646]を実装する必要があります。
There is no defined DHCPv6 Gateway option.
定義されたDHCPv6ゲートウェイオプションはありません。
Nodes using the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) are thus expected to determine their default router information and on-link prefix information from received Router Advertisements.
したがって、IPv6の動的ホスト構成プロトコル（DHCPv6）を使用するノードは、受信したルーターアドバタイズメントからデフォルトのルーター情報とオンリンクプレフィックス情報を決定することが期待されています。
Router Advertisement options have historically been limited to those that are critical to basic IPv6 functionality. Originally, DNS configuration was not included as an RA option, and DHCP was the recommended way to obtain DNS configuration information. Over time, the thinking surrounding such an option has evolved. It is now generally recognized that few nodes can function adequately without having access to a working DNS resolver; thus, a Standards Track document has been published to provide this capability [RFC8106].
ルーターアドバタイズメントオプションは、これまで、基本的なIPv6機能に不可欠なオプションに限定されていました。当初、DNS構成はRAオプションとして含まれていなかったため、DNS構成情報を取得する方法としてDHCPが推奨されていました。時間の経過とともに、そのようなオプションを取り巻く考え方は進化してきました。現在、機能しているDNSリゾルバーにアクセスしなくても適切に機能できるノードはほとんどないことが一般的に認識されています。したがって、この機能を提供するための標準化過程文書が公開されています[RFC8106]。
Implementations MUST include support for the DNS RA option [RFC8106].
実装には、DNS RAオプション[RFC8106]のサポートを含める必要があります。
8.4. DHCP Options versus Router Advertisement Options for Host Configuration
8.4. ホスト構成のDHCPオプションとルーターアドバタイズメントオプション
In IPv6, there are two main protocol mechanisms for propagating configuration information to hosts: RAs and DHCP. RA options have been restricted to those deemed essential for basic network functioning and for which all nodes are configured with exactly the same information. Examples include the Prefix Information Options, the MTU option, etc. On the other hand, DHCP has generally been preferred for configuration of more general parameters and for parameters that may be client specific. Generally speaking, however, there has been a desire to define only one mechanism for configuring a given option, rather than defining multiple (different) ways of configuring the same information.
IPv6では、構成情報をホストに伝達するための2つの主要なプロトコルメカニズム、RAとDHCPがあります。 RAオプションは、基本的なネットワーク機能に不可欠と見なされ、すべてのノードがまったく同じ情報で構成されているものに制限されています。例としては、プレフィックス情報オプション、MTUオプションなどがあります。一方、DHCPは、一般的に、より一般的なパラメーターの構成や、クライアント固有のパラメーターに適しています。ただし、一般的に言えば、同じ情報を構成する複数の（異なる）方法を定義するのではなく、特定のオプションを構成するメカニズムを1つだけ定義したいという要望がありました。
One issue with having multiple ways to configure the same information is that interoperability suffers if a host chooses one mechanism but the network operator chooses a different mechanism. For "closed" environments, where the network operator has significant influence over what devices connect to the network and thus what configuration mechanisms they support, the operator may be able to ensure that a particular mechanism is supported by all connected hosts. In more open environments, however, where arbitrary devices may connect (e.g., a Wi-Fi hotspot), problems can arise. To maximize interoperability in such environments, hosts would need to implement multiple configuration mechanisms to ensure interoperability.
同じ情報を複数の方法で構成する場合の問題の1つは、ホストが1つのメカニズムを選択し、ネットワークオペレーターが別のメカニズムを選択すると、相互運用性が低下することです。ネットワークオペレーターがネットワークに接続するデバイス、つまりサポートする構成メカニズムに大きな影響を与える「クローズド」環境の場合、オペレーターは、接続されているすべてのホストが特定のメカニズムをサポートしていることを確認できる場合があります。ただし、よりオープンな環境では、任意のデバイスが接続する可能性がある場合（Wi-Fiホットスポットなど）、問題が発生する可能性があります。このような環境で相互運用性を最大化するには、ホストは相互運用性を保証するために複数の構成メカニズムを実装する必要があります。
Multicast DNS (mDNS) and DNS-based Service Discovery (DNS-SD) are described in [RFC6762] and [RFC6763], respectively. These protocols, often collectively referred to as the 'Bonjour' protocols after their naming by Apple, provide the means for devices to discover services within a local link and, in the absence of a unicast DNS service, to exchange naming information.
マルチキャストDNS（mDNS）およびDNSベースのサービス検出（DNS-SD）は、それぞれ[RFC6762]および[RFC6763]で説明されています。これらのプロトコルは、Appleによって命名された後にまとめて「Bonjour」プロトコルと呼ばれることが多く、デバイスがローカルリンク内のサービスを発見し、ユニキャストDNSサービスがない場合は命名情報を交換する手段を提供します。
Where devices are to be deployed in networks where service discovery would be beneficial, e.g., for users seeking to discover printers or display devices, mDNS and DNS-SD SHOULD be supported.
プリンターやディスプレイデバイスを発見しようとしているユーザーなど、サービスディスカバリが有益なネットワークにデバイスを導入する場合は、mDNSとDNS-SDをサポートする必要があります（SHOULD）。
IPv6 nodes MAY support IPv4.
IPv6ノードはIPv4をサポートする場合があります。
10.1.1. Basic Transition Mechanisms for IPv6 Hosts and Routers - RFC 4213
10.1.1. IPv6ホストおよびルーターの基本的な移行メカニズム-RFC 4213
If an IPv6 node implements dual stack and tunneling, then [RFC4213] MUST be supported.
IPv6ノードがデュアルスタックとトンネリングを実装する場合、[RFC4213]をサポートする必要があります。
Software that allows users and operators to input IPv6 addresses in text form SHOULD support "A Recommendation for IPv6 Address Text Representation" [RFC5952].
ユーザーとオペレーターがテキスト形式でIPv6アドレスを入力できるようにするソフトウェアは、「IPv6アドレスのテキスト表現に関する推奨事項」[RFC5952]をサポートする必要があります（SHOULD）。
There are a number of IPv6-related APIs. This document does not mandate the use of any, because the choice of API does not directly relate to on-the-wire behavior of protocols. Implementers, however, would be advised to consider providing a common API or reviewing existing APIs for the type of functionality they provide to applications.
IPv6関連のAPIは多数あります。 APIの選択はプロトコルのネットワーク上での動作に直接関係しないため、このドキュメントではいずれの使用も義務付けていません。ただし、実装者は、アプリケーションに提供する機能のタイプについて、共通のAPIを提供するか、既存のAPIを確認することを検討することをお勧めします。
"Basic Socket Interface Extensions for IPv6" [RFC3493] provides IPv6 functionality used by typical applications. Implementers should note that RFC 3493 has been picked up and further standardized by the Portable Operating System Interface (POSIX) [POSIX].
「IPv6の基本ソケットインターフェイス拡張」[RFC3493]は、一般的なアプリケーションで使用されるIPv6機能を提供します。実装者は、RFC 3493が採用され、ポータブルオペレーティングシステムインターフェイス（POSIX）[POSIX]によってさらに標準化されていることに注意する必要があります。
"Advanced Sockets Application Program Interface (API) for IPv6" [RFC3542] provides access to advanced IPv6 features needed by diagnostic and other more specialized applications.
「IPv6用のAdvanced Sockets Application Program Interface（API）」[RFC3542]は、診断およびその他のより専門的なアプリケーションに必要な高度なIPv6機能へのアクセスを提供します。
"IPv6 Socket API for Source Address Selection" [RFC5014] provides facilities that allow an application to override the default Source Address Selection rules of [RFC6724].
「送信元アドレス選択用のIPv6ソケットAPI」[RFC5014]は、アプリケーションが[RFC6724]のデフォルトの送信元アドレス選択規則を上書きできるようにする機能を提供します。
"Socket Interface Extensions for Multicast Source Filters" [RFC3678] provides support for expressing source filters on multicast group memberships.
「マルチキャストソースフィルターのソケットインターフェイス拡張」[RFC3678]は、マルチキャストグループメンバーシップでソースフィルターを表現するためのサポートを提供します。
"Extension to Sockets API for Mobile IPv6" [RFC4584] provides application support for accessing and enabling Mobile IPv6 [RFC6275] features.
「モバイルIPv6用のソケットAPIの拡張」[RFC4584]は、モバイルIPv6 [RFC6275]機能にアクセスして有効にするためのアプリケーションサポートを提供します。
Mobile IPv6 [RFC6275] and associated specifications [RFC3776] [RFC4877] allow a node to change its point of attachment within the Internet, while maintaining (and using) a permanent address. All communication using the permanent address continues to proceed as expected even as the node moves around. The definition of Mobile IP includes requirements for the following types of nodes:
モバイルIPv6 [RFC6275]と関連する仕様[RFC3776] [RFC4877]を使用すると、永続的なアドレスを維持（および使用）しながら、ノードがインターネット内の接続ポイントを変更できます。パーマネントアドレスを使用するすべての通信は、ノードが移動しても期待どおりに続行されます。モバイルIPの定義には、次のタイプのノードの要件が含まれています。
- mobile nodes
- モバイルノード
- correspondent nodes with support for route optimization
- ルート最適化をサポートするコレスポンデントノード
- home agents
- ホームエージェント
- all IPv6 routers
- すべてのIPv6ルーター
At the present time, Mobile IP has seen only limited implementation and no significant deployment, partly because it originally assumed an IPv6-only environment rather than a mixed IPv4/IPv6 Internet. Additional work has been done to support mobility in mixed-mode IPv4 and IPv6 networks [RFC5555].
現時点では、モバイルIPは実装が限られており、大きな展開は見られません。これは、もともとIPv4 / IPv6混合インターネットではなくIPv6のみの環境を想定していたためです。混合モードのIPv4およびIPv6ネットワークでのモビリティをサポートするために、追加の作業が行われています[RFC5555]。
More usage and deployment experience is needed with mobility before any specific approach can be recommended for broad implementation in all hosts and routers. Consequently, Mobility Support in IPv6 [RFC6275], Mobile IPv6 Support for Dual Stack Hosts and Routers [RFC5555], and associated standards (such as Mobile IPv6 with IKEv2 and IPsec [RFC4877]) are considered a MAY at this time.
すべてのホストとルーターで幅広い実装を行うために特定のアプローチを推奨する前に、モビリティでより多くの使用と展開の経験が必要です。その結果、IPv6でのモビリティサポート[RFC6275]、デュアルスタックホストとルーターのモバイルIPv6サポート[RFC5555]、および関連する標準（IKEv2とモバイルIPv6とIPsec [RFC4877]など）は、現時点ではMAYと見なされます。
IPv6 for 3GPP [RFC7066] lists a snapshot of required IPv6 functionalities at the time the document was published that would need to be implemented, going above and beyond the recommendations in this document. Additionally, a 3GPP IPv6 Host MAY implement [RFC7278] to deliver IPv6 prefixes on the LAN link.
IPv6 for 3GPP [RFC7066]は、このドキュメントの推奨事項を超えて実装する必要がある、ドキュメントの公開時に必要なIPv6機能のスナップショットを示しています。さらに、3GPP IPv6ホストは、LANリンクでIPv6プレフィックスを配信するために[RFC7278]を実装してもよい（MAY）。
This section describes the security specification for IPv6 nodes.
このセクションでは、IPv6ノードのセキュリティ仕様について説明します。
Achieving security in practice is a complex undertaking. Operational procedures, protocols, key distribution mechanisms, certificate management approaches, etc., are all components that impact the level of security actually achieved in practice. More importantly, deficiencies or a poor fit in any one individual component can significantly reduce the overall effectiveness of a particular security approach.
実際にセキュリティを実現することは複雑な作業です。操作手順、プロトコル、キー配布メカニズム、証明書管理アプローチなどはすべて、実際に実際に達成されるセキュリティのレベルに影響を与えるコンポーネントです。さらに重要なことは、個々のコンポーネントの欠陥や適合性が低いと、特定のセキュリティアプローチの全体的な効果が大幅に低下する可能性があることです。
IPsec can provide either end-to-end security between nodes or channel security (for example, via a site-to-site IPsec VPN), making it possible to provide secure communication for all (or a subset of) communication flows at the IP layer between pairs of Internet nodes. IPsec has two standard operating modes: Tunnel-mode and Transport-mode. In Tunnel-mode, IPsec provides network-layer security and protects an entire IP packet by encapsulating the original IP packet and then prepending a new IP header. In Transport-mode, IPsec provides security for the transport layer (and above) by encapsulating only the transport-layer (and above) portion of the IP packet (i.e., without adding a second IP header).
IPsecは、ノード間のエンドツーエンドのセキュリティまたはチャネルのセキュリティ（たとえば、サイト間IPsec VPNを介して）を提供し、IPですべての（またはそのサブセットの）通信フローに安全な通信を提供できるようにします。インターネットノードのペア間のレイヤー。 IPsecには、トンネルモードとトランスポートモードの2つの標準動作モードがあります。トンネルモードでは、IPsecはネットワーク層のセキュリティを提供し、元のIPパケットをカプセル化してから新しいIPヘッダーを付加することにより、IPパケット全体を保護します。トランスポートモードでは、IPsecは、IPパケットのトランスポート層（およびそれ以上）部分のみをカプセル化することにより（つまり、2番目のIPヘッダーを追加せずに）、トランスポート層（およびそれ以上）にセキュリティを提供します。
Although IPsec can be used with manual keying in some cases, such usage has limited applicability and is not recommended.
IPsecは手動のキーイングで使用できる場合もありますが、そのような使用法には適用範囲に制限があるため、お勧めできません。
A range of security technologies and approaches proliferate today (e.g., IPsec, Transport Layer Security (TLS), Secure SHell (SSH), TLS VPNS, etc.). No single approach has emerged as an ideal technology for all needs and environments. Moreover, IPsec is not viewed as the ideal security technology in all cases and is unlikely to displace the others.
今日、さまざまなセキュリティテクノロジーとアプローチが急増しています（IPsec、トランスポート層セキュリティ（TLS）、セキュアシェル（SSH）、TLS VPNSなど）。すべてのニーズと環境にとって理想的なテクノロジーとして、単一のアプローチが出現したわけではありません。さらに、IPsecはすべてのケースで理想的なセキュリティテクノロジーとは見なされておらず、他のケースに取って代わることはほとんどありません。
Previously, IPv6 mandated implementation of IPsec and recommended the key-management approach of IKE. RFC 6434 updated that recommendation by making support of the IPsec architecture [RFC4301] a SHOULD for all IPv6 nodes, and this document retains that recommendation. Note that the IPsec Architecture requires the implementation of both manual and automatic key management (e.g., Section 4.5 of RFC 4301). Currently, the recommended automated key-management protocol to implement is IKEv2 [RFC7296].
以前は、IPv6ではIPsecの実装が必須であり、IKEのキー管理アプローチが推奨されていました。 RFC 6434は、IPsecアーキテクチャ[RFC4301]のサポートをすべてのIPv6ノードのSHOULDにすることにより、その推奨事項を更新しました。このドキュメントは、その推奨事項を保持しています。 IPsecアーキテクチャでは、手動と自動の両方のキー管理を実装する必要があることに注意してください（たとえば、RFC 4301のセクション4.5）。現在、実装に推奨される自動キー管理プロトコルはIKEv2 [RFC7296]です。
This document recognizes that there exists a range of device types and environments where approaches to security other than IPsec can be justified. For example, special-purpose devices may support only a very limited number or type of applications, and an application-specific security approach may be sufficient for limited management or configuration capabilities. Alternatively, some devices may run on extremely constrained hardware (e.g., sensors) where the full IPsec Architecture is not justified.
このドキュメントは、IPsec以外のセキュリティへのアプローチを正当化できるさまざまなデバイスタイプと環境が存在することを認識しています。たとえば、専用デバイスは非常に限られた数またはタイプのアプリケーションのみをサポートする場合があり、アプリケーション固有のセキュリティアプローチは、限られた管理または構成機能には十分である場合があります。または、一部のデバイスは、完全なIPsecアーキテクチャが正当化されていない、非常に制約されたハードウェア（センサーなど）で実行される場合があります。
Because most common platforms now support IPv6 and have it enabled by default, IPv6 security is an issue for networks that are ostensibly IPv4 only; see [RFC7123] for guidance on this area.
ほとんどの一般的なプラットフォームでIPv6がサポートされ、デフォルトで有効になっているため、IPv6のセキュリティは、表面上はIPv4のみであるネットワークの問題です。この領域のガイダンスについては[RFC7123]を参照してください。
"Security Architecture for the Internet Protocol" [RFC4301] SHOULD be supported by all IPv6 nodes. Note that the IPsec Architecture requires the implementation of both manual and automatic key management (e.g., Section 4.5 of [RFC4301]). Currently, the default automated key-management protocol to implement is IKEv2. As required in [RFC4301], IPv6 nodes implementing the IPsec Architecture MUST implement ESP [RFC4303] and MAY implement AH [RFC4302].
「インターネットプロトコルのセキュリティアーキテクチャ」[RFC4301]は、すべてのIPv6ノードでサポートされる必要があります（SHOULD）。 IPsecアーキテクチャでは、手動と自動の両方の鍵管理を実装する必要があることに注意してください（[RFC4301]のセクション4.5など）。現在、実装するデフォルトの自動キー管理プロトコルはIKEv2です。 [RFC4301]で要求されているように、IPsecアーキテクチャを実装するIPv6ノードはESP [RFC4303]を実装しなければならず（MUST）、AH [RFC4302]を実装してもよい（MAY）。
The current set of mandatory-to-implement algorithms for the IPsec Architecture are defined in Cryptographic Algorithm Implementation Requirements for ESP and AH [RFC8221]. IPv6 nodes implementing the IPsec Architecture MUST conform to the requirements in [RFC8221]. Preferred cryptographic algorithms often change more frequently than security protocols. Therefore, implementations MUST allow for migration to new algorithms, as RFC 8221 is replaced or updated in the future.
IPsecアーキテクチャの必須から実装までのアルゴリズムの現在のセットは、ESPおよびAHの暗号化アルゴリズム実装要件[RFC8221]で定義されています。 IPsecアーキテクチャを実装するIPv6ノードは、[RFC8221]の要件に準拠する必要があります。多くの場合、好ましい暗号化アルゴリズムは、セキュリティプロトコルよりも頻繁に変更されます。したがって、RFC 8221は将来的に置換または更新されるため、実装では新しいアルゴリズムへの移行を許可する必要があります。
The current set of mandatory-to-implement algorithms for IKEv2 are defined in Cryptographic Algorithm Implementation Requirements for ESP and AH [RFC8247]. IPv6 nodes implementing IKEv2 MUST conform to the requirements in [RFC8247] and/or any future updates or replacements to [RFC8247].
IKEv2の必須から実装までのアルゴリズムの現在のセットは、ESPおよびAHの暗号化アルゴリズム実装要件[RFC8247]で定義されています。 IKEv2を実装するIPv6ノードは、[RFC8247]の要件および/または[RFC8247]の将来の更新または置き換えに準拠する必要があります。
This section defines general host considerations for IPv6 nodes that act as routers. Currently, this section does not discuss detailed routing-specific requirements. For the case of typical home routers, [RFC7084] defines basic requirements for customer edge routers.
このセクションでは、ルーターとして機能するIPv6ノードのホストに関する一般的な考慮事項を定義します。現在、このセクションでは、ルーティング固有の詳細な要件については説明していません。一般的なホームルーターの場合、[RFC7084]はカスタマーエッジルーターの基本的な要件を定義しています。
The IPv6 Router Alert option [RFC2711] is an optional IPv6 Hop-by-Hop Header that is used in conjunction with some protocols (e.g., RSVP [RFC2205] or Multicast Listener Discovery (MLDv2) [RFC3810]). The Router Alert option will need to be implemented whenever such protocols that mandate its use are implemented. See Section 5.11.
IPv6ルーターアラートオプション[RFC2711]は、一部のプロトコル（RSVP [RFC2205]またはマルチキャストリスナーディスカバリ（MLDv2）[RFC3810]など）と共に使用されるオプションのIPv6ホップバイホップヘッダーです。ルーターアラートオプションは、その使用を義務付けるプロトコルが実装されている場合は常に実装する必要があります。セクション5.11を参照してください。
Sending Router Advertisements and processing Router Solicitations MUST be supported.
ルーター広告の送信とルーター要請の処理をサポートする必要があります。
Section 7 of [RFC6275] includes some mobility-specific extensions to Neighbor Discovery. Routers SHOULD implement Sections 7.3 and 7.5, even if they do not implement home agent functionality.
[RFC6275]のセクション7には、近隣探索に対するモビリティ固有の拡張機能が含まれています。ルータは、ホームエージェント機能を実装していなくても、セクション7.3および7.5を実装する必要があります（SHOULD）。
A single DHCP server ([RFC3315] or [RFC4862]) can provide configuration information to devices directly attached to a shared link, as well as to devices located elsewhere within a site. Communication between a client and a DHCP server located on different links requires the use of DHCP relay agents on routers.
単一のDHCPサーバー（[RFC3315]または[RFC4862]）は、共有リンクに直接接続されているデバイスや、サイト内の他の場所にあるデバイスに構成情報を提供できます。異なるリンクにあるクライアントとDHCPサーバー間の通信には、ルーターでDHCPリレーエージェントを使用する必要があります。
In simple deployments, consisting of a single router and either a single LAN or multiple LANs attached to the single router, together with a WAN connection, a DHCP server embedded within the router is one common deployment scenario (e.g., [RFC7084]). There is no need for relay agents in such scenarios.
単一のルーターと、単一のルーターまたは単一のルーターに接続された複数のLANのいずれかとWAN接続で構成される単純な展開では、ルーター内に埋め込まれたDHCPサーバーが1つの一般的な展開シナリオです（たとえば、[RFC7084]）。このようなシナリオでは、リレーエージェントは必要ありません。
In more complex deployment scenarios, such as within enterprise or service provider networks, the use of DHCP requires some level of configuration, in order to configure relay agents, DHCP servers, etc. In such environments, the DHCP server might even be run on a traditional server, rather than as part of a router.
企業やサービスプロバイダーのネットワーク内など、より複雑な展開シナリオでは、DHCPを使用するには、リレーエージェントやDHCPサーバーなどを構成するために、ある程度のレベルの構成が必要です。このような環境では、DHCPサーバーはルーターの一部としてではなく、従来のサーバー。
Because of the wide range of deployment scenarios, support for DHCP server functionality on routers is optional. However, routers targeted for deployment within more complex scenarios (as described above) SHOULD support relay agent functionality. Note that "Basic Requirements for IPv6 Customer Edge Routers" [RFC7084] requires implementation of a DHCPv6 server function in IPv6 Customer Edge (CE) routers.
展開シナリオは多岐にわたるため、ルーターでのDHCPサーバー機能のサポートはオプションです。ただし、より複雑なシナリオ（上記で説明）内での展開を対象とするルーターは、リレーエージェント機能をサポートする必要があります（SHOULD）。 「IPv6カスタマーエッジルーターの基本要件」[RFC7084]では、IPv6カスタマーエッジ（CE）ルーターにDHCPv6サーバー機能を実装する必要があることに注意してください。
Forwarding nodes MUST conform to BCP 198 [RFC7608]; thus, IPv6 implementations of nodes that may forward packets MUST conform to the rules specified in Section 5.1 of [RFC4632].
転送ノードはBCP 198 [RFC7608]に準拠する必要があります。したがって、パケットを転送する可能性のあるノードのIPv6実装は、[RFC4632]のセクション5.1で指定されたルールに準拠する必要があります。
The focus of this document is general IPv6 nodes. In this section, we briefly discuss considerations for constrained devices.
このドキュメントの焦点は、一般的なIPv6ノードです。このセクションでは、制約付きデバイスの考慮事項について簡単に説明します。
In the case of constrained nodes, with limited CPU, memory, bandwidth or power, support for certain IPv6 functionality may need to be considered due to those limitations. While the requirements of this document are RECOMMENDED for all nodes, including constrained nodes, compromises may need to be made in certain cases. Where such compromises are made, the interoperability of devices should be strongly considered, particularly where this may impact other nodes on the same link, e.g., only supporting MLDv1 will affect other nodes.
CPU、メモリ、帯域幅、または電力が制限されている制約されたノードの場合、これらの制限のため、特定のIPv6機能のサポートを検討する必要がある場合があります。このドキュメントの要件は、制約されたノードを含むすべてのノードで推奨されていますが、場合によっては妥協が必要になることがあります。そのような妥協が行われる場合、特にこれが同じリンク上の他のノードに影響を与える可能性がある場合など、デバイスの相互運用性を強く考慮する必要があります。たとえば、MLDv1のサポートのみが他のノードに影響します。
The IETF 6LowPAN (IPv6 over Low-Power Wireless Personal Area Network) WG produced six RFCs, including a general overview and problem statement [RFC4919] (the means by which IPv6 packets are transmitted over IEEE 802.15.4 networks [RFC4944] and ND optimizations for that medium [RFC6775]).
IETF 6LowPAN（低電力ワイヤレスパーソナルエリアネットワーク上のIPv6）WGは、一般的な概要と問題の説明[RFC4919]（IEEE 802.15.4ネットワーク[RFC4944]を介してIPv6パケットが送信される手段とND最適化を含む）を含む6つのRFCを作成しましたその媒体のため[RFC6775]）。
IPv6 nodes that are battery powered SHOULD implement the recommendations in [RFC7772].
バッテリー駆動のIPv6ノードは、[RFC7772]の推奨事項を実装する必要があります（SHOULD）。
Network management MAY be supported by IPv6 nodes. However, for IPv6 nodes that are embedded devices, network management may be the only possible way of controlling these nodes.
ネットワーク管理は、IPv6ノードでサポートされる場合があります。ただし、組み込みデバイスであるIPv6ノードの場合、ネットワーク管理がこれらのノードを制御する唯一の可能な方法である可能性があります。
Existing network management protocols include SNMP [RFC3411], NETCONF [RFC6241], and RESTCONF [RFC8040].
既存のネットワーク管理プロトコルには、SNMP [RFC3411]、NETCONF [RFC6241]、およびRESTCONF [RFC8040]が含まれます。
The obsoleted status of various IPv6-specific MIB modules is clarified in [RFC8096].
さまざまなIPv6固有のMIBモジュールの廃止されたステータスは、[RFC8096]で明確にされています。
The following two MIB modules SHOULD be supported by nodes that support an SNMP agent.
以下の2つのMIBモジュールは、SNMPエージェントをサポートするノードによってサポートされるべきです（SHOULD）。
The IP Forwarding Table MIB [RFC4292] SHOULD be supported by nodes that support an SNMP agent.
IP転送テーブルMIB [RFC4292]は、SNMPエージェントをサポートするノードによってサポートされるべきです（SHOULD）。
The IP MIB [RFC4293] SHOULD be supported by nodes that support an SNMP agent.
IP MIB [RFC4293]は、SNMPエージェントをサポートするノードによってサポートされるべきです（SHOULD）。
The Interface MIB [RFC2863] SHOULD be supported by nodes that support an SNMP agent.
インターフェイスMIB [RFC2863]は、SNMPエージェントをサポートするノードによってサポートされるべきです（SHOULD）。
The following YANG data models SHOULD be supported by nodes that support a NETCONF or RESTCONF agent.
次のYANGデータモデルは、NETCONFまたはRESTCONFエージェントをサポートするノードによってサポートされる必要があります（SHOULD）。
The IP Management YANG Model [RFC8344] SHOULD be supported by nodes that support NETCONF or RESTCONF.
IP管理YANGモデル[RFC8344]は、NETCONFまたはRESTCONFをサポートするノードによってサポートされる必要があります（SHOULD）。
The Interface Management YANG Model [RFC8343] SHOULD be supported by nodes that support NETCONF or RESTCONF.
インターフェース管理YANGモデル[RFC8343]は、NETCONFまたはRESTCONFをサポートするノードによってサポートされる必要があります（SHOULD）。
This document does not directly affect the security of the Internet, beyond the security considerations associated with the individual protocols.
このドキュメントは、個々のプロトコルに関連するセキュリティの考慮事項を超えて、インターネットのセキュリティに直接影響を与えません。
Security is also discussed in Section 13 above.
セキュリティについては、上記のセクション13でも説明しています。
This document has no IANA actions.
このドキュメントにはIANAアクションはありません。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, <https://www.rfc-editor.org/info/rfc1034>.
[RFC1034] Mockapetris、P。、「ドメイン名-概念と機能」、STD 13、RFC 1034、DOI 10.17487 / RFC1034、1987年11月、<https://www.rfc-editor.org/info/rfc1034>。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC1035] Mockapetris、P。、「ドメイン名-実装および仕様」、STD 13、RFC 1035、DOI 10.17487 / RFC1035、1987年11月、<https://www.rfc-editor.org/info/rfc1035>。
[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>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, DOI 10.17487/RFC2710, October 1999, <https://www.rfc-editor.org/info/rfc2710>.
[RFC2710] Deering、S.、Fenner、W。、およびB. Haberman、「IPv6のマルチキャストリスナーディスカバリ（MLD）」、RFC 2710、DOI 10.17487 / RFC2710、1999年10月、<https：//www.rfc-editor .org / info / rfc2710>。
[RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", RFC 2711, DOI 10.17487/RFC2711, October 1999, <https://www.rfc-editor.org/info/rfc2711>.
[RFC2711] Partridge、C。およびA. Jackson、「IPv6ルーターアラートオプション」、RFC 2711、DOI 10.17487 / RFC2711、1999年10月、<https://www.rfc-editor.org/info/rfc2711>。
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000, <https://www.rfc-editor.org/info/rfc2863>.
[RFC2863] McCloghrie、K。およびF. Kastenholz、「The Interfaces Group MIB」、RFC 2863、DOI 10.17487 / RFC2863、2000年6月、<https://www.rfc-editor.org/info/rfc2863>。
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001, <https://www.rfc-editor.org/info/rfc3168>.
[RFC3168]ラマクリシュナン、K。、フロイド、S。、およびD.ブラック、「IPへの明示的輻輳通知（ECN）の追加」、RFC 3168、DOI 10.17487 / RFC3168、2001年9月、<https：// www。 rfc-editor.org/info/rfc3168>。
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2003, <https://www.rfc-editor.org/info/rfc3315>.
[RFC3315] Droms、R.、Ed。、Bound、J.、Volz、B.、Lemon、T.、Perkins、C.、and M. Carney、 "Dynamic Host Configuration Protocol for IPv6（DHCPv6）"、RFC 3315 、DOI 10.17487 / RFC3315、2003年7月、<https://www.rfc-editor.org/info/rfc3315>。
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, DOI 10.17487/RFC3411, December 2002, <https://www.rfc-editor.org/info/rfc3411>.
[RFC3411] Harrington、D.、Presuhn、R。、およびB. Wijnen、「単純なネットワーク管理プロトコル（SNMP）管理フレームワークを記述するためのアーキテクチャ」、STD 62、RFC 3411、DOI 10.17487 / RFC3411、2002年12月、<https ：//www.rfc-editor.org/info/rfc3411>。
[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS Extensions to Support IP Version 6", STD 88, RFC 3596, DOI 10.17487/RFC3596, October 2003, <https://www.rfc-editor.org/info/rfc3596>.
[RFC3596] Thomson、S.、Huitema、C.、Ksinant、V。、およびM. Souissi、「DNS Extensions to Support IP Version 6」、STD 88、RFC 3596、DOI 10.17487 / RFC3596、2003年10月、<https： //www.rfc-editor.org/info/rfc3596>。
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, DOI 10.17487/RFC3736, April 2004, <https://www.rfc-editor.org/info/rfc3736>.
[RFC3736] Droms、R。、「IPv6のステートレス動的ホスト構成プロトコル（DHCP）サービス」、RFC 3736、DOI 10.17487 / RFC3736、2004年4月、<https://www.rfc-editor.org/info/rfc3736> 。
[RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, DOI 10.17487/RFC3810, June 2004, <https://www.rfc-editor.org/info/rfc3810>.
[RFC3810] Vida、R.、Ed。 L.コスタ編、「IPv6のマルチキャストリスナーディスカバリバージョン2（MLDv2）」、RFC 3810、DOI 10.17487 / RFC3810、2004年6月、<https://www.rfc-editor.org/info/rfc3810>。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, <https://www.rfc-editor.org/info/rfc4033>.
[RFC4033] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNSセキュリティの概要と要件」、RFC 4033、DOI 10.17487 / RFC4033、2005年3月、<https： //www.rfc-editor.org/info/rfc4033>。
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, DOI 10.17487/RFC4034, March 2005, <https://www.rfc-editor.org/info/rfc4034>.
[RFC4034] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNS Security Extensionsのリソースレコード」、RFC 4034、DOI 10.17487 / RFC4034、2005年3月、< https://www.rfc-editor.org/info/rfc4034>。
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, <https://www.rfc-editor.org/info/rfc4035>.
[RFC4035] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNSセキュリティ拡張機能のプロトコル変更」、RFC 4035、DOI 10.17487 / RFC4035、2005年3月、< https://www.rfc-editor.org/info/rfc4035>。
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, DOI 10.17487/RFC4213, October 2005, <https://www.rfc-editor.org/info/rfc4213>.
[RFC4213] Nordmark、E。およびR. Gilligan、「IPv6ホストおよびルーターの基本的な移行メカニズム」、RFC 4213、DOI 10.17487 / RFC4213、2005年10月、<https://www.rfc-editor.org/info/rfc4213 >。
[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>.
[RFC4291] Hinden、R。およびS. Deering、「IPバージョン6アドレッシングアーキテクチャ」、RFC 4291、DOI 10.17487 / RFC4291、2006年2月、<https://www.rfc-editor.org/info/rfc4291>。
[RFC4292] Haberman, B., "IP Forwarding Table MIB", RFC 4292, DOI 10.17487/RFC4292, April 2006, <https://www.rfc-editor.org/info/rfc4292>.
[RFC4292] Haberman、B。、「IP Forwarding Table MIB」、RFC 4292、DOI 10.17487 / RFC4292、2006年4月、<https://www.rfc-editor.org/info/rfc4292>。
[RFC4293] Routhier, S., Ed., "Management Information Base for the Internet Protocol (IP)", RFC 4293, DOI 10.17487/RFC4293, April 2006, <https://www.rfc-editor.org/info/rfc4293>.
[RFC4293] Routhier、S。、編、「インターネットプロトコル（IP）の管理情報ベース」、RFC 4293、DOI 10.17487 / RFC4293、2006年4月、<https://www.rfc-editor.org/info/ rfc4293>。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, <https://www.rfc-editor.org/info/rfc4301>.
[RFC4301] Kent、S。およびK. Seo、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、DOI 10.17487 / RFC4301、2005年12月、<https://www.rfc-editor.org/info/rfc4301>。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, December 2005, <https://www.rfc-editor.org/info/rfc4303>.
[RFC4303]ケント、S。、「IPカプセル化セキュリティペイロード（ESP）」、RFC 4303、DOI 10.17487 / RFC4303、2005年12月、<https://www.rfc-editor.org/info/rfc4303>。
[RFC4311] Hinden, R. and D. Thaler, "IPv6 Host-to-Router Load Sharing", RFC 4311, DOI 10.17487/RFC4311, November 2005, <https://www.rfc-editor.org/info/rfc4311>.
[RFC4311] Hinden、R。およびD. Thaler、「IPv6 Host-to-Router Load Sharing」、RFC 4311、DOI 10.17487 / RFC4311、2005年11月、<https://www.rfc-editor.org/info/rfc4311 >。
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", STD 89, RFC 4443, DOI 10.17487/RFC4443, March 2006, <https://www.rfc-editor.org/info/rfc4443>.
[RFC4443]コンタ、A。、ディアリング、S。、およびM.グプタ編、「インターネットプロトコルバージョン6（IPv6）仕様のインターネット制御メッセージプロトコル（ICMPv6）」、STD 89、RFC 4443、DOI 10.17487 / RFC4443、2006年3月、<https://www.rfc-editor.org/info/rfc4443>。
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, <https://www.rfc-editor.org/info/rfc4607>.
[RFC4607] Holbrook、H。およびB. Cain、「Source-Specific Multicast for IP」、RFC 4607、DOI 10.17487 / RFC4607、2006年8月、<https://www.rfc-editor.org/info/rfc4607>。
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August 2006, <https://www.rfc-editor.org/info/rfc4632>.
[RFC4632] Fuller、V。およびT. Li、「Classless Inter-domain Routing（CIDR）：the Internet Address Assignment and Aggregation Plan」、BCP 122、RFC 4632、DOI 10.17487 / RFC4632、2006年8月、<https：// www.rfc-editor.org/info/rfc4632>。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, <https://www.rfc-editor.org/info/rfc4861>.
[RFC4861] Narten、T.、Nordmark、E.、Simpson、W。、およびH. Soliman、「Neighbor Discovery for IP version 6（IPv6）」、RFC 4861、DOI 10.17487 / RFC4861、2007年9月、<https：/ /www.rfc-editor.org/info/rfc4861>。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007, <https://www.rfc-editor.org/info/rfc4862>.
[RFC4862] Thomson、S.、Narten、T。、およびT. Jinmei、「IPv6 Stateless Address Autoconfiguration」、RFC 4862、DOI 10.17487 / RFC4862、2007年9月、<https://www.rfc-editor.org/info / rfc4862>。
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, <https://www.rfc-editor.org/info/rfc4941>.
[RFC4941] Narten、T.、Draves、R。、およびS. Krishnan、「IPv6のステートレスアドレス自動構成のプライバシー拡張」、RFC 4941、DOI 10.17487 / RFC4941、2007年9月、<https：//www.rfc-editor .org / info / rfc4941>。
[RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation of Type 0 Routing Headers in IPv6", RFC 5095, DOI 10.17487/RFC5095, December 2007, <https://www.rfc-editor.org/info/rfc5095>.
[RFC5095] Abley、J.、Savola、P。、およびG. Neville-Neil、「Deprecation of Type 0 Routing Headers in IPv6」、RFC 5095、DOI 10.17487 / RFC5095、2007年12月、<https：//www.rfc -editor.org/info/rfc5095>。
[RFC5453] Krishnan, S., "Reserved IPv6 Interface Identifiers", RFC 5453, DOI 10.17487/RFC5453, February 2009, <https://www.rfc-editor.org/info/rfc5453>.
[RFC5453] Krishnan、S。、「Reserved IPv6 Interface Identifiers」、RFC 5453、DOI 10.17487 / RFC5453、2009年2月、<https://www.rfc-editor.org/info/rfc5453>。
[RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments", RFC 5722, DOI 10.17487/RFC5722, December 2009, <https://www.rfc-editor.org/info/rfc5722>.
[RFC5722] Krishnan、S。、「Handling of Overlapping IPv6 Fragments」、RFC 5722、DOI 10.17487 / RFC5722、2009年12月、<https://www.rfc-editor.org/info/rfc5722>。
[RFC5790] Liu, H., Cao, W., and H. Asaeda, "Lightweight Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Version 2 (MLDv2) Protocols", RFC 5790, DOI 10.17487/RFC5790, February 2010, <https://www.rfc-editor.org/info/rfc5790>.
[RFC5790] Liu、H.、Cao、W。、およびH. Asaeda、「Lightweight Internet Group Management Protocol Version 3（IGMPv3）and Multicast Listener Discovery Version 2（MLDv2）Protocols」、RFC 5790、DOI 10.17487 / RFC5790、February 2010、<https://www.rfc-editor.org/info/rfc5790>。
[RFC5942] Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes", RFC 5942, DOI 10.17487/RFC5942, July 2010, <https://www.rfc-editor.org/info/rfc5942>.
[RFC5942] Singh、H.、Beebee、W。、およびE. Nordmark、「IPv6サブネットモデル：リンクとサブネットプレフィックス間の関係」、RFC 5942、DOI 10.17487 / RFC5942、2010年7月、<https：// www。 rfc-editor.org/info/rfc5942>。
[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>.
[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> 。
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, <https://www.rfc-editor.org/info/rfc6241>.
[RFC6241] Enns、R。、編、Bjorklund、M。、編、Schoenwaelder、J。、編、およびA. Bierman、編、「Network Configuration Protocol（NETCONF）」、RFC 6241、DOI 10.17487 / RFC6241、2011年6月、<https://www.rfc-editor.org/info/rfc6241>。
[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, "IPv6 Flow Label Specification", RFC 6437, DOI 10.17487/RFC6437, November 2011, <https://www.rfc-editor.org/info/rfc6437>.
[RFC6437] Amante、S.、Carpenter、B.、Jiang、S。、およびJ. Rajahalme、「IPv6 Flow Label Specification」、RFC 6437、DOI 10.17487 / RFC6437、2011年11月、<https：//www.rfc- editor.org/info/rfc6437>。
[RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and M. Bhatia, "A Uniform Format for IPv6 Extension Headers", RFC 6564, DOI 10.17487/RFC6564, April 2012, <https://www.rfc-editor.org/info/rfc6564>.
[RFC6564] Krishnan、S.、Woodyatt、J.、Kline、E.、Hoagland、J.、およびM. Bhatia、「A Uniform Format for IPv6 Extension Headers」、RFC 6564、DOI 10.17487 / RFC6564、April 2012、< https://www.rfc-editor.org/info/rfc6564>。
[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, <https://www.rfc-editor.org/info/rfc6724>.
[RFC6724] Thaler、D.、Ed。、Draves、R.、Matsumoto、A。、およびT. Chown、「インターネットプロトコルバージョン6（IPv6）のデフォルトアドレス選択」、RFC 6724、DOI 10.17487 / RFC6724、2012年9月、<https://www.rfc-editor.org/info/rfc6724>。
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, DOI 10.17487/RFC6762, February 2013, <https://www.rfc-editor.org/info/rfc6762>.
[RFC6762] Cheshire、S。およびM. Krochmal、「マルチキャストDNS」、RFC 6762、DOI 10.17487 / RFC6762、2013年2月、<https://www.rfc-editor.org/info/rfc6762>。
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, <https://www.rfc-editor.org/info/rfc6763>.
[RFC6763] Cheshire、S。およびM. Krochmal、「DNSベースのサービスディスカバリ」、RFC 6763、DOI 10.17487 / RFC6763、2013年2月、<https://www.rfc-editor.org/info/rfc6763>。
[RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. Bormann, "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 6775, DOI 10.17487/RFC6775, November 2012, <https://www.rfc-editor.org/info/rfc6775>.
[RFC6775]シェルビー、Z。、編、チャクラバルティ、S。、ノードマーク、E。、およびC.ボーマン、「ローパワーワイヤレスパーソナルエリアネットワーク（6LoWPANs）を介したIPv6のネイバー探索最適化」、RFC 6775、DOI 10.17487 / RFC6775、2012年11月、<https://www.rfc-editor.org/info/rfc6775>。
[RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/RFC6891, April 2013, <https://www.rfc-editor.org/info/rfc6891>.
[RFC6891] Damas、J.、Graff、M。、およびP. Vixie、「DNSの拡張メカニズム（EDNS（0））」、STD 75、RFC 6891、DOI 10.17487 / RFC6891、2013年4月、<https：// www.rfc-editor.org/info/rfc6891>。
[RFC6946] Gont, F., "Processing of IPv6 "Atomic" Fragments", RFC 6946, DOI 10.17487/RFC6946, May 2013, <https://www.rfc-editor.org/info/rfc6946>.
[RFC6946] Gont、F。、「Processing of IPv6 "Atomic" Fragments」、RFC 6946、DOI 10.17487 / RFC6946、May 2013、<https://www.rfc-editor.org/info/rfc6946>。
[RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing of IPv6 Extension Headers", RFC 7045, DOI 10.17487/RFC7045, December 2013, <https://www.rfc-editor.org/info/rfc7045>.
[RFC7045] Carpenter、B。およびS. Jiang、「IPv6拡張ヘッダーの送信と処理」、RFC 7045、DOI 10.17487 / RFC7045、2013年12月、<https://www.rfc-editor.org/info/rfc7045> 。
[RFC7048] Nordmark, E. and I. Gashinsky, "Neighbor Unreachability Detection Is Too Impatient", RFC 7048, DOI 10.17487/RFC7048, January 2014, <https://www.rfc-editor.org/info/rfc7048>.
[RFC7048] Nordmark、E。およびI. Gashinsky、「Neighbor Unreachability Detection Is Too Inpatient」、RFC 7048、DOI 10.17487 / RFC7048、2014年1月、<https://www.rfc-editor.org/info/rfc7048>。
[RFC7112] Gont, F., Manral, V., and R. Bonica, "Implications of Oversized IPv6 Header Chains", RFC 7112, DOI 10.17487/RFC7112, January 2014, <https://www.rfc-editor.org/info/rfc7112>.
[RFC7112] Gont、F.、Manral、V。、およびR. Bonica、「特大IPv6ヘッダーチェーンの影響」、RFC 7112、DOI 10.17487 / RFC7112、2014年1月、<https://www.rfc-editor.org / info / rfc7112>。
[RFC7217] Gont, F., "A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)", RFC 7217, DOI 10.17487/RFC7217, April 2014, <https://www.rfc-editor.org/info/rfc7217>.
[RFC7217] Gont、F。、「IPv6ステートレスアドレス自動構成（SLAAC）で意味的に不透明なインターフェース識別子を生成する方法」、RFC 7217、DOI 10.17487 / RFC7217、2014年4月、<https://www.rfc-editor.org / info / rfc7217>。
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014, <https://www.rfc-editor.org/info/rfc7296>.
[RFC7296] Kaufman、C.、Hoffman、P.、Nir、Y.、Eronen、P。、およびT. Kivinen、「インターネットキーエクスチェンジプロトコルバージョン2（IKEv2）」、STD 79、RFC 7296、DOI 10.17487 / RFC7296 、2014年10月、<https://www.rfc-editor.org/info/rfc7296>。
[RFC7527] Asati, R., Singh, H., Beebee, W., Pignataro, C., Dart, E., and W. George, "Enhanced Duplicate Address Detection", RFC 7527, DOI 10.17487/RFC7527, April 2015, <https://www.rfc-editor.org/info/rfc7527>.
[RFC7527] Asati、R.、Singh、H.、Beebee、W.、Pignataro、C.、Dart、E。、およびW. George、「Enhanced Duplicate Address Detection」、RFC 7527、DOI 10.17487 / RFC7527、2015年4月、<https://www.rfc-editor.org/info/rfc7527>。
[RFC7559] Krishnan, S., Anipko, D., and D. Thaler, "Packet-Loss Resiliency for Router Solicitations", RFC 7559, DOI 10.17487/RFC7559, May 2015, <https://www.rfc-editor.org/info/rfc7559>.
[RFC7559]クリシュナン、S。、アニプコ、D。、およびD.ターラー、「ルーター要請のパケット損失回復力」、RFC 7559、DOI 10.17487 / RFC7559、2015年5月、<https：//www.rfc-editor。 org / info / rfc7559>。
[RFC7608] Boucadair, M., Petrescu, A., and F. Baker, "IPv6 Prefix Length Recommendation for Forwarding", BCP 198, RFC 7608, DOI 10.17487/RFC7608, July 2015, <https://www.rfc-editor.org/info/rfc7608>.
[RFC7608] Boucadair、M.、Petrescu、A。、およびF. Baker、「IPv6 Prefix Length Recommendation for Forwarding」、BCP 198、RFC 7608、DOI 10.17487 / RFC7608、2015年7月、<https：//www.rfc- editor.org/info/rfc7608>。
[RFC8021] Gont, F., Liu, W., and T. Anderson, "Generation of IPv6 Atomic Fragments Considered Harmful", RFC 8021, DOI 10.17487/RFC8021, January 2017, <https://www.rfc-editor.org/info/rfc8021>.
[RFC8021] Gont、F.、Liu、W。、およびT. Anderson、「Generation of IPv6 Atomic Fragments考慮される有害」、RFC 8021、DOI 10.17487 / RFC8021、2017年1月、<https：//www.rfc-editor。 org / info / rfc8021>。
[RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by Hosts in a Multi-Prefix Network", RFC 8028, DOI 10.17487/RFC8028, November 2016, <https://www.rfc-editor.org/info/rfc8028>.
[RFC8028]ベイカー、F.、B。カーペンター、「マルチプレフィックスネットワーク内のホストによるファーストホップルーターの選択」、RFC 8028、DOI 10.17487 / RFC8028、2016年11月、<https：//www.rfc-editor。 org / info / rfc8028>。
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, <https://www.rfc-editor.org/info/rfc8040>.
[RFC8040] Bierman、A.、Bjorklund、M。、およびK. Watsen、「RESTCONFプロトコル」、RFC 8040、DOI 10.17487 / RFC8040、2017年1月、<https://www.rfc-editor.org/info/rfc8040 >。
[RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu, "Recommendation on Stable IPv6 Interface Identifiers", RFC 8064, DOI 10.17487/RFC8064, February 2017, <https://www.rfc-editor.org/info/rfc8064>.
[RFC8064] Gont、F.、Cooper、A.、Thaler、D。、およびW. Liu、「Recommendation on Stable IPv6 Interface Identifiers」、RFC 8064、DOI 10.17487 / RFC8064、2017年2月、<https：// www。 rfc-editor.org/info/rfc8064>。
[RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, "IPv6 Router Advertisement Options for DNS Configuration", RFC 8106, DOI 10.17487/RFC8106, March 2017, <https://www.rfc-editor.org/info/rfc8106>.
[RFC8106] Jeong、J.、Park、S.、Beloeil、L。、およびS. Madanapalli、「DNS構成のIPv6ルーターアドバタイズメントオプション」、RFC 8106、DOI 10.17487 / RFC8106、2017年3月、<https：// www .rfc-editor.org / info / rfc8106>。
[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>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, <https://www.rfc-editor.org/info/rfc8200>.
[RFC8200] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、STD 86、RFC 8200、DOI 10.17487 / RFC8200、2017年7月、<https://www.rfc-editor.org / info / rfc8200>。
[RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., "Path MTU Discovery for IP version 6", STD 87, RFC 8201, DOI 10.17487/RFC8201, July 2017, <https://www.rfc-editor.org/info/rfc8201>.
[RFC8201] McCann、J.、Deering、S.、Mogul、J。、およびR. Hinden、編、「Path MTU Discovery for IP version 6」、STD 87、RFC 8201、DOI 10.17487 / RFC8201、2017年7月<https://www.rfc-editor.org/info/rfc8201>。
[RFC8221] Wouters, P., Migault, D., Mattsson, J., Nir, Y., and T. Kivinen, "Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 8221, DOI 10.17487/RFC8221, October 2017, <https://www.rfc-editor.org/info/rfc8221>.
[RFC8221] Wouters、P.、Migault、D.、Mattsson、J.、Nir、Y。、およびT. Kivinen、「暗号化アルゴリズムの実装要件およびカプセル化セキュリティペイロード（ESP）および認証ヘッダー（AH）の使用ガイダンス」 、RFC 8221、DOI 10.17487 / RFC8221、2017年10月、<https://www.rfc-editor.org/info/rfc8221>。
[RFC8247] Nir, Y., Kivinen, T., Wouters, P., and D. Migault, "Algorithm Implementation Requirements and Usage Guidance for the Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 8247, DOI 10.17487/RFC8247, September 2017, <https://www.rfc-editor.org/info/rfc8247>.
[RFC8247] Nir、Y.、Kivinen、T.、Wouters、P。、およびD. Migault、「Internet Key Exchange Protocol Version 2（IKEv2）のアルゴリズム実装要件および使用ガイダンス」、RFC 8247、DOI 10.17487 / RFC8247 、2017年9月、<https://www.rfc-editor.org/info/rfc8247>。
[RFC8343] Bjorklund, M., "A YANG Data Model for Interface Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, <https://www.rfc-editor.org/info/rfc8343>.
[RFC8343] Bjorklund、M。、「A YANG Data Model for Interface Management」、RFC 8343、DOI 10.17487 / RFC8343、2018年3月、<https://www.rfc-editor.org/info/rfc8343>。
[RFC8344] Bjorklund, M., "A YANG Data Model for IP Management", RFC 8344, DOI 10.17487/RFC8344, March 2018, <https://www.rfc-editor.org/info/rfc8344>.
[RFC8344] Bjorklund、M。、「IP管理用のYANGデータモデル」、RFC 8344、DOI 10.17487 / RFC8344、2018年3月、<https://www.rfc-editor.org/info/rfc8344>。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, <https://www.rfc-editor.org/info/rfc793>.
[RFC793] Postel、J。、「Transmission Control Protocol」、STD 7、RFC 793、DOI 10.17487 / RFC0793、1981年9月、<https://www.rfc-editor.org/info/rfc793>。
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, September 1997, <https://www.rfc-editor.org/info/rfc2205>.
[RFC2205] Braden、R.、Ed。、Zhang、L.、Berson、S.、Herzog、S。、およびS. Jamin、「Resource ReSerVation Protocol（RSVP）-Version 1 Functional Specification」、RFC 2205、DOI 10.17487 / RFC2205、1997年9月、<https://www.rfc-editor.org/info/rfc2205>。
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, <https://www.rfc-editor.org/info/rfc2464>.
[RFC2464] Crawford、M。、「Transmission of IPv6 Packets over Ethernet Networks」、RFC 2464、DOI 10.17487 / RFC2464、1998年12月、<https://www.rfc-editor.org/info/rfc2464>。
[RFC2491] Armitage, G., Schulter, P., Jork, M., and G. Harter, "IPv6 over Non-Broadcast Multiple Access (NBMA) networks", RFC 2491, DOI 10.17487/RFC2491, January 1999, <https://www.rfc-editor.org/info/rfc2491>.
[RFC2491] Armitage、G.、Schulter、P.、Jork、M。、およびG. Harter、「IPv6 over Non-Broadcast Multiple Access（NBMA）ネットワーク」、RFC 2491、DOI 10.17487 / RFC2491、1999年1月、<https ：//www.rfc-editor.org/info/rfc2491>。
[RFC2590] Conta, A., Malis, A., and M. Mueller, "Transmission of IPv6 Packets over Frame Relay Networks Specification", RFC 2590, DOI 10.17487/RFC2590, May 1999, <https://www.rfc-editor.org/info/rfc2590>.
[RFC2590] Conta、A.、Malis、A。、およびM. Mueller、「Transmission of IPv6 Packets over Frame Relay Networks Specification」、RFC 2590、DOI 10.17487 / RFC2590、1999年5月、<https：//www.rfc- editor.org/info/rfc2590>。
[RFC2874] Crawford, M. and C. Huitema, "DNS Extensions to Support IPv6 Address Aggregation and Renumbering", RFC 2874, DOI 10.17487/RFC2874, July 2000, <https://www.rfc-editor.org/info/rfc2874>.
[RFC2874] Crawford、M。、およびC. Huitema、「IPv6アドレスの集約と再番号付けをサポートするDNS拡張機能」、RFC 2874、DOI 10.17487 / RFC2874、2000年7月、<https://www.rfc-editor.org/info/ rfc2874>。
[RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2923, DOI 10.17487/RFC2923, September 2000, <https://www.rfc-editor.org/info/rfc2923>.
[RFC2923] Lahey、K。、「Path MTU Discovery with Path MTU Discovery」、RFC 2923、DOI 10.17487 / RFC2923、2000年9月、<https://www.rfc-editor.org/info/rfc2923>。
[RFC3146] Fujisawa, K. and A. Onoe, "Transmission of IPv6 Packets over IEEE 1394 Networks", RFC 3146, DOI 10.17487/RFC3146, October 2001, <https://www.rfc-editor.org/info/rfc3146>.
[RFC3146]藤沢健一、尾上明夫、「IEEE 1394ネットワーク上のIPv6パケットの送信」、RFC 3146、DOI 10.17487 / RFC3146、2001年10月、<https://www.rfc-editor.org/info/rfc3146 >。
[RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T. Hain, "Representing Internet Protocol version 6 (IPv6) Addresses in the Domain Name System (DNS)", RFC 3363, DOI 10.17487/RFC3363, August 2002, <https://www.rfc-editor.org/info/rfc3363>.
[RFC3363] Bush、R.、Durand、A.、Fink、B.、Gudmundsson、O。、およびT. Hain、「インターネットプロトコルバージョン6（IPv6）アドレスをドメインネームシステム（DNS）で表す」、RFC 3363 、DOI 10.17487 / RFC3363、2002年8月、<https://www.rfc-editor.org/info/rfc3363>。
[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>.
[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>。
[RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, "Advanced Sockets Application Program Interface (API) for IPv6", RFC 3542, DOI 10.17487/RFC3542, May 2003, <https://www.rfc-editor.org/info/rfc3542>.
[RFC3542] Stevens、W.、Thomas、M.、Nordmark、E.、and T. Jinmei、 "Advanced Sockets Application Program Interface（API）for IPv6"、RFC 3542、DOI 10.17487 / RFC3542、May 2003、<https： //www.rfc-editor.org/info/rfc3542>。
[RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, DOI 10.17487/RFC3646, December 2003, <https://www.rfc-editor.org/info/rfc3646>.
[RFC3646] Droms、R。、編、「IPv6の動的ホスト構成プロトコルのDNS構成オプション（DHCPv6）」、RFC 3646、DOI 10.17487 / RFC3646、2003年12月、<https://www.rfc-editor.org / info / rfc3646>。
[RFC3678] Thaler, D., Fenner, B., and B. Quinn, "Socket Interface Extensions for Multicast Source Filters", RFC 3678, DOI 10.17487/RFC3678, January 2004, <https://www.rfc-editor.org/info/rfc3678>.
[RFC3678] Thaler、D.、Fenner、B。、およびB. Quinn、「マルチキャストソースフィルターのソケットインターフェイス拡張」、RFC 3678、DOI 10.17487 / RFC3678、2004年1月、<https：//www.rfc-editor。 org / info / rfc3678>。
[RFC3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents", RFC 3776, DOI 10.17487/RFC3776, June 2004, <https://www.rfc-editor.org/info/rfc3776>.
[RFC3776] Arkko、J.、Devarapalli、V。、およびF. Dupont、「IPsecを使用したモバイルノードとホームエージェント間のモバイルIPv6シグナリングの保護」、RFC 3776、DOI 10.17487 / RFC3776、2004年6月、<https：// www.rfc-editor.org/info/rfc3776>。
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, DOI 10.17487/RFC3971, March 2005, <https://www.rfc-editor.org/info/rfc3971>.
[RFC3971] Arkko、J.、Ed。、Kempf、J.、Zill、B。、およびP. Nikander、「SEcure Neighbor Discovery（SEND）」、RFC 3971、DOI 10.17487 / RFC3971、2005年3月、<https：/ /www.rfc-editor.org/info/rfc3971>。
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, DOI 10.17487/RFC3972, March 2005, <https://www.rfc-editor.org/info/rfc3972>.
[RFC3972] Aura、T。、「Cryptographically Generated Addresses（CGA）」、RFC 3972、DOI 10.17487 / RFC3972、2005年3月、<https://www.rfc-editor.org/info/rfc3972>。
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, November 2005, <https://www.rfc-editor.org/info/rfc4191>.
[RFC4191] Draves、R。およびD. Thaler、「デフォルトのルーター設定とより具体的なルート」、RFC 4191、DOI 10.17487 / RFC4191、2005年11月、<https://www.rfc-editor.org/info/rfc4191 >。
[RFC4294] Loughney, J., Ed., "IPv6 Node Requirements", RFC 4294, DOI 10.17487/RFC4294, April 2006, <https://www.rfc-editor.org/info/rfc4294>.
[RFC4294] Loughney、J。、編、「IPv6ノードの要件」、RFC 4294、DOI 10.17487 / RFC4294、2006年4月、<https://www.rfc-editor.org/info/rfc4294>。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, DOI 10.17487/RFC4302, December 2005, <https://www.rfc-editor.org/info/rfc4302>.
[RFC4302]ケント、S。、「IP認証ヘッダー」、RFC 4302、DOI 10.17487 / RFC4302、2005年12月、<https://www.rfc-editor.org/info/rfc4302>。
[RFC4338] DeSanti, C., Carlson, C., and R. Nixon, "Transmission of IPv6, IPv4, and Address Resolution Protocol (ARP) Packets over Fibre Channel", RFC 4338, DOI 10.17487/RFC4338, January 2006, <https://www.rfc-editor.org/info/rfc4338>.
[RFC4338] DeSanti、C.、Carlson、C。、およびR. Nixon、「IPv6、IPv4、およびアドレス解決プロトコル（ARP）パケットのファイバーチャネル上での送信」、RFC 4338、DOI 10.17487 / RFC4338、2006年1月、< https://www.rfc-editor.org/info/rfc4338>。
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, DOI 10.17487/RFC4380, February 2006, <https://www.rfc-editor.org/info/rfc4380>.
[RFC4380] Huitema、C。、「Teredo：Tunneling IPv6 over UDP through Network Address Translations（NATs）」、RFC 4380、DOI 10.17487 / RFC4380、2006年2月、<https://www.rfc-editor.org/info/ rfc4380>。
[RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) for IPv6", RFC 4429, DOI 10.17487/RFC4429, April 2006, <https://www.rfc-editor.org/info/rfc4429>.
[RFC4429] Moore、N。、「IPv6の楽観的重複アドレス検出（DAD）」、RFC 4429、DOI 10.17487 / RFC4429、2006年4月、<https://www.rfc-editor.org/info/rfc4429>。
[RFC4584] Chakrabarti, S. and E. Nordmark, "Extension to Sockets API for Mobile IPv6", RFC 4584, DOI 10.17487/RFC4584, July 2006, <https://www.rfc-editor.org/info/rfc4584>.
[RFC4584] Chakrabarti、S。およびE. Nordmark、「Extension to Sockets API for Mobile IPv6」、RFC 4584、DOI 10.17487 / RFC4584、2006年7月、<https://www.rfc-editor.org/info/rfc4584> 。
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, <https://www.rfc-editor.org/info/rfc4821>.
[RFC4821] Mathis、M。およびJ. Heffner、「Packetization Layer Path MTU Discovery」、RFC 4821、DOI 10.17487 / RFC4821、2007年3月、<https://www.rfc-editor.org/info/rfc4821>。
[RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture", RFC 4877, DOI 10.17487/RFC4877, April 2007, <https://www.rfc-editor.org/info/rfc4877>.
[RFC4877] Devarapalli、V。およびF. Dupont、「IKEv2および改訂されたIPsecアーキテクチャによるモバイルIPv6オペレーション」、RFC 4877、DOI 10.17487 / RFC4877、2007年4月、<https://www.rfc-editor.org/info / rfc4877>。
[RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "Extended ICMP to Support Multi-Part Messages", RFC 4884, DOI 10.17487/RFC4884, April 2007, <https://www.rfc-editor.org/info/rfc4884>.
[RFC4884] Bonica、R.、Gan、D.、Tappan、D。、およびC. Pignataro、「マルチパートメッセージをサポートするための拡張ICMP」、RFC 4884、DOI 10.17487 / RFC4884、2007年4月、<https：// www.rfc-editor.org/info/rfc4884>。
[RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering ICMPv6 Messages in Firewalls", RFC 4890, DOI 10.17487/RFC4890, May 2007, <https://www.rfc-editor.org/info/rfc4890>.
[RFC4890] Davies、E。およびJ. Mohacsi、「ファイアウォールでのICMPv6メッセージのフィルタリングに関する推奨事項」、RFC 4890、DOI 10.17487 / RFC4890、2007年5月、<https://www.rfc-editor.org/info/rfc4890> 。
[RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals", RFC 4919, DOI 10.17487/RFC4919, August 2007, <https://www.rfc-editor.org/info/rfc4919>.
[RFC4919] Kushalnagar、N.、Montenegro、G。、およびC. Schumacher、「IPv6 over Low-Power Wireless Personal Area Networks（6LoWPANs）：Overview、Assumptions、Problem Statement、and Goals」、RFC 4919、DOI 10.17487 / RFC4919 、2007年8月、<https://www.rfc-editor.org/info/rfc4919>。
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, <https://www.rfc-editor.org/info/rfc4944>.
[RFC4944]モンテネグロ、G。、クシャルナガル、N。、ホイ、J。、およびD.キュラー、「IEEE 802.15.4ネットワークを介したIPv6パケットの送信」、RFC 4944、DOI 10.17487 / RFC4944、2007年9月、<https： //www.rfc-editor.org/info/rfc4944>。
[RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6 Socket API for Source Address Selection", RFC 5014, DOI 10.17487/RFC5014, September 2007, <https://www.rfc-editor.org/info/rfc5014>.
[RFC5014] Nordmark、E.、Chakrabarti、S。、およびJ. Laganier、「ソースアドレス選択用のIPv6ソケットAPI」、RFC 5014、DOI 10.17487 / RFC5014、2007年9月、<https：//www.rfc-editor。 org / info / rfc5014>。
[RFC5072] Varada, S., Ed., Haskins, D., and E. Allen, "IP Version 6 over PPP", RFC 5072, DOI 10.17487/RFC5072, September 2007, <https://www.rfc-editor.org/info/rfc5072>.
[RFC5072] Varada、S.、Ed。、Haskins、D.、and E. Allen、 "IP Version 6 over PPP"、RFC 5072、DOI 10.17487 / RFC5072、September 2007、<https：//www.rfc-editor .org / info / rfc5072>。
[RFC5121] Patil, B., Xia, F., Sarikaya, B., Choi, JH., and S. Madanapalli, "Transmission of IPv6 via the IPv6 Convergence Sublayer over IEEE 802.16 Networks", RFC 5121, DOI 10.17487/RFC5121, February 2008, <https://www.rfc-editor.org/info/rfc5121>.
[RFC5121] Patil、B.、Xia、F.、Sarikaya、B.、Choi、JH。、およびS. Madanapalli、「IEEE 802.16ネットワーク上のIPv6 Convergence Sublayerを介したIPv6の送信」、RFC 5121、DOI 10.17487 / RFC5121 、2008年2月、<https://www.rfc-editor.org/info/rfc5121>。
[RFC5555] Soliman, H., Ed., "Mobile IPv6 Support for Dual Stack Hosts and Routers", RFC 5555, DOI 10.17487/RFC5555, June 2009, <https://www.rfc-editor.org/info/rfc5555>.
[RFC5555] Soliman、H。、編、「デュアルスタックホストとルーターのモバイルIPv6サポート」、RFC 5555、DOI 10.17487 / RFC5555、2009年6月、<https://www.rfc-editor.org/info/rfc5555 >。
[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 2011, <https://www.rfc-editor.org/info/rfc6275>.
[RFC6275] Perkins、C.、Ed。、Johnson、D。、およびJ. Arkko、「IPv6のモビリティサポート」、RFC 6275、DOI 10.17487 / RFC6275、2011年7月、<https：//www.rfc-editor。 org / info / rfc6275>。
[RFC6563] Jiang, S., Conrad, D., and B. Carpenter, "Moving A6 to Historic Status", RFC 6563, DOI 10.17487/RFC6563, March 2012, <https://www.rfc-editor.org/info/rfc6563>.
[RFC6563] Jiang、S.、Conrad、D。、およびB. Carpenter、「A6を歴史的ステータスに移行」、RFC 6563、DOI 10.17487 / RFC6563、2012年3月、<https://www.rfc-editor.org/ info / rfc6563>。
[RFC6980] Gont, F., "Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery", RFC 6980, DOI 10.17487/RFC6980, August 2013, <https://www.rfc-editor.org/info/rfc6980>.
[RFC6980] Gont、F。、「IPv6 Neighbor DiscoveryによるIPv6フラグメンテーションのセキュリティへの影響」、RFC 6980、DOI 10.17487 / RFC6980、2013年8月、<https://www.rfc-editor.org/info/rfc6980>。
[RFC7066] Korhonen, J., Ed., Arkko, J., Ed., Savolainen, T., and S. Krishnan, "IPv6 for Third Generation Partnership Project (3GPP) Cellular Hosts", RFC 7066, DOI 10.17487/RFC7066, November 2013, <https://www.rfc-editor.org/info/rfc7066>.
[RFC7066] Korhonen、J。、編、Arkko、J。、編、Savolainen、T。、およびS. Krishnan、「IPv6 for Third Generation Partnership Project（3GPP）Cellular Hosts」、RFC 7066、DOI 10.17487 / RFC7066 、2013年11月、<https://www.rfc-editor.org/info/rfc7066>。
[RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic Requirements for IPv6 Customer Edge Routers", RFC 7084, DOI 10.17487/RFC7084, November 2013, <https://www.rfc-editor.org/info/rfc7084>.
[RFC7084] Singh、H.、Beebee、W.、Donley、C。、およびB. Stark、「IPv6カスタマーエッジルーターの基本要件」、RFC 7084、DOI 10.17487 / RFC7084、2013年11月、<https：// www .rfc-editor.org / info / rfc7084>。
[RFC7123] Gont, F. and W. Liu, "Security Implications of IPv6 on IPv4 Networks", RFC 7123, DOI 10.17487/RFC7123, February 2014, <https://www.rfc-editor.org/info/rfc7123>.
[RFC7123] Gont、F。およびW. Liu、「IPv4ネットワーク上のIPv6のセキュリティへの影響」、RFC 7123、DOI 10.17487 / RFC7123、2014年2月、<https://www.rfc-editor.org/info/rfc7123> 。
[RFC7278] Byrne, C., Drown, D., and A. Vizdal, "Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link", RFC 7278, DOI 10.17487/RFC7278, June 2014, <https://www.rfc-editor.org/info/rfc7278>.
[RFC7278] Byrne、C.、Drown、D。、およびA. Vizdal、「IPv6 / 64プレフィックスを第3世代パートナーシッププロジェクト（3GPP）モバイルインターフェイスからLANリンクに拡張」、RFC 7278、DOI 10.17487 / RFC7278、 2014年6月、<https://www.rfc-editor.org/info/rfc7278>。
[RFC7371] Boucadair, M. and S. Venaas, "Updates to the IPv6 Multicast Addressing Architecture", RFC 7371, DOI 10.17487/RFC7371, September 2014, <https://www.rfc-editor.org/info/rfc7371>.
[RFC7371] Boucadair、M.、S。Venaas、「Updates to the IPv6 Multicast Addressing Architecture」、RFC 7371、DOI 10.17487 / RFC7371、2014年9月、<https://www.rfc-editor.org/info/rfc7371> 。
[RFC7421] Carpenter, B., Ed., Chown, T., Gont, F., Jiang, S., Petrescu, A., and A. Yourtchenko, "Analysis of the 64-bit Boundary in IPv6 Addressing", RFC 7421, DOI 10.17487/RFC7421, January 2015, <https://www.rfc-editor.org/info/rfc7421>.
[RFC7421] Carpenter、B.、Ed。、Chown、T.、Gont、F.、Jiang、S.、Petrescu、A。、およびA. Yourtchenko、「IPv6アドレッシングの64ビット境界の分析」、RFC 7421、DOI 10.17487 / RFC7421、2015年1月、<https://www.rfc-editor.org/info/rfc7421>。
[RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy Considerations for IPv6 Address Generation Mechanisms", RFC 7721, DOI 10.17487/RFC7721, March 2016, <https://www.rfc-editor.org/info/rfc7721>.
[RFC7721] Cooper、A.、Gont、F。、およびD. Thaler、「IPv6アドレス生成メカニズムのセキュリティとプライバシーに関する考慮事項」、RFC 7721、DOI 10.17487 / RFC7721、2016年3月、<https：//www.rfc- editor.org/info/rfc7721>。
[RFC7739] Gont, F., "Security Implications of Predictable Fragment Identification Values", RFC 7739, DOI 10.17487/RFC7739, February 2016, <https://www.rfc-editor.org/info/rfc7739>.
[RFC7739] Gont、F。、「予測可能なフラグメント識別値のセキュリティへの影響」、RFC 7739、DOI 10.17487 / RFC7739、2016年2月、<https://www.rfc-editor.org/info/rfc7739>。
[RFC7772] Yourtchenko, A. and L. Colitti, "Reducing Energy Consumption of Router Advertisements", BCP 202, RFC 7772, DOI 10.17487/RFC7772, February 2016, <https://www.rfc-editor.org/info/rfc7772>.
[RFC7772] Yourtchenko、A。およびL. Colitti、「ルーターアドバタイズメントのエネルギー消費の削減」、BCP 202、RFC 7772、DOI 10.17487 / RFC7772、2016年2月、<https://www.rfc-editor.org/info/ rfc7772>。
[RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity Profiles for DHCP Clients", RFC 7844, DOI 10.17487/RFC7844, May 2016, <https://www.rfc-editor.org/info/rfc7844>.
[RFC7844] Huitema、C.、Mrugalski、T。、およびS. Krishnan、「DHCPクライアントの匿名プロファイル」、RFC 7844、DOI 10.17487 / RFC7844、2016年5月、<https://www.rfc-editor.org/ info / rfc7844>。
[RFC7934] Colitti, L., Cerf, V., Cheshire, S., and D. Schinazi, "Host Address Availability Recommendations", BCP 204, RFC 7934, DOI 10.17487/RFC7934, July 2016, <https://www.rfc-editor.org/info/rfc7934>.
[RFC7934] Colitti、L.、Cerf、V.、Cheshire、S。、およびD. Schinazi、「Host Address Availability Recommendations」、BCP 204、RFC 7934、DOI 10.17487 / RFC7934、2016年7月、<https：// www .rfc-editor.org / info / rfc7934>。
[RFC8087] Fairhurst, G. and M. Welzl, "The Benefits of Using Explicit Congestion Notification (ECN)", RFC 8087, DOI 10.17487/RFC8087, March 2017, <https://www.rfc-editor.org/info/rfc8087>.
[RFC8087] Fairhurst、G。およびM. Welzl、「明示的な輻輳通知（ECN）を使用する利点」、RFC 8087、DOI 10.17487 / RFC8087、2017年3月、<https://www.rfc-editor.org/info / rfc8087>。
[RFC8096] Fenner, B., "The IPv6-Specific MIB Modules Are Obsolete", RFC 8096, DOI 10.17487/RFC8096, April 2017, <https://www.rfc-editor.org/info/rfc8096>.
[RFC8096] Fenner、B。、「The IPv6-Specific MIB Modules Is Obsolete」、RFC 8096、DOI 10.17487 / RFC8096、2017年4月、<https://www.rfc-editor.org/info/rfc8096>。
[RFC8273] Brzozowski, J. and G. Van de Velde, "Unique IPv6 Prefix per Host", RFC 8273, DOI 10.17487/RFC8273, December 2017, <https://www.rfc-editor.org/info/rfc8273>.
[RFC8273] Brzozowski、J。およびG. Van de Velde、「Unique IPv6 Prefix per Host」、RFC 8273、DOI 10.17487 / RFC8273、2017年12月、<https://www.rfc-editor.org/info/rfc8273> 。
[POSIX] IEEE, "Information Technology -- Portable Operating System Interface (POSIX(R)) Base Specifications, Issue 7", IEEE Std 1003.1-2017, DOI: 10.1109/IEEESTD.2018.8277153, January 2018, <https://ieeexplore.ieee.org/document/8277153>.
[POSIX] IEEE、「Information Technology-Portable Operating System Interface（POSIX（R））Base Specifications、Issue 7」、IEEE Std 1003.1-2017、DOI：10.1109 / IEEESTD.2018.8277153、2018年1月、<https：// ieeexplore .ieee.org / document / 8277153>。
[USGv6] National Institute of Standards and Technology, "A Profile for IPv6 in the U.S. Government - Version 1.0", NIST SP500-267, July 2008, <https://www.nist.gov/programs-projects/usgv6-program>.
[USGv6]国立標準技術研究所、「米国政府におけるIPv6のプロファイル-バージョン1.0」、NIST SP500-267、2008年7月、<https://www.nist.gov/programs-projects/usgv6-program >。
There have been many editorial clarifications as well as significant additions and updates. While this section highlights some of the changes, readers should not rely on this section for a comprehensive list of all changes.
多くの編集上の説明、および重要な追加と更新がありました。このセクションではいくつかの変更点を取り上げていますが、読者はすべての変更点の包括的なリストをこのセクションに依存しないでください。
1. Restructured sections.
1. 再構成されたセクション。
2. Added 6LoWPAN to link layers as it has some deployment.
2. いくつかの展開があるため、レイヤーをリンクするために6LoWPANを追加しました。
3. Removed the Downstream-on-Demand (DoD) IPv6 Profile as it hasn't been updated.
3. ダウンストリームオンデマンド（DoD）IPv6プロファイルは更新されていないため、削除しました。
4. Updated MLDv2 support to a MUST since nodes are restricted if MLDv1 is used.
4. MLDv1を使用するとノードが制限されるため、MLDv2のサポートを必須に更新しました。
5. Required DNS RA options so SLAAC-only devices can get DNS; RFC 8106 is a MUST.
5. SLAACのみのデバイスがDNSを取得できるようにするために必要なDNS RAオプション。 RFC 8106は必須です。
6. Required RFC 3646 DNS Options for DHCPv6 implementations.
6. DHCPv6実装に必要なRFC 3646 DNSオプション。
7. Added RESTCONF and NETCONF as possible options to network management.
7. ネットワーク管理の可能なオプションとしてRESTCONFおよびNETCONFを追加しました。
8. Added a section on constrained devices.
8. 制約のあるデバイスに関するセクションを追加しました。
9. Added text on RFC 7934 to address availability to hosts (SHOULD).
9. ホストの可用性に対処するためにRFC 7934にテキストを追加しました（SHOULD）。
10. Added text on RFC 7844 for anonymity profiles for DHCPv6 clients.
10. DHCPv6クライアントの匿名プロファイルについてRFC 7844にテキストを追加しました。
11. Added mDNS and DNS-SD as updated service discovery.
11. 更新されたサービスディスカバリとしてmDNSおよびDNS-SDを追加しました。
12. Added RFC 8028 as a SHOULD as a method for solving a multi-prefix network.
12. マルチプレフィックスネットワークを解決する方法として、RFC 8028をSHOULDとして追加しました。
13. Added ECN RFC 3168 as a SHOULD.
13. ECN RFC 3168をSHOULDとして追加しました。
14. Added reference to RFC 7123 for security over IPv4-only networks.
14. IPv4のみのネットワーク上のセキュリティに関するRFC 7123への参照を追加しました。
15. Removed Jumbograms (RFC 2675) as they aren't deployed.
15. 展開されていないため、ジャンボグラム（RFC 2675）を削除しました。
16. Updated obsoleted RFCs to the new version of the RFC, including RFCs 2460, 1981, 7321, and 4307.
16. 廃止されたRFCをRFC 2460、1981、7321、4307を含む新しいバージョンのRFCに更新しました。
17. Added RFC 7772 for power consumptions considerations.
17. 消費電力に関する考慮事項についてRFC 7772を追加しました。
18. Added why /64 boundaries for more detail -- RFC 7421.
18. 理由/ 64境界を詳細に追加しました-RFC 7421。
19. Added a unique IPv6 prefix per host to support currently deployed IPv6 networks.
19. 現在展開されているIPv6ネットワークをサポートするために、ホストごとに一意のIPv6プレフィックスを追加しました。
20. Clarified RFC 7066 was a snapshot for 3GPP.
20. RFC 7066が3GPPのスナップショットであることを明確にしました。
21. Updated RFC 4191 as a MUST and the Type C Host as a SHOULD as they help solve multi-prefix problems.
21. RFC 4191を必須として更新し、タイプCホストをマルチプレフィックスの問題の解決に役立つSHOULDとして更新しました。
22. Removed IPv6 over ATM since there aren't many deployments.
22. 展開が少ないため、IPv6 over ATMを削除しました。
23. Added a note in Section 6.6 for Rule 5.5 from RFC 6724.
23. RFC 6724のRule 5.5についてセクション6.6に注記を追加しました。
24. Added MUST for BCP 198 for forwarding IPv6 packets.
24. IPv6パケットを転送するためのBCP 198のMUSTが追加されました。
25. Added a reference to RFC 8064 for stable address creation.
25. 安定したアドレス作成のためにRFC 8064への参照を追加しました。
26. Added text on the protection from excessive extension header options.
26. 過度の拡張ヘッダーオプションからの保護に関するテキストを追加しました。
27. Added text on the dangers of 1280 MTU UDP, especially with regard to DNS traffic.
27. 特にDNSトラフィックに関して、1280 MTU UDPの危険性に関するテキストを追加しました。
28. Added text to clarify RFC 8200 behavior for unrecognized extension headers or unrecognized ULPs.
28. 認識されない拡張ヘッダーまたは認識されないULPに対するRFC 8200の動作を明確にするためのテキストを追加しました。
29. Removed dated email addresses from design team acknowledgements for [RFC4294].
29. [RFC4294]の設計チームからの日付付きのメールアドレスを削除しました。
There have been many editorial clarifications as well as significant additions and updates. While this section highlights some of the changes, readers should not rely on this section for a comprehensive list of all changes.
多くの編集上の説明、および重要な追加と更新がありました。このセクションではいくつかの変更点を取り上げていますが、読者はすべての変更点の包括的なリストをこのセクションに依存しないでください。
1. Updated the Introduction to indicate that this document is an applicability statement and is aimed at general nodes.
1. 概要が更新され、このドキュメントが適用性に関する記述であり、一般的なノードを対象としていることが示されました。
2. Significantly updated the section on mobility protocols; added references and downgraded previous SHOULDs to MAYs.
2. モビリティプロトコルに関するセクションを大幅に更新。参照を追加し、以前のSHOULDをMAYにダウングレードしました。
3. Changed the Sub-IP Layer section to just list relevant RFCs, and added some more RFCs.
3. Sub-IP Layerセクションを変更して、関連するRFCのみをリストし、さらにいくつかのRFCを追加しました。
4. Added a section on SEND (it is a MAY).
4. SENDに関するセクションを追加しました（MAYです）。
5. Revised the section on Privacy Extensions [RFC4941] to add more nuance to the recommendation.
5. プライバシー拡張[RFC4941]のセクションを改訂して、推奨にさらにニュアンスを追加しました。
6. Completely revised the IPsec/IKEv2 section, downgrading the overall recommendation to a SHOULD.
6. IPsec / IKEv2セクションを完全に改訂し、全体的な推奨をSHOULDにダウングレードしました。
7. Upgraded recommendation of DHCPv6 to a SHOULD.
7. DHCPv6の推奨をSHOULDにアップグレードしました。
8. Added a background section on DHCP versus RA options, added a SHOULD recommendation for DNS configuration via RAs (RFC 6106), and cleaned up the DHCP recommendations.
8. DHCPとRAのオプションに関する背景セクションを追加し、RAを介したDNS構成に関する推奨事項（RFC 6106）を追加し、DHCP推奨事項をクリーンアップしました。
9. Added the recommendation that routers implement Sections 7.3 and 7.5 of [RFC6275].
9. [RFC6275]のセクション7.3および7.5をルーターが実装するという推奨を追加しました。
10. Added a pointer to subnet clarification document [RFC5942].
10. サブネットの明確化文書へのポインタを追加[RFC5942]。
11. Added text that "IPv6 Host-to-Router Load Sharing" [RFC4311] SHOULD be implemented.
11. 「IPv6ホストからルーターへの負荷共有」[RFC4311]を実装する必要があるというテキストを追加しました。
12. Added reference to [RFC5722] (Overlapping Fragments), and made it a MUST to implement.
12. [RFC5722]（重複フラグメント）への参照を追加し、実装する必要があります。
13. Made "A Recommendation for IPv6 Address Text Representation" [RFC5952] a SHOULD.
13. 「IPv6アドレステキスト表現の推奨事項」[RFC5952]をSHOULDにしました。
14. Removed the mention of delegation name (DNAME) from the discussion about [RFC3363].
14. [RFC3363]に関する議論から委任名（DNAME）の言及を削除しました。
15. Numerous updates to reflect newer versions of IPv6 documents, including [RFC3596], [RFC4213], [RFC4291], and [RFC4443].
15. [RFC3596]、[RFC4213]、[RFC4291]、[RFC4443]など、IPv6ドキュメントの新しいバージョンを反映するための多数の更新。
16. Removed discussion of "Managed" and "Other" flags in RAs. There is no consensus at present on how to process these flags, and discussion of their semantics was removed in the most recent update of Stateless Address Autoconfiguration [RFC4862].
16. RAの「管理」および「その他」のフラグの説明を削除しました。現在、これらのフラグの処理方法に関するコンセンサスはありません。それらのセマンティクスの説明は、ステートレスアドレス自動構成[RFC4862]の最新のアップデートで削除されました。
17. Added many more references to optional IPv6 documents.
17. オプションのIPv6ドキュメントへの参照をさらに追加しました。
18. Made "A Recommendation for IPv6 Address Text Representation" [RFC5952] a SHOULD.
18. 「IPv6アドレステキスト表現の推奨事項」[RFC5952]をSHOULDにしました。
19. Updated the MLD section to include reference to Lightweight MLD [RFC5790].
19. MLDセクションを更新して、軽量MLD [RFC5790]への参照を含めました。
20. Added a SHOULD recommendation for "Default Router Preferences and More-Specific Routes" [RFC4191].
20. 「デフォルトのルーター設定とより具体的なルート」[RFC4191]の推奨事項を追加する必要があります。
21. Made "IPv6 Flow Label Specification" [RFC6437] a SHOULD.
21. 「IPv6 Flow Label Specification」[RFC6437]をSHOULDにしました。
Acknowledgments
謝辞
o Acknowledgments (Current Document)
o 謝辞（現在のドキュメント）
The authors would like to thank Brian Carpenter, Dave Thaler, Tom Herbert, Erik Kline, Mohamed Boucadair, and Michayla Newcombe for their contributions and many members of the 6man WG for the inputs they gave.
著者は、彼らの貢献と彼らが与えたインプットに対する6man WGの多くのメンバーに貢献してくれたBrian Carpenter、Dave Thaler、Tom Herbert、Erik Kline、Mohamed Boucadair、Michayla Newcombeに感謝したいと思います。
o Authors and Acknowledgments from RFC 6434
o RFC 6434からの作者と謝辞
RFC 6434 was authored by Ed Jankiewicz, John Loughney, and Thomas Narten.
RFC 6434は、Ed Jankiewicz、John Loughney、およびThomas Nartenによって作成されました。
The authors of RFC 6434 thank Hitoshi Asaeda, Brian Carpenter, Tim Chown, Ralph Droms, Sheila Frankel, Sam Hartman, Bob Hinden, Paul Hoffman, Pekka Savola, Yaron Sheffer, and Dave Thaler for their comments. In addition, the authors thank Mark Andrews for comments and corrections on DNS text and Alfred Hoenes for tracking the updates to various RFCs.
RFC 6434の作成者は、コメントを提供してくれた浅枝仁、ブライアンカーペンター、ティムチョウン、ラルフドロムス、シーラフランケル、サムハートマン、ボブヒンデン、ポールホフマン、ペッカサボラ、ヤロンシェファー、デイブターラーに感謝します。さらに、作者は、DNSテキストに関するコメントと修正を提供してくれたMark Andrewsと、さまざまなRFCの更新を追跡してくれたAlfred Hoenesに感謝します。
o Authors and Acknowledgments from RFC 4294
o RFC 4294の作成者と謝辞
RFC 4294 was written by the IPv6 Node Requirements design team, which had the following members: Jari Arkko, Marc Blanchet, Samita Chakrabarti, Alain Durand, Gerard Gastaud, Jun-ichiro Itojun Hagino, Atsushi Inoue, Masahiro Ishiyama, John Loughney, Rajiv Raghunarayan, Shoichi Sakane, Dave Thaler, and Juha Wiljakka.
RFC 4294は、IPv6ノード要件設計チームによって作成され、Jari Arkko、Marc Blanchet、Samita Chakrabarti、Alain Durand、Gerard Gastaud、Jun-ichiro Itojun Hagino、Atsushi Inoue、Mashiro Ishiyama、John Loughney、Rajiv Raghunarayan 、坂根翔一、Dave Thaler、Juha Wiljakka。
The authors of RFC 4294 thank Ran Atkinson, Jim Bound, Brian Carpenter, Ralph Droms, Christian Huitema, Adam Machalek, Thomas Narten, Juha Ollila, and Pekka Savola for their comments.
RFC 4294の作成者は、Ran Atkinson、Jim Bound、Brian Carpenter、Ralph Droms、Christian Huitema、Adam Machalek、Thomas Narten、Juha Ollila、およびPekka Savolaにコメントを寄せてくれました。
Authors' Addresses
著者のアドレス
Tim Chown Jisc Lumen House, Library Avenue Harwell Oxford, Didcot OX11 0SG United Kingdom
Tim Chown Jisc Lumen House、Library Avenue Harwell Oxford、Didcot OX11 0SGイギリス
Email: tim.chown@jisc.ac.uk
John Loughney Intel Santa Clara, CA United States of America
John Loughney Intel Santa Clara、CAアメリカ合衆国
Email: john.loughney@gmail.com
Timothy Winters University of New Hampshire, Interoperability Lab (UNH-IOL) Durham, NH United States of America
ティモシーウィンターズ大学ニューハンプシャー大学、インターオペラビリティラボ（UNH-IOL）ダーラム、NHアメリカ合衆国
Email: twinters@iol.unh.edu