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
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）IETFトラスト（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イン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移行メカニズムの一つとして（手動で設定）は、IPv6型の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]で扱われていなかった脅威の数を同定しました。最も完全なソリューションは、IPv6インのIPv4トンネリングを保護するためにIPsecを使用することです。文書は、意図的に相互運用可能な方法で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と成功のIPsecセキュリティアソシエーション（SA）の確立のために、この文書によって行われた仮定によって対処することができ脅威やシナリオを分析します。第5節では、インターネットキー交換（IKE）とパケットフォーマットとセキュリティポリシーデータベース（SPD）エントリでIPセキュリティ（IPsec）の交換の詳細を示します。第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インタフェースを指します。語句「トンネルインターフェース」の使用は、IPv6インのIPv4は、IPv4上でパケットをトンネリング受信インターフェースを指します。
[RFC4213] is mostly concerned about address spoofing threats:
[RFC4213]はアドレススプーフィングの脅威について、主に懸念しています：
1. The IPv4 source address of the encapsulating ("outer") packet can be spoofed.
1.カプセル化（「外側」）パケットの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.
脅威（1）を軽減するために、Oは、カプセル開放装置は、パケットのIPv4ソースアドレスが設定されたトンネルエンドポイントのアドレスと同じであることを検証します。カプセル開放装置はまた、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（2）、カプセル開放装置は、内部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.
トランスポートモードでは、IPsecのカプセル化セキュリティペイロード（ESP）または認証ヘッダ（AH）セキュリティアソシエーション（SA）は、（IPv4のソースはIPv4-DEST、プロトコル= 41）によって定義されたトラフィックを保護するために確立されています。このようIPsecパケットを受信すると、受信機は、最初のIPsecが（例えば、ESP）を変換を適用して、パケットがSAのために適切であることを確認するために、セキュリティパラメータインデックス（SPI）と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イングレスフィルタリングによって緩和することができる、すなわち、パケットが厳密なリバースパス転送（RPF）[RFC3704]をチェックと同様トンネルエンドポイントに向かう経路の方向におけるインターフェースから到来していることを確認してください。
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インの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.
トンネルモードでは、IPsecのSAは、（IPv6のソース、IPv6の宛先）によって定義されたトラフィックを保護するために確立されています。このようなIPsecパケットを受信すると、受信機は、最初のIPsec（例えば、ESP）変換を適用した後、SPI、それが受信した介してパケットがSAのために適切であることを確認するために、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型のIPv4トンネルがまだ[RFC4213]を存在することに留意されたいです。
There are roughly three scenarios:
大まかに3つのシナリオがあります。
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（ボーダー）デバイスとIPv6の上流プロバイダのルータ間のトンネルを参照してください。サイトの縮退場合は、単一のホストです。
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ホスト及びルータは、トンネルIPv6は、IPv4パケット内にそれをカプセル化することにより、トポロジを転送したIPv4の領域にわたってデータグラムができます。トンネリングは、さまざまな方法で使用することができます。
.--------. _----_ .--------.
|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.
IPv4インフラストラクチャによって相互接続されたIPv6 / IPv4ルーター自体の間ことができるトンネルIPv6パケットを。この場合、トンネルは、IPv6パケットが取るエンドツーエンドパスの一つのセグメントにまたがります。
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プレフィックスの広い範囲から来るので、IPv6がSAに使用されるアドレス結合は、一般的に不可能である可能性があります。 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 / IPv4ルーターできトンネルIPv6パケットを。このトンネルは、エンドツーエンドのパスの最後のセグメントに及びます。
+---------------------+
| 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は、受信したパケットに対して同様の検証を行うことができません。これは、展開の例ほとんどの顧客に/ 48を割り当てる例えば、インターネットサービスプロバイダ（ISP）は非常に合理的であるかもしれません。トンネルは（弱い意味で）「信頼」ISPのルータ、およびISPのルータは、サイトBは/ 48内のパケットを発信することができる唯一のものであることを確認でき終了する顧客宅内機器（CPE）。
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.
IPv4インフラストラクチャ自体の間にできたトンネルIPv6パケットによって相互接続されたIPv6 / 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は、もともと（本書でのIKEv1と呼ばれる）[RFC2409]で定義され、現在（IKEv2のと呼ばれる;も参照[RFC4718]）[RFC4306]に取って代わられています。それらの間のいくつかの違いがあります。このドキュメントに関連する相違点は、以下に説明されています。
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.
新機能のいくつかはのIKEv1を使用してネゴシエートすることができないように2 [RFC4301]は、IKEv2のを想定しています。 [RFC4301]で与えられたIPsec SAのための複数のトラフィックセレクタを交渉する有効です。これが唯一のIKEv2で可能です。 IKEv1のが使用されている場合には、複数のSAは、各トラフィックセレクタのための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のに基づいて既存の実装がすでに[RFC4301]をサポートすることができるかもしれないことに注意してください（1）に記載された特徴（2）。適切であれば、展開はセキュリティアーキテクチャのいずれかのバージョンを使用することもできます。
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アーキテクチャの両方で動作しますが、交渉は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.
IPsecは、セクション3に記載されているシナリオのIPv6トラフィック（内部ヘッダ）を保護するために使用される場合、いくつかの要件が生じます。
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. IPv6トラフィックのすべてがリンクローカル（例えば、近隣探索）およびマルチキャストトラフィックを含む、保護されるべきです。これがないと、攻撃者は2つのルータ間通信に混乱を引き起こしたIPv6近隣キャッシュを汚染することができます。
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).
ルータ間のトンネルで、[トラフィックの送信元と送信先のアドレスは、通常のルーティングによって学習されているプレフィックスの広い範囲から来ることができました。ルーティングは、常に新しい接頭語を学ぶことができたように、一はすべてのプレフィックスが先験的[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トラフィックは、トランスポートまたはトンネルモードを使用して保護することができます。トンネルモードを使用する場合、付録A.1に記載のように実装は、またはではないかもしれないインターフェイスとしてのIPsecトンネルモードSAをモデル化することができるように多くの問題があります。
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エントリが記載されなければなりません。上記の要件に照らして評価する、すべてのリンクローカルトラフィックのマルチキャストトラフィックは、おそらくSPDエントリの長いリストが得られ、識別される必要があるであろう。保護を必要とするトラフィックは、必ずしも（例えば、ルーターのトンネル）、先験的[RFC3884]を知らないので、第二の要件は、満足することは困難です。ほとんどすべての実装が適切なソースアドレス選択のためのアドレスは（の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をインターフェースとしてモデル化されている場合は、保護を必要とするトラフィックは、インターフェイスを指すルートとしてモデル化することができます。トラフィックが必要な保護が必ずしも事前に知られていないので、しかし、第二の要件は、満足することは困難です。 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.
トンネルがはるかに簡単な解決策であり、また簡単にリンクローカルおよびマルチキャストトラフィックを保護して保護するために、トランスポートモードを適用しているので、我々はこのコンテキストでトンネルモードを使用することはお勧めしません。トンネルモードでは、しかしながら、付録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エントリはそれぞれ、IPV4-TEP1及びIPV4-TEP2示されるトンネルエンドポイントのIPv4アドレスを持つ2つのルータ、ルータ1及びルータ2は、存在すると仮定する。 （他のシナリオでは、の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.
NATトラバーサルを使用する場合SPDエントリの両方で、「IKE」は4500、ポートおそらくUDP宛先ポート500とを指します。
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、およびフェーズ2つのIDなどのプロトコル値41を運びます。 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.
ピア認証データベース（PAD）は、SPDと鍵管理デーモン[RFC4306]との間のリンクを提供します。これは、IKEv2のと一緒に使用する場合にのみ、[RFC4301]で定義され、従って関連します。
As there is currently no defined way to discover the PAD-related parameters dynamically, it is assumed that these are manually configured:
動的PAD関連のパラメータを発見する全く定義された方法は現在存在しないように、これらは手動で設定されているものとします。
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の交換でアサート：アイデンティティの多くの異なるタイプを使用することができます。少なくとも、ピアの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は、いくつかの方法によりピアを認証することができます。事前共有鍵とX.509証明書ベースの認証は、[RFC4301]によって必要とされます。それは実装のより多くと相互運用するため、少なくとも、事前共有キーは、サポートされるべきです。
o The child SA authorization data should contain the IPv4 address of the peer.
チャイルド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アドレスは、鍵交換の際のアイデンティティとしてサポートされなければなりません。これはアイデンティティ保護を提供しないように、メインモードまたはアグレッシブモードは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イン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プレフィックスは、事前に知られる必要があるので、そのような使用方法は、より複雑であり、マルチキャストおよびリンクローカルトラフィックは、トンネル上では動作しません。トンネルモードでの取り扱いフラグメントはまた、より困難です。モビリティ及びマルチホーミングプロトコル（MOBIKE）[RFC4555]は、トンネルモードのみをサポートするので、トンネルのIPv4のエンドポイントは、動的であり、他の制約が適用されない場合しかし、トンネルモードを使用することは許容される溶液であってもよいです。
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 SAを確立するために使用する必要があります。サポートされており、利用できる場所の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イン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.
IPsecは、ESPで、（受信機の裁量で）完全性とデータ起源認証、機密性、およびオプションのアンチリプレイ機能を提供しています。整合性なしで機密性を使用することはお勧めできません。 ESPは、さらに限定されたトラフィックフロー機密性を提供します。
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で説明したシナリオのためにIPsecを使用して、および3は、エンドツーエンドの通信を保護することを目的としませんのでご注意ください。それはちょうどトンネル部を保護します。これは、スプーフィングパケットにIPsecトンネルに取り付けられていないIPv6のエンドポイントのためにまだ可能です。
The authors are listed in alphabetical order.
著者は、アルファベット順に記載されています。
Suresh Satapati also participated in the initial discussions on this topic.
スレシュ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.
著者は彼らの実質的な帰還のためにスティーブン・ケント、マイケル・リチャードソン、フロリアンWeimerさん、エルウィン・デイヴィス、エリックVyncke、Merike Kaeoの、アルフレッドHoenes、フランシスデュポン、そしてデヴィッド・ブラックに感謝したいと思います。
We would like to thank Pasi Eronen for his text contributions and suggestions for improvement.
私たちは、改善のための彼のテキストの貢献と提案をパシEronenに感謝したいと思います。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409]ハーキンとD.とD.カレル、 "インターネットキー交換（IKE）"、RFC 2409、1998年11月。
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.
[RFC3704]ベイカー、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.、ボルペ、V.、DiBurro、L.、及びM.ステンバーグ、 "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.ギリガン、 "IPv6ホストとルータのための基本的な変遷メカニズム"、RFC 4213、2005年10月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]ケント、S.、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 4303、2005年12月。
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306]カウフマン、C.、 "インターネットキーエクスチェンジ（IKEv2の）プロトコル"、RFC 4306、2005年12月。
[RFC2893] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 2893, August 2000.
[RFC2893]ギリガン、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]カーペンター、B.およびK.ムーア、RFC 3056、2001年2月 "のIPv4クラウドを介したIPv6ドメインの接続"。
[RFC3193] Patel, B., Aboba, B., Dixon, W., Zorn, G., and S. Booth, "Securing L2TP using IPsec", RFC 3193, November 2001.
[RFC3193]パテル、B.、Aboba、B.、ディクソン、W.、ゾルン、G.、およびS.ブース、 "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.ディクソン、 "IPsecでネットワークアドレス変換（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]タッチ、J.、エッゲルト、L.、およびY.王、 "ダイナミックルーティングのための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.ローゼン、 "IP又は総称ルーティングカプセル化（GRE）でMPLSカプセル化"、RFC 4023、2005年3月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302]ケント、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.ホフマン、 "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.ディアス、 "IPv6のトンネルエンドポイントディスカバリメカニズムの解析"、進歩、2005年1月に働いています。
[VLINK] Duffy, M., "Framework for IPsec Protected Virtual Links for PPVPNs", Work in Progress, October 2002.
[VLINK]ダフィー、M.、 "PPVPNsのIPsec保護された仮想リンクのための枠組み"、進歩、2002年10月の作業。
Appendix A. Using Tunnel Mode
トンネルモードを使用した付録A.
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）モデルは動作させることができ、それが適用可能性を低減しており、およびトランスポートモードトンネルの使用が代わりに推奨される、ということに注意してください。しかし、我々は1つがどのような場合に、それを使用したい場合はSSPDトンネルモードがどのように見えるかを説明します。
A.1. Tunnel Mode Implementation Methods
A.1。トンネルモードの実装方法
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.「汎用のSPD」：いくつかの実装モデルIPインタフェースとしてトンネルモードSA。この場合、IPsecトンネルインターフェイスが作成され、「任意」アドレスを使用する（「:: / 0 < - > :: / 0」）のIPsecトラフィックセレクタとしてSAを設定しています。これは、2つのノード間のすべてのトラフィックがIPSecで保護することができますが、ルーティングテーブルには、トンネル経由で送信されるどのようなトラフィックを決定します。 IPsecポリシーのチェックはIPv6がまったくアドレスをチェックしないようイングレスフィルタリングは、別途トンネルインターフェイスに適用する必要があります。ルーティングプロトコルは、マルチキャストなどがこのトンネルを通っていきます。このモードでは、トランスポートモードと同様です。 SPDは、インターフェイス固有でなければなりません。 IKEは、IPv4を使用するが、トンネルがIPv6であり、しかし、そこにIPv6インタフェース[VLINK]にIPv4インタフェースをマッピングする標準的な解決策はなく、このアプローチは不可能です。
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」：いくつかの実装では、IPインタフェースとしてトンネルモードSAをモデル化していません。トラフィックの選択は、特定のSPDエントリに基づいて、例えば、 "2001：DB8：1 :: / 48 < - > 2001：DB8：2 :: / 48"。 （実装がすべてのIPSecトラフィックのための共通の擬似インターフェースを有していてもよいが）、2つのエンドポイント間のIPsecセッションがインタフェースを持たないように、重複アドレス検出（DAD）、マルチキャストリスナー発見（MLD）、またはリンクローカルに存在しません保護するトラフィック。マルチキャストは、トンネル上不可能です。イングレスフィルタリングは、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.
（2）オプションが選択されたときに、オペレータが搬送モード又は（1）オプションが選択されたときに明示的に有効にしなければならないのに対し、イングレスフィルタリングは、IPsec処理によって保証されます。
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に反映する必要があるかもしれません。
A.2. Specific SPD for Host-to-Host Scenario
A.2。ホスト間のシナリオのための具体的な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つのホスト、ホスト1とホスト2が存在すると仮定し、トンネルエンドポイントのIPv4アドレスは、IPv4-TEP1及びIPV4-TEP2を付しそれぞれ。
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.
NATトラバーサルを使用する場合、「IKE」は、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ペイロードはフェーズ2つのIDとしてIPV6-EP1およびIPv6-TEP2を運びます。 IKEv2のでは、トラフィックセレクタは、同じ情報を運ぶために使用されています。
A.3. Specific SPD for Host-to-Router Scenario
A.3。ホストツールーターシナリオのための具体的なSPD
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-PREF / 48でIPV6- EP1を置き換えることによって導出することができます。
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のためのバイパスエントリを注意してください。これは同様のエントリ、「ローカル= IPV6-PREF / 48＆=リモート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ペイロードは、それらの位相2のアイデンティティとしてIPV6-EP1とID_IPV6_ADDR_RANGEまたはID_IPV6_ADDR_SUBNETを運びます。開始アドレスはゼロであり、終了アドレスはID_IPV6_ADDR_RANGEのためのすべてのものです。開始アドレスはゼロIPアドレスで、終了アドレスはID_IPV6_ADDR_SUBNETためのすべてゼロです。 IKEv2のでは、トラフィックセレクタは、同じ情報を運ぶために使用されています。
Appendix B. Optional Features
付録B.オプション機能
B.1. Dynamic Address Configuration
B.1。動的アドレスの設定
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のは、動的ホスト構成プロトコル（DHCP）様の情報ペイロードとのIKEv2ピアを提供することができます。これらの構成ペイロードは、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アドレスを取得するためにホストとルーターのシナリオでホストによって（例えば）を使用することができます。これらの手順の詳細は、このメモの範囲外です。
B.2. NAT Traversal and Mobility
B.2。 NATトラバーサルとモビリティ
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].
ネットワークアドレス（およびポート）変換デバイスは、一般的に、今日のネットワークで発見されました。問題とNATを横断するIPsecで保護されたデータトラフィックの要件の詳細な説明は、[RFC3715]に提供されます。
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交換において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のインIPv4トンネリングの場合、NATトラバーサルは、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つは、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トラバーサルを使用すると、外側のアドレスSAを再交渉することなく変更することができます。これは、モビリティのと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を使用するソリューションを提供し、それだけで、トンネルモードをサポートします。
B.3. Tunnel Endpoint Discovery
B.3。トンネルエンドポイント発見
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.
ISPのWebページから、例えば、アウトオブバンドメカニズムを使用して、O。
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").
DHCPv4（例えば、「tunnel-service.example.com」）が提供するDNS検索パスにそれを追加することで、サービス名をルックアップするためにDNSを使用して、O。
o Using a DHCP option.
DHCPオプションを使用して、O。
o Using a pre-configured or pre-determined IPv4 anycast address.
事前に設定または予め決められたIPv4エニーキャストアドレスを使用し、O。
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型の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セッションを確立するのに十分ではありません。 PADの情報は（5.2節を参照）も、動的に学習する必要があります。したがって、現在、自動終点検出がPAD情報は、それがIPアドレス特異的ではないように選択された場合にのみ利益を提供します。
Authors' Addresses
著者のアドレス
Richard Graveman RFG Security, LLC 15 Park Avenue Morristown, NJ 07960 USA
リチャードGraveman RFGセキュリティ、LLC 15パークアベニューモリスタウン、NJ 07960 USA
EMail: rfg@acm.org
メールアドレス：rfg@acm.org
Mohan Parthasarathy Nokia 313 Fairchild Drive Mountain View, CA 94043 USA
モハンパルタサラティノキア313フェアチャイルドドライブマウンテンビュー、CA 94043 USA
EMail: mohanp@sbcglobal.net
メールアドレス：mohanp@sbcglobal.net
Pekka Savola CSC/FUNET Espoo Finland
ペッカSavola CSC / FUNETエスポーフィンランド
EMail: psavola@funet.fi
メールアドレス：psavola@funet.fi
Hannes Tschofenig Nokia Siemens Networks Otto-Hahn-Ring 6 Munich, Bayern 81739 Germany
ハンネスTschofenigノキアシーメンスネットワークスオットー・ハーンリング6ミュンヘン、バイエルン81739ドイツ
EMail: Hannes.Tschofenig@nsn.com
メールアドレス：Hannes.Tschofenig@nsn.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。