[要約] RFC 4891は、IPv6-in-IPv4トンネルを保護するためにIPsecを使用する方法についてのガイドラインです。このRFCの目的は、IPv6トラフィックをIPv4ネットワーク上で安全に転送するためのセキュリティメカニズムを提供することです。
Network Working Group R. Graveman
Request for Comments: 4891 RFG Security, LLC
Category: Informational M. Parthasarathy
Nokia
P. Savola
CSC/FUNET
H. Tschofenig
Nokia Siemens Networks
May 2007
Using IPsec to Secure IPv6-in-IPv4 Tunnels
IPSECを使用してIPv6-in-IPV4トンネルを保護します
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 IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
Abstract
概要
This document gives guidance on securing manually configured IPv6-in-IPv4 tunnels using IPsec in transport mode. No additional protocol extensions are described beyond those available with the IPsec framework.
このドキュメントは、輸送モードでIPSECを使用して、手動で構成されたIPv6-in-IPV4トンネルを保護するためのガイダンスを提供します。IPSECフレームワークで利用可能なものを超えて、追加のプロトコル拡張機能は説明されていません。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Threats and the Use of IPsec . . . . . . . . . . . . . . . . . 3
2.1. IPsec in Transport Mode . . . . . . . . . . . . . . . . . 4
2.2. IPsec in Tunnel Mode . . . . . . . . . . . . . . . . . . . 5
3. Scenarios and Overview . . . . . . . . . . . . . . . . . . . . 5
3.1. Router-to-Router Tunnels . . . . . . . . . . . . . . . . . 6
3.2. Site-to-Router/Router-to-Site Tunnels . . . . . . . . . . 6
3.3. Host-to-Host Tunnels . . . . . . . . . . . . . . . . . . . 8
4. IKE and IPsec Versions . . . . . . . . . . . . . . . . . . . . 9
5. IPsec Configuration Details . . . . . . . . . . . . . . . . . 10
5.1. IPsec Transport Mode . . . . . . . . . . . . . . . . . . . 11
5.2. Peer Authorization Database and Identities . . . . . . . . 12
6. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . . 15
Appendix A. Using Tunnel Mode . . . . . . . . . . . . . . . . . . 17
A.1. Tunnel Mode Implementation Methods . . . . . . . . . . . . 17
A.2. Specific SPD for Host-to-Host Scenario . . . . . . . . . . 18
A.3. Specific SPD for Host-to-Router Scenario . . . . . . . . . 19
Appendix B. Optional Features . . . . . . . . . . . . . . . . . . 20
B.1. Dynamic Address Configuration . . . . . . . . . . . . . . 20
B.2. NAT Traversal and Mobility . . . . . . . . . . . . . . . . 20
B.3. Tunnel Endpoint Discovery . . . . . . . . . . . . . . . . 21
The IPv6 Operations (v6ops) working group has selected (manually configured) IPv6-in-IPv4 tunneling [RFC4213] as one of the IPv6 transition mechanisms for IPv6 deployment.
IPv6操作（V6OPS）ワーキンググループは、IPv6展開のIPv6遷移メカニズムの1つとして、IPv6-in-IPV4トンネル[RFC4213]を選択しました。
[RFC4213] identified a number of threats that had not been adequately analyzed or addressed in its predecessor [RFC2893]. The most complete solution is to use IPsec to protect IPv6-in-IPv4 tunneling. The document was intentionally not expanded to include the details on how to set up an IPsec-protected tunnel in an interoperable manner, but instead the details were deferred to this memo.
[RFC4213]は、その前身で適切に分析または対処されていない多くの脅威を特定しました[RFC2893]。最も完全な解決策は、IPSECを使用してIPv6-in-IPV4トンネリングを保護することです。このドキュメントは、IPSECで保護されたトンネルを相互運用可能な方法でセットアップする方法の詳細を含めるように意図的に拡張されていませんでしたが、その代わりに詳細はこのメモに延期されました。
The first four sections of this document analyze the threats and scenarios that can be addressed by IPsec and assumptions made by this document for successful IPsec Security Association (SA) establishment. Section 5 gives the details of Internet Key Exchange (IKE) and IP security (IPsec) exchange with packet formats and Security Policy Database (SPD) entries. Section 6 gives recommendations. Appendices further discuss tunnel mode usage and optional extensions.
このドキュメントの最初の4つのセクションでは、IPSECセキュリティ協会（SA）の成功のためにこのドキュメントが行ったIPSECおよび仮定によって対処できる脅威とシナリオを分析します。セクション5では、インターネットキーエクスチェンジ（IKE）およびIPセキュリティ（IPSEC）交換の詳細と、パケット形式とセキュリティポリシーデータベース（SPD）エントリを使用します。セクション6で推奨事項を示します。付録では、トンネルモードの使用とオプションの拡張機能についてさらに説明します。
This document does not address the use of IPsec for tunnels that are not manually configured (e.g., 6to4 tunnels [RFC3056]). Presumably, some form of opportunistic encryption or "better-than-nothing security" might or might not be applicable. Similarly, propagating quality-of-service attributes (apart from Explicit Congestion Notification bits [RFC4213]) from the encapsulated packets to the tunnel path is out of scope.
このドキュメントでは、手動で構成されていないトンネルへのIPSECの使用については対処していません（例：6to4トンネル[RFC3056]）。おそらく、何らかの形の日和見的暗号化または「より良いセキュリティ」が適用されるかもしれないし、適用されるかもしれないし、そうでないかもしれない。同様に、カプセル化されたパケットからトンネルパスまでのサービス品質属性（明示的な輻輳通知ビット[RFC4213]を除く）を伝播することは範囲外です。
The use of the word "interface" or the phrase "IP interface" refers to the IPv6 interface that must be present on any IPv6 node to send or receive IPv6 packets. The use of the phrase "tunnel interface" refers to the interface that receives the IPv6-in-IPv4 tunneled packets over IPv4.
「インターフェイス」またはフレーズ「IPインターフェイス」という言葉の使用は、IPv6パケットを送信または受信するために任意のIPv6ノードに存在する必要があるIPv6インターフェイスを指します。「トンネルインターフェイス」というフレーズの使用は、IPv4を介してIPv6-in-IPv4トンネルパケットを受信するインターフェイスを指します。
[RFC4213] is mostly concerned about address spoofing threats:
[RFC4213]は、住所のスプーフィングの脅威について主に心配しています。
1. The IPv4 source address of the encapsulating ("outer") packet can be spoofed.
1. カプセル化（ "outer"）パケットのIPv4ソースアドレスをスプーフィングできます。
2. The IPv6 source address of the encapsulated ("inner") packet can be spoofed.
2. カプセル化された（「内側」）パケットのIPv6ソースアドレスをスプーフィングできます。
The reason threat (1) exists is the lack of universal deployment of IPv4 ingress filtering [RFC3704]. The reason threat (2) exists is that the IPv6 packet is encapsulated in IPv4 and hence may escape IPv6 ingress filtering. [RFC4213] specifies the following strict address checks as mitigating measures:
脅威（1）が存在する理由は、IPv4イングレスフィルタリング[RFC3704]の普遍的な展開の欠如です。脅威（2）が存在する理由は、IPv6パケットがIPv4にカプセル化されているため、IPv6イングレスフィルタリングをエスケープする可能性があるためです。[RFC4213]は、次の厳格なアドレスチェックを緩和測定として指定します。
o To mitigate threat (1), the decapsulator verifies that the IPv4 source address of the packet is the same as the address of the configured tunnel endpoint. The decapsulator may also implement IPv4 ingress filtering, i.e., check whether the packet is received on a legitimate interface.
o 脅威を軽減するために、脱カプセレーターは、パケットのIPv4ソースアドレスが構成されたトンネルエンドポイントのアドレスと同じであることを確認します。Decapsuratorは、IPv4イングレスフィルタリングを実装する場合もあります。つまり、パケットが正当なインターフェイスで受信されるかどうかを確認します。
o To mitigate threat (2), the decapsulator verifies whether the inner IPv6 address is a valid IPv6 address and also applies IPv6 ingress filtering before accepting the IPv6 packet.
o 脅威を軽減するために、脱カプセレーターは、内側のIPv6アドレスが有効なIPv6アドレスであるかどうかを確認し、IPv6パケットを受け入れる前にIPv6イングレスフィルタリングも適用します。
This memo proposes using IPsec for providing stronger security in preventing these threats and additionally providing integrity, confidentiality, replay protection, and origin protection between tunnel endpoints.
このメモは、これらの脅威を防止し、トンネルエンドポイント間の整合性、機密性、リプレイ保護、および起源保護をさらに提供するために、より強力なセキュリティを提供するためにIPSECを使用することを提案しています。
IPsec can be used in two ways, in transport and tunnel mode; detailed discussion about applicability in this context is provided in Section 5.
IPSECは、輸送モードとトンネルモードの2つの方法で使用できます。このコンテキストでの適用性に関する詳細な議論は、セクション5に記載されています。
In transport mode, the IPsec Encapsulating Security Payload (ESP) or Authentication Header (AH) security association (SA) is established to protect the traffic defined by (IPv4-source, IPv4-dest, protocol = 41). On receiving such an IPsec packet, the receiver first applies the IPsec transform (e.g., ESP) and then matches the packet against the Security Parameter Index (SPI) and the inbound selectors associated with the SA to verify that the packet is appropriate for the SA via which it was received. A successful verification implies that the packet came from the right IPv4 endpoint, because the SA is bound to the IPv4 source address.
トランスポートモードでは、（IPv4-Source、IPv4-Dest、Protocol = 41）で定義されたトラフィックを保護するために、セキュリティペイロード（ESP）または認証ヘッダー（AH）セキュリティ協会（AH）のセキュリティヘッダー（AH）セキュリティ協会（AH）をカプセル化するIPSECが確立されています。このようなIPSECパケットを受信すると、受信機は最初にIPSEC変換（ESPなど）を適用し、次にパケットをSAに関連付けたインバウンドセレクターと一致させ、SAにパケットがSAに適していることを確認します。それを介して受け取られました。検証が成功すると、SAがIPv4ソースアドレスに結合しているため、パケットが適切なIPv4エンドポイントから来たことが意味されます。
This prevents threat (1) but not threat (2). IPsec in transport mode does not verify the contents of the payload itself where the IPv6 addresses are carried. That is, two nodes using IPsec transport mode to secure the tunnel can spoof the inner payload. The packet will be decapsulated successfully and accepted.
これは脅威（1）を防ぎますが、脅威（2）ではありません。輸送モードのIPSECは、IPv6アドレスが運ばれるペイロード自体の内容を検証しません。つまり、IPSECトランスポートモードを使用してトンネルを保護する2つのノードは、内部ペイロードを押し上げる可能性があります。パケットは脱カプセル化され、受け入れられます。
This shortcoming can be partially mitigated by IPv6 ingress filtering, i.e., check that the packet is arriving from the interface in the direction of the route towards the tunnel endpoint, similar to a Strict Reverse Path Forwarding (RPF) check [RFC3704].
この欠点は、IPv6イングレスフィルタリングによって部分的に軽減できます。つまり、パケットがトンネルエンドポイントに向かってルートの方向にインターフェイスから到着していることを確認します。
In most implementations, a transport mode SA is applied to a normal IPv6-in-IPv4 tunnel. Therefore, ingress filtering can be applied in the tunnel interface. (Transport mode is often also used in other kinds of tunnels such as Generic Routing Encapsulation (GRE) [RFC4023] and Layer 2 Tunneling Protocol (L2TP) [RFC3193].)
ほとんどの実装では、輸送モードSAが通常のIPv6-in-IPV4トンネルに適用されます。したがって、イングレスフィルタリングはトンネルインターフェイスに適用できます。（輸送モードは、一般的なルーティングカプセル化（GRE）[RFC4023]やレイヤー2トンネルプロトコル（L2TP）[RFC3193]などの他の種類のトンネルでも使用されることがよくあります。）
In tunnel mode, the IPsec SA is established to protect the traffic defined by (IPv6-source, IPv6-destination). On receiving such an IPsec packet, the receiver first applies the IPsec transform (e.g., ESP) and then matches the packet against the SPI and the inbound selectors associated with the SA to verify that the packet is appropriate for the SA via which it was received. The successful verification implies that the packet came from the right endpoint.
トンネルモードでは、（IPv6-Source、IPv6-destination）によって定義されたトラフィックを保護するためにIPSEC SAが確立されます。このようなIPSECパケットを受信すると、受信機は最初にIPSEC変換（例えば、ESP）を適用し、次にSAに関連付けられたSPIとインバウンドセレクターに対してパケットを一致させて、パケットが受信したSAに適していることを確認します。。検証が成功したことは、パケットが正しいエンドポイントから来たことを意味します。
The outer IPv4 addresses may be spoofed, and IPsec cannot detect this in tunnel mode; the packets will be demultiplexed based on the SPI and possibly the IPv6 address bound to the SA. Thus, the outer address spoofing is irrelevant as long as the decryption succeeds and the inner IPv6 packet can be verified to have come from the right tunnel endpoint.
外側のIPv4アドレスがスプーフィングされる可能性があり、IPSECはトンネルモードでこれを検出できません。SPIと場合によってはSAにバインドされたIPv6アドレスに基づいて、パケットは反転されます。したがって、復号化が成功し、内側のIPv6パケットが適切なトンネルエンドポイントから来たことを確認できる限り、外側のアドレススプーフィングは無関係です。
As described in Section 5, using tunnel mode is more difficult than applying transport mode to a tunnel interface, and as a result this document recommends transport mode. Note that even though transport rather than tunnel mode is recommended, an IPv6-in-IPv4 tunnel specified by protocol 41 still exists [RFC4213].
セクション5で説明したように、トンネルモードの使用はトンネルインターフェイスに輸送モードを適用するよりも困難であり、その結果、このドキュメントは輸送モードを推奨します。トンネルモードではなく輸送が推奨されていても、プロトコル41で指定されたIPv6-in-IPV4トンネルがまだ存在していることに注意してください[RFC4213]。
There are roughly three scenarios:
およそ3つのシナリオがあります。
1. (Generic) router-to-router tunnels.
1. （ジェネリック）ルーターからルーターへのトンネル。
2. Site-to-router or router-to-site tunnels. These refer to tunnels between a site's IPv6 (border) device and an IPv6 upstream provider's router. A degenerate case of a site is a single host.
2. サイトからルーターまたはルーターからサイトへのトンネル。これらは、サイトのIPv6（Border）デバイスとIPv6の上流プロバイダーのルーター間のトンネルを指します。サイトの退化したケースは、単一のホストです。
3. Host-to-host tunnels.
3. ホストツーホストトンネル。
IPv6/IPv4 hosts and routers can tunnel IPv6 datagrams over regions of IPv4 forwarding topology by encapsulating them within IPv4 packets. Tunneling can be used in a variety of ways.
IPv6/IPv4ホストとルーターは、IPv4パケット内でそれらをカプセル化することにより、IPv4転送トポロジの領域でIPv6データグラムをトンネルできます。トンネリングはさまざまな方法で使用できます。
.--------. _----_ .--------.
|v6-in-v4| _( IPv4 )_ |v6-in-v4|
| Router | <======( Internet )=====> | Router |
| A | (_ _) | B |
'--------' '----' '--------'
^ IPsec tunnel between ^
| Router A and Router B |
V V
Figure 1: Router-to-Router Scenario.
図1：ルーター間シナリオ。
IPv6/IPv4 routers interconnected by an IPv4 infrastructure can tunnel IPv6 packets between themselves. In this case, the tunnel spans one segment of the end-to-end path that the IPv6 packet takes.
IPv6/IPv4ルーターは、IPv4インフラストラクチャによって相互接続されている可能性があります。この場合、トンネルは、IPv6パケットがとるエンドツーエンドパスの1つのセグメントにまたがっています。
The source and destination addresses of the IPv6 packets traversing the tunnel could come from a wide range of IPv6 prefixes, so binding IPv6 addresses to be used to the SA is not generally feasible. IPv6 ingress filtering must be performed to mitigate the IPv6 address spoofing threat.
トンネルを横断するIPv6パケットのソースおよび宛先アドレスは、幅広いIPv6プレフィックスから生じる可能性があるため、SAに使用するIPv6アドレスを結合することは一般に実行不可能です。IPv6イングレスフィルタリングを実行して、IPv6アドレスのスプーフィング脅威を緩和する必要があります。
A specific case of router-to-router tunnels, when one router resides at an end site, is described in the next section.
ルーターからルーターへのトンネルの特定のケースは、1つのルーターがエンドサイトに存在する場合、次のセクションで説明します。
This is a generalization of host-to-router and router-to-host tunneling, because the issues when connecting a whole site (using a router) and connecting a single host are roughly equal.
これは、ホストからルーターへの一般化と、ルーターからホストへのトンネルの一般化です。これは、サイト全体を接続して（ルーターを使用）、単一のホストを接続する場合の問題がほぼ等しいためです。
_----_ .---------. IPsec _----_ IPsec .-------.
_( IPv6 )_ |v6-in-v4 | Tunnel _( IPv4 )_ Tunnel | V4/V6 |
( Internet )<--->| Router |<=======( Internet )=======>| Site B |
(_ _) | A | (_ _) '--------'
'----' '---------' '----'
^
|
V
.--------.
| Native |
| IPv6 |
| node |
'--------'
Figure 2: Router-to-Site Scenario.
図2：ルーターからサイトへのシナリオ。
IPv6/IPv4 routers can tunnel IPv6 packets to their final destination IPv6/IPv4 site. This tunnel spans only the last segment of the end-to-end path.
IPv6/IPv4ルーターは、IPv6パケットを最終宛先IPv6/IPv4サイトにトンネルできます。このトンネルは、エンドツーエンドパスの最後のセグメントのみに及びます。
+---------------------+
| IPv6 Network |
| |
.--------. _----_ | .--------. |
| V6/V4 | _( IPv4 )_ | |v6-in-v4| |
| Site B |<====( Internet )==========>| Router | |
'--------' (_ _) | | A | |
'----' | '--------' |
IPsec tunnel between | ^ |
IPv6 Site and Router A | | |
| V |
| .-------. |
| | V6 | |
| | Hosts | |
| '--------' |
+---------------------+
Figure 3: Site-to-Router Scenario.
図3：サイト間シナリオ。
In the other direction, IPv6/IPv4 hosts can tunnel IPv6 packets to an intermediary IPv6/IPv4 router that is reachable via an IPv4 infrastructure. This type of tunnel spans the first segment of the packet's end-to-end path.
他の方向では、IPv6/IPv4ホストは、IPv4インフラストラクチャを介して到達可能な中間IPv6/IPv4ルーターにIPv6パケットをトンネルできます。このタイプのトンネルは、パケットのエンドツーエンドパスの最初のセグメントに及びます。
The hosts in the site originate the packets with IPv6 source addresses coming from a well-known prefix, whereas the destination addresses could be any nodes on the Internet.
サイトのホストは、よく知られているプレフィックスからのIPv6ソースアドレスを備えたパケットを発信しますが、宛先アドレスはインターネット上の任意のノードである可能性があります。
In this case, an IPsec tunnel mode SA could be bound to the prefix that was allocated to the router at Site B, and Router A could verify that the source address of the packet matches the prefix. Site B will not be able to do a similar verification for the packets it receives. This may be quite reasonable for most of the deployment cases, for example, an Internet Service Provider (ISP) allocating a /48 to a customer. The Customer Premises Equipment (CPE) where the tunnel is terminated "trusts" (in a weak sense) the ISP's router, and the ISP's router can verify that Site B is the only one that can originate packets within the /48.
この場合、IPSECトンネルモードSAは、サイトBのルーターに割り当てられたプレフィックスにバインドできます。ルーターAは、パケットのソースアドレスがプレフィックスと一致することを確認できます。サイトBは、受信するパケットについて同様の確認を行うことはできません。これは、ほとんどの展開ケース、たとえばインターネットサービスプロバイダー（ISP）がA /48を顧客に割り当てるのに非常に合理的かもしれません。トンネルが「信頼」（弱い意味で）がISPのルーターを終了し、ISPのルーターがサイトBが /48内のパケットを発信できる唯一のものであることを確認できます。
IPv6 spoofing must be prevented, and setting up ingress filtering may require some amount of manual configuration; see more of these options in Section 5.
IPv6スプーフィングを防ぐ必要があり、イングレスフィルタリングをセットアップするには、ある程度の手動構成が必要になる場合があります。セクション5のこれらのオプションの詳細をご覧ください。
.--------. _----_ .--------.
| V6/V4 | _( IPv4 )_ | V6/V4 |
| Host | <======( Internet )=====> | Host |
| A | (_ _) | B |
'--------' '----' '--------'
IPsec tunnel between
Host A and Host B
Figure 4: Host-to-Host Scenario.
図4：ホストからホストへのシナリオ。
IPv6/IPv4 hosts interconnected by an IPv4 infrastructure can tunnel IPv6 packets between themselves. In this case, the tunnel spans the entire end-to-end path.
IPv6/IPv4は、IPv4インフラストラクチャによって相互接続されたホストをホストします。この場合、トンネルはエンドツーエンドパス全体に広がります。
In this case, the source and the destination IPv6 addresses are known a priori. A tunnel mode SA could be bound to these specific addresses. Address verification prevents IPv6 source address spoofing completely.
この場合、ソースと宛先IPv6アドレスは先験的に知られています。トンネルモードSAは、これらの特定のアドレスにバインドできます。アドレス検証により、IPv6ソースアドレスのスプーフィングが完全に防止されます。
As noted in the Introduction, automatic host-to-host tunneling methods (e.g., 6to4) are out of scope for this memo.
導入部で述べたように、自動ホストからホストへのトンネリング方法（例：6to4）は、このメモの範囲外です。
This section discusses the different versions of the IKE and IPsec security architecture and their applicability to this document.
このセクションでは、IKEおよびIPSECセキュリティアーキテクチャのさまざまなバージョンと、このドキュメントへの適用性について説明します。
The IPsec security architecture was previously defined in [RFC2401] and is now superseded by [RFC4301]. IKE was originally defined in [RFC2409] (which is called IKEv1 in this document) and is now superseded by [RFC4306] (called IKEv2; see also [RFC4718]). There are several differences between them. The differences relevant to this document are discussed below.
IPSECセキュリティアーキテクチャは以前[RFC2401]で定義されており、現在は[RFC4301]に取って代わられています。IKEはもともと[RFC2409]（このドキュメントではIKEV1と呼ばれています）で定義されており、現在[RFC4306]（IKEV2と呼ばれ、[RFC4718]も参照）に取って代わられています。それらにはいくつかの違いがあります。このドキュメントに関連する違いについては、以下で説明します。
1. [RFC2401] does not require allowing IP as the next layer protocol in traffic selectors when an IPsec SA is negotiated. In contrast, [RFC4301] requires supporting IP as the next layer protocol (like TCP or UDP) in traffic selectors.
1. [RFC2401]は、IPSEC SAが交渉されたときに、トラフィックセレクターの次のレイヤープロトコルとしてIPを許可する必要はありません。対照的に、[RFC4301]は、トラフィックセレクターの次のレイヤープロトコル（TCPやUDPなど）としてIPをサポートする必要があります。
2. [RFC4301] assumes IKEv2, as some of the new features cannot be negotiated using IKEv1. It is valid to negotiate multiple traffic selectors for a given IPsec SA in [RFC4301]. This is possible only with IKEv2. If IKEv1 is used, then multiple SAs need to be set up, one for each traffic selector.
2. [RFC4301]は、IKEV1を使用して新しい機能の一部を交渉できないため、IKEV2を想定しています。[RFC4301]の特定のIPSEC SAの複数のトラフィックセレクターを交渉することは有効です。これは、IKEV2でのみ可能です。IKEV1を使用する場合、複数のSASをセットアップする必要があります。1つはトラフィックセレクターごとに1つです。
Note that the existing implementations based on IKEv1 may already be able to support the [RFC4301] features described in (1) and (2). If appropriate, the deployment may choose to use either version of the security architecture.
IKEV1に基づく既存の実装は、（1）および（2）で説明されている[RFC4301]機能を既にサポートできる可能性があることに注意してください。必要に応じて、展開はどちらのバージョンのセキュリティアーキテクチャを使用するかを選択できます。
IKEv2 supports features useful for configuring and securing tunnels not present with IKEv1.
IKEV2は、IKEV1に存在しないトンネルの構成と保護に役立つ機能をサポートしています。
1. IKEv2 supports legacy authentication methods by carrying them in Extensible Authentication Protocol (EAP) payloads. This can be used to authenticate hosts or sites to an ISP using EAP methods that support username and password.
1. IKEV2は、拡張可能な認証プロトコル（EAP）ペイロードでそれらを運ぶことにより、レガシー認証方法をサポートします。これは、ユーザー名とパスワードをサポートするEAPメソッドを使用して、ホストまたはサイトをISPに認証するために使用できます。
2. IKEv2 supports dynamic address configuration, which may be used to configure the IPv6 address of the host.
2. IKEV2は、ホストのIPv6アドレスを構成するために使用される動的アドレス構成をサポートします。
Network Address Translation (NAT) traversal works with both the old and revised IPsec architectures, but the negotiation is integrated with IKEv2.
ネットワークアドレス変換（NAT）トラバーサルは、古いIPSECアーキテクチャと改訂されたIPSECアーキテクチャの両方で機能しますが、交渉はIKEV2と統合されています。
For the purposes of this document, where the confidentiality of ESP [RFC4303] is not required, AH [RFC4302] can be used as an alternative to ESP. The main difference is that AH is able to provide integrity protection for certain fields in the outer IPv4 header and IPv4 options. However, as the outer IPv4 header will be discarded in any case, and those particular fields are not believed to be relevant in this particular application, there is no particular reason to use AH.
ESP [RFC4303]の機密性が必要ないこのドキュメントの目的のために、AH [RFC4302]はESPの代替として使用できます。主な違いは、AHが外側のIPv4ヘッダーとIPv4オプションの特定のフィールドに整合性保護を提供できることです。ただし、いずれにしても外側のIPv4ヘッダーは破棄され、これらの特定のフィールドはこの特定のアプリケーションに関連するとは考えられていないため、AHを使用する特別な理由はありません。
This section describes the SPD entries for setting up the IPsec transport mode SA to protect the IPv6 traffic.
このセクションでは、IPv6トラフィックを保護するためにIPSECトランスポートモードSAをセットアップするためのSPDエントリについて説明します。
Several requirements arise when IPsec is used to protect the IPv6 traffic (inner header) for the scenarios listed in Section 3.
セクション3にリストされているシナリオのIPv6トラフィック（内側ヘッダー）を保護するためにIPSECを使用すると、いくつかの要件が生じます。
1. All of IPv6 traffic should be protected, including link-local (e.g., Neighbor Discovery) and multicast traffic. Without this, an attacker can pollute the IPv6 neighbor cache causing disruption in communication between the two routers.
1. Link-Local（隣接発見など）やマルチキャストトラフィックなど、IPv6トラフィックはすべて保護する必要があります。これがなければ、攻撃者はIPv6ネイバーキャッシュを汚染し、2つのルーター間の通信を混乱させます。
2. In router-to-router tunnels, the source and destination addresses of the traffic could come from a wide range of prefixes that are normally learned through routing. As routing can always learn a new prefix, one cannot assume that all the prefixes are known a priori [RFC3884]. This mainly affects scenario (1).
2. ルーターからルーターへのトンネルでは、トラフィックのソースと宛先アドレスは、通常はルーティングを通じて学習される幅広いプレフィックスから得られる可能性があります。ルーティングは常に新しいプレフィックスを学習できるため、すべてのプレフィックスが先験的に既知であると想定することはできません[RFC3884]。これは主にシナリオ（1）に影響します。
3. Source address selection depends on the notions of routes and interfaces. This implies that the reachability to the various IPv6 destinations appear as routes in the routing table. This affects scenarios (2) and (3).
3. ソースアドレスの選択は、ルートとインターフェイスの概念に依存します。これは、さまざまなIPv6宛先の到達可能性がルーティングテーブルのルートとして表示されることを意味します。これは、シナリオ（2）および（3）に影響します。
The IPv6 traffic can be protected using transport or tunnel mode. There are many problems when using tunnel mode as implementations may or may not model the IPsec tunnel mode SA as an interface as described in Appendix A.1.
IPv6トラフィックは、輸送モードまたはトンネルモードを使用して保護できます。実装としてトンネルモードを使用すると、IPSECトンネルモードSAをインターフェイスとしてモデル化する場合としない場合、付録A.1で説明している場合は多くの問題があります。
If IPsec tunnel mode SA is not modeled as an interface (e.g., as of this writing, popular in many open source implementations), the SPD entries for protecting all traffic between the two endpoints must be described. Evaluating against the requirements above, all link-local traffic multicast traffic would need to be identified, possibly resulting in a long list of SPD entries. The second requirement is difficult to satisfy, because the traffic needing protection is not necessarily (e.g., router-to-router tunnel) known a priori [RFC3884]. The third requirement is also problematic, because almost all implementations assume addresses are assigned on interfaces (rather than configured in SPDs) for proper source address selection.
IPSECトンネルモードSAがインターフェイスとしてモデル化されていない場合（たとえば、この記述のように、多くのオープンソースの実装で人気）、2つのエンドポイント間のすべてのトラフィックを保護するためのSPDエントリを説明する必要があります。上記の要件に対して評価すると、すべてのLink-Local Traffic Multicast Trafficを特定する必要があり、SPDエントリの長いリストになる可能性があります。保護を必要とするトラフィックは必ずしも（例えば、ルーターからルーターへのトンネルなど）先験的な[RFC3884]が知られているわけではないため、2番目の要件を満たすことは困難です。適切なソースアドレスの選択のために、ほとんどすべての実装がアドレスがインターフェイス（SPDで構成されているのではなく）に割り当てられていると仮定すると仮定するため、3番目の要件も問題です。
If the IPsec tunnel mode SA is modeled as interface, the traffic that needs protection can be modeled as routes pointing to the interface. But the second requirement is difficult to satisfy, because the traffic needing protection is not necessarily known a priori. The third requirement is easily solved, because IPsec is modeled as an interface.
IPSECトンネルモードSAがインターフェイスとしてモデル化されている場合、保護を必要とするトラフィックは、インターフェイスを指すルートとしてモデル化できます。しかし、保護を必要とするトラフィックは必ずしもアプリオリであるとは限らないため、2番目の要件を満たすことは困難です。IPSECはインターフェイスとしてモデル化されるため、3番目の要件は簡単に解決できます。
In practice, (2) has been solved by protecting all the traffic (::/0), but no interoperable implementations support this feature. For a detailed list of issues pertaining to this, see [VLINK].
実際には、（2）はすべてのトラフィック（::/0）を保護することで解決されていますが、相互運用可能な実装はこの機能をサポートしていません。これに関連する問題の詳細なリストについては、[vlink]を参照してください。
Because applying transport mode to protect a tunnel is a much simpler solution and also easily protects link-local and multicast traffic, we do not recommend using tunnel mode in this context. Tunnel mode is, however, discussed further in Appendix A.
トンネルを保護するためにトランスポートモードを適用することははるかに簡単なソリューションであり、Link-LocalおよびMulticastトラフィックを簡単に保護するため、このコンテキストでトンネルモードを使用することはお勧めしません。ただし、トンネルモードについては、付録Aでさらに説明します。
This document assumes that tunnels are manually configured on both sides and the ingress filtering is manually set up to discard spoofed packets.
このドキュメントでは、トンネルが両側で手動で構成されており、イングレスフィルタリングがスプーフィングされたパケットを破棄するように手動でセットされていると想定しています。
Transport mode has typically been applied to L2TP, GRE, and other tunneling methods, especially when the user wants to tunnel non-IP traffic. [RFC3884], [RFC3193], and [RFC4023] provide examples of applying transport mode to protect tunnel traffic that spans only a part of an end-to-end path.
通常、トランスポートモードは、特にユーザーが非IPトラフィックをトンネルしたい場合、L2TP、GRE、およびその他のトンネルメソッドに適用されます。[RFC3884]、[RFC3193]、および[RFC4023]は、エンドツーエンドパスの一部に及ぶトンネルトラフィックを保護するための輸送モードを適用する例を提供します。
IPv6 ingress filtering must be applied on the tunnel interface on all the packets that pass the inbound IPsec processing.
IPv6イングレスフィルタリングは、インバウンドIPSEC処理に合格するすべてのパケットのトンネルインターフェイスに適用する必要があります。
The following SPD entries assume that there are two routers, Router1 and Router2, with tunnel endpoint IPv4 addresses denoted IPV4-TEP1 and IPV4-TEP2, respectively. (In other scenarios, the SPDs are set up similarly.)
次のSPDエントリは、Tunnel Endpoint IPv4アドレスがそれぞれIPv4-Tep1とIPv4-Tep2を示し、Router1とRouter2の2つのRouterがあることを想定しています。（他のシナリオでは、SPDも同様にセットアップされています。）
Router1's SPD:
Next Layer
Rule Local Remote Protocol Action
---- ----- ------ ---------- --------
1 IPV4-TEP1 IPV4-TEP2 ESP BYPASS
2 IPV4-TEP1 IPV4-TEP2 IKE BYPASS
3 IPv4-TEP1 IPV4-TEP2 41 PROTECT(ESP,transport)
Router2's SPD:
Next Layer
Rule Local Remote Protocol Action
---- ----- ------ ---------- --------
1 IPV4-TEP2 IPV4-TEP1 ESP BYPASS
2 IPV4-TEP2 IPV4-TEP1 IKE BYPASS
3 IPv4-TEP2 IPV4-TEP1 41 PROTECT(ESP,transport)
In both SPD entries, "IKE" refers to UDP destination port 500 and possibly also port 4500 if NAT traversal is used.
両方のSPDエントリで、「IKE」はUDP宛先ポート500を指し、場合によってはNATトラバーサルが使用されている場合はポート4500も指します。
The packet format is as shown in Table 1.
パケット形式は、表1に示すとおりです。
+----------------------------+------------------------------------+
| Components (first to last) | Contains |
+----------------------------+------------------------------------+
| IPv4 header | (src = IPV4-TEP1, dst = IPV4-TEP2) |
| ESP header | |
| IPv6 header | (src = IPV6-EP1, dst = IPV6-EP2) |
| (payload) | |
+----------------------------+------------------------------------+
Table 1: Packet Format for IPv6/IPv4 Tunnels.
表1：IPv6/IPv4トンネルのパケット形式。
The IDci and IDcr payloads of IKEv1 carry the IPv4-TEP1, IPV4-TEP2, and protocol value 41 as phase 2 identities. With IKEv2, the traffic selectors are used to carry the same information.
IKEV1のIDCIおよびIDCRペイロードは、IPv4-TEP1、IPv4-TEP2、およびプロトコル値41をフェーズ2のアイデンティティとして運びます。IKEV2を使用すると、トラフィックセレクターを使用して同じ情報を掲載します。
The Peer Authorization Database (PAD) provides the link between SPD and the key management daemon [RFC4306]. This is defined in [RFC4301] and hence relevant only when used with IKEv2.
Peer Authorizationデータベース（PAD）は、SPDと主要な管理デーモン[RFC4306]の間のリンクを提供します。これは[RFC4301]で定義されているため、IKEV2で使用された場合にのみ関連性があります。
As there is currently no defined way to discover the PAD-related parameters dynamically, it is assumed that these are manually configured:
現在、パッド関連のパラメーターを動的に発見する定義された方法はないため、これらは手動で構成されていると想定されています。
o The Identity of the peer asserted in the IKEv2 exchange: Many different types of identities can be used. At least, the IPv4 address of the peer should be supported.
o IKEV2 Exchangeで主張されているピアのアイデンティティ：さまざまなタイプのアイデンティティを使用できます。少なくとも、ピアのIPv4アドレスをサポートする必要があります。
o IKEv2 can authenticate the peer by several methods. Pre-shared key and X.509 certificate-based authentication is required by [RFC4301]. At least, pre-shared key should be supported, because it interoperates with a larger number of implementations.
o IKEV2は、いくつかの方法でピアを認証できます。[RFC4301]では、事前に共有キーとX.509証明書ベースの認証が必要です。少なくとも、より多くの実装と相互運用するため、少なくとも恥ずかしさキーをサポートする必要があります。
o The child SA authorization data should contain the IPv4 address of the peer.
o Child SA承認データには、ピアのIPv4アドレスを含める必要があります。
IPv4 address should be supported as Identity during the key exchange. As this does not provide Identity protection, main mode or aggressive mode can be used with IKEv1.
IPv4アドレスは、キーエクスチェンジ中にIDとしてサポートされる必要があります。これはアイデンティティ保護を提供しないため、IKEV1でメインモードまたはアグレッシブモードを使用できます。
In Section 5, we examined the differences between setting up an IPsec IPv6-in-IPv4 tunnel using either transport or tunnel mode. We observe that applying transport mode to a tunnel interface is the simplest and therefore recommended solution.
セクション5では、輸送モードまたはトンネルモードのいずれかを使用してIPSEC IPv6-in-IPV4トンネルのセットアップの違いを調べました。トンネルインターフェイスに輸送モードを適用することが最も簡単で推奨されるソリューションであることがわかります。
In Appendix A, we also explore what it would take to use so-called Specific SPD (SSPD) tunnel mode. Such usage is more complicated because IPv6 prefixes need to be known a priori, and multicast and link-local traffic do not work over such a tunnel. Fragment handling in tunnel mode is also more difficult. However, because the Mobility and Multihoming Protocol (MOBIKE) [RFC4555] supports only tunnel mode, when the IPv4 endpoints of a tunnel are dynamic and the other constraints are not applicable, using tunnel mode may be an acceptable solution.
付録Aでは、いわゆる特定のSPD（SSPD）トンネルモードを使用するために必要なことも調査します。IPv6プレフィックスはアプリオリであることを知っている必要があり、マルチキャストとリンクローカルトラフィックはそのようなトンネル上で機能しないため、このような使用法はより複雑です。トンネルモードでのフラグメント処理もより困難です。ただし、トンネルのIPv4エンドポイントが動的であり、他の制約が適用されない場合、トンネルモードを使用することは許容可能なソリューションである場合、モビリティとマルチホームプロトコル（Mobike）[RFC4555]はトンネルモードのみをサポートするためです。
Therefore, our primary recommendation is to use transport mode applied to a tunnel interface. Source address spoofing can be limited by enabling ingress filtering on the tunnel interface.
したがって、私たちの主な推奨は、トンネルインターフェイスに適用されたトランスポートモードを使用することです。ソースアドレスのスプーフィングは、トンネルインターフェイスでのイングレスフィルタリングを有効にすることで制限できます。
Manual keying must not be used as large amounts of IPv6 traffic may be carried over the tunnels and doing so would make it easier for an attacker to recover the keys. IKEv1 or IKEv2 must be used for establishing the IPsec SAs. IKEv2 should be used where supported and available; if not, IKEv1 may be used instead.
IPv6のトラフィックを大量にトンネルに持ち込むことができるため、手動キーを使用してはなりません。攻撃者がキーを回復しやすくすることができます。IKEV1またはIKEV2は、IPSEC SASの確立に使用する必要があります。IKEV2は、サポートされ、利用可能な場合に使用する必要があります。そうでない場合は、代わりにIKEV1を使用できます。
When running IPv6-in-IPv4 tunnels (unsecured) over the Internet, it is possible to "inject" packets into the tunnel by spoofing the source address (data plane security), or if the tunnel is signaled somehow (e.g., using authentication protocol and obtaining a static v6 prefix), someone might be able to spoof the signaling (control plane security).
IPv6-in-IPV4トンネル（無担保）をインターネット上で実行する場合、ソースアドレス（データプレーンセキュリティ）をスプーフィングすることにより、またはトンネルが何らかの形で信号がある場合（例えば、認証プロトコルを使用してトンネルを「挿入」することが可能です。静的V6プレフィックスを取得します）、誰かがシグナリング（コントロールプレーンのセキュリティ）をスプーフィングできる可能性があります。
The IPsec framework plays an important role in adding security to both the protocol for tunnel setup and data traffic.
IPSECフレームワークは、トンネルのセットアップとデータトラフィックのプロトコルの両方にセキュリティを追加する上で重要な役割を果たします。
Either IKEv1 or IKEv2 provides a secure signaling protocol for establishing, maintaining, and deleting an IPsec tunnel.
IKEV1またはIKEV2のいずれかが、IPSECトンネルを確立、維持、削除するための安全なシグナル伝達プロトコルを提供します。
IPsec, with ESP, offers integrity and data origin authentication, confidentiality, and optional (at the discretion of the receiver) anti-replay features. Using confidentiality without integrity is discouraged. ESP furthermore provides limited traffic flow confidentiality.
ESPを備えたIPSECは、整合性とデータ起源の認証、機密性、およびオプションの（受信機の裁量で）レプレイアンチレプレイ機能を提供します。整合性のない機密性を使用することは落胆します。特に、トラフィックフローの機密性が限られています。
IPsec provides access control mechanisms through the distribution of keys and also through the application of policies dictated by the Security Policy Database (SPD).
IPSECは、キーの分布を通じて、またセキュリティポリシーデータベース（SPD）によって決定されるポリシーの適用を通じて、アクセス制御メカニズムを提供します。
The NAT traversal mechanism provided by IKEv2 introduces some weaknesses into IKE and IPsec. These issues are discussed in more detail in [RFC4306].
IKEV2によって提供されるNATトラバーサルメカニズムは、IKEとIPSECにいくつかの弱点を導入します。これらの問題については、[RFC4306]で詳しく説明します。
Please note that using IPsec for the scenarios described in Figures 1, 2, and 3 does not aim to protect the end-to-end communication. It protects just the tunnel part. It is still possible for an IPv6 endpoint not attached to the IPsec tunnel to spoof packets.
図1、2、および3で説明したシナリオにIPSECを使用すると、エンドツーエンドのコミュニケーションを保護することを目的としていないことに注意してください。トンネル部分だけを保護します。IPSECトンネルに添付されていないIPv6エンドポイントがスプーフィングパケットに添付されていない可能性があります。
The authors are listed in alphabetical order.
著者はアルファベット順にリストされています。
Suresh Satapati also participated in the initial discussions on this topic.
Suresh Satapatiは、このトピックに関する最初の議論にも参加しました。
The authors would like to thank Stephen Kent, Michael Richardson, Florian Weimer, Elwyn Davies, Eric Vyncke, Merike Kaeo, Alfred Hoenes, Francis Dupont, and David Black for their substantive feedback.
著者は、スティーブン・ケント、マイケル・リチャードソン、フロリアン・ワイマー、エルウィン・デイビス、エリック・ヴィンケ、メリなど、実質的なフィードバックについてケオ、アルフレッド・ホーネス、フランシス・デュポン、デビッド・ブラックに感謝したいと思います。
We would like to thank Pasi Eronen for his text contributions and suggestions for improvement.
彼のテキスト貢献と改善の提案について、Pasi Eronenに感謝したいと思います。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401] Kent、S。およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409] Harkins、D。およびD. Carrel、「The Internet Key Exchange（IKE）」、RFC 2409、1998年11月。
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.
[RFC3704] Baker、F。およびP. Savola、「マルチホームネットワークのイングレスフィルタリング」、BCP 84、RFC 3704、2004年3月。
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 3948, January 2005.
[RFC3948] Huttunen、A.、Swander、B.、Volpe、V.、Diburro、L。、およびM. Stenberg、「IPSEC ESPパケットのUDPカプセル化」、RFC 3948、2005年1月。
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4213] Nordmark、E。およびR. Gilligan、「IPv6ホストとルーターの基本的な遷移メカニズム」、RFC 4213、2005年10月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent、S。およびK. SEO、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303] Kent、S。、「セキュリティペイロード（ESP）」、RFC 4303、2005年12月。
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306] Kaufman、C。、「Internet Key Exchange（IKEV2）プロトコル」、RFC 4306、2005年12月。
[RFC2893] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 2893, August 2000.
[RFC2893] Gilligan、R。およびE. Nordmark、「IPv6ホストとルーターの遷移メカニズム」、RFC 2893、2000年8月。
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[RFC3056] Carpenter、B。およびK. Moore、「IPv4 Cloudsを介したIPv6ドメインの接続」、RFC 3056、2001年2月。
[RFC3193] Patel, B., Aboba, B., Dixon, W., Zorn, G., and S. Booth, "Securing L2TP using IPsec", RFC 3193, November 2001.
[RFC3193] Patel、B.、Aboba、B.、Dixon、W.、Zorn、G。、およびS. Booth、「IPSECを使用したL2TPの保護」、RFC 3193、2001年11月。
[RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation (NAT) Compatibility Requirements", RFC 3715, March 2004.
[RFC3715] Aboba、B。およびW. Dixon、「Ipsec-Networkアドレス翻訳（NAT）互換性要件」、RFC 3715、2004年3月。
[RFC3884] Touch, J., Eggert, L., and Y. Wang, "Use of IPsec Transport Mode for Dynamic Routing", RFC 3884, September 2004.
[RFC3884] Touch、J.、Eggert、L。、およびY. Wang、「動的ルーティングのためのIPSEC輸送モードの使用」、RFC 3884、2004年9月。
[RFC4023] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)", RFC 4023, March 2005.
[RFC4023] Worster、T.、Rekhter、Y.、およびE. Rosen、「IPまたは汎用ルーティングカプセル化（GRE）のMPLのカプセル化」、RFC 4023、2005年3月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302] Kent、S。、「IP認証ヘッダー」、RFC 4302、2005年12月。
[RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", RFC 4555, June 2006.
[RFC4555] Eronen、P。、「IKEV2モビリティおよびマルチホミングプロトコル（MOBIKE）」、RFC 4555、2006年6月。
[RFC4718] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and Implementation Guidelines", RFC 4718, October 2006.
[RFC4718] Eronen、P。およびP. Hoffman、「IKEV2の説明と実装ガイドライン」、RFC 4718、2006年10月。
[TUNN-AD] Palet, J. and M. Diaz, "Analysis of IPv6 Tunnel End-point Discovery Mechanisms", Work in Progress, January 2005.
[Tunn-Ad] Palet、J。およびM. Diaz、「IPv6トンネルエンドポイント発見メカニズムの分析」、2005年1月、進行中の作業。
[VLINK] Duffy, M., "Framework for IPsec Protected Virtual Links for PPVPNs", Work in Progress, October 2002.
[Vlink] Duffy、M。、「IPSECのフレームワークPPVPNSの仮想リンクのフレームワーク」、2002年10月、進行中の作業。
First, we describe the different tunnel mode implementation methods. We note that, in this context, only the so-called Specific SPD (SSPD) model (without a tunnel interface) can be made to work, but it has reduced applicability, and the use of a transport mode tunnel is recommended instead. However, we will describe how the SSPD tunnel mode might look if one would like to use it in any case.
まず、さまざまなトンネルモードの実装方法について説明します。この文脈では、いわゆる特定のSPD（SSPD）モデル（トンネルインターフェイスなし）のみを機能させることができますが、適用性が低下し、代わりに輸送モードトンネルの使用が推奨されます。ただし、いずれにせよ、SSPDトンネルモードがどのように使用するかを説明します。
Tunnel mode could (in theory) be deployed in two very different ways depending on the implementation:
トンネルモードは（理論的に）実装に応じて、2つの非常に異なる方法で展開できます。
1. "Generic SPDs": some implementations model the tunnel mode SA as an IP interface. In this case, an IPsec tunnel interface is created and used with "any" addresses ("::/0 <-> ::/0" ) as IPsec traffic selectors while setting up the SA. Though this allows all traffic between the two nodes to be protected by IPsec, the routing table would decide what traffic gets sent over the tunnel. Ingress filtering must be separately applied on the tunnel interface as the IPsec policy checks do not check the IPv6 addresses at all. Routing protocols, multicast, etc. will work through this tunnel. This mode is similar to transport mode. The SPDs must be interface-specific. However, because IKE uses IPv4 but the tunnel is IPv6, there is no standard solution to map the IPv4 interface to IPv6 interface [VLINK] and this approach is not feasible.
1. 「Generic SPDS」：一部の実装は、IPインターフェイスとしてトンネルモードSAをモデル化します。この場合、IPSECトンネルインターフェイスが作成され、SAのセットアップ中にIPSECトラフィックセレクターとして「任意の」アドレス（ "::/0 <-> ::/0"）で使用されます。これにより、2つのノード間のすべてのトラフィックをIPSECによって保護できますが、ルーティングテーブルはトンネル上に送信されるトラフィックを決定します。IPSECポリシーチェックがIPv6アドレスをまったくチェックしないため、イングレスフィルタリングはトンネルインターフェイスに個別に適用する必要があります。ルーティングプロトコル、マルチキャストなどは、このトンネルを介して機能します。このモードは、トランスポートモードに似ています。SPDはインターフェイス固有でなければなりません。ただし、IKEはIPv4を使用しているが、トンネルはIPv6であるため、IPv4インターフェイスをIPv6インターフェイス[Vlink]にマッピングする標準的なソリューションはなく、このアプローチは実行可能ではありません。
2. "Specific SPDs": some implementations do not model the tunnel mode SA as an IP interface. Traffic selection is based on specific SPD entries, e.g., "2001:db8:1::/48 <-> 2001:db8: 2::/48". As the IPsec session between two endpoints does not have an interface (though an implementation may have a common pseudo-interface for all IPsec traffic), there is no Duplicate Address Detection (DAD), Multicast Listener Discovery (MLD), or link-local traffic to protect; multicast is not possible over such a tunnel. Ingress filtering is performed automatically by the IPsec traffic selectors.
2. 「特定のSPD」：一部の実装では、トンネルモードSAをIPインターフェイスとしてモデル化しません。トラフィックの選択は、特定のSPDエントリ、「2001：DB8：1 ::/48 <-> 2001：DB8：2 ::/48」に基づいています。2つのエンドポイント間のIPSECセッションにはインターフェイスがないため（実装にはすべてのIPSECトラフィックに共通の擬似インターフェイスがある場合があります）、アドレス検出（DAD）、マルチキャストリスナーディスカバリー（MLD）、またはLink-Localが重複していません。保護するためのトラフィック。このようなトンネルではマルチキャストは不可能です。Ingressフィルタリングは、IPSECトラフィックセレクターによって自動的に実行されます。
Ingress filtering is guaranteed by IPsec processing when option (2) is chosen, whereas the operator has to enable it explicitly when transport mode or option (1) is chosen.
Ingressフィルタリングは、オプション（2）が選択された場合にIPSEC処理によって保証されますが、オペレーターは、輸送モードまたはオプション（1）が選択されている場合に明示的に有効にする必要があります。
In summary, there does not appear to be a standard solution in this context for the first implementation approach.
要約すると、最初の実装アプローチのために、このコンテキストでは標準的なソリューションはないようです。
The second approach can be made to work, but is only applicable in host-to-host or site-to-router/router-to-site scenarios (i.e., when the IPv6 prefixes can be known a priori), and it offers only a limited set of features (e.g., no multicast) compared with a transport mode tunnel.
2番目のアプローチは機能するために作成できますが、ホストからホストまたはサイトからルーター/ルーターからサイトへのシナリオ（つまり、IPv6プレフィックスが先験的に既知である場合）にのみ適用でき、それは提供のみを提供します輸送モードトンネルと比較して、限られた機能のセット（たとえば、マルチキャストなし）。
When tunnel mode is used, fragment handling [RFC4301] may also be more difficult compared with transport mode and, depending on implementation, may need to be reflected in SPDs.
トンネルモードを使用する場合、フラグメントハンドリング[RFC4301]も輸送モードと比較してより困難になる可能性があり、実装に応じてSPDに反映する必要があります。
The following SPD entries assume that there are two hosts, Host1 and Host2, whose IPv6 addresses are denoted IPV6-EP1 and IPV6-EP2 (global addresses), and the IPV4 addresses of the tunnel endpoints are denoted IPV4-TEP1 and IPV4-TEP2, respectively.
次のSPDエントリは、IPv6アドレスがIPv6-EP1およびIPv6-EP2（グローバルアドレス）と表示されている2つのホスト、HOST1とHOST2があると想定しています。それぞれ。
Host1's SPD:
Next Layer
Rule Local Remote Protocol Action
---- ----- ------ ---------- --------
1 IPV6-EP1 IPV6-EP2 ESP BYPASS
2 IPV6-EP1 IPV6-EP2 IKE BYPASS
3 IPv6-EP1 IPV6-EP2 41 PROTECT(ESP,
tunnel{IPV4-TEP1,IPV4-TEP2})
Host2's SPD:
Next Layer
Rule Local Remote Protocol Action
---- ----- ------ ---------- --------
1 IPV6-EP2 IPV6-EP1 ESP BYPASS
2 IPV6-EP2 IPV6-EP1 IKE BYPASS
3 IPv6-EP2 IPV6-EP1 41 PROTECT(ESP,
tunnel{IPV4-TEP2,IPV4-TEP1})
"IKE" refers to UDP destination port 500 and possibly also port 4500 if NAT traversal is used.
「Ike」とは、NATトラバーサルが使用されている場合、UDP宛先ポート500を指し、場合によってはポート4500も指します。
The IDci and IDcr payloads of IKEv1 carry the IPV6-EP1 and IPV6-TEP2 as phase 2 identities. With IKEv2, the traffic selectors are used to carry the same information.
IKEV1のIDCIおよびIDCRペイロードは、IPv6-EP1およびIPv6-TEP2をフェーズ2のアイデンティティとして運びます。IKEV2を使用すると、トラフィックセレクターを使用して同じ情報を掲載します。
The following SPD entries assume that the host has the IPv6 address IPV6-EP1 and the tunnel endpoints of the host and router are IPV4- TEP1 and IPV4-TEP2, respectively. If the tunnel is between a router and a host where the router has allocated an IPV6-PREF/48 to the host, the corresponding SPD entries can be derived by replacing IPV6- EP1 with IPV6-PREF/48.
次のSPDエントリは、ホストがIPv6アドレスIPv6-EP1を持ち、ホストとルーターのトンネルエンドポイントがそれぞれIPv4-TEP1とIPv4-TEP2であると想定しています。トンネルがルーターとホストの間にある場合、ルーターがIPv6-PREF/48をホストに割り当てた場合、対応するSPDエントリはIPv6-EP1をIPv6-PREF/48に置き換えることで導出できます。
Please note the bypass entry for host's SPD, absent in router's SPD. While this might be an implementation matter for host-to-router tunneling, having a similar entry, "Local=IPV6-PREF/48 & Remote=IPV6- PREF/48", is critical for site-to-router tunneling.
ルーターのSPDにはないホストのSPDのバイパスエントリに注意してください。これはホストからルーターへのトンネルの実装問題である可能性がありますが、同様のエントリ「Local = IPv6-Pref/48＆Remote = IPv6- Pref/48」は、サイト間トンネリングにとって重要です。
Host's SPD:
Next Layer
Rule Local Remote Protocol Action
---- ----- ------ ---------- --------
1 IPV6-EP1 IPV6-EP2 ESP BYPASS
2 IPV6-EP1 IPV6-EP2 IKE BYPASS
3 IPV6-EP1 IPV6-EP1 ANY BYPASS
4 IPV6-EP1 ANY ANY PROTECT(ESP,
tunnel{IPV4-TEP1,IPV4-TEP2})
Router's SPD:
Next Layer
Rule Local Remote Protocol Action
---- ----- ------ ---------- --------
1 IPV6-EP2 IPV6-EP1 ESP BYPASS
2 IPV6-EP2 IPV6-EP1 IKE BYPASS
3 ANY IPV6-EP1 ANY PROTECT(ESP,
tunnel{IPV4-TEP1,IPV4-TEP2})
The IDci and IDcr payloads of IKEv1 carry the IPV6-EP1 and ID_IPV6_ADDR_RANGE or ID_IPV6_ADDR_SUBNET as their phase 2 identities. The starting address is zero and the end address is all ones for ID_IPV6_ADDR_RANGE. The starting address is zero IP address and the end address is all zeroes for ID_IPV6_ADDR_SUBNET. With IKEv2, the traffic selectors are used to carry the same information.
IKEV1のIDCIおよびIDCRペイロードは、IPv6-EP1およびID_IPV6_ADDR_RANGEまたはID_IPV6_ADDR_SUBNETをフェーズ2のIDとして運びます。開始アドレスはゼロで、EndアドレスはID_IPv6_addr_rangeのすべてです。開始アドレスはIPアドレスゼロであり、EndアドレスはID_IPv6_addr_subnetのすべてゼロです。IKEV2を使用すると、トラフィックセレクターを使用して同じ情報を掲載します。
With the exchange of protected configuration payloads, IKEv2 is able to provide the IKEv2 peer with Dynamic Host Configuration Protocol (DHCP)-like information payloads. These configuration payloads are exchanged between the IKEv2 initiator and responder.
保護された構成ペイロードの交換により、IKEV2はIKEV2ピアに動的ホスト構成プロトコル（DHCP）のような情報ペイロードを提供できます。これらの構成ペイロードは、IKEV2イニシエーターとレスポンダーの間で交換されます。
This could be used (for example) by the host in the host-to-router scenario to obtain an IPv6 address from the ISP as part of setting up the IPsec tunnel mode SA. The details of these procedures are out of scope for this memo.
これを（たとえば）ホストからルーターへのシナリオのホストが使用して、IPSECトンネルモードSAのセットアップの一環としてISPからIPv6アドレスを取得できます。これらの手順の詳細は、このメモの範囲外です。
Network address (and port) translation devices are commonly found in today's networks. A detailed description of the problem and requirements of IPsec-protected data traffic traversing a NAT is provided in [RFC3715].
ネットワークアドレス（およびポート）翻訳デバイスは、今日のネットワークによく見られます。[RFC3715]には、NATを通過するIPSECで保護されたデータトラフィックの問題と要件の詳細な説明が提供されています。
IKEv2 can detect the presence of a NAT automatically by sending NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP payloads in the initial IKE_SA_INIT exchange. Once a NAT is detected and both endpoints support IPsec NAT traversal extensions, UDP encapsulation can be enabled.
IKEV2は、最初のIKE_SA_INIT ExchangeでNAT_DETECTION_SOURCE_IPおよびNAT_DETECTION_DESTINATION_IPペイロードを送信することにより、NATの存在を自動的に検出できます。NATが検出され、両方のエンドポイントがIPSEC NATトラバーサルエクステンションをサポートすると、UDPカプセル化を有効にできます。
More details about UDP encapsulation of IPsec-protected IP packets can be found in [RFC3948].
IPSECで保護されたIPパケットのUDPカプセル化の詳細については、[RFC3948]をご覧ください。
For IPv6-in-IPv4 tunneling, NAT traversal is interesting for two reasons:
IPv6-in-IPV4トンネリングの場合、NAT Traversalは2つの理由で興味深いものです。
1. One of the tunnel endpoints is often behind a NAT, and configured tunneling, using protocol 41, is not guaranteed to traverse the NAT. Hence, using IPsec tunnels would enable one to set up both a secure tunnel and a tunnel that might not always be possible without other tunneling mechanisms.
1. トンネルのエンドポイントの1つは、多くの場合NATの背後にあり、プロトコル41を使用した構成されたトンネルは、NATを横断することは保証されていません。したがって、IPSECトンネルを使用すると、他のトンネリングメカニズムがなければ常に可能ではない安全なトンネルとトンネルの両方をセットアップできます。
2. Using NAT traversal allows the outer address to change without having to renegotiate the SAs. This could be beneficial for a crude form of mobility and in scenarios where the NAT changes the IP addresses frequently. However, as the outer address may change, this might introduce new security issues, and using tunnel mode would be most appropriate.
2. NATトラバーサルを使用すると、SASを再交渉することなく外側のアドレスが変更できます。これは、NATがIPアドレスを頻繁に変更するシナリオでは、粗い形式のモビリティやシナリオにとって有益です。ただし、外側のアドレスが変更される可能性があるため、これにより新しいセキュリティの問題が発生する可能性があり、トンネルモードの使用が最も適切です。
When NAT is not applied, the second benefit would still be desirable. In particular, using manually configured tunneling is an operational challenge with dynamic IP addresses, because both ends need to be reconfigured if an address changes. Therefore, an easy and efficient way to re-establish the IPsec tunnel if the IP address changes would be desirable. MOBIKE [RFC4555] provides a solution when IKEv2 is used, but it only supports tunnel mode.
NATが適用されない場合、2番目の利点が依然として望ましいでしょう。特に、手動で構成されたトンネリングを使用することは、動的なIPアドレスを備えた運用上の課題です。これは、アドレスが変更された場合に両端を再構成する必要があるためです。したがって、IPアドレスの変更が望ましい場合、IPSECトンネルを再確立する簡単で効率的な方法。Mobike [RFC4555]は、IKEV2を使用するときにソリューションを提供しますが、トンネルモードのみをサポートします。
The IKEv2 initiator needs to know the address of the IKEv2 responder to start IKEv2 signaling. A number of ways can be used to provide the initiator with this information, for example:
IKEV2イニシエーターは、IKEV2シグナル伝達を開始するためにIKEV2レスポンダーのアドレスを知る必要があります。たとえば、この情報をイニシエーターに提供するために多くの方法を使用できます。
o Using out-of-band mechanisms, e.g., from the ISP's Web page.
o ISPのWebページから、帯域外のメカニズムを使用します。
o Using DNS to look up a service name by appending it to the DNS search path provided by DHCPv4 (e.g., "tunnel-service.example.com").
o DNSを使用して、DHCPV4が提供するDNS検索パスに追加することにより、サービス名を検索します（例：「Tunnel-Service.example.com」）。
o Using a DHCP option.
o DHCPオプションを使用します。
o Using a pre-configured or pre-determined IPv4 anycast address.
o 事前に構成または事前に決定されたIPv4 Anycastアドレスを使用します。
o Using other, unspecified or proprietary methods.
o 他の、不特定、または独自の方法を使用します。
For the purpose of this document, it is assumed that this address can be obtained somehow. Once the address has been learned, it is configured as the tunnel endpoint for the configured IPv6-in-IPv4 tunnel.
このドキュメントの目的のために、このアドレスは何らかの形で取得できると想定されています。アドレスが学習されると、構成されたIPv6-in-IPV4トンネルのトンネルエンドポイントとして構成されます。
This problem is also discussed at more length in [TUNN-AD].
この問題については、[Tunn-AD]でより長く説明します。
However, simply discovering the tunnel endpoint is not sufficient for establishing an IKE session with the peer. The PAD information (see Section 5.2) also needs to be learned dynamically. Hence, currently, automatic endpoint discovery provides benefit only if PAD information is chosen in such a manner that it is not IP-address specific.
ただし、単にトンネルエンドポイントを発見するだけでは、ピアとのIKEセッションを確立するのに十分ではありません。パッド情報（セクション5.2を参照）も動的に学習する必要があります。したがって、現在、自動エンドポイントディスカバリーは、IPアドレス固有ではないような方法でPAD情報が選択された場合にのみ利益を提供します。
Authors' Addresses
著者のアドレス
Richard Graveman RFG Security, LLC 15 Park Avenue Morristown, NJ 07960 USA
リチャードグレイグマンRFGセキュリティ、LLC 15パークアベニューモリスタウン、ニュージャージー07960 USA
EMail: rfg@acm.org
Mohan Parthasarathy Nokia 313 Fairchild Drive Mountain View, CA 94043 USA
Mohan Parthasarathy Nokia 313 Fairchild Drive Mountain View、CA 94043 USA
EMail: mohanp@sbcglobal.net
Pekka Savola CSC/FUNET Espoo Finland
Pekka Savola CSC/Funet Espoo Finland
EMail: psavola@funet.fi
Hannes Tschofenig Nokia Siemens Networks Otto-Hahn-Ring 6 Munich, Bayern 81739 Germany
Hannes Tschofenig Nokia Siemens Networks Otto-Hahn-Ring 6 Munich、Bayern 81739ドイツ
EMail: Hannes.Tschofenig@nsn.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
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, THE IETF TRUST 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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
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 currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。