Network Working Group J. Loughney, Ed.
Request for Comments: 4294 Nokia
Category: Informational April 2006
IPv6 Node Requirements
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
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がうまく機能し、状況や展開、多数の相互運用を可能にします。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Requirement Language .......................................3
1.2. Scope of This Document .....................................3
1.3. Description of IPv6 Nodes ..................................3
2. Abbreviations Used in This Document .............................3
3. Sub-IP Layer ....................................................4
3.1. Transmission of IPv6 Packets over Ethernet Networks
- RFC 2464 .................................................4
3.2. IP version 6 over PPP - RFC 2472 ...........................4
3.3. IPv6 over ATM Networks - RFC 2492 ..........................4
4. IP Layer ........................................................5
4.1. Internet Protocol Version 6 - RFC 2460 .....................5
4.2. Neighbor Discovery for IPv6 - RFC 2461 .....................5
4.3. Path MTU Discovery and Packet Size .........................6
4.4. ICMP for the Internet Protocol Version 6 (IPv6) -
RFC 2463 ...................................................7
4.5. Addressing .................................................7
4.6. Multicast Listener Discovery (MLD) for IPv6 - RFC 2710 .....8
5. DNS and DHCP ....................................................8
5.1. DNS ........................................................8
5.2. Dynamic Host Configuration Protocol for IPv6
(DHCPv6) - RFC 3315 ........................................9
6. IPv4 Support and Transition ....................................10
6.1. Transition Mechanisms .....................................10
7. Mobile IP ......................................................10
8. Security .......................................................10
8.1. Basic Architecture ........................................10
8.2. Security Protocols ........................................11
8.3. Transforms and Algorithms .................................11
8.4. Key Management Methods ....................................12
9. Router-Specific Functionality ..................................12
9.1. General ...................................................12
10. Network Management ............................................12
10.1. Management Information Base Modules (MIBs) ...............12
11. Security Considerations .......................................13
12. References ....................................................13
12.1. Normative References .....................................13
12.2. Informative References ...................................16
13. Authors and Acknowledgements ..................................18
The goal of this document is to define the common functionality required from both IPv6 hosts and routers. Many IPv6 nodes will implement optional or additional features, but this document summarizes requirements from other published Standards Track documents in one place.
このドキュメントの目的は、IPv6ホストとルータの両方から必要な共通の機能を定義することです。多くのIPv6ノードは、オプションや追加機能を実装しますが、この文書は、一つの場所に他の公開標準化過程ドキュメントから要件をまとめたもの。
This document tries to avoid discussion of protocol details, and references RFCs for this purpose. This document is informational in nature and does not update Standards Track RFCs.
この文書では、プロトコルの詳細の議論を避けようとし、この目的のためにRFCを参照しています。この文書では、自然の中で情報提供され、標準化過程RFCを更新しません。
Although the document points to different specifications, it should be noted that in most cases, the granularity of requirements are smaller than a single specification, as many specifications define multiple, independent pieces, some of which may not be mandatory.
異なる仕様に文書ポイントが、多くの仕様は必須ではないかもしれないいくつかは複数の独立した部分を、定義として、ほとんどの場合、要求の粒度は、単一の仕様よりも小さいことに留意すべきです。
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:
実装者は、ノードでのIPv6の正確な使用方法を知ることが常に可能ではないとして、IPv6ノードのための最優先の要件は、ジョン・ポステルの頑健性の原則に従うべきであるということです。
Be conservative in what you do, be liberal in what you accept from others [RFC-793].
あなたは何をすべきかで保守的である、あなたが他の人[RFC-793]から受け入れるものの中にリベラルこと。
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 [RFC-2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119 [RFC-2119]に記載されているように解釈されます。
IPv6 covers many specifications. It is intended that IPv6 will be deployed in many different situations and environments. Therefore, it is important to develop the requirements for IPv6 nodes to ensure interoperability.
IPv6は多くの仕様をカバーしています。 IPv6が多くの異なる状況や環境に配備されることが意図されています。したがって、相互運用性を確保するために、IPv6ノードのための要件を開発することが重要です。
This document assumes that all IPv6 nodes meet the minimum requirements specified here.
この文書は、すべてのIPv6ノードは、ここで指定された最小要件を満たしていることを前提としています。
From the Internet Protocol, Version 6 (IPv6) Specification [RFC-2460], we have the following definitions:
インターネットプロトコルバージョン6（IPv6）の仕様[RFC-2460]から、我々は次のような定義があります。
Description of an IPv6 Node
IPv6のノードの説明
- a device that implements IPv6.
- IPv6を実装してデバイス。
Description of an IPv6 router
IPv6ルータの説明
- a node that forwards IPv6 packets not explicitly addressed to itself.
- IPv6を転送するノードは、明示的に自分宛ではないパケット。
Description of an IPv6 Host
IPv6ホストの説明
- any node that is not a router.
- ルータではありません任意のノード。
ATM Asynchronous Transfer Mode
ATM非同期転送モード
AH Authentication Header
AH認証ヘッダー
DAD Duplicate Address Detection
DAD重複アドレス検出
ESP Encapsulating Security Payload
ESPカプセル化セキュリティペイロード
ICMP Internet Control Message Protocol
ICMPインターネット制御メッセージプロトコル
IKE Internet Key Exchange
IKEインターネットキー交換
MIB Management Information Base
MIB管理情報ベース
MLD Multicast Listener Discovery
MLDのマルチキャストリスナ発見
MTU Maximum Transfer Unit
MTU最大転送ユニット
NA Neighbor Advertisement
NAの近隣広告
NBMA Non-Broadcast Multiple Access
NBMA非ブロードキャストマルチアクセス
ND Neighbor Discovery
NDの近隣探索
NS Neighbor Solicitation
NSの近隣要請
NUD Neighbor Unreachability Detection
NUDの近隣到達不能検出
PPP Point-to-Point Protocol
PPPポイントツーポイントプロトコル
PVC Permanent Virtual Circuit
PVCパーマネントバーチャルサーキット
SVC Switched Virtual Circuit
SVCは、仮想回線を交換しました
An IPv6 node must include support for one or more IPv6 link-layer specifications. Which link-layer specifications are included 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ノードは、一の以上のIPv6リンク層仕様のサポートが含まれている必要があります。どのようなリンク層に依存する含まれているリンク層の仕様は、システム上で利用可能なハードウェアでサポートされています。適合IPv6ノードは、そのインターフェイスの一部ではなく、他のIPv6をサポートすることが可能です。
As IPv6 is run over new layer 2 technologies, it is expected that new specifications will be issued. This section highlights some major layer 2 technologies and is not intended to be complete.
IPv6は新しいレイヤ2つのテクノロジー上で実行されると、新しい仕様が発行されることが期待されます。このセクションでは、いくつかの主要なレイヤ2テクノロジーを強調し、完全であることを意図したものではありません。
Nodes supporting IPv6 over Ethernet interfaces MUST implement Transmission of IPv6 Packets over Ethernet Networks [RFC-2464].
イーサネットインターフェイス上のIPv6をサポートしているノードは、イーサネットネットワーク、[RFC-2464]上のIPv6パケットの伝送を実装しなければなりません。
Nodes supporting IPv6 over PPP MUST implement IPv6 over PPP [RFC-2472].
PPP上でIPv6をサポートするノードは、PPP [RFC-2472]上でIPv6を実装しなければなりません。
Nodes supporting IPv6 over ATM Networks MUST implement IPv6 over ATM Networks [RFC-2492]. Additionally, RFC 2492 states:
ATMネットワーク上でIPv6をサポートするノードは、ATMネットワーク上のIPv6 [RFC-2492]を実装しなければなりません。また、RFC 2492で述べています：
A minimally conforming IPv6/ATM driver SHALL support the PVC mode of operation. An IPv6/ATM driver that supports the full SVC mode SHALL also support PVC mode of operation.
最低限準拠のIPv6 / ATMドライバが操作のPVCモードをサポートしなければなりません。フルSVCモードをサポートしたIPv6 / ATMドライバは、操作のPVCモードをサポートします。
The Internet Protocol Version 6 is specified in [RFC-2460]. This specification MUST be supported.
インターネットプロトコルバージョン6は、[RFC-2460]で指定されています。この仕様をサポートしなければなりません。
Unrecognized options in Hop-by-Hop Options or Destination Options extensions 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.
ノードは常に、送信、受信、およびフラグメントヘッダを処理できなければなりません。全て準拠IPv6実装は、IPv6パケットを送受信することが可能でなければなりません。転送機能をサポートすることができます。
RFC 2460 specifies extension headers and the processing for these headers.
RFC 2460は、拡張ヘッダーおよびこれらのヘッダの処理を指定します。
A full implementation of IPv6 includes implementation of the following extension headers: Hop-by-Hop Options, Routing (Type 0), Fragment, Destination Options, Authentication and Encapsulating Security Payload [RFC-2460].
ホップバイホップオプション、ルーティング（タイプ0）、フラグメント、宛先オプション、認証およびカプセル化セキュリティペイロード[RFC-2460]のIPv6の完全な実装は、以下の拡張ヘッダの実装を含みます。
An IPv6 node MUST be able to process these headers. It should be noted that there is some discussion about the use of Routing Headers and possible security threats [IPv6-RH] that they cause.
IPv6ノードは、これらのヘッダを処理できなければなりません。ルーティングヘッダや潜在的なセキュリティ上の脅威それらが引き起こす[IPv6の-RH]の使用に関するいくつかの議論があることに留意すべきです。
Neighbor Discovery SHOULD be supported. [RFC-2461] states:
近隣探索はサポートされる必要があります。 [RFC-2461]は述べています：
"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., 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 is an area for further study."
この文書は、すべてのリンクタイプに適用されます。ただし、NDは、そのサービスのいくつかのためにリンク層マルチキャストを使用しているため、（特定のリンクタイプ上での操作IPをカバー文書で）特に指定しない限り」、それが可能であるいくつかのリンクタイプの（例えば、これらのサービスを実装するNBMAリンク）別のプロトコルまたはメカニズムは）特定のリンクタイプ上のIPの動作をカバーする適切な文書に（指定されます。そのようなリダイレクトのようなマルチキャストに直接依存しない本書で記述されたサービス、 、等ネクストホップ決意、近隣到達不能検出は、この文書で指定されるように提供されることが期待されている。一つはNBMAリンク上NDを使用する方法の詳細は、さらなる研究のための領域です「。
Some detailed analysis of Neighbor Discovery follows:
近隣探索のいくつかの詳細な分析は次のとおりです。
Router Discovery is how hosts locate routers that reside on an attached link. Router Discovery MUST be supported for implementations.
ルータ検出は、ホストが接続されたリンクにあるルーターを見つける方法です。ルータ検出は実装のためにサポートしなければなりません。
Prefix Discovery is how hosts discover the set of address prefixes that define which destinations are on-link for an attached link. Prefix discovery MUST be supported for implementations. Neighbor Unreachability Detection (NUD) MUST be supported for all paths between hosts and neighboring nodes. It is not required for paths between routers. However, when a node receives a unicast Neighbor Solicitation (NS) message (that may be a NUD's NS), the node MUST respond to it (i.e., send a unicast Neighbor Advertisement).
接頭語ディスカバリーはホストが宛先が付属リンクのためにリンクされている定義するアドレスプレフィックスのセットを発見する方法です。プレフィックス発見は、実装のためにサポートしなければなりません。近隣到達不能検出（NUD）は、ホストと隣接ノードの間のすべてのパスのためにサポートしなければなりません。これは、ルータ間のパスは必要ありません。ノードは、ユニキャスト近隣要請（NS）メッセージを受信した場合しかし、ノードはそれに応答しなければならない（すなわち、NUDのNSがあってもよい）（即ち、ユニキャスト近隣広告を送信します）。
Duplicate Address Detection MUST be supported on all links supporting link-layer multicast (RFC 2462, Section 5.4, specifies DAD MUST take place on all unicast addresses).
重複アドレス検出は、リンク層マルチキャストサポートするすべてのリンクでサポートしなければならない（RFC 2462、セクション5.4を、DADがすべてのユニキャストアドレスに行われなければならない指定）。
A host implementation MUST support sending Router Solicitations.
ホストの実装では、ルータ要請の送信をサポートしなければなりません。
Receiving and processing Router Advertisements MUST be supported for host implementations. The ability to understand specific Router Advertisement options is dependent on supporting the specification where the RA is specified.
受信と処理ルータ広告はホストの実装のためにサポートしなければなりません。特定のルータアドバタイズメントオプションを理解する能力は、RAが指定されている仕様をサポートに依存しています。
Sending and Receiving Neighbor Solicitation (NS) and Neighbor Advertisement (NA) MUST be supported. NS and NA messages are required for Duplicate Address Detection (DAD).
送信と受信近隣要請（NS）をして近隣広告（NA）がサポートしなければなりません。 NSとNAのメッセージが重複アドレス検出（DAD）のために必要とされます。
Redirect functionality SHOULD be supported. If the node is a router, Redirect functionality MUST be supported.
機能がサポートされるべきでリダイレクトします。ノードがルータである場合には、機能がサポートされなければならないリダイレクトします。
Path MTU Discovery [RFC-1981] SHOULD be supported, though minimal implementations MAY choose to not support it and avoid large packets. The rules in RFC 2460 MUST be followed for packet fragmentation and reassembly.
最小限の実装がそれをサポートし、大きなパケットを避けるためではないことを選択するかもしれませんがパスMTUディスカバリ[RFC-1981]は、サポートされる必要があります。 RFC 2460でのルールは、パケットの断片化と再構築のために従わなければなりません。
IPv6 Jumbograms [RFC-2675] MAY be supported.
IPv6のジャンボグラム[RFC-2675]はサポートされるかもしれません。
ICMPv6 [RFC-2463] MUST be supported.
ICMPv6の[RFC-2463]はサポートしなければなりません。
The IPv6 Addressing Architecture [RFC-3513] MUST be supported as updated by [RFC-3879].
[RFC-3879]で更新されたIPv6アドレス指定アーキテクチャ[RFC-3513]はサポートしなければなりません。
IPv6 Stateless Address Autoconfiguration is defined in [RFC-2462]. This specification MUST be supported for nodes that are hosts. Static address can be supported as well.
IPv6のステートレスアドレス自動設定は、[RFC-2462]で定義されています。この仕様は、ホストであるノードのためにサポートしなければなりません。静的アドレスもサポートすることができます。
Nodes that are routers MUST be able to generate link local addresses as described in RFC 2462 [RFC-2462].
RFC 2462 [RFC-2462]に記載されているようにルータであるノードは、リンクローカルアドレスを生成できなければなりません。
From 2462:
2462年から：
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.
この文書で指定された自動設定プロセスは、ホストだけではなくルータに適用されます。ホストの自動設定は、ルータによってアドバタイズされた情報を使用しているので、ルータは、いくつかの他の手段で設定する必要があります。しかし、ルータは、この文書で説明するメカニズムを使用してリンクローカルアドレスを生成することが期待されます。また、ルータが正常にインターフェイスに割り当てる前に、すべてのアドレスにこの文書で説明する重複アドレス検出手順を通過することが予想されます。
Duplicate Address Detection (DAD) MUST be supported.
重複アドレス検出（DAD）がサポートしなければなりません。
Privacy Extensions for Stateless Address Autoconfiguration [RFC-3041] SHOULD be supported. It is recommended that this behavior be configurable on a connection basis within each application when available. It is noted that a number of applications do not work with addresses generated with this method, while other applications work quite well with them.
ステートレスアドレス自動設定[RFC-3041]のための個人情報保護の拡張機能がサポートされるべきです。この動作が可能な各アプリケーション内の接続ごとに構成することをお勧めします。他のアプリケーションがそれらと非常にうまく動作しながら、アプリケーションの数は、この方法で生成されたアドレスでは動作しないことに留意されたいです。
The rules specified in the Default Address Selection for IPv6 [RFC-3484] document MUST be implemented. It is expected that IPv6 nodes will need to deal with multiple addresses.
IPv6のデフォルトのアドレス選択で指定されたルール[RFC-3484]文書を実装する必要があります。 IPv6ノードは、複数のアドレスに対処する必要があることが期待されます。
Stateful Address Autoconfiguration MAY be supported. DHCPv6 [RFC-3315] is the standard stateful address configuration protocol; see Section 5.3 for DHCPv6 support.
ステートフルアドレス自動をサポートすることができます。 DHCPv6のは、[RFC-3315]標準のステートフルアドレス構成プロトコルです。 DHCPv6のサポートについては、セクション5.3を参照してください。
Nodes which do not support Stateful Address Autoconfiguration may be unable to obtain any IPv6 addresses, aside from link-local addresses, when it receives a router advertisement with the 'M' flag (Managed address configuration) set and that contains no prefixes advertised for Stateless Address Autoconfiguration (see Section 4.5.2). Additionally, such nodes will be unable to obtain other configuration information, such as the addresses of DNS servers when it is connected to a link over which the node receives a router advertisement in which the 'O' flag ("Other stateful configuration") is set.
それはセット「M」フラグ（管理アドレス設定）とルータ広告を受信したときにステートフルアドレスの自動構成をサポートしていないノードは、リンクローカルアドレスとは別に、任意のIPv6アドレスを取得できない場合があり、それはステートレスのための宣伝何の接頭辞が含まれていませんアドレス自動設定（4.5.2項を参照してください）。それは、ノードが「O」フラグ（「その他のステートフル設定が」）であるルータ広告を受信する上リンクに接続されている場合に加えて、そのようなノードは、DNSサーバのアドレスなど、他の構成情報を取得することができませんセットする。
Nodes that need to join multicast groups SHOULD implement MLDv2 [RFC-3810]. However, if the node has applications that only need support for Any-Source Multicast [RFC-3569], the node MAY implement MLDv1 [RFC-2710] instead. If the node has applications that need support for Source-Specific Multicast [RFC-3569, SSM-ARCH], the node MUST support MLDv2 [RFC-3810].
マルチキャストグループに参加する必要があるノードは、MLDv2の[RFC-3810]を実装する必要があります。ノードのみどれ-ソースマルチキャスト[RFC-3569]のサポートを必要とするアプリケーションを持っている場合は、ノードが代わりのMLDv1 [RFC-2710]を実装してもよい（MAY）。ノードは、ソース固有のマルチキャスト[RFC-3569、SSM-ARCH]のサポートを必要とするアプリケーションを持っている場合、ノードは、MLDv2の[RFC-3810]をサポートしなければなりません。
When MLD is used, the rules in the "Source Address Selection for the Multicast Listener Discovery (MLD) Protocol" [RFC-3590] MUST be followed.
MLDを使用する場合は、[RFC-3590]「Multicast Listener Discovery（MLD）プロトコルのためのソースアドレス選択」のルールに従わなければなりません。
DNS is described in [RFC-1034], [RFC-1035], [RFC-3152], [RFC-3363], and [RFC-3596]. 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 that applications rely on and generally needs to be supported. All nodes that need to resolve names SHOULD implement stub-resolver [RFC-1034] functionality, as in RFC 1034, Section 5.3.1, with support for:
DNSは、[RFC-1034]に記載されている、[RFC-1035]、[RFC-3152]、[RFC-3363]、および[RFC-3596]。いないすべてのノードが名前を解決する必要があります。 DNS名を解決する必要は決してありませんものは、リゾルバ機能を実装する必要はありません。しかし、名前を解決する機能は、アプリケーションが依存していると一般的にサポートされる必要があり、基本的なインフラストラクチャの機能があります。名前を解決する必要があるすべてのノードは、のためにサポートして、RFC 1034のように、セクション5.3.1をスタブリゾルバ[RFC-1034]の機能を実装する必要があります。
- AAAA type Resource Records [RFC-3596];
- AAAAタイプのリソースレコード[RFC-3596];
- reverse addressing in ip6.arpa using PTR records [RFC-3152];
- PTRレコード[RFC-3152]を用いてIP6.ARPAにアドレッシング逆。
- EDNS0 [RFC-2671] to allow for DNS packet sizes larger than 512 octets.
- EDNS0 [RFC-2671] DNSパケットを可能にするためには512オクテットよりも大きいサイズ。
Those nodes are RECOMMENDED to support DNS security extensions [RFC-4033], [RFC-4034], and [RFC-4035].
これらのノードは、DNSセキュリティ拡張[RFC-4033]、[RFC-4034]、および[RFC-4035]をサポートすることをお勧めします。
Those nodes are NOT RECOMMENDED to support the experimental A6 and DNAME Resource Records [RFC-3363].
これらのノードは、実験A6とDNAMEリソースレコード[RFC-3363]をサポートするために推奨されていません。
The method by which IPv6 nodes that use DHCP for address assignment can obtain IPv6 addresses and other configuration information upon receipt of a Router Advertisement with the 'M' flag set is described in Section 5.5.3 of RFC 2462.
「M」フラグセットは、RFC 2462のセクション5.5.3に記載されていると、アドレス割り当てのためにDHCPを使用するIPv6ノードは、ルータ通知を受信すると、IPv6アドレスおよびその他の構成情報を取得することができる方法。
In addition, in the absence of a router, those IPv6 nodes that use DHCP for address assignment MUST initiate DHCP to obtain IPv6 addresses and other configuration information, as described in Section 5.5.2 of RFC 2462. Those IPv6 nodes that do not use DHCP for address assignment can ignore the 'M' flag in Router Advertisements.
DHCPを使用しないこれらのIPv6ノードは、RFC 2462のセクション5.5.2に記載されるように加えて、ルータの非存在下で、アドレス割り当てのためにDHCPを使用して、それらのIPv6ノードは、IPv6アドレスやその他の設定情報を取得するためにDHCPを開始しなければなりませんアドレス割り当てのためのルータ広告で「M」フラグを無視することができます。
The method by which IPv6 nodes that use DHCP to obtain other configuration information can obtain other configuration information upon receipt of a Router Advertisement with the 'O' flag set is described in Section 5.5.3 of RFC 2462.
他の構成情報を取得するためにDHCPを使用するIPv6ノードは「O」フラグが設定されたルータ広告を受信したときに他の構成情報を取得することができる方法は、RFC 2462のセクション5.5.3に記載されています。
Those IPv6 nodes that use DHCP to obtain other configuration information initiate DHCP for other configuration information upon receipt of a Router Advertisement with the 'O' flag set, as described in Section 5.5.3 of RFC 2462. Those IPv6 nodes that do not use DHCP for other configuration information can ignore the 'O' flag in Router Advertisements.
DHCPを使用しないものIPv6ノードは、RFC 2462のセクション5.5.3に記載したように他の構成情報を取得するためにDHCPを使用して、それらのIPv6ノードは、「O」フラグが設定されたルータ広告を受信する他の構成については、DHCPを開始します他の構成については、ルータ広告で「O」フラグを無視することができます。
An IPv6 node can use the subset of DHCP (described in [RFC-3736]) to obtain other configuration information.
IPv6ノードは、他の構成情報を取得する（[RFC-3736]に記載されている）DHCPのサブセットを使用することができます。
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.
動的ホストIPv6の構成プロトコル（DHCPv6の）を使用して、ノードがデフォルトルータの情報と受信ルータ広告からのリンクプレフィックス情報を決定することが期待されています。
IPv6 nodes MAY support IPv4.
IPv6ノードは、IPv4をサポートするかもしれません。
If an IPv6 node implements dual stack and tunneling, then [RFC-4213] MUST be supported.
IPv6ノードは、デュアルスタックとトンネリングを実装する場合、[RFC-4213]はサポートしなければなりません。
The Mobile IPv6 [RFC-3775] specification defines requirements for the following types of nodes:
モバイルIPv6 [RFC-3775]仕様は、ノードの次のタイプのための要件を定義します。
- mobile nodes
- モバイルノード
- correspondent nodes with support for route optimization
- ルート最適化をサポートする通信相手ノード
- home agents
- ホームエージェント
- all IPv6 routers
- すべてのIPv6ルータ
Hosts MAY support mobile node functionality described in Section 8.5 of [RFC-3775], including support of generic packet tunneling [RFC-2473] and secure home agent communications [RFC-3776].
ホストは、汎用パケットトンネリング[RFC-2473]で安全なホーム・エージェント・コミュニケーション[RFC-3776]のサポートを含む、[RFC-3775]のセクション8.5で説明した移動ノードの機能をサポートするかもしれません。
Hosts SHOULD support route optimization requirements for correspondent nodes described in Section 8.2 of [RFC-3775].
ホストは、[RFC-3775]のセクション8.2で説明した通信相手ノードの経路最適化の要件をサポートする必要があります。
Routers SHOULD support the generic mobility-related requirements for all IPv6 routers described in Section 8.3 of [RFC-3775]. Routers MAY support the home agent functionality described in Section 8.4 of [RFC-3775], including support of [RFC-2473] and [RFC-3776].
ルータは、[RFC-3775]のセクション8.3に記載されているすべてのIPv6ルータのための一般的なモビリティ関連の要件をサポートする必要があります。ルータは、[RFC-2473]と[RFC-3776]のサポートを含む[RFC-3775]の8.4節で説明したホームエージェント機能をサポートすることができます。
This section describes the specification of IPsec for the IPv6 node.
このセクションでは、IPv6ノードのIPsecの仕様を記載しています。
Security Architecture for the Internet Protocol [RFC-4301] MUST be supported.
インターネットプロトコル[RFC-4301]のためのセキュリティアーキテクチャをサポートしなければなりません。
ESP [RFC-4303] MUST be supported. AH [RFC-4302] MUST be supported.
ESP [RFC-4303]はサポートしなければなりません。 AH [RFC-4302]はサポートしなければなりません。
Current IPsec RFCs specify the support of transforms and algorithms for use with AH and ESP: NULL encryption, DES-CBC, HMAC-SHA-1-96, and HMAC-MD5-96. However, "Cryptographic Algorithm Implementation Requirements For ESP And AH" [RFC-4305] contains the current set of mandatory to implement algorithms for ESP and AH. It also specifies algorithms that should be implemented because they are likely to be promoted to mandatory at some future time. IPv6 nodes SHOULD conform to the requirements in [RFC-4305], as well as the requirements specified below.
NULL暗号化、DES-CBC、HMAC-SHA-1-96、およびHMAC-MD5-96：現在のIPsec RFCは、AHとESPで使用するための変換とアルゴリズムのサポートを指定します。しかし、「ESPとAHのための暗号アルゴリズム実装要件」[RFC-4305]はESPとAHのためのアルゴリズムを実装するために必須の現在のセットが含まれています。また、彼らはいくつかの将来の時点で義務的に昇格される可能性があるため、実装されるべきであるアルゴリズムを指定します。 IPv6ノードは、[RFC-4305]における要件、ならびに以下の指定された要件に適合すべきです。
Since ESP encryption and authentication are both optional, support for the NULL encryption algorithm [RFC-2410] and the NULL authentication algorithm [RFC-4303] MUST be provided to maintain consistency with the way these services are negotiated. However, while authentication and encryption can each be NULL, they MUST NOT both be NULL. The NULL encryption algorithm is also useful for debugging.
ESP暗号化と認証の両方が任意であるため、NULL暗号化アルゴリズム[RFC-2410]およびNULL認証アルゴリズム[RFC-4303]のサポートは、これらのサービスが交渉される方法との一貫性を維持するために提供されなければなりません。認証と暗号化は、各NULLにすることができますしながら、しかし、彼らは両方ともNULLであってはなりません。 NULL暗号化アルゴリズムはまた、デバッグに便利です。
The DES-CBC encryption algorithm [RFC-2405] SHOULD NOT be supported within ESP. Security issues related to the use of DES are discussed in [DESDIFF], [DESINT], and [DESCRACK]. DES-CBC is still listed as required by the existing IPsec RFCs, but updates to these RFCs will be published in the near future. DES provides 56 bits of protection, which is no longer considered sufficient.
DES-CBC暗号化アルゴリズム[RFC-2405]はESP内でサポートされるべきではありません。 DESの使用に関連するセキュリティ問題は[DESDIFF]、[DESINT]で議論されている、および[DESCRACK]。既存のIPsecのRFCで要求されるDES-CBCはまだ記載されていますが、これらのRFCへの更新は、近い将来に公開されます。 DESはもはや十分であると考えられる保護の56ビットを、提供します。
The use of the HMAC-SHA-1-96 algorithm [RFC-2404] within AH and ESP MUST be supported. The use of the HMAC-MD5-96 algorithm [RFC-2403] within AH and ESP MAY also be supported.
AHとESP内HMAC-SHA-1-96アルゴリズム[RFC-2404]の使用をサポートしなければなりません。 AHとESP内のHMAC-MD5-96アルゴリズム[RFC-2403]の使用もサポートされるかもしれません。
The 3DES-CBC encryption algorithm [RFC-2451] does not suffer from the same security issues as DES-CBC, and the 3DES-CBC algorithm within ESP MUST be supported to ensure interoperability.
3DES-CBC暗号化アルゴリズム[RFC-2451]はDES-CBCと同じセキュリティ上の問題に悩まされない、とESP内3DES-CBCアルゴリズムは、相互運用性を確保するためにサポートしなければなりません。
The AES-128-CBC algorithm [RFC-3602] MUST also be supported within ESP. AES-128 is expected to be a widely available, secure, and efficient algorithm. While AES-128-CBC is not required by the current IPsec RFCs, it is expected to become required in the future.
AES-128-CBCアルゴリズム[RFC-3602]はまた、ESP内でサポートされなければなりません。 AES-128は広く、利用可能な安全かつ効率的なアルゴリズムであると予想されます。 AES-128-CBCは、現在のIPsecのRFCによって必要とされていないが、将来的に必要になることが予想されます。
An implementation MUST support the manual configuration of the security key and SPI. The SPI configuration is needed in order to delineate between multiple keys.
実装は、セキュリティキーおよびSPIの手動設定をサポートしなければなりません。 SPIの設定は、複数のキーの間で線引きするために必要とされています。
Key management SHOULD be supported. Examples of key management systems include IKEv2 [RFC-4306] and Kerberos; S/MIME and TLS include key management functions.
鍵管理がサポートされるべきです。鍵管理システムの例としては、IKEv2の[RFC-4306]およびKerberosを含みます。 S / MIMEとTLSは、鍵管理機能を含みます。
Where key refresh, anti-replay features of AH and ESP, or on-demand creation of Security Associations (SAs) is required, automated keying MUST be supported.
キーリフレッシュが、AHとESP、またはセキュリティアソシエーション（SA）のオンデマンド作成のアンチリプレイ機能が必要な場合は、自動化されたキーをサポートしなければなりません。
Key management methods for multicast traffic are also being worked on by the MSEC WG.
マルチキャストトラフィックのためのキー管理方法もMSEC WGが作業されています。
This section defines general host considerations for IPv6 nodes that act as routers. Currently, this section does not discuss routing-specific requirements.
このセクションでは、ルータとして機能しIPv6ノードのための一般的なホストの考慮事項を定義します。現在、このセクションでは、ルーティング固有の要件については説明しません。
The IPv6 Router Alert Option [RFC-2711] is an optional IPv6 Hop-by-Hop Header that is used in conjunction with some protocols (e.g., RSVP [RFC-2205] or MLD [RFC-2710]). The Router Alert option will need to be implemented whenever protocols that mandate its usage are implemented. See Section 4.6.
IPv6ルーター警告オプション[RFC-2711]オプションのIPv6のホップバイホップヘッダいくつかのプロトコルと併用（例えば、RSVP [RFC-2205]またはMLD [RFC-2710]）で使用されています。その使用を強制プロトコルが実装されるたびにルータアラートオプションが実装する必要があります。 4.6節を参照してください。
Sending Router Advertisements and processing Router Solicitation MUST be supported.
ルータ広告と処理ルータ要請を送信すると、サポートしなければなりません。
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ノードのために、ネットワーク管理は、これらのノードを制御するための唯一の可能な方法であってもよいです。
The following two MIBs SHOULD be supported by nodes that support an SNMP agent.
次の二つのMIBは、SNMPエージェントをサポートするノードによってサポートされる必要があります。
IP Forwarding Table MIB [RFC-4292] SHOULD be supported by nodes that support an SNMP agent.
IP転送テーブルMIB [RFC-4292]はSNMPエージェントをサポートしているノードによってサポートされるべきです。
IP MIB [RFC-4293] SHOULD be supported by nodes that support an SNMP agent.
IP MIB [RFC-4293]はSNMPエージェントをサポートしているノードによってサポートされるべきです。
This document does not affect the security of the Internet, but implementations of IPv6 are expected to support a minimum set of security features to ensure security on the Internet. "IP Security Document Roadmap" [RFC-2411] is important for everyone to read.
この文書は、インターネットのセキュリティに影響を与えませんが、IPv6のの実装は、インターネット上のセキュリティを確保するためのセキュリティ機能の最小セットをサポートすることが期待されます。 「IPセキュリティドキュメントロードマップ」[RFC-2411]は、誰もが読むことのために重要です。
The security considerations in RFC 2460 state the following:
RFC 2460の状態次のセキュリティの考慮事項：
The security features of IPv6 are described in the Security Architecture for the Internet Protocol [RFC-2401].
IPv6ののセキュリティ機能は、インターネットプロトコル[RFC-2401]のためのセキュリティアーキテクチャで説明されています。
RFC 2401 has been obsoleted by RFC 4301, therefore refer RFC 4301 for the security features of IPv6.
RFC 2401は、IPv6のセキュリティ機能については、RFC 4301を参照してくださいので、RFC 4301で廃止されました。
[RFC-1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC-1035] Mockapetris、P.、 "ドメイン名 - 実装及び仕様"、STD 13、RFC 1035、1987年11月。
[RFC-1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[RFC-1981]マッキャン、J.、デアリング、S.、およびJ.モーグル、 "経路MTUディスカバリIPバージョン6"、RFC 1981、1996年8月。
[RFC-2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC-2104] Krawczyk、H.、ベラー、M.、およびR.カネッティ、 "HMAC：メッセージ認証のための鍵付きハッシュ化"、RFC 2104、1997年2月。
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC-2403] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within ESP and AH", RFC 2403, November 1998.
[RFC-2403] Madson、C.とR.グレン、 "ESPおよびAH内のHMAC-MD5-96の使用"、RFC 2403、1998年11月。
[RFC-2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998.
[RFC-2404] Madson、C.およびR.グレン、 "ESPおよびAH内HMAC-SHA-1-96の使用"、RFC 2404、1998年11月。
[RFC-2405] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher Algorithm With Explicit IV", RFC 2405, November 1998.
[RFC-2405] Madson、C.およびN. Doraswamy、 "明示的なIVとESP DES-CBC暗号アルゴリズム"、RFC 2405、1998年11月。
[RFC-2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and Its Use With IPsec", RFC 2410, November 1998.
[RFC-2410]グレン、R.とS.ケント、 "NULL暗号化アルゴリズムとIPsecでの使用"、RFC 2410、1998年11月。
[RFC-2411] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security Document Roadmap", RFC 2411, November 1998.
[RFC-2411]セイヤー、R.、Doraswamy、N.、およびR.グレン、 "IPセキュリティドキュメントロードマップ"、RFC 2411、1998年11月。
[RFC-2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher Algorithms", RFC 2451, November 1998.
[RFC-2451]ペレイラ、R.とR.アダムス、 "ESP CBCモード暗号アルゴリズム"、RFC 2451、1998年11月。
[RFC-2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC-2460]デアリング、S.とR. Hindenと、 "インターネットプロトコルバージョン6（IPv6）の仕様"、RFC 2460、1998年12月。
[RFC-2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[RFC-2461] Narten氏、T.、Nordmarkと、E.、およびW.シンプソン、 "IPバージョン6（IPv6）のための近隣探索"、RFC 2461、1998年12月。
[RFC-2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[RFC-2462]トムソン、S.とT. Narten氏、 "IPv6のステートレスアドレス自動設定"、RFC 2462、1998年12月。
[RFC-2463] Conta, A. and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 2463, December 1998.
、RFC 2463、1998年12月 "インターネットプロトコルバージョン6（IPv6）仕様のためのインターネット制御メッセージプロトコル（ICMPv6の）" [RFC-2463]コンタ、A.、およびS.デアリング、。
[RFC-2472] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472, December 1998.
[RFC-2472] Haskin、D.およびE.アレン、 "PPPオーバーIPバージョン6"、RFC 2472、1998年12月。
[RFC-2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998.
[RFC-2473]コンタ、A.、およびS.デアリング、 "IPv6の仕様の汎用パケットトンネリング"、RFC 2473、1998年12月。
[RFC-2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999.
[RFC-2671]いるVixie、P.、 "DNS用拡張メカニズム（EDNS0）"、RFC 2671、1999年8月。
[RFC-2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
[RFC-2710]デアリング、S.、フェナー、W.、およびB.ハーバーマン、 "マルチキャストリスナ発見（MLD）IPv6の"、RFC 2710、1999年10月。
[RFC-2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", RFC 2711, October 1999.
[RFC-2711]ヤマウズラ、C.とA.ジャクソン、 "IPv6のルータアラートオプション"、RFC 2711、1999年10月。
[RFC-3041] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[RFC-3041] Narten氏、T.およびR. Draves、 "IPv6におけるステートレスアドレス自動設定のための個人情報保護の拡張"、RFC 3041、2001年1月。
[RFC-3152] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152, August 2001.
[RFC-3152]ブッシュ、R.、 "IP6.ARPAの委任"、BCP 49、RFC 3152、2001年8月。
[RFC-3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC-3315] Droms、R.、バウンド、J.、フォルツ、B.、レモン、T.、パーキンス、C.、およびM.カーニー、 "IPv6のための動的ホスト構成プロトコル（DHCPv6）"、RFC 3315、 2003年7月。
[RFC-3363] 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.
[RFC-3363]ブッシュ、R.、デュラン、A.、フィンク、B.、グドムンソン、O.、およびT.ハイン、 "を表すインターネットプロトコルバージョンドメインネームシステム（DNS）6（IPv6）アドレス"、 RFC 3363、2002年8月。
[RFC-3484] Frye, R., Levi, D., Routhier, S., and B. Wijnen, "Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework", BCP 74, RFC 3584, August 2003.
[RFC-3484]フライ、R.、レヴィ、D.、Routhier、S.、およびB. Wijnenの、BCP 74 "バージョン1、バージョン2、及びインターネット標準ネットワーク管理フレームワークのバージョン3の間の共存"、 RFC 3584、2003年8月。
[RFC-3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.
[RFC-3513] HindenとR.とS.デアリング、 "インターネットプロトコルバージョン6（IPv6）のアドレス指定アーキテクチャ"、RFC 3513、2003年4月。
[RFC-3590] Haberman, B., "Source Address Selection for the Multicast Listener Discovery (MLD) Protocol", RFC 3590, September 2003.
[RFC-3590]ハーバーマン、B.、 "Multicast Listener Discovery（MLD）プロトコルのためのソースアドレス選択"、RFC 3590、2003年9月。
[RFC-3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS Extensions to Support IP Version 6", RFC 3596, October 2003.
、RFC 3596 "IPバージョン6をサポートするDNS拡張機能" [RFC-3596]トムソン、S.、のHuitema、C.、Ksinant、V.、およびM. Souissi、2003年10月。
[RFC-3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher Algorithm and Its Use with IPsec", RFC 3602, September 2003.
[RFC-3602]フランケル、S.、グレン、R.、およびS.ケリー、 "AES-CBC暗号アルゴリズムおよびIPSecでの使用"、RFC 3602、2003年9月。
[RFC-3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC-3775]ジョンソン、D.、パーキンス、C.、およびJ. Arkko、 "IPv6におけるモビリティサポート"、RFC 3775、2004年6月。
[RFC-3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents", RFC 3776, June 2004.
[RFC-3776] Arkko、J.、Devarapalli、V.、およびF.デュポン、 "モバイルノードとホームエージェント間のモバイルIPv6シグナリングを保護するためにIPsecを使用する"、RFC 3776、2004年6月。
[RFC-3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC-3810]ヴィーダ、R.とL.コスタ、 "IPv6のマルチキャストリスナ発見バージョン2（MLDv2の）"、RFC 3810、2004年6月。
[RFC-3879] Huitema, C. and B. Carpenter, "Deprecating Site Local Addresses", RFC 3879, September 2004.
[RFC-3879]のHuitema、C.およびB.大工、 "卑下サイトローカルアドレス"、RFC 3879、2004年9月。
[RFC-4292] Haberman, B., "IP Forwarding Table MIB", RFC 4292, April 2006.
[RFC-4292]ハーバーマン、B.、 "IP転送テーブルMIB"、RFC 4292、2006年4月。
[RFC-4293] Routhier, S., Ed., "Management Information Base for the Internet Protocol (IP)", RFC 4293, April 2006.
[RFC-4293] Routhier、S.、エド。、 "インターネットプロトコル（IP）のための管理情報ベース"、RFC 4293、2006年4月。
[RFC-4301] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC-4301]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 4301、2005年12月。
[RFC-4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC-4302]ケント、S.、 "IP認証ヘッダー"、RFC 4302、2005年12月。
[RFC-4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC-4303]ケント、S.、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 4303、2005年12月。
[RFC-4305] Eastlake 3rd, D., "Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 4305, December 2005.
[RFC-4305]イーストレーク第3、D.、RFC 4305、2005年12月 "カプセル化セキュリティペイロード（ESP）と認証ヘッダー（AH）のための暗号アルゴリズム実装要件"。
[DESDIFF] Biham, E., Shamir, A., "Differential Cryptanalysis of DES-like cryptosystems", Journal of Cryptology Vol 4, Jan 1991.
[DESDIFF] Biham、E.、シャミル、A.、 "DESのような暗号の差分解読法"、暗号学第4巻、1991年1月のジャーナル。
[DESCRACK] Cracking DES, O'Reilly & Associates, Sebastapol, CA 2000.
[DESCRACK] DES、オライリー＆アソシエーツ、Sebastapol、CA 2000割れ。
[DESINT] Bellovin, S., "An Issue With DES-CBC When Used Without Strong Integrity", Proceedings of the 32nd IETF, Danvers, MA, April 1995.
[DESINT] Bellovin氏、S.、 "強い整合性なしで使用DES-CBCの問題"、第32回のIETF、ダンバース、MA、1995年4月の議事。
[IPv6-RH] P. Savola, "Security of IPv6 Routing Header and Home Address Options", Work in Progress.
、進行中の作業[IPv6の-RH] P. Savola、「IPv6ルーティングヘッダーとホームアドレスオプションのセキュリティ」。
[RFC-793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC-793]ポステル、J.、 "送信制御プロトコル"、STD 7、RFC 793、1981年9月。
[RFC-1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC-1034] Mockapetris、P.、 "ドメイン名 - 概念と設備"、STD 13、RFC 1034、1987年11月。
[RFC-2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC-2205]ブレーデン、R.、チャン、L.、Berson氏、S.、ハーツォグ、S.、およびS.ヤミン、 "リソース予約プロトコル（RSVP） - バージョン1機能仕様"、RFC 2205、1997年9月。
[RFC-2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998.
[RFC-2464]クロフォード、M.、 "イーサネットネットワークの上のIPv6パケットのトランスミッション"、RFC 2464、1998年12月。
[RFC-2492] Armitage, G., Schulter, P., and M. Jork, "IPv6 over ATM Networks", RFC 2492, January 1999.
[RFC-2492]アーミテージ、G.、Schulter、P.、および "ATMネットワーク上のIPv6" M. Jorkの、RFC 2492、1999年1月。
[RFC-2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", RFC 2675, August 1999.
[RFC-2675]ボーマン、D.、デアリング、S.、およびR. Hindenと "IPv6のジャンボグラム"、RFC 2675、1999年8月。
[RFC-4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC-4213] Nordmarkと、E.とR.ギリガン、RFC 4213の "IPv6ホストとルータのための基本的な移行メカニズム"、2005年10月。
[RFC-3569] Bhattacharyya, S., "An Overview of Source-Specific Multicast (SSM)", RFC 3569, July 2003.
[RFC-3569]バッタチャリヤ、S.、 "ソース固有マルチキャスト（SSM）の概要"、RFC 3569、2003年7月。
[RFC-3736] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, April 2004.
[RFC-3736] Droms、R.、 "IPv6のステートレス動的ホスト構成プロトコル（DHCP）サービス"、RFC 3736、2004年4月。
[RFC-4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005.
[RFC-4001]ダニエル、M.、ハーバーマン、B.、Routhier、S.、およびJ. Schoenwaelder、 "インターネットネットワークアドレスのためのテキストの表記法"、RFC 4001、2005年2月。
[RFC-4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[RFC-4033]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "DNSセキュリティ序論と要件"、RFC 4033、2005年3月。
[RFC-4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005.
[RFC-4034]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "DNSセキュリティ拡張機能のためのリソースレコード"、RFC 4034、2005年3月。
[RFC-4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.
[RFC-4035]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "DNSセキュリティ拡張のためのプロトコル変更"、RFC 4035、2005年3月。
[RFC-4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC-4306]カウフマン、C.、エド。、 "インターネットキーエクスチェンジ（IKEv2の）プロトコル"、RFC 4306、2005年12月。
[SSM-ARCH] H. Holbrook, B. Cain, "Source-Specific Multicast for IP", Work in Progress.
[SSM-ARCH] H.ホルブルック、B.カイン、 "IPのためのソース固有のマルチキャスト" が進行中で働いています。
This document was written by the IPv6 Node Requirements design team:
この文書は、IPv6ノード要件のデザインチームによって書かれました：
Jari Arkko [jari.arkko@ericsson.com]
ヤリArkko [jari.arkko@ericsson.com]
Marc Blanchet [marc.blanchet@viagenie.qc.ca]
マルク・ブランシェ[marc.blanchet@viagenie.qc.ca]
Samita Chakrabarti [samita.chakrabarti@eng.sun.com]
サミットChakrabarti [samita.chakrabarti@eng.sun.com]
Alain Durand [alain.durand@sun.com]
アラン・デュラン[alain.durand@sun.com]
Gerard Gastaud [gerard.gastaud@alcatel.fr]
ジェラルドGastaud [gerard.gastaud@alcatel.fr]
Jun-ichiro itojun Hagino [itojun@iijlab.net]
じゅんーいちろ いとじゅん はぎの 「いとじゅん＠いいｊぁｂ。ねｔ」
Atsushi Inoue [inoue@isl.rdc.toshiba.co.jp]
あつし いのうえ 「いのうえ＠いｓｌ。ｒｄｃ。としば。こ。ｊｐ」
Masahiro Ishiyama [masahiro@isl.rdc.toshiba.co.jp]
まさひろ いしやま 「まさひろ＠いｓｌ。ｒｄｃ。としば。こ。ｊｐ」
John Loughney [john.loughney@nokia.com]
ジョンLoughney [john.loughney@nokia.com]
Rajiv Raghunarayan [raraghun@cisco.com]
ラジブRaghunarayn [ररघुन@सिस्को.कॉम]
Shoichi Sakane [shouichi.sakane@jp.yokogawa.com]
しょいち さかね 「しょういち。さかね＠ｊｐ。よこがわ。こｍ」
Dave Thaler [dthaler@windows.microsoft.com]
デーブターラー[dthaler@windows.microsoft.com]
Juha Wiljakka [juha.wiljakka@Nokia.com]
ユハWiljakka [juha.wiljakka@Nokia.com]
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.
作者は彼らのコメントのために、蘭アトキンソン、ジムはバウンドブライアン・カーペンター、ラルフDroms、クリスチャンのHuitema、アダムMachalek、トーマスNarten氏、ユハ・オリラ、およびペッカSavolaに感謝したいと思います。
Editor's Contact Information
編集者の連絡先情報
Comments or questions regarding this document should be sent to the IPv6 Working Group mailing list (ipv6@ietf.org) or to:
本書に関するコメントや質問は、IPv6ワーキンググループのメーリングリスト（ipv6@ietf.org）またはに送信する必要があります。
John Loughney Nokia Research Center Itamerenkatu 11-13 00180 Helsinki Finland
ジョンLoughneyノキア・リサーチセンターItamerenkatu 11-13 00180ヘルシンキフィンランド
Phone: +358 50 483 6242 EMail: John.Loughney@Nokia.com
電話番号：+358 50 483 6242 Eメール：John.Loughney@Nokia.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。