[要約] RFC 4294は、IPv6ノードの要件に関するガイドラインであり、IPv6ネットワークの設計と実装に役立ちます。このRFCの目的は、IPv6ノードの動作と相互運用性を確保するための基準を提供することです。
Network Working Group J. Loughney, Ed.
Request for Comments: 4294 Nokia
Category: Informational April 2006
IPv6 Node Requirements
IPv6ノード要件
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).
Copyright（c）The Internet Society（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ノードはオプションまたは追加機能を実装しますが、このドキュメントでは、他の公開されている標準の要件を1か所で追跡します。
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を参照します。このドキュメントは本質的に情報に基づいており、RFCSの追跡標準を更新していません。
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ノードの最優先要件は、Jon Postelの堅牢性の原理を順守する必要があるということです。
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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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
お父さんの複製アドレス検出
ESP Encapsulating Security Payload
特にセキュリティペイロードをカプセル化します
ICMP Internet Control Message Protocol
ICMPインターネット制御メッセージプロトコル
IKE Internet Key Exchange MIB Management Information Base
IKE Internet Key Exchange MIB管理情報ベース
MLD Multicast Listener Discovery
MLDマルチキャストリスナーの発見
MTU Maximum Transfer Unit
MTU最大転送ユニット
NA Neighbor Advertisement
na neighbor Advertisement
NBMA Non-Broadcast Multiple Access
NBMAノンブロードキャストマルチアクセス
ND Neighbor Discovery
Nd Neighbor Discovery
NS Neighbor Solicitation
NS Neighbor Solicitation
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ノードには、1つ以上の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をサポートするノードは、イーサネットネットワークを介してIPv6パケットの送信を実装する必要があります[RFC-2464]。
Nodes supporting IPv6 over PPP MUST implement IPv6 over PPP [RFC-2472].
PPPよりもIPv6をサポートするノードは、PPPを介してIPv6を実装する必要があります[RFC-2472]。
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].
IPv6の完全な実装には、次の拡張ヘッダーの実装が含まれます。ホップバイホップオプション、ルーティング（タイプ0）、フラグメント、目的地オプション、認証、セキュリティペイロードのカプセル化[RFC-2460]。
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."
「特定のリンクタイプで操作IPをカバーするドキュメントで）指定されていない限り、このドキュメントはすべてのリンクタイプに適用されます。ただし、NDは一部のサービスにリンクレイヤーマルチキャストを使用するため、一部のリンクタイプ（たとえば、NBMAリンク）それらのサービスを実装するための代替プロトコルまたはメカニズムが指定されます（特定のリンクタイプでのIPの操作をカバーする適切なドキュメントで）。このドキュメントで説明されているサービスは、リダイレクトなどのマルチキャストに直接依存しないサービス、Next-Hopの決定、近隣の到達性検出などは、このドキュメントで指定されているように提供されると予想されます。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、すべてのユニキャストアドレスでパパが行わなければならないことを指定するすべてのリンクで重複するアドレスの検出がサポートされる必要があります。
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).
Neighbor Solicitation（NS）およびNeighbor Advertisement（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.
Path MTU Discovery [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].
IPv6アドレス指定アーキテクチャ[RFC-3513]は、[RFC-3879]によって更新されるようにサポートする必要があります。
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ステートレスアドレスAutoconfigurationは[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.
このドキュメントで指定されている自動構成プロセスは、ルーターではなくホストにのみ適用されます。ホストAutoconfigurationはルーターによって宣伝されている情報を使用するため、ルーターは他の手段で構成する必要があります。ただし、このドキュメントで説明されているメカニズムを使用して、ルーターがリンクローカルアドレスを生成することが予想されます。さらに、ルーターは、インターフェイスに割り当てる前に、すべてのアドレスでこのドキュメントで説明されている重複するアドレス検出手順を正常に渡すことが期待されています。
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.
Statelessアドレスのプライバシー拡張オートコンチュレーション[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.
Stateful Address Autoconfigurationをサポートしないノードは、Link-Localアドレスを除いて、「M」フラグ（マネージドアドレス構成）セットでルーター広告を受信し、統計のために広告されていない接頭辞が含まれていない場合、IPv6アドレスを取得できない場合があります。Autoconfigurationに対応します（セクション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]を実装できます。ノードにソース固有のマルチキャスト[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を使用する場合、「マルチキャストリスナーディスカバリー（MLD）プロトコルのソースアドレス選択」[RFC-3590]のルールに従う必要があります。
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名を解決する必要がないものは、Resolver機能を実装する必要はありません。ただし、名前を解決する機能は、アプリケーションが依存しており、一般的にサポートする必要がある基本的なインフラストラクチャ機能です。名前を解決する必要があるすべてのノードは、RFC 1034、セクション5.3.1のように、次のサポートを備えたStub-Resolver [RFC-1034]機能を実装する必要があります。
- AAAA type Resource Records [RFC-3596];
- AAAAタイプリソースレコード[RFC-3596];
- reverse addressing in ip6.arpa using PTR records [RFC-3152];
- PTRレコードを使用したIP6.ARPAでの逆アドレス指定[RFC-3152];
- EDNS0 [RFC-2671] to allow for DNS packet sizes larger than 512 octets.
- EDNS0 [RFC-2671]は、512オクテットを超えるDNSパケットサイズを可能にします。
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.
アドレス割り当てにDHCPを使用するIPv6ノードがIPv6アドレスとその他の構成情報を取得する方法は、「M」フラグセットを使用してルーター広告を受け取ると、RFC 2462のセクション5.5.3で説明されています。
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ノードは、DHCPを開始してIPv6アドレスおよびその他の構成情報を取得する必要があります。アドレスの割り当てについては、ルーター広告の「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で説明されているように、「O」フラグセットを使用してルーター広告を受け取ったときに他の構成情報のDHCPを開始します。DHCPを使用しないIPv6ノード他の構成の場合、情報はルーター広告の「O」フラグを無視できます。
An IPv6 node can use the subset of DHCP (described in [RFC-3736]) to obtain other configuration information.
IPv6ノードは、DHCPのサブセット（[RFC-3736]で説明）を使用して、他の構成情報を取得できます。
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-3775]のセクション8.5で説明されているモバイルノード機能をサポートする場合があります。これには、ジェネリックパケットトンネル[RFC-2473]のサポートやセキュアホームエージェント通信[RFC-3776]が含まれます。
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.
現在のIPSEC RFCは、AHおよびESP：Null暗号化、DES-CBC、HMAC-SHA-1-96、およびHMAC-MD5-96で使用する変換とアルゴリズムのサポートを指定します。ただし、「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]で説明されています。DES-CBCは、既存のIPSEC RFCの要求に応じてまだリストされていますが、これらの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のアンチレプレイ機能、またはセキュリティ協会のオンデマンド作成（SAS）が必要な場合、自動キーイングをサポートする必要があります。
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]は、いくつかのプロトコル（例：RSVP [RFC-2205]またはMLD [RFC-2710]）と組み合わせて使用されるオプションのIPv6ホップバイホップヘッダーです。ルーターアラートオプションは、その使用法を義務付けるプロトコルが実装されるたびに実装する必要があります。セクション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.
次の2つの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はRFC 4301によって廃止されているため、IPv6のセキュリティ機能については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] McCann、J.、Deering、S。、およびJ. Mogul、「IPバージョン6のPath MTU Discovery」、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.、Bellare、M。、およびR. Canetti、「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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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. Glenn、「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. Glenn、「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、「ESP Des-CBC暗号アルゴリズムを備えたIVを備えた」、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] Glenn、R。およびS. Kent、「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] Thayer、R.、Doraswamy、N。、およびR. Glenn、「IP Security Document Roadmap」、RFC 2411、1998年11月。
[RFC-2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher Algorithms", RFC 2451, November 1998.
[RFC-2451] Pereira、R。およびR. Adams、「ESP CBC-Mode Cipher Algorithms」、RFC 2451、1998年11月。
[RFC-2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC-2460] Deering、S。and R. Hinden、「Internet Protocol、バージョン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. Simpson、「IPバージョン6（IPv6）の近隣発見」、RFC 2461、1998年12月。
[RFC-2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[RFC-2462] Thomson、S。およびT. Narten、「IPv6 Stateless Address Autoconfiguration」、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] Conta、A。およびS. Deering、「インターネットプロトコルバージョン6（IPv6）仕様のインターネット制御メッセージプロトコル（ICMPV6）」、RFC 2463、1998年12月。
[RFC-2472] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472, December 1998.
[RFC-2472] Haskin、D。およびE. Allen、「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] Conta、A。およびS. Deering、「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] Deering、S.、Fenner、W。、およびB. Haberman、「IPv6のマルチキャストリスナーディスカバリー（MLD）」、RFC 2710、1999年10月。
[RFC-2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", RFC 2711, October 1999.
[RFC-2711] Partridge、C。およびA. Jackson、「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のステートレスアドレスAutoconfigurationのプライバシー拡張」、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.、Bound、J.、Volz、B.、Lemon、T.、Perkins、C。、およびM. Carney、「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] Bush、R.、Durand、A.、Fink、B.、Gudmundsson、O.、およびT. Hain、「インターネットプロトコルバージョン6（IPv6）を表すドメイン名システム（DNS）」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] Frye、R.、Levi、D.、Routhier、S。、およびB. Wijnen、「インターネット標準ネットワーク管理フレームワークのバージョン1、バージョン2、およびバージョン3の共存」、BCP 74、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. Deering、「インターネットプロトコルバージョン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] Haberman、B。、「マルチキャストリスナーディスカバリー（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] Thomson、S.、Huitema、C.、Ksinant、V。、およびM. Souissi、「DNS拡張機能IPバージョン6」、RFC 3596、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] Johnson、D.、Perkins、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. Dupont、「IPSECを使用してモバイルノードとホームエージェント間のモバイルIPv6シグナル伝達を保護する」、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] Vida、R。およびL. Costa、「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。and B. Carpenter、「脱退するサイトローカルアドレス」、RFC 3879、2004年9月。
[RFC-4292] Haberman, B., "IP Forwarding Table MIB", RFC 4292, April 2006.
[RFC-4292] Haberman、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.、ed。、「インターネットプロトコルの管理情報ベース（IP）」、RFC 4293、2006年4月。
[RFC-4301] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC-4301] Kent、S。およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[RFC-4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC-4302] Kent、S。、「IP認証ヘッダー」、RFC 4302、2005年12月。
[RFC-4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC-4303] Kent、S。、「セキュリティペイロードのカプセル化（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] EastLake 3rd、D。、「セキュリティペイロード（ESP）および認証ヘッダー（AH）をカプセル化するための暗号化アルゴリズムの実装要件」、RFC 4305、2005年12月。
[DESDIFF] Biham, E., Shamir, A., "Differential Cryptanalysis of DES-like cryptosystems", Journal of Cryptology Vol 4, Jan 1991.
[Desdiff] Biham、E.、Shamir、A。、「DESのような暗号システムの微分暗号化」、Journal of Cryptology Vol 4、1991年1月。
[DESCRACK] Cracking DES, O'Reilly & Associates, Sebastapol, CA 2000.
[Descrack] Cracking Des、O'Reilly＆Associates、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の議事録、マサチューセッツ州ダンバース、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] Postel、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] Braden、R.、Zhang、L.、Berson、S.、Herzog、S。、およびS. Jamin、「リソース予約プロトコル（RSVP） - バージョン1機能仕様」、RFC 2205、1997年9月。
[RFC-2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998.
[RFC-2464] Crawford、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] Armitage、G.、Schulter、P。、およびM. Jork、「ATM Networks Over ATM Networks」、RFC 2492、1999年1月。
[RFC-2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", RFC 2675, August 1999.
[RFC-2675]ボーマン、D。、ディアリング、S。、およびR.ヒンデン、「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. Gilligan、「IPv6ホストとルーターの基本的な遷移メカニズム」、RFC 4213、2005年10月。
[RFC-3569] Bhattacharyya, S., "An Overview of Source-Specific Multicast (SSM)", RFC 3569, July 2003.
[RFC-3569] Bhattacharyya、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] Daniele、M.、Haberman、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] Arends、R.、Austein、R.、Larson、M.、Massey、D.、およびS. Rose、「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] Arends、R.、Austein、R.、Larson、M.、Massey、D.、およびS. Rose、「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] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNSセキュリティ拡張のプロトコル修正」、RFC 4035、2005年3月。
[RFC-4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC-4306] Kaufman、C.、ed。、「Internet Key Exchange（IKEV2）Protocol」、RFC 4306、2005年12月。
[SSM-ARCH] H. Holbrook, B. Cain, "Source-Specific Multicast for IP", Work in Progress.
[SSM-ARCH] H. Holbrook、B。Cain、「IP用のソース固有のマルチキャスト」、進行中の作業。
This document was written by the IPv6 Node Requirements design team:
このドキュメントは、IPv6ノード要件デザインチームによって作成されました。
Jari Arkko [jari.arkko@ericsson.com]
Jari Arkko [jari.arkko@ericsson.com]
Marc Blanchet [marc.blanchet@viagenie.qc.ca]
Marc Blanchet [marc.blanchet@viagenie.qc.ca]
Samita Chakrabarti [samita.chakrabarti@eng.sun.com]
Samita Chakrabarti [samita.chakrabarti@eng.sun.com]
Alain Durand [alain.durand@sun.com]
Alain Durand [alain.durand@sun.com]
Gerard Gastaud [gerard.gastaud@alcatel.fr]
Gerard Gastaud [gerard.gastaud@alcatel.fr]
Jun-ichiro itojun Hagino [itojun@iijlab.net]
jun-ichiro itojun hagino [itojun@iijlab.net]
Atsushi Inoue [inoue@isl.rdc.toshiba.co.jp]
ATSUSHI INOUE [inoue@isl.rdc.toshiba.co.jp]
Masahiro Ishiyama [masahiro@isl.rdc.toshiba.co.jp]
石山島[masahiro@isl.rdc.toshiba.co.jp]
John Loughney [john.loughney@nokia.com]
ジョン・ラフニー[john.loughney@nokia.com]
Rajiv Raghunarayan [raraghun@cisco.com]
Rajiv Raghunarayan [raraghun@cisco.com]
Shoichi Sakane [shouichi.sakane@jp.yokogawa.com]
Shoichi sakane [shouichi.sakane@jp.yokogawa.com]
Dave Thaler [dthaler@windows.microsoft.com]
Dave Thaler [dthaler@windows.microsoft.com]
Juha Wiljakka [juha.wiljakka@Nokia.com]
Juha 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.
著者は、Ran Atkinson、Jim Bound、Brian Carpenter、Ralph Droms、Christian Huitema、Adam Machalek、Thomas Narten、Juha Ollila、Pekka 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
ジョン・ラフニー・ノキア研究センターitamerenkatu 11-13 00180ヘルシンキフィンランド
Phone: +358 50 483 6242
EMail: John.Loughney@Nokia.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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）によって提供されます。