Internet Engineering Task Force (IETF)                     E. Jankiewicz
Request for Comments: 6434                       SRI International, Inc.
Obsoletes: 4294                                              J. Loughney
Category: Informational                                            Nokia
ISSN: 2070-1721                                                T. Narten
                                                         IBM Corporation
                                                           December 2011
                         IPv6 Node Requirements



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 4294.

この文書はRFC 4294を廃止します。

Status of This Memo


This document is not an Internet Standards Track specification; it is published for informational purposes.


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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.

このドキュメントはインターネットエンジニアリングタスクフォース(IETF)の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ(IESG)によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 RFC 5741のセクション2を参照してください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at


Copyright Notice


Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.

著作権(C)2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents ( 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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.


Table of Contents


   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Scope of This Document . . . . . . . . . . . . . . . . . .  5
     1.2.  Description of IPv6 Nodes  . . . . . . . . . . . . . . . .  5
   2.  Requirements Language  . . . . . . . . . . . . . . . . . . . .  5
   3.  Abbreviations Used in This Document  . . . . . . . . . . . . .  5
   4.  Sub-IP Layer . . . . . . . . . . . . . . . . . . . . . . . . .  6
   5.  IP Layer . . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     5.1.  Internet Protocol Version 6 - RFC 2460 . . . . . . . . . .  7
     5.2.  Neighbor Discovery for IPv6 - RFC 4861 . . . . . . . . . .  8
     5.3.  Default Router Preferences and More-Specific Routes -
           RFC 4191 . . . . . . . . . . . . . . . . . . . . . . . . .  9
     5.4.  SEcure Neighbor Discovery (SEND) - RFC 3971  . . . . . . .  9
     5.5.  IPv6 Router Advertisement Flags Option - RFC 5175  . . . .  9
     5.6.  Path MTU Discovery and Packet Size . . . . . . . . . . . . 10
       5.6.1.  Path MTU Discovery - RFC 1981  . . . . . . . . . . . . 10
     5.7.  IPv6 Jumbograms - RFC 2675 . . . . . . . . . . . . . . . . 10
     5.8.  ICMP for the Internet Protocol Version 6 (IPv6) - RFC
           4443 . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     5.9.  Addressing . . . . . . . . . . . . . . . . . . . . . . . . 11
       5.9.1.  IP Version 6 Addressing Architecture - RFC 4291  . . . 11
       5.9.2.  IPv6 Stateless Address Autoconfiguration - RFC 4862  . 11
       5.9.3.  Privacy Extensions for Address Configuration in
               IPv6 - RFC 4941  . . . . . . . . . . . . . . . . . . . 12
       5.9.4.  Default Address Selection for IPv6 - RFC 3484  . . . . 12
       5.9.5.  Stateful Address Autoconfiguration (DHCPv6) - RFC
               3315 . . . . . . . . . . . . . . . . . . . . . . . . . 12
     5.10. Multicast Listener Discovery (MLD) for IPv6  . . . . . . . 13
   6.  DHCP versus Router Advertisement Options for Host
       Configuration  . . . . . . . . . . . . . . . . . . . . . . . . 13
   7.  DNS and DHCP . . . . . . . . . . . . . . . . . . . . . . . . . 14
     7.1.  DNS  . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     7.2.  Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
           - RFC 3315 . . . . . . . . . . . . . . . . . . . . . . . . 15
       7.2.1.  Other Configuration Information  . . . . . . . . . . . 15
       7.2.2.  Use of Router Advertisements in Managed
               Environments . . . . . . . . . . . . . . . . . . . . . 15
     7.3.  IPv6 Router Advertisement Options for DNS
           Configuration - RFC 6106 . . . . . . . . . . . . . . . . . 15
   8.  IPv4 Support and Transition  . . . . . . . . . . . . . . . . . 16
     8.1.  Transition Mechanisms  . . . . . . . . . . . . . . . . . . 16
       8.1.1.  Basic Transition Mechanisms for IPv6 Hosts and
               Routers - RFC 4213 . . . . . . . . . . . . . . . . . . 16
   9.  Application Support  . . . . . . . . . . . . . . . . . . . . . 16
     9.1.  Textual Representation of IPv6 Addresses - RFC 5952  . . . 16
     9.2.  Application Programming Interfaces (APIs)  . . . . . . . . 16
   10. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
   11. Security . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     11.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 18
     11.2. Transforms and Algorithms  . . . . . . . . . . . . . . . . 19
   12. Router-Specific Functionality  . . . . . . . . . . . . . . . . 19
     12.1. IPv6 Router Alert Option - RFC 2711  . . . . . . . . . . . 19
     12.2. Neighbor Discovery for IPv6 - RFC 4861 . . . . . . . . . . 19
     12.3. Stateful Address Autoconfiguration (DHCPv6) - RFC 3315 . . 19
   13. Network Management . . . . . . . . . . . . . . . . . . . . . . 20
     13.1. Management Information Base (MIB) Modules  . . . . . . . . 20
       13.1.1. IP Forwarding Table MIB  . . . . . . . . . . . . . . . 20
       13.1.2. Management Information Base for the Internet
               Protocol (IP)  . . . . . . . . . . . . . . . . . . . . 20
   14. Security Considerations  . . . . . . . . . . . . . . . . . . . 20
   15. Authors and Acknowledgments  . . . . . . . . . . . . . . . . . 21
     15.1. Authors and Acknowledgments (Current Document) . . . . . . 21
     15.2. Authors and Acknowledgments from RFC 4279  . . . . . . . . 21
   16. Appendix: Changes from RFC 4294  . . . . . . . . . . . . . . . 22
   17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
     17.1. Normative References . . . . . . . . . . . . . . . . . . . 23
     17.2. Informative References . . . . . . . . . . . . . . . . . . 26
1. Introduction
1. はじめに

This document defines common functionality required from 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.


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.


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.


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. For example, this document does not mandate that all clients support DHCP, but some deployment scenarios may deem it appropriate to make such a requirement. For example, government agencies in the USA have defined profiles for specialized requirements for IPv6 in target environments (see [DODv6] and [USGv6]).

この文書では、便利なインターネットサービスを提供するために、デバイスに必要な要件の最低限のレベルを定義し、デバイスタイプおよび展開シナリオの広い範囲を考慮しています。なぜなら展開シナリオの広い範囲で、この文書で指定された最低限の要件は、すべての展開シナリオには十分ではないかもしれません。他のプロファイルは、特定の使用状況や展開環境のための適切な追加やより厳しい要件を定義することは完全に合理的(そして実際に予想される)です。たとえば、このドキュメントでは、すべてのクライアントがDHCPをサポートすることを強制しませんが、いくつかの展開シナリオは、それが適切な要求を行うこととみなすことができます。例えば、米国の政府機関は、ターゲット環境でのIPv6のための専門の要件([USGv6] [DODv6]を参照して)のためのプロファイルを定義しています。

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" [RFC0793].


1.1. Scope of This Document
1.1. この文書の範囲

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ノードのための要件を開発することが重要です。

This document assumes that all IPv6 nodes meet the minimum requirements specified here.


1.2. Description of IPv6 Nodes
1.2. IPv6ノードの説明

From the Internet Protocol, Version 6 (IPv6) Specification [RFC2460], we have the following definitions:


IPv6 node - a device that implements IPv6.

IPv6ノード - IPv6を実装するデバイス。

IPv6 router - a node that forwards IPv6 packets not explicitly addressed to itself.

IPv6ルータ - ではないが、明示的に自分宛てのIPv6パケットを転送するノード。

IPv6 host - any node that is not a router.

IPv6ホスト - ルータではありません任意のノード。

2. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。

3. Abbreviations Used in This Document

ATM Asynchronous Transfer Mode


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 Multiple Access


ND Neighbor Discovery


NS Neighbor Solicitation


NUD Neighbor Unreachability Detection


PPP Point-to-Point Protocol


4. Sub-IP Layer

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.


As IPv6 is run over new layer 2 technologies, it is expected that new specifications will be issued. In the following, we list 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.


- Transmission of IPv6 Packets over Ethernet Networks [RFC2464]

- イーサネットネットワークの上のIPv6パケットのトランスミッション[RFC2464]

- IPv6 over ATM Networks [RFC2492]

- ATMネットワーク上のIPv6 [RFC2492]

- Transmission of IPv6 Packets over Frame Relay Networks Specification [RFC2590]

- フレームリレーネットワーク仕様[RFC2590]の上のIPv6パケットのトランスミッション

- Transmission of IPv6 Packets over IEEE 1394 Networks [RFC3146]

- IEEE 1394ネットワーク[RFC3146]の上のIPv6パケットのトランスミッション

- 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:


- Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs) [RFC4380]

- のTeredo:ネットワークアドレス変換(NATを)を通じてUDP経由トンネルのIPv6 [RFC4380]

- Section 3 of "Basic Transition Mechanisms for IPv6 Hosts and Routers" [RFC4213]

- 「IPv6のホストとルータのための基本的な移行メカニズム」の第3節[RFC4213]

5. IP Layer
5. IPレイヤ
5.1. Internet Protocol Version 6 -
5.1. インターネットプロトコルバージョン6 -

The Internet Protocol Version 6 is specified in [RFC2460]. This specification MUST be supported.


Any unrecognized extension headers or options MUST be processed as described in RFC 2460.

RFC 2460に記載されているように認識されない拡張ヘッダまたはオプションを処理しなければなりません。

The node MUST follow the packet transmission rules in RFC 2460.

ノードは、RFC 2460でパケット転送ルールに従わなければなりません。

Nodes MUST always be able to send, receive, and process fragment headers. All conformant IPv6 implementations MUST be capable of sending and receiving IPv6 packets; the forwarding functionality MAY be supported. Overlapping fragments MUST be handled as described in [RFC5722].

ノードは常に、送信、受信、およびフラグメントヘッダを処理できなければなりません。全て準拠IPv6実装は、IPv6パケットを送受信することが可能でなければなりません。転送機能をサポートすることができます。 [RFC5722]に記載されているように重複するフラグメントが処理されなければなりません。

RFC 2460 specifies extension headers and the processing for these headers.

RFC 2460は、拡張ヘッダーおよびこれらのヘッダの処理を指定します。

An IPv6 node MUST be able to process these 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.


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.


5.2. Neighbor Discovery for IPv6 -
5.2. IPv6の近隣探索 -

Neighbor Discovery is defined in [RFC4861]; the definition was updated by [RFC5942]. Neighbor Discovery SHOULD be supported. 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は、そのサービスのいくつかのためにリンク層マルチキャストを使用しているのでしかし、いくつかのリンクタイプ(例えば、非ブロードキャストマルチアクセス(NBMA)リンク)、代替プロトコルまたはそれらのサービスを実装するためのメカニズムに指定される可能性があります(適切な文書で)特定のリンクタイプオーバーIPの動作を覆います。等リダイレクト、次ホップ決定、近隣非検出、等のマルチキャストに直接依存しない本書で記述されたサービスは、この文書で指定されるように提供されることが期待されます。 1は、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.

ホストはまた、ホストと隣接ノードの間のすべてのパスの近隣到達不能検出(NUD)を実装しなければなりません。 NUDルータ間のパスのために必要とされません。ただし、すべてのノードは、ユニキャスト近隣要請(NS)メッセージに応答しなければなりません。

Hosts MUST support the sending of Router Solicitations and the receiving of Router Advertisements. The ability to understand individual Router Advertisement options is dependent on supporting the functionality making use of the particular option.


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 backbone routers. They MAY be enabled by default on routers intended to support hosts on edge networks.


"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]はサポートされる必要があります。

5.3. Default Router Preferences and More-Specific Routes -
5.3. デフォルトルータの設定と、より詳細なルート -

"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 the other router does not, and choosing the "wrong" default router can result in reachability failures. In such cases, RFC 4191 can help.

「デフォルトルータの設定とより具体的なルート」[RFC4191]は複数に接続されたノードのサポート(異なる)ネットワーク、ルータ広告を介して、デフォルトルータとして自身をアドバタイズそれぞれ提供ルータを提供します。いくつかのシナリオでは、1つのルータが他のルータにはない宛先への接続性を提供してもよいし、「間違った」デフォルトルータを選択すると、到達可能性障害につながることができます。このような場合には、RFC 4191は助けることができます。

Small Office/Home Office (SOHO) deployments supported by routers adhering to [RFC6204] use RFC 4191 to advertise routes to certain local destinations. Consequently, nodes that will be deployed in SOHO environments SHOULD implement RFC 4191.

[RFC6204]に付着したルータでサポートされているスモールオフィス/ホームオフィス(SOHO)の展開は、特定の地域の目的地へのルートをアドバタイズするためにRFC 4191を使用します。その結果、SOHO環境で展開されるノードは、RFC 4191を実装する必要があります。

5.4. SEcure Neighbor Discovery (SEND) -
5.4. セキュアな近隣探索(SEND) -

SEND [RFC3971] and Cryptographically Generated Address (CGA) [RFC3972] provide a way to secure the message exchanges of Neighbor Discovery. SEND is a new technology in that it has no IPv4 counterpart, but it has significant potential to address certain classes of spoofing attacks. While there have been some implementations of SEND, there has been only limited deployment experience to date in using the technology. In addition, the IETF working group Cga & Send maIntenance (csi) is currently working on additional extensions intended to make SEND more attractive for deployment.

SEND [RFC3971]と暗号化生成アドレス(CGA)[RFC3972]は近隣探索のメッセージ交換を保護する方法を提供します。 SENDは、それが何のIPv4対応していないことで、新たな技術ですが、それはスプーフィング攻撃の特定のクラスに対処するための大きな可能性を秘めています。 SENDのいくつかの実装が行われているが、唯一の技術を使用して、日付への展開の経験が限られていました。また、IETFワーキンググループCGA&メンテナンス(CSI)を送るには、現在の展開のためのSENDをより魅力的にすることを目的と追加の拡張に取り組んでいます。

At this time, SEND is considered optional, and IPv6 nodes MAY provide SEND functionality.


5.5. IPv6 Router Advertisement Flags Option -
5.5. IPv6ルーター広告フラグオプション -

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, and 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.


5.6. Path MTU Discovery and Packet Size
5.6. パスMTUディスカバリおよびパケットサイズ
5.6.1. Path MTU Discovery -
5.6.1. パスMTUディスカバリ -

"Path MTU Discovery for IP version 6" [RFC1981] SHOULD be supported. From [RFC2460]:

[RFC1981]「IPバージョン6のパスMTUディスカバリーは、」サポートされる必要があります。 [RFC2460]から:

It is strongly recommended that IPv6 nodes implement Path MTU Discovery [RFC1981], 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.


The rules in [RFC2460] and [RFC5722] MUST be followed for packet fragmentation and reassembly.


One operational issue with Path MTU Discovery occurs when firewalls block ICMP Packet Too Big messages. Path MTU Discovery relies on such messages to determine what size messages can be successfully sent. "Packetization Layer Path MTU Discovery" [RFC4821] avoids having a dependency on Packet Too Big messages.

ファイアウォールは、ICMPパケット過大メッセージをブロックしたときにパスMTUディスカバリの一つの運用問題が発生します。パスMTUディスカバリは、メッセージが正常に送信することができますどのようなサイズを決定するためにこのようなメッセージに依存しています。 「パケット化レイヤのパスMTUディスカバリ」[RFC4821]はパケット過大メッセージに依存する必要がなくなります。

5.7. IPv6 Jumbograms -
5.7. IPv6のジャンボグラム -

IPv6 Jumbograms [RFC2675] are an optional extension that allow the sending of IP datagrams larger than 65.535 bytes. IPv6 Jumbograms make use of IPv6 hop-by-hop options and are only suitable on paths in which every hop and link are capable of supporting Jumbograms (e.g., within a campus or datacenter). To date, few implementations exist, and there is essentially no reported experience from usage.

IPv6のジャンボグラム[RFC2675]はIPの送信が65.535バイトを超えるデータグラム可能オプションの拡張です。 IPv6のジャンボグラムは、IPv6のホップバイホップオプションを利用すると、すべてのホップリンク(例えば、キャンパスまたはデータセンター内)ジャンボグラムをサポートすることができるされたパスにのみ適しています。現在までに、いくつかの実装が存在し、利用状況から本質的に報告経験がありません。

Consequently, IPv6 Jumbograms [RFC2675] remain optional at this time.


5.8. ICMP for the Internet Protocol Version 6 (IPv6) -
5.8. インターネットプロトコルバージョン6のためのICMP(IPv6)の -

ICMPv6 [RFC4443] MUST be supported. "Extended ICMP to Support Multi-Part Messages" [RFC4884] MAY be supported.

ICMPv6の[RFC4443]はサポートしなければなりません。 [RFC4884]「マルチパートメッセージをサポートするように拡張ICMPは、」サポートされるかもしれません。

5.9. Addressing
5.9. アドレッシング
5.9.1. IP Version 6 Addressing Architecture -
5.9.1. IPバージョン6のアーキテクチャへの対応 -

The IPv6 Addressing Architecture [RFC4291] MUST be supported.


5.9.2. IPv6 Stateless Address Autoconfiguration -
5.9.2. IPv6のステートレスアドレス自動設定 -

Hosts MUST support IPv6 Stateless Address Autoconfiguration as defined in [RFC4862]. Configuration of static address(es) may be supported as well.


Nodes that are routers MUST be able to generate link-local addresses as described in [RFC4862].


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].


"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は、取得してデバイスを迅速にあるネットワークから別のネットワークへ移動するようにアドレスを設定するのに必要な時間を削減するために、モバイルIPv6に関連して開発された、そして遷移遅延を最小にすることが望ましいです。汎用デバイスについては、RFC 4429は、この時点では、オプションのまま。

5.9.3. Privacy Extensions for Address Configuration in IPv6 -
5.9.3. IPv6でのアドレス構成のための個人情報保護の拡張 -

Privacy Extensions for Stateless Address Autoconfiguration [RFC4941] addresses a specific problem involving a client device whose user is concerned about its activity or location being tracked. The problem arises both for a static client and for one that regularly changes its point of attachment to the Internet. When using Stateless Address Autoconfiguration [RFC4862], the Interface Identifier portion of formed addresses stays constant and is globally unique. Thus, although a node's global IPv6 address will change if it changes its point of attachment, the Interface Identifier portion of those addresses remains the same, making it possible for servers to track the location of an individual device as it moves around or its pattern of activity if it remains in one place. This may raise privacy concerns as described in [RFC4862].

ステートレスアドレス自動設定[RFC4941]のための個人情報保護の拡張機能は、ユーザーのアクティビティや場所を懸念されて追跡されているクライアントデバイスを含む特定の問題に対処します。問題は、静的なクライアントのために、定期的にインターネットへの接続点を変更するいずれかの両方が生じます。ステートレスアドレス自動設定[RFC4862]を使用する場合、形成されたアドレスのインタフェース識別子部分は一定のままとグローバルに一意です。それは接続点を変更した場合、ノードのグローバルIPv6アドレスが変更されているがこのように、これらのアドレスのインタフェース識別子部分は、それが可能それが動き回る又はそのパターンとしてサーバは、個々のデバイスの位置を追跡するために作る、同じまま活動は、それが一つの場所に残っている場合。 [RFC4862]で説明したようにこれはプライバシーの問題を引き起こす可能性があります。

In such situations, RFC 4941 SHOULD be implemented. In other cases, such as with dedicated servers in a data center, RFC 4941 provides limited or no benefit.

このような状況では、RFC 4941を実装する必要があります。このようなデータセンター内の専用サーバーと同様に他の場合では、RFC 4941は、限られた又は全く利益を提供します。

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]を参照してください。

5.9.4. Default Address Selection for IPv6 -
5.9.4. IPv6のデフォルトのアドレス選択 -

The rules specified in the Default Address Selection for IPv6 [RFC3484] document MUST be implemented. IPv6 nodes will need to deal with multiple addresses configured simultaneously.

IPv6の[RFC3484]文書のデフォルトアドレス選択で指定されたルールを実装する必要があります。 IPv6ノードが同時に設定される複数のアドレスに対処する必要があります。

5.9.5. Stateful Address Autoconfiguration (DHCPv6) -
5.9.5. ステートフルアドレス自動設定(DHCPv6の) -

DHCPv6 [RFC3315] can be used to obtain and configure addresses. In general, a network may provide for the configuration of addresses through Router Advertisements, 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 address assignment. Consequently, all hosts SHOULD implement address configuration via DHCPv6.


In the absence of a router, IPv6 nodes using DHCP for address assignment MAY initiate DHCP to obtain IPv6 addresses and other configuration information, as described in Section 5.5.2 of [RFC4862].


5.10. Multicast Listener Discovery (MLD) for IPv6
5.10. IPv6のマルチキャストリスナー発見(MLD)

Nodes that need to join multicast groups MUST support MLDv1 [RFC2710]. MLDv1 is needed by any node that is expected to receive and process multicast traffic. Note that Neighbor Discovery (as used on most link types -- see Section 5.2) depends on multicast and requires that nodes join Solicited Node multicast addresses.

マルチキャストグループに参加する必要があるノードは、MLDv1を[RFC2710]をサポートしなければなりません。 MLDv1は、マルチキャストトラフィックを受信して​​処理することが期待されている任意のノードで必要とされます。マルチキャストに依存し、ノードが要請ノードマルチキャストアドレスに参加することが必要です - (5.2節を参照してくださいほとんどのリンクタイプで使用されるような)その近隣探索に注意してください。

MLDv2 [RFC3810] extends the functionality of MLDv1 by supporting Source-Specific Multicast. The original MLDv2 protocol [RFC3810] supporting Source-Specific Multicast [RFC4607] supports two types of "filter modes". Using an INCLUDE filter, a node indicates a multicast group along with a list of senders for the group from which it wishes to receive traffic. Using an EXCLUDE filter, a node indicates a multicast group along with a list of senders from which it wishes to exclude receiving traffic. In practice, operations to block source(s) using EXCLUDE mode are rarely used but add considerable implementation complexity to MLDv2. Lightweight MLDv2 [RFC5790] is a simplified subset of the original MLDv2 specification that omits EXCLUDE filter mode to specify undesired source(s).

MLDv2 [RFC3810]はソース固有マルチキャストをサポートすることのMLDv1の機能を拡張します。ソース固有マルチキャスト[RFC4607]を支持する元のMLDv2プロトコル[RFC3810]は、「フィルタモード」の2種類をサポートしています。 INCLUDEフィルタを使用して、ノードは、トラフィックを受信することを希望するグループのための送信者のリストと一緒にマルチキャストグループを示しています。 EXCLUDEフィルタを使用して、ノードは、トラフィックを受信除外したいそこから送信者のリストと一緒にマルチキャストグループを示しています。実際には、EXCLUDEモード使用してソース(S)をブロックする操作はほとんど使用されないが、MLDv2のにかなりの実装の複雑さを追加します。軽量のMLDv2 [RFC5790]は、望ましくないソース(S)を指定するフィルタモードをEXCLUDE省略元のMLDv2仕様の簡略化されたサブセットです。

Nodes SHOULD implement either MLDv2 [RFC3810] or Lightweight MLDv2 [RFC5790]. Specifically, nodes supporting applications using Source-Specific Multicast that expect to take advantage of MLDv2's EXCLUDE functionality [RFC3810] MUST support MLDv2 as defined in [RFC3810], [RFC4604], and [RFC4607]. Nodes supporting applications that expect to only take advantage of MLDv2's INCLUDE functionality as well as Any-Source Multicast will find it sufficient to support MLDv2 as defined in [RFC5790].

ノードは、MLDv2の[RFC3810]または軽量のMLDv2 [RFC5790]のいずれかを実装する必要があります。具体的には、[RFC3810]、[RFC4604]及び[RFC4607]で定義されるようにするMLDv2の機能をEXCLUDE [RFC3810]を利用することを期待ソース固有マルチキャストを使用してサポートアプリケーションはのMLDv2をサポートしなければならないノード。唯一のMLDv2のを活用することを期待するアプリケーションをサポートするノードは、機能性を含むだけでなく、任意の-ソースマルチキャストは、[RFC5790]で定義されているのMLDv2をサポートすることが十分でしょう。

If a node only supports applications that use Any-Source Multicast (i.e, they do not use Source-Specific Multicast), implementing MLDv1 [RFC2710] is sufficient. In all cases, however, nodes are strongly encouraged to implement MLDv2 or Lightweight MLDv2 rather than MLDv1, as the presence of a single MLDv1 participant on a link requires that all other nodes on the link operate in version 1 compatibility mode.


When MLDv1 is used, the rules in the Source Address Selection for the Multicast Listener Discovery (MLD) Protocol [RFC3590] MUST be followed.

MLDv1を使用する場合、Multicast Listener Discovery(MLD)プロトコル[RFC3590]のためのソースアドレス選択のルールに従わなければなりません。

6. DHCP versus Router Advertisement Options for Host Configuration
ホスト構成のためのRouter Advertisementオプション対6. DHCP

In IPv6, there are two main protocol mechanisms for propagating configuration information to hosts: Router Advertisements (RAs) and DHCP. Historically, 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. That said, identifying the exact line on whether a particular option should be configured via DHCP versus an RA option has not always been easy. 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.


One issue with having multiple ways of configuring 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 WIFI hotspot), problems can arise. To maximize interoperability in such environments, hosts would need to implement multiple configuration mechanisms to ensure interoperability.


Originally, in IPv6, configuring information about DNS servers was performed exclusively via DHCP. In 2007, an RA option was defined but was published as Experimental [RFC5006]. In 2010, "IPv6 Router Advertisement Options for DNS Configuration" [RFC6106] was published as a Standards Track document. Consequently, DNS configuration information can now be learned either through DHCP or through RAs. Hosts will need to decide which mechanism (or whether both) should be implemented. Specific guidance regarding DNS server discovery is discussed in Section 7.

もともと、IPv6では、DNSサーバに関する設定情報は、DHCP経由で独占的に実施されました。 2007年には、RAのオプションが定義されていたが、実験的な[RFC5006]として発行されました。 2010年には、[RFC6106]「DNS設定のためのIPv6ルータアドバタイズメントのオプションは、」標準化過程文書として公開されました。そのため、DNSの設定情報は現在、DHCPを介して、またはRAのいずれかを介して学習することができます。ホストは、そのメカニズム(あるいはその両方か)実装されるべきかを決定する必要があります。 DNSサーバー検出に関する具体的な指針は、第7節で議論されています。

7. DNS and DHCP
7.1. DNS
7.1. DNS

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 [RFC1034], Section 5.3.1, with support for:

DNSは、[RFC1034]、[RFC1035]、[RFC3363]及び[RFC3596]に記載されています。いないすべてのノードが名前を解決する必要があります。 DNS名を解決する必要は決してありませんものは、リゾルバ機能を実装する必要はありません。しかし、名前を解決する機能は、アプリケーションが依存している上での基本的なインフラ機能であり、最もノードがサポートを提供する必要があります。すべてのノードがをサポートする[RFC1034]、セクション5.3.1に記載のスタブリゾルバ[RFC1034]の機能を実装する必要があります。

- AAAA type Resource Records [RFC3596];

- AAAAリソースレコード[RFC3596]を入力し、

- reverse addressing in using PTR records [RFC3596];

- PTRレコード[RFC3596]を用いip6.arpaにアドレッシング逆。

- Extension Mechanisms for DNS (EDNS0) [RFC2671] to allow for DNS packet sizes larger than 512 octets.

- DNSパケットが512オクテットよりも大きいサイズのDNS(EDNS0)[RFC2671]のための拡張機構は許可します。

Those nodes are RECOMMENDED to support DNS security extensions [RFC4033] [RFC4034] [RFC4035].

これらのノードは、DNSセキュリティ拡張[RFC4033] [RFC4034] [RFC4035]をサポートすることをお勧めします。

Those nodes are NOT RECOMMENDED to support the experimental A6 Resource Records [RFC3363].


7.2. Dynamic Host Configuration Protocol for IPv6 (DHCPv6) -
7.2. IPv6の動的ホスト構成プロトコル(DHCPv6) -
7.2.1. Other Configuration Information
7.2.1. その他の構成情報

IPv6 nodes use DHCP [RFC3315] to obtain address configuration information (see Section 5.9.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.

IPv6ノード(セクション5.9.5を参照)アドレス構成情報を取得すると、追加の(非アドレス)の設定を取得するためにDHCP [RFC3315]を使用します。ホスト実装がDHCP経由でのみ利用可能である設定を必要とするアプリケーションまたは他のプロトコルをサポートしている場合、ホストはDHCPを実装する必要があります。そのような設定の必要性が存在しないその上で専門的なデバイスの場合、DHCPは必要ではないかもしれません。

An IPv6 node can use the subset of DHCP (described in [RFC3736]) to obtain other configuration information.


7.2.2. Use of Router Advertisements in Managed Environments
7.2.2. 管理された環境でのルータ広告の利用

Nodes using the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) are expected to determine their default router information and on-link prefix information from received Router Advertisements.


7.3. IPv6 Router Advertisement Options for DNS Configuration -
7.3. DNSの設定のためのIPv6ルータアドバタイズメントのオプション -

Router Advertisements have historically limited options to those that are critical to basic IPv6 functioning. 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. [RFC5006] was published as an Experimental document in 2007, and recently, a revised version was placed on the Standards Track [RFC6106].

ルータ広告は、基本的なIPv6の機能に不可欠なものに歴史的に限られた選択肢を持っています。もともとは、DNSの設定は、RAのオプションとして含まれ、DHCPは、DNSの設定情報を取得するための推奨方法だったいませんでした。時間が経つにつれて、そのようなオプションを取り巻く思考が進化してきました。今では一般的に少数のノードが動作してDNSリゾルバへのアクセスを持たずに適切に機能し得ることが認識されています。 [RFC5006]は、2007年に実験的文書として発表された、そして最近では、改訂版では標準化過程[RFC6106]の上に置きました。

Implementations SHOULD implement the DNS RA option [RFC6106].

実装は、DNS RAオプション[RFC6106]を実装する必要があります。

8. IPv4 Support and Transition
8. IPv4のサポートと遷移

IPv6 nodes MAY support IPv4.


8.1. Transition Mechanisms
8.1. 移行メカニズム

8.1.1. Basic Transition Mechanisms for IPv6 Hosts and Routers - 4213

8.1.1. IPv6のホストとルータのための基本的な変遷メカニズム - 4213

If an IPv6 node implements dual stack and tunneling, then [RFC4213] MUST be supported.


9. Application Support
9.1. Textual Representation of IPv6 Addresses -
9.1. IPv6ののテキスト表現はアドレス -

Software that allows users and operators to input IPv6 addresses in text form SHOULD support "A Recommendation for IPv6 Address Text Representation" [RFC5952].


9.2. Application Programming Interfaces (APIs)
9.2. アプリケーションプログラミングインタフェース(API)

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 RFC3493 has been picked up and further standardized by the Portable Operating System Interface (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 Socket API for Source Address Selection" [RFC5014] provides facilities that allow an application to override the default Source Address Selection rules of [RFC3484].


"Socket Interface Extensions for Multicast Source Filters" [RFC3678] provides support for expressing source filters on multicast group memberships.


"Extension to Sockets API for Mobile IPv6" [RFC4584] provides application support for accessing and enabling Mobile IPv6 [RFC6275] features.

「モバイルIPv6のソケットAPIへの拡張は、」[RFC4584]はアクセスし、モバイルIPv6 [RFC6275]の機能を有効にするためのアプリケーション・サポートを提供します。

10. Mobility

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. Recently, additional work has been done to support mobility in mixed-mode IPv4 and IPv6 networks [RFC5555].

現時点では、モバイルIPは、それが元々のIPv6のみの環境ではなく、IPv4 / 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, [RFC6275], [RFC5555], and associated standards such as [RFC4877] are considered a MAY at this time.


11. Security

This section describes the specification for security for IPv6 nodes.


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 provides channel security at the Internet layer, 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 provides sufficient flexibility and granularity that individual TCP connections can (selectively) be protected, etc.

IPsecは全て(またはサブセット)通信はインターネットノードの対の間のIPレイヤで流れることが可能な安全な通信を提供することが、インターネット層でのチャネルセキュリティを提供します。 IPsecは、個々のTCP接続が(選択的に)保護することができる十分な柔軟性及び粒度などを提供します

Although IPsec can be used with manual keying in some cases, such usage has limited applicability and is not recommended.


A range of security technologies and approaches proliferate today (e.g., IPsec, Transport Layer Security (TLS), Secure SHell (SSH), etc.) No one 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.


Previously, IPv6 mandated implementation of IPsec and recommended the key management approach of IKE. This document updates that recommendation by making support of the IPsec Architecture [RFC4301] a SHOULD for all IPv6 nodes. Note that the IPsec Architecture requires (e.g., Section 4.5 of RFC 4301) the implementation of both manual and automatic key management. Currently, the default automated key management protocol to implement is IKEv2 [RFC5996].

以前は、IPv6のは、IPsecの実装を義務付けとIKEの鍵管理アプローチをお勧めします。この文書は、すべてのIPv6ノードのIPsecアーキテクチャ[RFC4301] SHOULDの支援を行うことにより、その勧告を更新します。 IPsecのアーキテクチャ(RFC 4301の例えば、セクション4.5)手動および自動鍵管理の両方の実装を必要とすることに留意されたいです。現在、実装するためのデフォルトの自動化された鍵管理プロトコルは、IKEv2の[RFC5996]です。

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.


11.1. Requirements
11.1. 必要条件

"Security Architecture for the Internet Protocol" [RFC4301] SHOULD be supported by all IPv6 nodes. Note that the IPsec Architecture requires (e.g., Section 4.5 of [RFC4301]) the implementation of both manual and automatic key management. 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ノードによってサポートされる必要があります。 IPsecのアーキテクチャが必要であることに注意してください(例えば、[RFC4301]のセクション4.5)手動および自動キー管理の実装。現在、実装するためのデフォルトの自動化された鍵管理プロトコルは、IKEv2のです。 [RFC4301]で必要に応じて、IPsecのアーキテクチャを実装するIPv6ノードはESP [RFC4303]を実装しなければならないとAH [RFC4302]を実装してもよい(MAY)。

11.2. Transforms and Algorithms
11.2. トランスフォームとアルゴリズム

The current set of mandatory-to-implement algorithms for the IPsec Architecture are defined in "Cryptographic Algorithm Implementation Requirements For ESP and AH" [RFC4835]. IPv6 nodes implementing the IPsec Architecture MUST conform to the requirements in [RFC4835]. Preferred cryptographic algorithms often change more frequently than security protocols. Therefore, implementations MUST allow for migration to new algorithms, as RFC 4835 is replaced or updated in the future.

IPsecのアーキテクチャの実装に必須のアルゴリズムは、「ESPとAHのための暗号アルゴリズム実装要件」[RFC4835]で定義されている現在の一連。 IPv6は、IPsecのアーキテクチャは、[RFC4835]の要求事項に従わなければなりません実装するノード。好適な暗号化アルゴリズムは、多くの場合、セキュリティプロトコルよりも頻繁に変更します。 RFC 4835を交換したり、将来的に更新されるので、実装は、新しいアルゴリズムへの移行を考慮しなければなりません。

The current set of mandatory-to-implement algorithms for IKEv2 are defined in "Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2)" [RFC4307]. IPv6 nodes implementing IKEv2 MUST conform to the requirements in [RFC4307] and/or any future updates or replacements to [RFC4307].

IKEv2のための実装に必須のアルゴリズムの現在のセットは、[RFC4307]「インターネット鍵交換バージョン2(IKEv2の)で使用するための暗号アルゴリズム」で定義されています。 IPv6は、IKEv2のは[RFC4307]と[RFC4307]での要件および/または任意の将来の更新または交換に従わなければなりません実装するノード。

12. Router-Specific Functionality

This section defines general host considerations for IPv6 nodes that act as routers. Currently, this section does not discuss routing-specific requirements.


12.1. IPv6 Router Alert Option -
12.1. IPv6ルーターの警告オプション -

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 (MLD) [RFC2710]). The Router Alert option will need to be implemented whenever protocols that mandate its usage (e.g., MLD) are implemented. See Section 5.10.

IPv6ルーター警告オプション[RFC2711]は、オプションのIPv6のホップバイホップヘッダいくつかのプロトコル(例えば、RSVP [RFC2205]またはマルチキャストリスナー発見(MLD)[RFC2710])と組み合わせて使用​​されています。その使用(例えば、MLD)を義務付けるプロトコルが実装されるたびにルータアラートオプションが実装する必要があります。 5.10を参照してください。

12.2. Neighbor Discovery for IPv6 -
12.2. IPv6の近隣探索 -

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.


12.3. Stateful Address Autoconfiguration (DHCPv6) -
12.3. ステートフルアドレス自動設定(DHCPv6の) -

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.


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., [RFC6204]). However, there is no need for relay agents in such scenarios.


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.


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" [RFC6204] requires implementation of a DHCPv6 server function in IPv6 Customer Edge (CE) routers.

なぜなら展開シナリオの広い範囲で、ルータのDHCPサーバ機能のサポートはオプションです。しかしながら、(上記のように)より複雑なシナリオの中に配備するためのターゲットルータは、リレーエージェント機能をサポートする必要があります。 [RFC6204]はIPv6のカスタマーエッジ(CE)ルータでDHCPv6サーバ機能の実装を必要とする「IPv6のカスタマーエッジルータのための基本要件」ことに注意してください。

13. Network Management

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.


13.1. Management Information Base (MIB) Modules
13.1. 管理情報ベース(MIB)モジュール

The following two MIB modules SHOULD be supported by nodes that support a Simple Network Management Protocol (SNMP) agent.

次の二つのMIBモジュールは、SNMP(Simple Network Management Protocol)エージェントをサポートするノードによってサポートされる必要があります。

13.1.1. IP Forwarding Table MIB
13.1.1. IP転送テーブルMIB

The IP Forwarding Table MIB [RFC4292] SHOULD be supported by nodes that support an SNMP agent.

IP転送テーブルMIB [RFC4292]はSNMPエージェントをサポートしているノードによってサポートされるべきです。

13.1.2. Management Information Base for the Internet Protocol (IP)
13.1.2. インターネットプロトコルのための管理情報ベース(IP)

The IP MIB [RFC4293] SHOULD be supported by nodes that support an SNMP agent.

IP MIB [RFC4293]はSNMPエージェントをサポートしているノードによってサポートされるべきです。

14. Security Considerations

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 11 above.


15. Authors and Acknowledgments
15.1. Authors and Acknowledgments (Current Document)
15.1. 著者と謝辞(現在のドキュメント)

For this version of the IPv6 Node Requirements document, the authors would like to 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.


15.2. Authors and Acknowledgments from
15.2. 著者と謝辞から

The original version of this document (RFC 4279) was written by the IPv6 Node Requirements design team:

この文書(RFC 4279)のオリジナル版は、IPv6ノード要件のデザインチームによって書かれました:

Jari Arkko


Marc Blanchet


Samita Chakrabarti


Alain Durand


Gerard Gastaud


Jun-ichiro Itojun Hagino

じゅんーいちろ いとじゅん はぎの いとじゅん@いいjぁb。ねt

Atsushi Inoue

あつし いのうえ いのうえ@いsl。rdc。としば。こ。jp

Masahiro Ishiyama

まさひろ いしやま まさひろ@いsl。rdc。としば。こ。jp

John Loughney


Rajiv Raghunarayan


Shoichi Sakane

しょいち さかね しょういち。さかね@jp。よこがわ。こm

Dave Thaler


Juha Wiljakka


The authors would like to thank Ran Atkinson, Jim Bound, Brian Carpenter, Ralph Droms, Christian Huitema, Adam Machalek, Thomas Narten, Juha Ollila, and Pekka Savola for their comments. Thanks to Mark Andrews for comments and corrections on DNS text. Thanks to Alfred Hoenes for tracking the updates to various RFCs.

作者は彼らのコメントのために、蘭アトキンソン、ジムはバウンドブライアン・カーペンター、ラルフDroms、クリスチャンのHuitema、アダムMachalek、トーマスNarten氏、ユハ・オリラ、およびペッカSavolaに感謝したいと思います。 DNSテキストのコメントと修正のためのマーク・アンドリュースに感謝します。さまざまなRFCへの更新を追跡するためのアルフレッドHoenesに感謝します。

16. Appendix: Changes from

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.


2. Significantly updated the section on Mobility protocols, adding references and downgrading previous SHOULDs to MAYs.


3. Changed Sub-IP Layer section to just list relevant RFCs, and added some more RFCs.


4. Added section on SEND (it is a MAY).
SEND 4.セクションを追加(これはMAYです)。

5. Revised section on Privacy Extensions [RFC4941] to add more nuance to recommendation.


6. Completely revised IPsec/IKEv2 section, downgrading overall recommendation to a SHOULD.

6.完全SHOULDへの全体的な勧告をダウングレード、IPsecの/ IKEv2のセクションを改訂します。

7. Upgraded recommendation of DHCPv6 to SHOULD.
7. SHOULDへのDHCPv6の勧告をアップグレードしました。

8. Added background section on DHCP versus RA options, added SHOULD recommendation for DNS configuration via RAs [RFC6106], and cleaned up DHCP recommendations.

8. RAオプションに対するDHCPで追加の背景部が、RAの[RFC6106]を介してDNS構成のSHOULD推奨を加え、DHCPの推奨をクリーンアップ。

9. Added recommendation that routers implement Sections 7.3 and 7.5 of [RFC6275].


10. Added pointer to subnet clarification document [RFC5942].

11. Added text that "IPv6 Host-to-Router Load Sharing" [RFC4311] SHOULD be implemented.


12. Added reference to [RFC5722] (Overlapping Fragments), and made it a MUST to implement.


13. Made "A Recommendation for IPv6 Address Text Representation" [RFC5952] a SHOULD.

13. [RFC5952] SHOULDの「IPv6アドレスのテキスト表現のための勧告」を作りました。

14. Removed mention of "DNAME" from the discussion about [RFC3363].

15. Numerous updates to reflect newer versions of IPv6 documents, including [RFC4443], [RFC4291], [RFC3596], and [RFC4213].


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].


17. Added many more references to optional IPv6 documents.

18. Made "A Recommendation for IPv6 Address Text Representation" [RFC5952] a SHOULD.

18. [RFC5952] SHOULDの「IPv6アドレスのテキスト表現のための勧告」を作りました。

19. Added reference to [RFC5722] (Overlapping Fragments), and made it a MUST to implement.


20. Updated MLD section to include reference to Lightweight MLD [RFC5790].

軽量MLD [RFC5790]への参照を含むように前記更新されたMLD部。

21. Added SHOULD recommendation for "Default Router Preferences and More-Specific Routes" [RFC4191].

「デフォルトルータの設定と、より詳細なルート」[RFC4191] 21.追加するかの勧告。

22. Made "IPv6 Flow Label Specification" [RFC6437] a SHOULD.
22.メイドの "IPv6フローラベル仕様" [RFC6437] SHOULD。
17. References
17.1. Normative References
17.1. 引用規格

[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.

[RFC1034] Mockapetris、P.、 "ドメイン名 - 概念と設備"、STD 13、RFC 1034、1987年11月。

[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.

[RFC1035] Mockapetris、P.、 "ドメイン名 - 実装及び仕様"、STD 13、RFC 1035、1987年11月。

[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.

[RFC1981]マッキャン、J.、デアリング、S.、およびJ.ムガール人、RFC 1981、1996年8月 "IPバージョン6のパスMTUディスカバリー"。

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。

[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.

[RFC2460]デアリング、S.とR. Hindenと、 "インターネットプロトコルバージョン6(IPv6)の仕様"、RFC 2460、1998年12月。

[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999.

[RFC2671]いるVixie、P.、 "DNS用拡張メカニズム(EDNS0)"、RFC 2671、1999年8月。

[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.

[RFC2710]デアリング、S.、フェナー、W.、およびB.ハーバーマン、 "IPv6のためのマルチキャストリスナー発見(MLD)"、RFC 2710、1999年10月。

[RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", RFC 2711, October 1999.

[RFC2711]ウズラ、C.とA.ジャクソン、 "IPv6のルータアラートオプション"、RFC 2711、1999年10月。

[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.

[RFC3315] Droms、R.、バウンド、J.、フォルツ、B.、レモン、T.、パーキンス、C.、およびM.カーニー、 "IPv6のための動的ホスト構成プロトコル(DHCPv6)"、RFC 3315、2003年7月。

[RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.

[RFC3484] Draves、R.、RFC 3484 "インターネットプロトコルバージョン6(IPv6)のデフォルトのアドレス選択"、2003年2月。

[RFC3590] Haberman, B., "Source Address Selection for the Multicast Listener Discovery (MLD) Protocol", RFC 3590, September 2003.

[RFC3590]ハーバーマン、B.、 "Multicast Listener Discovery(MLD)プロトコルのためのソースアドレス選択"、RFC 3590、2003年9月。

[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS Extensions to Support IP Version 6", RFC 3596, October 2003.

[RFC3596]トムソン、S.、のHuitema、C.、Ksinant、V.、およびM. Souissi、RFC 3596、2003年10月 "DNSの拡張機能は、IPバージョン6をサポートします"。

[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, April 2004.

[RFC3736] Droms、R.、 "IPv6のステートレス動的ホスト構成プロトコル(DHCP)サービス"、RFC 3736、2004年4月。

[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.

"IPv6のマルチキャストリスナ発見バージョン2(MLDv2の)" [RFC3810]ヴィーダ、R.とL.コスタ、RFC 3810、2004年6月。

[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.

[RFC4033]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "DNSセキュリティ序論と要件"、RFC 4033、2005年3月。

[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005.

[RFC4034]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "DNSセキュリティ拡張機能のためのリソースレコード"、RFC 4034、2005年3月。

[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.

[RFC4035]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "DNSセキュリティ拡張のためのプロトコル変更"、RFC 4035、2005年3月。

[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005.

[RFC4213] Nordmarkと、E.とR.ギリガン、 "IPv6ホストとルータのための基本的な変遷メカニズム"、RFC 4213、2005年10月。

[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.

[RFC4291] HindenとR.とS.デアリング、 "IPバージョン6アドレッシング体系"、RFC 4291、2006年2月。

[RFC4292] Haberman, B., "IP Forwarding Table MIB", RFC 4292, April 2006.

[RFC4292]ハーバーマン、B.、 "IP転送テーブルMIB"、RFC 4292、2006年4月。

[RFC4293] Routhier, S., "Management Information Base for the Internet Protocol (IP)", RFC 4293, April 2006.

[RFC4293] Routhier、S.、 "インターネットプロトコル(IP)のための管理情報ベース"、RFC 4293、2006年4月。

[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.

[RFC4301]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、2005年12月。

[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.

[RFC4303]ケント、S.、 "IPカプセル化セキュリティペイロード(ESP)"、RFC 4303、2005年12月。

[RFC4307] Schiller, J., "Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2)", RFC 4307, December 2005.

[RFC4307]シラー、J.、 "インターネット鍵交換バージョン2(IKEv2の)での使用のための暗号アルゴリズム"、RFC 4307、2005年12月。

[RFC4311] Hinden, R. and D. Thaler, "IPv6 Host-to-Router Load Sharing", RFC 4311, November 2005.

[RFC4311] HindenとR.とD.ターラー、 "IPv6ホストツールーター負荷分散"、RFC 4311、2005年11月。

[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006.

[RFC4443]コンタ、A.、デアリング、S.、およびM.グプタ、 "インターネットプロトコルバージョン6(IPv6)の仕様のためのインターネット制御メッセージプロトコル(ICMPv6の)"、RFC 4443、2006年3月。

[RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific Multicast", RFC 4604, August 2006.

[RFC4604]ホルブルック、H.、カイン、B.、およびB.ハーバーマン、 "ソース固有マルチキャストのためにインターネットグループ管理プロトコルバージョン3(IGMPv3の)およびマルチキャストリスナ発見プロトコルバージョン2(MLDv2の)の使用"、RFC 4604、8月2006。

[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006.

[RFC4607]ホルブルック、H.、およびB.カイン、 "IPのためのソース固有のマルチキャスト"、RFC 4607、2006年8月。

[RFC4835] Manral, V., "Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 4835, April 2007.

[RFC4835] Manral、V.、RFC 4835、2007年4月 "カプセル化セキュリティペイロード(ESP)と認証ヘッダー(AH)のための暗号アルゴリズム実装要件"。

[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.

[RFC4861] Narten氏、T.、Nordmarkと、E.、シンプソン、W.、およびH.ソリマン、 "IPバージョン6(IPv6)のための近隣探索"、RFC 4861、2007年9月。

[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.

[RFC4862]トムソン、S.、Narten氏、T.、およびT.神明、 "IPv6のステートレスアドレス自動設定"、RFC 4862、2007年9月。

[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, September 2007.

[RFC4941] Narten氏、T.、Draves、R.、およびS.クリシュナン、 "IPv6におけるステートレスアドレス自動設定のための個人情報保護の拡張"、RFC 4941、2007年9月。

[RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation of Type 0 Routing Headers in IPv6", RFC 5095, December 2007.

[RFC5095] Abley、J.、Savola、P.、およびG.ネビル・ニール、 "ルーティングヘッダIPv6におけるタイプ0の廃止"、RFC 5095、2007年12月。

[RFC5453] Krishnan, S., "Reserved IPv6 Interface Identifiers", RFC 5453, February 2009.

[RFC5453]クリシュナン、S.、 "予約済みIPv6インタフェース識別子"、RFC 5453、2009年2月。

[RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments", RFC 5722, December 2009.

[RFC5722]クリシュナン、S.、 "重複のIPv6フラグメントの取り扱い"、RFC 5722、2009年12月。

[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, February 2010.

[RFC5790]劉、H.、曹操、W.、およびH. Asaeda、 "軽量インターネットグループ管理プロトコルバージョン3(IGMPv3の)およびマルチキャストリスナ発見バージョン2(MLDv2の)プロトコル"、RFC 5790、2010年2月。

[RFC5942] Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes", RFC 5942, July 2010.

[RFC5942]シン、H.、Beebee、W.、およびE. Nordmarkと、 "IPv6のサブネットモデル:リンクとサブネットプレフィックスとの関係"、RFC 5942、2010年7月。

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

[RFC5952]川村、S.とM.川島、RFC 5952、2010年8月、 "IPv6アドレスのテキスト表現のための勧告"。

[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.

[RFC5996]カウフマン、C.、ホフマン、P.、ニール、Y.、およびP. Eronen、 "インターネット鍵交換プロトコルバージョン2(IKEv2の)"、RFC 5996、2010年9月。

[RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, "IPv6 Router Advertisement Options for DNS Configuration", RFC 6106, November 2010.

[RFC6106]チョン、J.、公園、S.、Beloeilの、L.、およびS. Madanapalli、 "DNS設定のためのIPv6ルータアドバタイズメントのオプション"、RFC 6106、2010年11月。

[RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O. Troan, "Basic Requirements for IPv6 Customer Edge Routers", RFC 6204, April 2011.

[RFC6204]シン、H.、Beebee、W.、Donley、C.、スターク、B.、およびO. Troan、 "IPv6のカスタマーエッジルータのための基本要件"、RFC 6204、2011年4月。

[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, "IPv6 Flow Label Specification", RFC 6437, November 2011.

[RFC6437] Amante、S.、大工、B.、江、S.、およびJ. Rajahalme、 "IPv6のフローラベル仕様"、RFC 6437、2011年11月。

17.2. Informative References
17.2. 参考文献

[DODv6] DISR IPv6 Standards Technical Working Group, "DoD IPv6 Standard Profiles For IPv6 Capable Products Version 5.0", July 2010, <>.

[DODv6] DISR IPv6の標準技術作業部会、2010年7月の "IPv6対応製品のバージョン5.0については、国防総省のIPv6標準プロファイル"、<>。

[POSIX] IEEE, "IEEE Std. 1003.1-2008 Standard for Information Technology -- Portable Operating System Interface (POSIX), ISO/IEC 9945:2009", <>.

[POSIX] IEEE、 "IEEE STD 1003.1から2008規格情報技術 - ポータブルオペレーティングシステムインタフェース(POSIX)、ISO / IEC 9945:2009"、<>。

[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.

[RFC0793]ポステル、J.、 "伝送制御プロトコル"、STD 7、RFC 793、1981年9月。

[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.

[RFC2205]ブレーデン、B.、チャン、L.、Berson氏、S.、ハーツォグ、S.、およびS.ヤミン、 "リソース予約プロトコル(RSVP) - バージョン1機能仕様"、RFC 2205、1997年9月。

[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998.

[RFC2464]クロフォード、M.、 "イーサネットネットワークの上のIPv6パケットのトランスミッション"、RFC 2464、1998年12月。

[RFC2491] Armitage, G., Schulter, P., Jork, M., and G. Harter, "IPv6 over Non-Broadcast Multiple Access (NBMA) networks", RFC 2491, January 1999.

、RFC 2491、1999年1月 "非ブロードキャスト多重アクセス(NBMA)ネットワーク上のIPv6" [RFC2491]アーミテージ、G.、Schulter、P.、Jorkの、M.、およびG.ハーター、。

[RFC2492] Armitage, G., Schulter, P., and M. Jork, "IPv6 over ATM Networks", RFC 2492, January 1999.

[RFC2492]アーミテージ、G.、Schulter、P.、およびM. Jorkの、 "ATMネットワーク上のIPv6"、RFC 2492、1999年1月。

[RFC2590] Conta, A., Malis, A., and M. Mueller, "Transmission of IPv6 Packets over Frame Relay Networks Specification", RFC 2590, May 1999.

[RFC2590]コンタ、A.、Malis、A.、およびM.ミュラー、 "フレームリレーネットワークの仕様上のIPv6パケットの送信"、RFC 2590、1999年5月。

[RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", RFC 2675, August 1999.

[RFC2675]ボーマン、D.、デアリング、S.、およびR. Hindenと "IPv6のジャンボグラム"、RFC 2675、1999年8月。

[RFC3146] Fujisawa, K. and A. Onoe, "Transmission of IPv6 Packets over IEEE 1394 Networks", RFC 3146, October 2001.

[RFC3146]藤沢、K.とA.尾上、 "IEEE 1394のネットワークの上のIPv6パケットのトランスミッション"、RFC 3146、2001年10月。

[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, August 2002.

[RFC3363]ブッシュ、R.、デュラン、A.、フィンク、B.、グドムンソン、O.、およびT.ハイン、RFC 3363 "ドメインネームシステム(DNS)にインターネットプロトコルバージョン6(IPv6)アドレスを表します" 、2002年8月。

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

[RFC3493]ギリガン、R.、トムソン、S.、バウンド、J.、マッキャン、J.、およびW.スティーブンス、 "IPv6の基本的なソケットインタフェース拡張"、RFC 3493、2003年2月。

[RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, "Advanced Sockets Application Program Interface (API) for IPv6", RFC 3542, May 2003.

"IPv6用の拡張ソケットアプリケーション・プログラム・インターフェース(API)" [RFC3542]スティーブンス、W.、トーマス、M.、Nordmarkと、E.、およびT.神明、RFC 3542、2003年5月。

[RFC3678] Thaler, D., Fenner, B., and B. Quinn, "Socket Interface Extensions for Multicast Source Filters", RFC 3678, January 2004.

[RFC3678]ターラー、D.、フェナー、B.、およびB.クイン、RFC 3678 "マルチキャストソースフィルタのためのソケットインタフェース拡張"、2004年1月。

[RFC3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents", RFC 3776, June 2004.

[RFC3776] Arkko、J.、Devarapalli、V.、およびF.デュポン、 "モバイルノードとホームエージェント間のモバイルIPv6シグナリングを保護するためにIPsecを使用する"、RFC 3776、2004年6月。

[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.

[RFC3971] Arkko、J.、ケンプ、J.、Zill、B.、およびP. Nikander、 "セキュア近隣探索(SEND)"、RFC 3971、2005年3月。

[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005.

[RFC3972]オーラ、T.、 "暗号的に生成されたアドレス(CGA)"、RFC 3972、2005年3月。

[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191, November 2005.

[RFC4191] Draves、R.とD.ターラー、 "デフォルトルータの設定と、より詳細なルート"、RFC 4191、2005年11月。

[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.

[RFC4302]ケント、S.、 "IP認証ヘッダー"、RFC 4302、2005年12月。

[RFC4338] DeSanti, C., Carlson, C., and R. Nixon, "Transmission of IPv6, IPv4, and Address Resolution Protocol (ARP) Packets over Fibre Channel", RFC 4338, January 2006.

[RFC4338] DeSanti、C.、カールソン、C.、およびR.ニクソン、 "IPv6の、IPv4のの送信、アドレス解決プロトコル(ARP)、ファイバチャネル上のパケット"、RFC 4338、2006年1月。

[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006.

[RFC4380]のHuitema、C.、 "のTeredo:ネットワークアドレス変換を通じてUDP経由トンネリングのIPv6器(NAT)"、RFC 4380、2006年2月。

[RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) for IPv6", RFC 4429, April 2006.

[RFC4429]ムーア、N.、 "IPv6の楽観重複アドレス検出(DAD)"、RFC 4429、2006年4月。

[RFC4584] Chakrabarti, S. and E. Nordmark, "Extension to Sockets API for Mobile IPv6", RFC 4584, July 2006.

[RFC4584] Chakrabarti、S。およびE. Nordmarkと、 "モバイルIPv6のためのソケットAPIへの拡張"、RFC 4584、2006年7月。

[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, March 2007.

[RFC4821]マシス、M.とJ. Heffner、 "パケット化レイヤのパスMTUディスカバリ"、RFC 4821、2007年3月。

[RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture", RFC 4877, April 2007.

[RFC4877] Devarapalli、V.とF.デュポン、 "IKEv2のと改訂のIPsecアーキテクチャとのモバイルIPv6の操作"、RFC 4877、2007年4月。

[RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "Extended ICMP to Support Multi-Part Messages", RFC 4884, April 2007.

[RFC4884] Bonica、R.、ガン、D.、タッパン、D.、およびC. Pignataro、RFC 4884、2007年4月 "拡張ICMPは、マルチパートメッセージをサポートするために"。

[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, September 2007.

[RFC4944]モンテネグロ、G.、クシャルナガル、N.、ホイ、J.、およびD. Culler、 "IEEE 802.15.4ネットワークの上のIPv6パケットの送信"、RFC 4944、2007年9月。

[RFC5006] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, "IPv6 Router Advertisement Option for DNS Configuration", RFC 5006, September 2007.

[RFC5006]チョン、J.、公園、S.、Beloeilの、L.、およびS. Madanapalli、 "DNS設定のためのIPv6ルータアドバタイズメント・オプション"、RFC 5006、2007年9月。

[RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6 Socket API for Source Address Selection", RFC 5014, September 2007.

[RFC5014] Nordmarkと、E.、Chakrabarti、S.、およびJ. Laganier、 "ソースアドレス選択のIPv6ソケットAPI"、RFC 5014、2007年9月。

[RFC5072] S.Varada, Haskins, D., and E. Allen, "IP Version 6 over PPP", RFC 5072, September 2007.

[RFC5072] S.Varada、ハスキンズ、D.、およびE.アレン、 "PPPオーバーIPバージョン6"、RFC 5072、2007年9月。

[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, February 2008.

[RFC5121]パティル、B.、夏、F.、Sarikaya、B.、チェ、JH。、およびS. Madanapalli、 "IEEE 802.16ネットワークの上のIPv6コンバージェンスサブレイヤを介したIPv6の送信"、RFC 5121、2008年2月。

[RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and Routers", RFC 5555, June 2009.

[RFC5555]ソリマン、H.、RFC 5555 "デュアルスタックホストとルータのためのモバイルIPv6のサポート"、2009年6月。

[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, July 2011.

[RFC6275]パーキンス、C.、ジョンソン、D.、およびJ. Arkko、 "IPv6におけるモビリティサポート"、RFC 6275、2011年7月。

[USGv6] National Institute of Standards and Technology, "A Profile for IPv6 in the U.S. Government - Version 1.0", July 2008, <>.

[USGv6]米国国立標準技術研究所、「米国政府におけるIPv6のプロフィール - バージョン1.0」、2008年7月、<>。

Authors' Addresses


Ed Jankiewicz SRI International, Inc. 333 Ravenswood Ave. Menlo Park, CA 94025 USA

エドJankiewicz SRIインターナショナル社333レーヴンズウッドアベニュー。メンロパーク、CA 94025 USA

Phone: +1 443 502 5815 EMail:

電話:+1 443 502 5815 Eメール

John Loughney Nokia 200 South Mathilda Ave. Sunnyvale, CA 94086 USA

ジョンLoughneyノキア200南マチルダアベニュー。サニーベール、CA 94086 USA

Phone: +1 650 283 8068 EMail:

電話:+1 650 283 8068 Eメール

Thomas Narten IBM Corporation 3039 Cornwallis Ave. PO Box 12195 Research Triangle Park, NC 27709-2195 USA

トーマスNarten氏IBMコーポレーション3039コーンウォリスアベニュー。私書箱12195リサーチトライアングルパーク、ノースカロライナ州27709から2195 USA

Phone: +1 919 254 7798 EMail:

電話:+1 919 254 7798 Eメール