RFC4891 日本語訳
4891 Using IPsec to Secure IPv6-in-IPv4 Tunnels. R. Graveman, M.Parthasarathy, P. Savola, H. Tschofenig. May 2007. (Format: TXT=46635 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
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
Gravemanがコメントのために要求するワーキンググループR.をネットワークでつないでください: 4891 RFGセキュリティ、LLCカテゴリ: 情報のM.のP.Savola CSC/FUNET H.Tschofenigノキアパルタサラティノキアシーメンスは2007年5月をネットワークでつなぎます。
Using IPsec to Secure IPv6-in-IPv4 Tunnels
IPv4のIPv6にトンネルを固定するのにIPsecを使用します。
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).
IETFが信じる著作権(C)(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を使用することで手動で中の構成されたIPv6IPv4にトンネルを固定するときの指導を与えます。 追加議定書拡大は全くIPsecフレームワークで利用可能なそれらを超えて説明されません。
Graveman, et al. Informational [Page 1] RFC 4891 IPsec with IPv6-in-IPv4 Tunnels May 2007
Graveman、他 IPv6がIPv4にある情報[1ページ]のRFC4891IPsecは2007年5月にトンネルを堀ります。
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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 2。 IPsec. . . . . . . . . . . . . . . . . 3 2.1の脅威と使用。 交通機関. . . . . . . . . . . . . . . . . 4 2.2によるIPsec。 トンネル・モード. . . . . . . . . . . . . . . . . . . 5 3におけるIPsec。 シナリオと概要. . . . . . . . . . . . . . . . . . . . 5 3.1。 ルータからルータは.63.2にトンネルを堀ります。 ルータからサイトからルータ/サイトは.63.3にトンネルを堀ります。 ホストからホストは.8 4にトンネルを堀ります。 IKEとIPsecバージョン. . . . . . . . . . . . . . . . . . . . 9 5。 IPsec構成の詳細. . . . . . . . . . . . . . . . . 10 5.1。 IPsecはモード. . . . . . . . . . . . . . . . . . . 11 5.2を輸送します。 同輩承認データベースとアイデンティティ. . . . . . . . 12 6。 推薦. . . . . . . . . . . . . . . . . . . . . . . 13 7。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 13 8。 貢献者. . . . . . . . . . . . . . . . . . . . . . . . . 14 9。 承認. . . . . . . . . . . . . . . . . . . . . . . 14 10。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 15 10.1。 引用規格. . . . . . . . . . . . . . . . . . . 15 10.2。 トンネル・モード. . . . . . . . . . . . . . . . . . 17A.1を使用する有益な参照. . . . . . . . . . . . . . . . . . 15付録A.。 モード実装メソッド. . . . . . . . . . . . 17A.2にトンネルを堀ってください。 ホストからホストへのシナリオ. . . . . . . . . . 18A.3のための特定のSPD。 ホストからルータへのシナリオ. . . . . . . . . 19付録B.オプション機能. . . . . . . . . . . . . . . . . . 20B.1のための特定のSPD。 ダイナミックなアドレス構成. . . . . . . . . . . . . . 20B.2。 NAT縦断と移動性. . . . . . . . . . . . . . . . 20B.3。 トンネル終点発見. . . . . . . . . . . . . . . . 21
Graveman, et al. Informational [Page 2] RFC 4891 IPsec with IPv6-in-IPv4 Tunnels May 2007
Graveman、他 IPv6がIPv4にある情報[2ページ]のRFC4891IPsecは2007年5月にトンネルを堀ります。
1. Introduction
1. 序論
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 Operations(v6ops)ワーキンググループは、IPv6展開のためのIPv6変遷メカニズムの1つとして[RFC4213]にトンネルを堀りながら、IPv4のIPv6を選択しました(手動で構成されます)。
[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]で適切に分析されなかったか、または扱われていなかった多くの脅威を特定しました。 最も完全なソリューションはIPv4のIPv6トンネリングを保護するのに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 Security Association(SA)設立のためのこのドキュメントによってされた仮定を分析します。 セクション5はパケット・フォーマットに従ったインターネット・キー・エクスチェンジ(IKE)とIPセキュリティ(IPsec)交換とSecurity Policy Database(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])の使用を扱いません。 おそらく、何らかのフォームの便宜主義的な暗号化か「ないよりましなセキュリティ」が、適切であるかもしれない、または適切でないかもしれません。 同様に、範囲の外にカプセル化されたパケットからトンネル経路までサービスの質属性(Explicit Congestion Notificationビット[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のトンネルを堀られたパケットをIPv4の上に受けるインタフェースについて言及します。
2. Threats and the Use of IPsec
2. IPsecの脅威と使用
[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ソースアドレスを偽造することができます。
Graveman, et al. Informational [Page 3] RFC 4891 IPsec with IPv6-in-IPv4 Tunnels May 2007
Graveman、他 IPv6がIPv4にある情報[3ページ]のRFC4891IPsecは2007年5月にトンネルを堀ります。
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)が存在している理由は[RFC3704]をフィルターにかけるIPv4イングレスの普遍的な展開の不足です。 脅威(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 脅威(1)を緩和するために、decapsulatorは、パケットのIPv4ソースアドレスが構成されたトンネル終点のアドレスと同じであることを確かめます。 また、正統のインタフェースにパケットを受け取るか否かに関係なく、decapsulatorは、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 decapsulatorは、脅威(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.
2つの方法、輸送とトンネルモードでIPsecを使用できます。 このような関係においては適用性の詳細な論議をセクション5に提供します。
2.1. IPsec in Transport Mode
2.1. 交通機関によるIPsec
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 Encapsulating Security有効搭載量(超能力)かAuthentication Header(AH)セキュリティ協会(SA)が、(IPv4-ソース、IPv4-dest、プロトコル=41)によって定義されたトラフィックを保護するために確立されます。 そのようなIPsecパケットを受けると、受信機は、SAに、パケットが適切であることを確かめるために最初に、IPsec変換(例えば、超能力)を適用して、次に、Security Parameter Index(SPI)とSAに関連している本国行きのセレクタに対してパケットに合っています。 うまくいっている検証は、パケットが正しいIPv4終点から来たのを含意します、SAが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.
これは脅威(2)ではなく、脅威(1)を防ぎます。 IPv6アドレスが運ばれるところで交通機関によるIPsecはペイロード自体のコンテンツについて確かめません。 すなわち、トンネルを固定するのにIPsec交通機関を使用する2つのノードが内側のペイロードを偽造することができます。 パケットを首尾よくdecapsulatedして、受け入れるでしょう。
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イングレスフィルタリングでこの短所を部分的に緩和できます、すなわち、パケットがトンネル終点(Strict Reverse Path Forwardingと同様(RPF)のチェック[RFC3704])に向かったルートの向きにインタフェースから到着する予定であるのをチェックしてください。
Graveman, et al. Informational [Page 4] RFC 4891 IPsec with IPv6-in-IPv4 Tunnels May 2007
Graveman、他 IPv6がIPv4にある情報[4ページ]のRFC4891IPsecは2007年5月にトンネルを堀ります。
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は正常なIPv4のIPv6トンネルに適用されます。 したがって、トンネルのインタフェースでイングレスフィルタリングを適用できます。 (また、交通機関は他の種類のGenericルート設定Encapsulation(GRE)[RFC4023]やLayer2Tunnelingプロトコル(L2TP)[RFC3193]などのトンネルでしばしば使用されます。)
2.2. IPsec in Tunnel Mode
2.2. トンネル・モードにおけるIPsec
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パケットを受けると、受信機は、SAに、パケットが適切であることを確かめるために最初に、IPsec変換(例えば、超能力)を適用して、次に、SAに関連しているSPIと本国行きのセレクタに対してパケットに合っています。 うまくいっている検証は、パケットが正しい終点から来たのを含意します。
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によって指定されたIPv4のIPv6トンネルがまだ存在していることに[RFC4213]注意してください。
3. Scenarios and Overview
3. シナリオと概要
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(境界)デバイスとIPv6上流プロバイダーのルータの間のトンネルについて言及します。 サイトの堕落したケースは独身のホストです。
3. Host-to-host tunnels.
3. ホストからホストはトンネルを堀ります。
Graveman, et al. Informational [Page 5] RFC 4891 IPsec with IPv6-in-IPv4 Tunnels May 2007
Graveman、他 IPv6がIPv4にある情報[5ページ]のRFC4891IPsecは2007年5月にトンネルを堀ります。
3.1. Router-to-Router Tunnels
3.1. ルータからRouterへのTunnels
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
.--------. _----_ .--------. |v4のv6| _(IPv4)_ |v4のv6| | ルータ| <===(インターネット)=====>| ルータ| | A| (_ _) | B| '--------' '----' '--------'^IPsecは^の間でトンネルを堀ります'| ルータAとルータ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パケットが取る経路の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つのルータが終わっていた状態である)はトンネルを堀ります。サイトは次が区分する説明されたコネです。
3.2. Site-to-Router/Router-to-Site Tunnels
3.2. ルータからサイトからルータ/SiteへのTunnels
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.
これはホストからルータとルータからホストへのトンネリングの一般化です、全体のサイト(ルータを使用する)をつなげて、独身のホストに接するとき、問題がおよそ等しいので。
Graveman, et al. Informational [Page 6] RFC 4891 IPsec with IPv6-in-IPv4 Tunnels May 2007
Graveman、他 IPv6がIPv4にある情報[6ページ]のRFC4891IPsecは2007年5月にトンネルを堀ります。
_----_ .---------. IPsec _----_ IPsec .-------.
_( IPv6 )_ |v6-in-v4 | Tunnel _( IPv4 )_ Tunnel | V4/V6 |
( Internet )<--->| Router |<=======( Internet )=======>| Site B |
(_ _) | A | (_ _) '--------'
'----' '---------' '----'
^
|
V
.--------.
| Native |
| IPv6 |
| node |
'--------'
_----_ .---------. IPsec_----_ IPsec。-------. _(IPv6)_ |v4のv6| トンネル_(IPv4)_トンネル| V4/V6| (インターネット)<-->、| ルータ|<====(インターネット)=======>| サイトB| (_ _) | A| (_ _) '--------' '----' '---------' '----' ^ | V。--------. | ネイティブ| | IPv6| | ノード| '--------'
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 | |
| '--------' |
+---------------------+
+---------------------+ | IPv6ネットワーク| | | .--------. _----_ | .--------. | | V6/V4| _(IPv4)_ | |v4のv6| | | サイトB|<==(インターネット)==========>| ルータ| | '--------' (_ _) | | A| | '----' | '--------' | IPsecは間にトンネルを堀ります。| ^ | IPv6サイトとルータA| | | | V| | .-------. | | | V6| | | | ホスト| | | '--------' | +---------------------+
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ソースアドレスがよく知られる接頭語から来ていて、サイトのホストはパケットを溯源しますが、送付先アドレスはインターネットのどんなノードであるかもしれません。
Graveman, et al. Informational [Page 7] RFC 4891 IPsec with IPv6-in-IPv4 Tunnels May 2007
Graveman、他 IPv6がIPv4にある情報[7ページ]のRFC4891IPsecは2007年5月にトンネルを堀ります。
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.
この場合、Site Bのルータに割り当てられた接頭語にIPsecトンネルモードSAを縛ることができました、そして、Router Aはパケットのソースアドレスが接頭語に合っていることを確かめることができました。 サイトBはそれが受けるパケットのための同様の検証ができないでしょう。 展開ケースの大部分に、これはかなり妥当であるかもしれません、例えば、インターネットサービスプロバイダ(ISP)が48対1顧客を/に割り当てて。 トンネルが終えられるCustomer Premises Equipment(CPE)はISPのルータを「信じます」、そして、(弱い意味で)ISPのルータはSite 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でこれらの一層のオプションを見てください。
3.3. Host-to-Host Tunnels
3.3. ホストからホストへのTunnels
.--------. _----_ .--------.
| V6/V4 | _( IPv4 )_ | V6/V4 |
| Host | <======( Internet )=====> | Host |
| A | (_ _) | B |
'--------' '----' '--------'
IPsec tunnel between
Host A and Host B
.--------. _----_ .--------. | V6/V4| _(IPv4)_ | V6/V4| | ホスト| <===(インターネット)=====>| ホスト| | A| (_ _) | B| '--------' '----' '--------'IPsecはHost Aと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/IPv4ホストは自分たちの間のトンネルIPv6パケットをそうすることができます。 この場合、トンネルは終わりから端への全体の経路にかかります。
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.
Introductionに述べられるように、このメモのための範囲の外にホストからホストへのトンネリング自動メソッド(例えば、6to4)があります。
Graveman, et al. Informational [Page 8] RFC 4891 IPsec with IPv6-in-IPv4 Tunnels May 2007
Graveman、他 IPv6がIPv4にある情報[8ページ]のRFC4891IPsecは2007年5月にトンネルを堀ります。
4. IKE and IPsec Versions
4. IKEとIPsecバージョン
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つです。
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.
古くて改訂されたIPsecアーキテクチャがあるネットワークAddress Translation(NAT)縦断作品、交渉だけが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
このドキュメントの目的のために、超能力に代わる手段としてAH[RFC4302]を使用できます。(そこでは、超能力[RFC4303]の秘密性は必要ではありません)。 主な違いはAHが外側のIPv4ヘッダーとIPv4オプションに、ある一定の分野のための保全保護を供給できるということです。 しかしながら、外側のIPv4として、ヘッダーはいずれでも捨てられるでしょう。
Graveman, et al. Informational [Page 9] RFC 4891 IPsec with IPv6-in-IPv4 Tunnels May 2007
Graveman、他 IPv6がIPv4にある情報[9ページ]のRFC4891IPsecは2007年5月にトンネルを堀ります。
case, and those particular fields are not believed to be relevant in this particular application, there is no particular reason to use AH.
特定の分野がこの特定用途で関連しているのは信じられていないケース、およびそれら、AHを使用するどんな特定の理由もありません。
5. IPsec Configuration Details
5. IPsec構成の詳細
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. リンク地方(例えば、Neighborディスカバリー)とマルチキャストトラフィックを含んでいて、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).
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トラフィックを保護できます。 実装がAppendix 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エントリーに関する長い一覧表をもたらして。 2番目の要件は満たすのが難しいです、保護を必要とするトラフィックが必ず先験的[RFC3884]に知られているというわけではないので(例えば、ルータからルータへのトンネル)。 また、3番目の要件も問題が多いです、ほとんどすべての実装が、アドレスが適切なソースアドレス選択のためにインタフェース(SPDsで構成されているよりむしろ)で割り当てられると仮定するので。
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
IPsecトンネルモードSAがインタフェースとしてモデル化されるなら、インタフェースを示すルートとして保護を必要とするトラフィックはモデル化できます。 しかし、保護を必要とするトラフィックが必ず先験的に知られているというわけではないので、2番目の要件は満たすのが難しいです。 The
Graveman, et al. Informational [Page 10] RFC 4891 IPsec with IPv6-in-IPv4 Tunnels May 2007
Graveman、他 IPv6がIPv4にある情報[10ページ]のRFC4891IPsecは2007年5月にトンネルを堀ります。
third requirement is easily solved, because IPsec is modeled as an interface.
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)を保護することによって、解決されましたが、どんな共同利用できる実装もこの特徴をサポートしません。 これに関係する問題の詳細なリストに関しては、[Vリンク]を見てください。
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.
トンネルを保護するために交通機関を適用するのがはるかに簡単なソリューションであり、また、容易にリンク地方とマルチキャストトラフィックを保護するので、私たちは、このような関係においてはトンネルモードを使用することを勧めません。 しかしながら、Appendix Aで、より詳しくトンネルモードについて議論します。
This document assumes that tunnels are manually configured on both sides and the ingress filtering is manually set up to discard spoofed packets.
このドキュメントは、トンネルが両側で手動で構成されて、イングレスフィルタリングが手動でパケットであると偽造された破棄まで設定されると仮定します。
5.1. IPsec Transport Mode
5.1. IPsec交通機関
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.
交通機関はL2TP、GRE、および他のトンネリングメソッドに通常適用されました、特にユーザが非IPトラフィックにトンネルを堀りたがっているとき。 [RFC3884]、[RFC3193]、および[RFC4023]は、終わりから端への経路の一部だけにかかるトンネルトラフィックを保護するために適用交通機関に関する例を提供します。
IPv6 ingress filtering must be applied on the tunnel interface on all the packets that pass the inbound IPsec processing.
本国行きのIPsec処理を通過するすべてのパケットでトンネルのインタフェースでIPv6イングレスフィルタリングを適用しなければなりません。
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アドレスの指示されたIPV4-TEP1とIPV4-TEP2と2つのルータ、Router1、およびRouter2があると仮定します。 (他のシナリオでは、SPDsは同様にセットアップされます。)
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)
Router1のSPD: 次の層の規則の地方のリモートプロトコル動き---- ----- ------ ---------- -------- 1 IPV4-TEP1 IPV4-TEP2超能力迂回2IPV4-TEP1 IPV4-TEP2イケ迂回3IPv4-TEP1 IPV4-TEP2 41は保護します。(超能力、輸送)
Graveman, et al. Informational [Page 11] RFC 4891 IPsec with IPv6-in-IPv4 Tunnels May 2007
Graveman、他 IPv6がIPv4にある情報[11ページ]のRFC4891IPsecは2007年5月にトンネルを堀ります。
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)
Router2のSPD: 次の層の規則の地方のリモートプロトコル動き---- ----- ------ ---------- -------- 1 IPV4-TEP2 IPV4-TEP1超能力迂回2IPV4-TEP2 IPV4-TEP1イケ迂回3IPv4-TEP2 IPV4-TEP1 41は保護します。(超能力、輸送)
In both SPD entries, "IKE" refers to UDP destination port 500
and possibly also port 4500 if NAT traversal is used.
両方のSPDエントリーでは、NAT縦断が使用されているなら、「イケ」がUDP仕向港500とことによるとまた、ポート4500を示します。
The packet format is as shown in Table 1.
パケット・フォーマットがTable1に示されるようにあります。
+----------------------------+------------------------------------+
| Components (first to last) | Contains |
+----------------------------+------------------------------------+
| IPv4 header | (src = IPV4-TEP1, dst = IPV4-TEP2) |
| ESP header | |
| IPv6 header | (src = IPV6-EP1, dst = IPV6-EP2) |
| (payload) | |
+----------------------------+------------------------------------+
+----------------------------+------------------------------------+ | コンポーネント(最初に、持続する)| 含んでいます。| +----------------------------+------------------------------------+ | IPv4ヘッダー| (src=IPV4-TEP1、dst=IPV4-TEP2) | | 超能力ヘッダー| | | IPv6ヘッダー| (src=IPV6-EP1、dst=IPV6-EP2) | | (ペイロード) | | +----------------------------+------------------------------------+
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のアイデンティティとしてのプロトコル値41を運びます。 IKEv2と共に、トラフィックセレクタは、同じ情報を運ぶのに使用されます。
5.2. Peer Authorization Database and Identities
5.2. 同輩承認データベースとアイデンティティ
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 Database(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交換で断言された同輩のIdentity: 多くの異なったタイプのアイデンティティを使用できます。 少なくとも、同輩の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]によって必要とされます。 少なくとも、あらかじめ共有されたキーは、より多くの実装で共同利用するので、支えられるべきです。
Graveman, et al. Informational [Page 12] RFC 4891 IPsec with IPv6-in-IPv4 Tunnels May 2007
Graveman、他 IPv6がIPv4にある情報[12ページ]のRFC4891IPsecは2007年5月にトンネルを堀ります。
o The child SA authorization data should contain the IPv4 address of
the peer.
o 子供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アドレスは主要な交換の間、Identityとしてサポートされるべきです。 これが保護をIdentityに供給しないとき、IKEv1と共に主なモードか攻撃的なモードを使用できます。
6. Recommendations
6. 推薦
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では、私たちは輸送かトンネルモードのどちらかを使用することでIPv4のIPsec IPv6トンネルを設立するところの違いを調べました。 私たちは、トンネルのインタフェースに交通機関を付けるのが、最も簡単でしたがって、お勧めのソリューションであることを観測します。
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.
また、Appendix Aでは、私たちはいわゆるSpecific SPD(SSPD)トンネルモードを使用するのに要するものについて調査します。 IPv6接頭語が、先験的に知られている必要があるので、そのような用法は、より複雑です、そして、マルチキャストとリンク地方のトラフィックはそのようなトンネルの上で働いていません。 また、トンネルモードにおける断片取り扱いも、より難しいです。 しかしながら、トンネルのIPv4終点がダイナミックであり、他の規制が適切でないときに、MobilityとMultihomingプロトコル(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トラフィックがトンネルの上まで運ばれるとき使用されてはいけなくて、そうする手動の合わせることで、攻撃者がキーを回収するのが、より簡単になるでしょう。 IPsec SAsを設立するのにIKEv1かIKEv2を使用しなければなりません。 IKEv2はサポートされて入手できるところで使用されるべきです。 そうでなければ、IKEv1は代わりに使用されるかもしれません。
7. Security Considerations
7. セキュリティ問題
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).
IPv4のIPv6トンネル(非機密保護した)をインターネットの上に動かすとき、ソースアドレスが(データ飛行機セキュリティ)であると偽造することによってパケットがトンネルに「注入」であることが可能であるか、またはトンネルがどうにか(例えば、認証プロトコルを使用して、静的な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トンネルを確立して、維持して、削除するのに安全なシグナリングプロトコルを提供します。
Graveman, et al. Informational [Page 13] RFC 4891 IPsec with IPv6-in-IPv4 Tunnels May 2007
Graveman、他 IPv6がIPv4にある情報[13ページ]のRFC4891IPsecは2007年5月にトンネルを堀ります。
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は超能力と共に発生源認証、秘密性、および任意(受信機の裁量における)の反再生機能を保全とデータに提供します。 保全なしで秘密性を使用するのはお勧めできないです。 その上、超能力は限られた交通の流れ秘密性を提供します。
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はキーの分配を通してSecurity Policy Database(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終点には、パケットを偽造するのがまだ可能です。
8. Contributors
8. 貢献者
The authors are listed in alphabetical order.
作者はアルファベット順に記載されています。
Suresh Satapati also participated in the initial discussions on this topic.
また、Suresh Satapatiはこの話題についての初期の議論に参加しました。
9. Acknowledgments
9. 承認
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.
作者は彼らの実質的なフィードバックについてスティーブン・ケント、マイケル・リチャードソン、フローリアンバイマー、Elwynデイヴィース、エリックVyncke、Merike Kaeo、アルフレッドHoenes、フランシス・デュポン、およびデヴィッドBlackに感謝したがっています。
We would like to thank Pasi Eronen for his text contributions and suggestions for improvement.
彼のテキスト貢献と改善提案についてパシEronenに感謝申し上げます。
Graveman, et al. Informational [Page 14] RFC 4891 IPsec with IPv6-in-IPv4 Tunnels May 2007
Graveman、他 IPv6がIPv4にある情報[14ページ]のRFC4891IPsecは2007年5月にトンネルを堀ります。
10. References
10. 参照
10.1. Normative References
10.1. 引用規格
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC2401] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[RFC2409]ハーキンとD.とD.個人閲覧室、「インターネット・キー・エクスチェンジ(IKE)」、RFC2409 1998年11月。
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004.
[RFC3704]ベイカー、F.とP.Savola、「Multihomedのためにネットワークをフィルターにかけるイングレス」BCP84、2004年3月のRFC3704。
[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.Stenberg、「IPsec超能力パケットのUDPカプセル化」RFC3948(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ホストとルータのための基本的な変遷メカニズム」、RFC4213、2005年10月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4301] ケントとS.とK.Seo、「インターネットプロトコルのためのセキュリティー体系」、RFC4301、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
[RFC4303]ケント、S.、「セキュリティが有効搭載量(超能力)であるとカプセル化するIP」、RFC4303、2005年12月。
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
[RFC4306] コーフマン、C.、「インターネット・キー・エクスチェンジ(IKEv2)プロトコル」、RFC4306、2005年12月。
10.2. Informative References
10.2. 有益な参照
[RFC2893] Gilligan, R. and E. Nordmark, "Transition Mechanisms for
IPv6 Hosts and Routers", RFC 2893, August 2000.
[RFC2893] ギリガンとR.とE.Nordmark、「IPv6ホストとルータのための変遷メカニズム」、RFC2893、2000年8月。
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
via IPv4 Clouds", RFC 3056, February 2001.
[RFC3056] 大工とB.とK.ムーア、「IPv4 Cloudsを通したIPv6 Domainsの接続」、RFC3056、2001年2月。
[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を固定します」、RFC3193、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)互換性要件」、RFC3715、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交通機関のダイナミックルーティングの使用」、RFC3884、2004年9月。
Graveman, et al. Informational [Page 15] RFC 4891 IPsec with IPv6-in-IPv4 Tunnels May 2007
Graveman、他 IPv6がIPv4にある情報[15ページ]のRFC4891IPsecは2007年5月にトンネルを堀ります。
[RFC4023] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating
MPLS in IP or Generic Routing Encapsulation (GRE)",
RFC 4023, March 2005.
[RFC4023] オースター、T.、Rekhter、Y.、およびE.ローゼン、「IPか一般ルーティングのカプセル化(GRE)でMPLSをカプセル化します」、RFC4023(2005年3月)。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
December 2005.
[RFC4302] ケント、S.、「IP認証ヘッダー」、RFC4302、2005年12月。
[RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol
(MOBIKE)", RFC 4555, June 2006.
[RFC4555]Eronen、2006年6月のP.、「IKEv2移動性とマルチホーミングプロトコル(MOBIKE)」RFC4555。
[RFC4718] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and
Implementation Guidelines", RFC 4718, October 2006.
[RFC4718] EronenとP.とP.ホフマン、「IKEv2明確化と実装ガイドライン」、RFC4718、2006年10月。
[TUNN-AD] Palet, J. and M. Diaz, "Analysis of IPv6 Tunnel End-point
Discovery Mechanisms", Work in Progress, January 2005.
[TUNN-西暦] 「IPv6トンネルエンドポイント発見メカニズムの分析」という殻、J.、およびM.ディアーズは進歩、2005年1月に働いています。
[VLINK] Duffy, M., "Framework for IPsec Protected Virtual Links
for PPVPNs", Work in Progress, October 2002.
[Vリンク]ダフィー、M.、「IPsecのためのフレームワークはPPVPNsのために仮想のリンクを保護したこと」が進歩、2002年10月に働いています。
Graveman, et al. Informational [Page 16] RFC 4891 IPsec with IPv6-in-IPv4 Tunnels May 2007
Graveman、他 IPv6がIPv4にある情報[16ページ]のRFC4891IPsecは2007年5月にトンネルを堀ります。
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.
まず最初に、私たちは異なったトンネルモード実装メソッドを説明します。 適用性を減少させました、そして、私たちは、いわゆるSpecific 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. 「ジェネリックSPDs」: いくつかの実装がIPインタフェースとしてトンネルモードSAをモデル化します。 IPsecトンネルのインタフェースがこの場合「any」のアドレスと共に作成されて、使用される、(「: : /0<->: : /0インチ)、IPsecがSAをセットアップしている間、セレクタを取引する、」 これは、2つのノードの間のすべてのトラフィックがIPsecによって保護されるのを許容しますが、経路指定テーブルは、どんなトラフィックがトンネルの上に送られるかを決めるでしょう。 IPsec方針チェックが全くIPv6アドレスをチェックしないので、別々にトンネルのインタフェースでイングレスフィルタリングを適用しなければなりません。 ルーティング・プロトコル、マルチキャストなどはこのトンネルを終えるでしょう。 このモードは、モードを輸送するために同様です。 SPDsはインタフェース特有であるに違いありません。 しかしながら、IKEがIPv4を使用しますが、トンネルがIPv6であるので、IPv6インタフェース[Vリンク]に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. 「特定のSPDs」: いくつかの実装はIPインタフェースとしてトンネルモードSAをモデル化しません。 トラフィック選択が例えば特定のSPDエントリーに基づいている、「2001:db8:1:、:、」/48<->2001:、db8: 2::/48". 2つの終点の間のIPsecセッションにインタフェースがないとき(実装には、すべてのIPsecトラフィックのための一般的な疑似インタフェースがあるかもしれませんが)、保護するどんなDuplicate Address Detection(DAD)、Multicast Listenerディスカバリー(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)が選ばれているとき、イングレスフィルタリングはIPsec処理で保証されますが、交通機関かオプション(1)が選ばれていると、オペレータは明らかにそれを可能にしなければなりません。
In summary, there does not appear to be a standard solution in this context for the first implementation approach.
概要では、このような関係においては最初の実装アプローチの標準液はあると載っていません。
Graveman, et al. Informational [Page 17] RFC 4891 IPsec with IPv6-in-IPv4 Tunnels May 2007
Graveman、他 IPv6がIPv4にある情報[17ページ]のRFC4891IPsecは2007年5月にトンネルを堀ります。
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]は、また、交通機関と比べて、より難しいかもしれなく、実装によって、SPDsに反映される必要があるかもしれません。
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.
トンネル終点のIPV4アドレスは、それぞれ以下のSPDエントリーが、IPv6アドレスが指示されたIPV6-EP1とIPV6-EP2(グローバルなアドレス)である2人のホスト、Host1、およびHost2があると仮定して、指示された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})
Host1のSPD: 次の層の規則の地方のリモートプロトコル動き---- ----- ------ ---------- -------- 1 IPV6-EP1 IPV6-EP2超能力迂回2IPV6-EP1 IPV6-EP2イケ迂回3IPv6-EP1 IPV6-EP2 41は保護します。(超能力、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})
Host2のSPD: 次の層の規則の地方のリモートプロトコル動き---- ----- ------ ---------- -------- 1 IPV6-EP2 IPV6-EP1超能力迂回2IPV6-EP2 IPV6-EP1イケ迂回3IPv6-EP2 IPV6-EP1 41は保護します。(超能力、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のアイデンティティとしてIPV6-EP1とIPV6-TEP2を運びます。 IKEv2と共に、トラフィックセレクタは、同じ情報を運ぶのに使用されます。
Graveman, et al. Informational [Page 18] RFC 4891 IPsec with IPv6-in-IPv4 Tunnels May 2007
Graveman、他 IPv6がIPv4にある情報[18ページ]のRFC4891IPsecは2007年5月にトンネルを堀ります。
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をホストに割り当てたところにルータとホストの間にあるなら、IPV6- EP1をIPV6-PREF/48に取り替えることによって、対応するSPDエントリーを引き出すことができます。
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})
ホストのSPD: 次の層の規則の地方のリモートプロトコル動き---- ----- ------ ---------- -------- 1 どんな迂回4IPV6-EP1も少しも少しも保護するIPV6-EP1 IPV6-EP2超能力迂回2IPV6-EP1 IPV6-EP2イケ迂回3IPV6-EP1 IPV6-EP1(超能力、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})
ルータのSPD: 次の層の規則の地方のリモートプロトコル動き---- ----- ------ ---------- -------- 1 どんなIPV6-EP1も少しも保護するIPV6-EP2 IPV6-EP1超能力迂回2IPV6-EP2 IPV6-EP1イケ迂回3(超能力、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と共に、トラフィックセレクタは、同じ情報を運ぶのに使用されます。
Graveman, et al. Informational [Page 19] RFC 4891 IPsec with IPv6-in-IPv4 Tunnels May 2007
Graveman、他 IPv6がIPv4にある情報[19ページ]のRFC4891IPsecは2007年5月にトンネルを堀ります。
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はDynamic Host Configuration Protocolの(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は、初期のイケ_SA_INIT交換で_SOURCE_IPとNAT_DETECTION_DESTINATION_IPペイロードをNAT_DETECTIONに送ることによって、自動的にNATの存在を検出できます。 いったんNATが検出されて、両方の終点が、IPsec NATが縦断拡大であるとサポートすると、UDPカプセル化を可能にすることができます。
More details about UDP encapsulation of IPsec-protected IP packets can be found in [RFC3948].
[RFC3948]でIPsecによって保護されたIPパケットのUDPカプセル化に関するその他の詳細を見つけることができます。
For IPv6-in-IPv4 tunneling, NAT traversal is interesting for two reasons:
IPv4のIPv6トンネリングにおいて、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の後ろでトンネル終点の1つはそうです、そして、プロトコル41を使用して、構成されたトンネリングは、NATを横断するために保証されません。 したがって、IPsecトンネルを使用するのは、1つが安全なトンネルとトンネルの他のトンネリングメカニズムなしでいつも可能であるかもしれないというわけではない両方を設立するのを可能にするでしょう。
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アドレスを変えるシナリオで有益であるかもしれません。 しかしながら、外側のアドレスが変化するとき、これは新しい安全保障問題を紹介するかもしれません、そして、トンネルモードを使用するのは最も適切でしょう。
Graveman, et al. Informational [Page 20] RFC 4891 IPsec with IPv6-in-IPv4 Tunnels May 2007
Graveman、他 IPv6がIPv4にある情報[20ページ]のRFC4891IPsecは2007年5月にトンネルを堀ります。
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.
2番目の利益はNATがいつでないかが適用されたのがまだ望ましいでしょう。 手動で構成されたトンネリングを使用するのは、特に、動的IPアドレスとの操作上の挑戦です、アドレスが変化するなら両端が、再構成される必要があるので。 したがって、IPアドレスが変化するなら、IPsecトンネルを復職させる簡単で効率的な方法は望ましいでしょう。 IKEv2が使用されているとき、MOBIKE[RFC4555]は解決法を提供しますが、それはトンネルモードをサポートするだけです。
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.
o バンドの外では、例えば、ISPのウェブページからメカニズムを使用します。
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 DHCPv4(例えば、「トンネルservice.example.com」)によって提供されたDNS検索経路にそれを追加することによってサービス名を調べるのにDNSを使用します。
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.
このドキュメントの目的のために、どうにかこのアドレスを得ることができると思われます。 アドレスがいったん学習されると、それは構成されたIPv4のIPv6トンネルへのトンネル終点として構成されます。
This problem is also discussed at more length in [TUNN-AD].
また、[TUNN-西暦]のときに、より多くの長さでこの問題について議論します。
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-アドレス特有でないくらいの方法で選ばれている場合にだけ、自動終点発見は利益を提供します。
Graveman, et al. Informational [Page 21] RFC 4891 IPsec with IPv6-in-IPv4 Tunnels May 2007
Graveman、他 IPv6がIPv4にある情報[21ページ]のRFC4891IPsecは2007年5月にトンネルを堀ります。
Authors' Addresses
作者のアドレス
Richard Graveman RFG Security, LLC 15 Park Avenue Morristown, NJ 07960 USA
リチャードGraveman RFG Security、モリスタウン、LLC15パーク・アベニューニュージャージー07960米国
EMail: rfg@acm.org
メール: rfg@acm.org
Mohan Parthasarathy Nokia 313 Fairchild Drive Mountain View, CA 94043 USA
モハンパルタサラティノキア313フェアチャイルド・Driveカリフォルニア94043マウンテンビュー(米国)
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
Graveman, et al. Informational [Page 22] RFC 4891 IPsec with IPv6-in-IPv4 Tunnels May 2007
Graveman、他 IPv6がIPv4にある情報[22ページ]のRFC4891IPsecは2007年5月にトンネルを堀ります。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Graveman, et al. Informational [Page 23]
Graveman、他 情報[23ページ]
一覧
スポンサーリンク
