Network Working Group V. Devarapalli
Request for Comments: 5266 Wichorus
BCP: 136 P. Eronen
Category: Best Current Practice Nokia
June 2008
Secure Connectivity and Mobility Using Mobile IPv4 and
IKEv2 Mobility and Multihoming (MOBIKE)
Status of This Memo
このメモのステータス
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントはインターネットコミュニティのためのインターネットBest Current Practicesを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Abstract
抽象
Enterprise users require mobility and secure connectivity when they roam and connect to the services offered in the enterprise. Secure connectivity is required when the user connects to the enterprise from an untrusted network. Mobility is beneficial when the user moves, either inside or outside the enterprise network, and acquires a new IP address. This document describes a solution using Mobile IPv4 (MIPv4) and mobility extensions to IKEv2 (MOBIKE) to provide secure connectivity and mobility.
エンタープライズユーザーがローミング時に機動性とセキュアな接続を必要とし、企業内で提供されるサービスに接続します。ユーザが信頼できないネットワークから企業に接続するときにセキュアな接続が必要となります。モビリティは、企業ネットワークの内部または外部のいずれかのときに、ユーザーが移動し、有益であり、そして新しいIPアドレスを取得します。この文書では、セキュアな接続性とモビリティを提供するためのIKEv2（MOBIKE）にモバイルIPv4（MIPv4の）とモビリティの拡張機能を使用して解決策を説明しています。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Access Modes . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.1. Access Mode: 'c' . . . . . . . . . . . . . . . . . . . 6
3.1.2. Access Mode: 'f' . . . . . . . . . . . . . . . . . . . 6
3.1.3. Access Mode: 'mc' . . . . . . . . . . . . . . . . . . 6
3.2. Mobility within the Enterprise . . . . . . . . . . . . . . 7
3.3. Mobility When outside the Enterprise . . . . . . . . . . . 7
3.4. Crossing Security Boundaries . . . . . . . . . . . . . . . 7
3.4.1. Operation When Moving from an Untrusted Network . . . 8
3.4.2. Operation When Moving from a Trusted Network . . . . . 9
4. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Normative References . . . . . . . . . . . . . . . . . . . 11
7.2. Informative References . . . . . . . . . . . . . . . . . . 11
Appendix A. Applicability to a Mobile Operator Network . . . . . 13
A typical enterprise network consists of users connecting to the services from a trusted network (intranet), and from an untrusted network (Internet). The trusted and untrusted networks are typically separated by a demilitarized zone (DMZ). Access to the intranet is controlled by a firewall and a Virtual Private Network (VPN) gateway in the DMZ.
典型的な企業ネットワークは、信頼できるネットワーク（イントラネット）から、信頼できないネットワーク（インターネット）からサービスに接続しているユーザーから成ります。信頼できると信頼できないネットワークは、典型的には、非武装地帯（DMZ）によって分離されています。イントラネットへのアクセスは、ファイアウォールと、DMZ内の仮想プライベートネットワーク（VPN）ゲートウェイによって制御されます。
Enterprise users, when roaming on untrusted networks, most often have to authenticate themselves to the VPN gateway and set up a secure tunnel in order to access the intranet. The use of IPsec VPNs is very common to enable such secure connectivity to the intranet. When the user is on the trusted network, VPNs are not used. However, the users benefit tremendously when session mobility between subnets, through the use of Mobile IPv4, is available.
企業ユーザーは、信頼できないネットワークにローミング時、ほとんどの場合、VPNゲートウェイに自分自身を認証し、イントラネットにアクセスするために、安全なトンネルを設定する必要があります。 IPsecのVPNの使用は、イントラネットへの安全な接続を可能にすることは非常に一般的です。ユーザーは、信頼できるネットワーク上にある場合は、VPNが使用されていません。サブネット間のセッションモビリティは、モバイルIPv4を使用して、利用可能なときただし、ユーザーが途方もメリットがあります。
There has been some work done on using Mobile IPv4 and IPsec VPNs to provide roaming and secure connectivity to an enterprise [RFC5265] [RFC4093]. The solution described in [RFC5265] was designed with certain restrictions, including requiring no modifications to the VPN gateways, and involves the use of two layers of MIPv4, with one home agent inside the intranet and one in the Internet or in the DMZ before the VPN gateway. The per-packet overhead is very high in this solution. It is also challenging to implement and have two instances of MIPv4 active at the same time on a mobile node. However, the solution described here is only applicable when Internet Key Exchange Protocol version 2 (IKEv2) IPsec VPNs are used.
企業[RFC5265] [RFC4093]にローミングし、安全な接続を提供するために、モバイルIPv4およびIPsec VPNを使用して行われ、いくつかの作業がありました。 [RFC5265]に記載された溶液は、前にインターネットまたはDMZ内の1つのホームイントラネット内のエージェントと一つで、VPNゲートウェイへの変更を必要としないなど、一定の制限で設計されており、MIPv4の二層の使用を必要としました。 VPNゲートウェイ。パケットごとのオーバーヘッドは、このソリューションでは非常に高いです。また、モバイルノード上で同時にアクティブのMIPv4の2つのインスタンスを実装して持つことが困難です。インターネット鍵交換プロトコルバージョン2（IKEv2の）のIPsec VPNが使用されている場合しかし、ここで説明するソリューションにのみ適用されます。
This document describes an alternate solution that does not require two layers of MIPv4. The solution described in this document uses Mobile IPv4 when the mobile node is on the trusted network and MOBIKE-capable IPsec VPNs when the mobile node is on the untrusted network. The mobile node uses the tunnel inner address (TIA) given out by the IPsec VPN gateway as the co-located care-of address (CoA) for MIPv4 registration. This eliminates the need for using an external MIPv4 home agent and the need for encapsulating the VPN tunnel inside a MIPv4 tunnel.
この文書では、MIPv4の二層を必要としない代替ソリューションについて説明します。モバイルノードが信頼できないネットワーク上にあるとき、モバイルノードは、トラステッド・ネットワークとMOBIKE対応のIPsec VPNの上にあるときに、この文書で説明するソリューションは、モバイルIPv4を使用します。モバイルノードは、同一位置気付アドレス（CoA）MIPv4の登録としてのIPsec VPNゲートウェイによって与えられるトンネル内部アドレス（TIA）を使用します。これは、外部のMIPv4ホームエージェントとのMIPv4トンネル内でVPNトンネルをカプセル化するための必要性を使用する必要がなくなります。
The following assumptions are made for the solution described in this document.
以下の仮定は、この文書で説明するソリューションのために作られています。
o IKEv2 [RFC4306] and IPsec [RFC4301] are used to set up the VPN tunnels between the mobile node and the VPN gateway.
OのIKEv2 [RFC4306]とIPsec [RFC4301]は、移動ノードとVPNゲートウェイ間のVPNトンネルを設定するために使用されます。
o The VPN gateway and the mobile node support MOBIKE extensions as defined in [RFC4555].
[RFC4555]で定義されるようにVPNゲートウェイとモバイルノード支援MOBIKE拡張O。
o When the mobile node is on the trusted network, traffic should not go through the DMZ. Current deployments of firewalls and DMZs consider the scenario where only a small amount of the total enterprise traffic goes through the DMZ. Routing through the DMZ typically involves stateful inspection of each packet by the firewalls in the DMZ. Moreover, the DMZ architecture assumes that the DMZ is less secure than the internal network. Therefore, the DMZ-based architecture allows the least amount of traffic to traverse the DMZ, that is, only traffic between the trusted network and the external network. Requiring all normal traffic to the mobile nodes to traverse the DMZ would negate this architecture.
モバイルノードは、信頼できるネットワーク上にある場合には、O、トラフィックはDMZを通過するべきではありません。ファイアウォールやDMZの現在の展開では、全企業の少量のトラフィックがDMZを通過するだけのシナリオを検討してください。 DMZを介してルーティングすることは、典型的にDMZ内のファイアウォールによって各パケットのステートフルインスペクションを含みます。また、DMZアーキテクチャは、DMZは、内部ネットワークよりも安全であることを前提としています。したがって、DMZベースのアーキテクチャは、それは、トラステッド・ネットワークと外部ネットワークの間のトラフィックだけで、DMZを横断するトラフィックの最小量を可能にします。 DMZを横断するモバイルノードへのすべての通常のトラフィックを要求することは、このアーキテクチャを否定するでしょう。
o When the mobile node is on the trusted network and uses a wireless access technology, confidentiality protection of the data traffic is provided by the particular access technology. In some networks, confidentiality protection MAY be available between the mobile node and the first hop access router, in which case it is not required at layer 2.
モバイルノードは、信頼できるネットワーク上にあり、無線アクセス技術を使用する場合、O、データトラフィックの機密保護は、特定のアクセス技術によって提供されます。一部のネットワークでは、機密保護は、それがレイヤ2で必要とされない場合には、移動ノードと第1のホップのアクセスルータの間で利用可能であってもよいです。
This document also presents a solution for the mobile node to detect when it is on a trusted network, so that the IPsec tunnel can be dropped and the mobile node can use Mobile IP in the intranet.
また、このドキュメントはIPsecトンネルをドロップすることができ、移動ノードがイントラネット内のモバイルIPを使用できるように、それは、信頼されたネットワーク上にあるときを検出するためのモバイルノードのための解決策を提示します。
IPsec VPN gateways that use IKEv1 [RFC2409] are not addressed in this document.
IKEv1の[RFC2409]を使用したIPsec VPNゲートウェイは、本書で扱われていません。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
Many of the following terms are defined in [RFC5265], but are repeated here to make this document self-contained.
次の用語の多くは、[RFC5265]で定義されているが、この文書は自己完結型にするためにここで繰り返されています。
FA: Mobile IPv4 foreign agent.
FA：モバイルIPv4外部エージェント。
Co-CoA: co-located care-of address.
共同アシルCoA：共存気付アドレス。
FA-CoA: foreign agent care-of address.
FA-CoAを：外国人のエージェントの気付アドレス。
FW: firewall.
FW：ファイアウォール。
i-FA: Mobile IPv4 foreign agent residing in the trusted (intranet) network.
I-FA：信頼できる（イントラネット）ネットワークに存在するモバイルIPv4外部エージェント。
i-HA: Mobile IPv4 home agent residing in the trusted (intranet) network.
I-HA：信頼できる（イントラネット）ネットワークに存在するモバイルIPv4ホームエージェント。
i-MIP: The mobile node uses the home agent in the internal network.
I-MIP：モバイルノードは、内部ネットワークにホームエージェントを使用しています。
VPN-TIA: VPN tunnel inner address. This address is given out by the VPN gateway during IKE negotiation and is routable in the trusted network.
VPN-TIA：VPNトンネル内部アドレス。このアドレスは、IKEネゴシエーションの間にVPNゲートウェイによって与えられ、信頼できるネットワークにルーティング可能です。
mVPN: VPN with MOBIKE functionality.
MVPN：MOBIKE機能を持つVPN。
The following access modes are used in explaining the protocol. The access modes are explained in more detail in [RFC5265].
以下のアクセス・モードは、プロトコルの説明で使用されています。アクセス・モードは、[RFC5265]で詳細に説明されています。
f: i-MIP with FA-CoA
V：FA-CoAを持つV-MIP
c: i-MIP with Co-CoA
C：共同CoAを持つI-MIP
mc: i-MIP with MOBIKE-enabled VPN, with VPN-TIA as Co-CoA
MC：共同CoAとしてVPN-TIAとMOBIKE対応のVPNとI-MIP、
The mobile node is configured with a home address that remains the same irrespective of whether the mobile node is inside or outside the enterprise network. The mobile node is also reachable at the same home address irrespective of its current point of attachment. When the mobile node is connected to the intranet directly, it uses Mobile IP for internal mobility.
モバイルノードは、モバイルノードは、企業ネットワークの内部または外部にあるかにかかわらず同じままであるホームアドレスが設定されています。モバイルノードは、アタッチメントのその現在のポイントの同一のホームアドレスによらずに到達可能です。モバイルノードが直接イントラネットに接続されている場合、それは内部のモビリティのためのモバイルIPを使用します。
When the mobile node roams and connects to an untrusted network outside the enterprise, it sets up a VPN tunnel to the VPN gateway. However, it still maintains a valid binding cache entry at the i-HA. It uses the VPN-TIA, allocated by the VPN gateway, as the co-located CoA for registration with the i-HA. If the VPN-TIA changes or if the mobile node moves and connects to another VPN gateway, then it sends a Registration Request to the i-HA using the new co-located CoA.
モバイルノードがローミングし、企業外部の信頼できないネットワークに接続すると、それはVPNゲートウェイへのVPNトンネルを設定します。しかし、それはまだ私-HAの有効なバインディングキャッシュエントリを維持します。これは、I-HAへの登録のために同じ場所に配置CoAとして、VPNゲートウェイによって割り当てられたVPN-TIAを使用します。 VPN-TIAの場合、または移動ノードの移動を変更し、別のVPNゲートウェイに接続している場合、それは新たな共同配置CoAを使用して、I-HAに登録要求を送信します。
If the mobile node moves while outside the enterprise and its access network changes, it uses the MOBIKE protocol to update the VPN gateway of its current address. The internal home agent is not aware of the mobile node's movement as long as the mobile node is attached to the same VPN gateway and the TIA remains the same.
企業とそのアクセスネットワークの変更の外側に、それは、現在のアドレスのVPNゲートウェイを更新するMOBIKEプロトコルを使用している間、移動ノードが移動した場合。内部ホームエージェントは、モバイルノードの動きを認識していない限り、移動ノードが同一のVPNゲートウェイとTIAに取り付けられているのと同じままです。
Figure 1 depicts the network topology assumed for the solution. It also shows the possible mobile node locations and access modes.
図1は、溶液に対して想定ネットワークトポロジを示しています。また、可能、移動ノードの位置とアクセスモードを示しています。
{home} (MN) [i-HA]
\ /
.-+---+-.
( )
[mVPN] `--+----'
! !
.--+--. [R]
( DMZ ) !
.-+-------+--. `--+--' .-----+------.
( ) ! ( )
( external net +---[R]----[FW]----[R]--+ internal net )
( ) ( )
`--+---------' `---+---+----'
/ / \
[DHCP] [R] [DHCP] [R] [R] [i-FA]
\ / \ / \ /
.+--+---. .-+-+--. .--+--+-.
( ) ( ) ( )
`---+---' `--+---' `---+---'
! ! !
(MN) {mc} (MN) {c} (MN) {f}
Figure 1: Network Topology Using MIPv4 and MOBIKE
図1：ネットワークトポロジのMIPv4とMOBIKEを使用して
The solution described above results in a Mobile IP tunnel inside an IPsec tunnel. The Mobile IP tunnel is between the mobile node and the home agent, and the IPsec tunnel is between the mobile node (MN) and the mVPN gateway. The mobile node MUST reverse tunnel through the home agent [RFC3024] when the Mobile IP tunnel is inside an IPsec tunnel.
溶液は、IPsecトンネル内のモバイルIPトンネルをもたらす上述します。モバイルIPトンネルがモバイルノードとホームエージェントの間であり、IPsecトンネルは、モバイルノード（MN）とMVPNゲートウェイとの間です。モバイルIPトンネルは、IPsecトンネル内にあるとき、モバイルノードは、ホームエージェント[RFC3024]を介してトンネルを逆にしなければなりません。
The overhead of running a Mobile IP tunnel inside an IPsec tunnel can be avoided by having the Mobile IP foreign agent functionality on the VPN gateway. This is out of scope for this document and is further described in [MEGHANA].
IPsecトンネル内のモバイルIPトンネルを実行するオーバーヘッドは、VPNゲートウェイのモバイルIPフォーリンエージェント機能を有することによって回避することができます。これは、この文書の範囲外であり、さらに[MEGHANA]に記載されています。
Whenever the mobile node attaches to a new link, it may encounter a foreign agent. The mobile node MUST not use the foreign agent care-of address with the i-HA when attached to an untrusted access network. The default behavior for the mobile node is to always configure an address from the access link using DHCP. The mobile node then checks if it is attached to a trusted access network by sending a Registration Request to the i-HA in the co-located care-of address mode. If the mobile node discovers that it is attached to a trusted access network, then it MAY start using a foreign agent care-of address with the i-HA. In order to do this, the mobile node has to perform a new registration with the i-HA.
モバイルノードが新しいリンクに接続するたびに、外国人のエージェントが発生することがあります。信頼できないアクセスネットワークに接続するとき、モバイルノードがi-HAとフォーリンエージェント気付アドレスを使用することはできません。モバイルノードのデフォルトの動作は、常にDHCPを使用してアクセスリンクからアドレスを設定することです。それは同じ場所に配置気付アドレスモードでI-HAに登録要求を送信することにより、信頼できるアクセスネットワークに接続されている場合、モバイルノードは、チェックします。モバイルノードは、それが信頼できるアクセスネットワークに接続されていることを発見した場合、それがi-HAとフォーリンエージェント気付アドレスを使用して起動することがあります。これを行うためには、モバイルノードがi-HAとの新規登録を行う必要があります。
The mobile node can use a foreign agent on a untrusted access network, if there is an external home agent that the mobile node is able to use. The use of an external home agent in the untrusted access network and a home agent in the trusted access network at the same time is described in detail in [RFC5265].
モバイルノードが使用することができ、外部ホームエージェントが存在する場合、モバイルノードは、信頼できないアクセスネットワーク上の外国人のエージェントを使用することができます。同時に信頼アクセスネットワーク内の信頼できないアクセスネットワーク内の外部ホームエージェントを使用すると、ホームエージェントは、[RFC5265]に詳細に記載されています。
Some IPsec VPN implementations allow a host to send traffic directly to the Internet when attached to an untrusted network. This traffic bypasses the IPsec tunnel with the VPN gateway. This document does not prevent such traffic from being sent out from the host, but there will be no mobility or session continuity for the traffic. Any data traffic that is sent through the Mobile IP tunnel with the home agent is always sent through the VPN gateway.
いくつかのIPsec VPNの実装は、信頼できないネットワークに接続されたときにホストが直接インターネットにトラフィックを送信することができます。このトラフィックは、VPNゲートウェイとのIPsecトンネルをバイパスします。この文書では、ホストから送出されることから、このようなトラフィックを防ぐことはできませんが、トラフィックのためのモビリティやセッション継続性はありません。ホームエージェントにモバイルIPトンネルを経由して送信されたすべてのデータトラフィックは、常にVPNゲートウェイを介して送信されます。
The following access modes are used in the solution described in this document.
以下のアクセスモードが、この文書で説明するソリューションで使用されています。
This access mode is standard Mobile IPv4 [RFC3344] with a co-located care-of address. The mobile node must detect that it is connected to an internal trusted network before using this mode. The co-located care-of address is assigned by the access network to which the mobile node is attached.
このアクセスモードは、同一位置気付アドレスを標準モバイルIPv4 [RFC3344]です。モバイルノードは、それがこのモードを使用する前に、信頼できる内部ネットワークに接続されていることを検出する必要があります。同一位置気付アドレスは、移動ノードが接続されているアクセスネットワークによって割り当てられます。
This access mode is standard Mobile IPv4 [RFC3344] with a foreign agent care-of address. The mobile node can use this mode only when it detects that it is connected to an internal trusted network and also detects a foreign agent on the access network.
このアクセス・モードは、外部エージェントの気付アドレスを持つ標準のモバイルIPv4 [RFC3344]です。それはそれは内部の信頼できるネットワークに接続されていることを検出し、また、アクセスネットワーク上の外国人のエージェントを検出した場合にのみ、移動ノードは、このモードを使用することができます。
This access mode involves using both Mobile IPv4 and a MOBIKE-enabled IPsec VPN gateway, resulting in a Mobile IP tunnel inside an IPsec tunnel. The mobile node uses the VPN-TIA as the co-located CoA for registering with the home agent. This mode is used only when the mobile node is attached to an untrusted network and is required to set up an IPsec tunnel with a VPN gateway to gain access to the trusted network.
このアクセスモードは、IPsecトンネル内のモバイルIPトンネルを生じる、モバイルIPv4とMOBIKE対応のIPsec VPNゲートウェイの両方を使用することを含みます。モバイルノードは、ホームエージェントに登録するための共同設置CoAとしてVPN-TIAを使用しています。このモードでは、モバイルノードが信頼できないネットワークに接続され、信頼されたネットワークへのアクセスを得るためにVPNゲートウェイとのIPsecトンネルを設定する必要がある場合にのみ使用されます。
When the mobile node is inside the enterprise network and attached to the intranet, it uses Mobile IPv4 [RFC3344] for subnet mobility. The mobile node always configures a care-of address through DHCP on the access link and uses it as the co-located care-of address. The mobile node MAY use a foreign agent care-of address, if a foreign agent is available. However, the foreign agent care-of address is used only when the mobile node is attached to the trusted access network. The mobile node attempts Foreign Agent discovery and CoA address acquisition through DHCP simultaneously in order to avoid the delay in discovering a foreign agent when there is no foreign agent available. The mobile node maintains a valid binding cache entry at all times at the home agent mapping the home address to the current CoA. Whenever the mobile node moves, it sends a Registration Request to update the binding cache entry.
モバイルノードは、エンタープライズネットワーク内で、イントラネットに結合した場合、それはサブネットモビリティ用モバイルIPv4 [RFC3344]を使用します。モバイルノードは、常にアクセスリンク上のDHCPを通じて気付アドレスを設定し、同じ場所に配置気付けアドレスとして使用します。外国人のエージェントが利用可能な場合、移動ノードは、外部エージェントの気付アドレスを使用するかもしれません。しかし、外国人のエージェントの気付アドレスは、モバイルノードが信頼できるアクセスネットワークに接続されている場合にのみ使用されます。モバイルノードが同時に利用可能な外国人のエージェントが存在しない場合に外国人のエージェントを発見の遅れを避けるために、DHCPによる外部エージェントの発見とCoAのアドレス取得を試みます。モバイルノードは、現在のCoAにホームアドレスをマッピングするホームエージェントで常に有効なバインディングキャッシュエントリを維持します。モバイルノードが移動するたびに、バインディングキャッシュエントリを更新するための登録リクエストを送信します。
The Mobile IP signaling messages between the mobile node and the home agent are authenticated as described in [RFC3344].
[RFC3344]に記載されているように、モバイルノードとホームエージェントとの間のモバイルIPシグナリングメッセージは認証されています。
The mobile node maintains a valid binding cache entry at the home agent even when it is outside the enterprise network.
モバイルノードは、それが企業ネットワークの外にある場合でも、ホームエージェントで有効なバインディングキャッシュエントリを維持します。
When the mobile node is attached to an untrusted network, it sets up an IPsec VPN tunnel with the VPN gateway to gain access to the enterprise network. If the mobile node moves and its IP address changes, it initiates the MOBIKE protocol [RFC4555] to update the address on the VPN gateway.
モバイルノードは、信頼できないネットワークに接続されている場合には、企業ネットワークへのアクセスを得るためにVPNゲートウェイとのIPsec VPNトンネルを設定します。モバイルノードが移動すると、そのIPアドレスが変更された場合は、VPNゲートウェイのアドレスを更新するためにMOBIKEプロトコル[RFC4555]を開始します。
The mobile node maintains a binding at the home agent even when it is outside the enterprise network. If the TIA changes due to the mobile node re-connecting to the VPN gateway or attaching to a different VPN gateway, the mobile node should send a Registration Request to its home agent to update the binding cache with the new TIA.
モバイルノードは、それが企業ネットワーク外であっても、ホームエージェントでの結合を維持します。モバイルノードにTIAの変更は、VPNゲートウェイに再接続するか、別のVPNゲートウェイに装着する場合は、モバイルノードは、新しいTIAとのバインディングキャッシュを更新するために、そのホームエージェントに登録リクエストを送信する必要があります。
Security boundary detection is based on the reachability of the i-HA from the mobile node's current point of attachment. Whenever the mobile node detects a change in network connectivity, it sends a Registration Request to the i-HA without any VPN encapsulation. If the mobile node receives a Registration Reply with the Trusted Networks Configured (TNC) extension from the i-HA, then it assumes that it is on a trusted network. The TNC extension is described in [RFC5265]. The mobile node MUST check that the Registration Reply is integrity protected using the mobile node-home agent mobility security association before concluding it is attached to a trusted network. This security boundary detection is based on the mechanism described in [RFC5265] to detect attachment to the internal trusted network. The mobile node should re-transmit the Registration Request if it does not receive the Registration Reply within a timeout period. The number of times the mobile node should re-transmit the Registration Request and the timeout period for receiving the Registration Reply are configurable on the mobile node.
セキュリティ境界検出は、添付のモバイルノードの現在のポイントからI-HAの到達可能性に基づいています。モバイルノードは、ネットワーク接続の変化を検出するたびに、それがどのVPNカプセル化することなく、I-HAに登録要求を送信します。モバイルノードは、I-HAから信頼されたネットワーク構成済み（TNC）拡張子の登録応答を受信した場合、それはそれが信頼できるネットワーク上にあることを前提としています。 TNC拡張は[RFC5265]に記載されています。モバイルノードは、登録応答は、それが信頼できるネットワークに接続されている締結する前に、モバイルノードのホームエージェントのモビリティセキュリティアソシエーションを使用して保護整合性であることをチェックしなければなりません。このセキュリティ境界検出は、内部トラステッドネットワークへの接続を検出するために[RFC5265]で説明されたメカニズムに基づいています。それはタイムアウト期間内に登録応答を受信しない場合、モバイルノードは、登録要求を再送信する必要があります。モバイルノードが登録要求および登録応答を受信するためのタイムアウト期間を再送信する回数は、移動ノードに設定されています。
When the mobile node is attached to an untrusted network and is using an IPsec VPN to the enterprise network, the ability to send a Registration Request to the i-HA without VPN encapsulation would require some interaction between the IPsec and MIPv4 modules on the mobile node. This is local to the mobile node and out of scope for this document.
モバイルノードが信頼できないネットワークに接続されており、企業ネットワークへのIPsec VPNを使用している場合、VPNカプセル化せずにI-HAに登録要求を送信する機能は、モバイルノードにIPsecとMIPv4のモジュール間の何らかの相互作用を必要とするであろう。これは、このドキュメントの範囲の移動ノードとアウトにローカルです。
If the mobile node has an existing VPN tunnel to its VPN gateway, it MUST send a MOBIKE message at the same time as the registration request to the i-HA whenever the IP address changes. If the mobile node receives a response from the VPN gateway, but not from the i-HA, it assumes it is outside the enterprise network. If it receives a response from the i-HA, then it assumes it is inside the enterprise network.
モバイルノードがそのVPNゲートウェイへの既存のVPNトンネルがある場合は、I-HAたびにIPアドレスの変更に登録要求と同時にMOBIKEメッセージを送らなければなりません。モバイルノードは、VPNゲートウェイからではなく、I-HAからの応答を受信した場合、それが企業ネットワークの外にあると仮定します。それは、I-HAからの応答を受信した場合、それは、それが企業ネットワーク内にある前提。
There could also be some out-of-band mechanisms that involve configuring the wireless access points with some information that the mobile node can recognize as access points that belong to the trusted network in an enterprise network. Such mechanisms are beyond the scope of this document.
また、モバイルノードは、企業ネットワーク内の信頼できるネットワークに属しているアクセスポイントとして認識可能ないくつかの情報を持つワイヤレスアクセスポイントの設定を伴ういくつかのアウトオブバンドメカニズムがあるかもしれません。このようなメカニズムはこのドキュメントの範囲を超えています。
The mobile node should not send any normal traffic while it is trying to detect whether it is attached to the trusted or untrusted network. This is described in more detail in [RFC5265].
それが信頼できるか、信頼できないネットワークに接続されているかどうかを検出しようとしている間、移動ノードは、任意の通常のトラフィックを送信するべきではありません。これは、[RFC5265]に詳細に記載されています。
When the mobile node is outside the enterprise network and attached to an untrusted network, it has an IPsec VPN tunnel with its mobility aware VPN gateway, and a valid registration with a home agent on the intranet with the VPN-TIA as the care-of address.
モバイルノードが企業ネットワークの外にあると信頼できないネットワークに接続するとき、それは気付としてVPN-TIAとイントラネット上のホームエージェントとの移動性を意識VPNゲートウェイとのIPsec VPNトンネル、および有効な登録を有しています住所。
If the mobile node moves and its IP address changes, it performs the following steps:
モバイルノードが移動すると、そのIPアドレスが変更された場合、それは、次の手順を実行します。
1a. Initiate an IKE mobility exchange to update the VPN gateway with the current address. If the new network is also untrusted, this will be enough for setting up the connectivity. If the new network is trusted, and if the VPN gateway is reachable, this exchange will allow the mobile node to keep the VPN state alive while on the trusted side. If the VPN gateway is not reachable from inside, then this exchange will fail.
図1a。現在のアドレスとVPNゲートウェイを更新するために、IKEモビリティ交換を開始します。新しいネットワークでも信頼されていない場合には、これは、接続をセットアップするための十分でしょう。新しいネットワークが信頼されている場合は、VPNゲートウェイが到達可能であるならば、そして、この交換は、モバイルノードが信頼できる側にしばらく生きているVPNの状態を維持することができます。 VPNゲートウェイが内側から到達可能でない場合は、この交換は失敗します。
1b. At the same time as step 1, send a Mobile IPv4 Registration Request to the internal home agent without VPN encapsulation.
図1b。ステップ1と同時に、VPNカプセル化することなく、内部のホームエージェントにモバイルIPv4登録リクエストを送信します。
2. If the mobile node receives a Registration Reply to the request sent in step 1b, then the current subnet is a trusted subnet, and the mobile node can communicate without VPN tunneling. The mobile node MAY tear down the VPN tunnel.
前記移動ノードは、ステップ1bに送信された要求への登録応答を受信した場合、現在のサブネットは信頼サブネットであり、モバイルノードは、VPNトンネリングなしで通信することができます。モバイルノードは、VPNトンネルを切断してもよい（MAY）。
When the mobile node is inside the enterprise and attached to the intranet, it does not use a VPN tunnel for data traffic. It has a valid binding cache entry at its home agent. If the VPN gateway is reachable from the trusted network, the mobile node MAY have valid IKEv2 security associations with its VPN gateway. The IPsec security associations can be created when required. The mobile node may have to re-negotiate the IKEv2 security associations to prevent them from expiring.
モバイルノードが企業内部で、イントラネットに結合した場合、それはデータトラフィックのVPNトンネルを使用していません。これは、そのホームエージェントで有効なバインディングキャッシュエントリがあります。 VPNゲートウェイは、信頼できるネットワークから到達可能である場合には、モバイルノードは、そのVPNゲートウェイと有効なのIKEv2セキュリティアソシエーションを持っているかもしれません。必要なときにIPsecセキュリティアソシエーションを作成することができます。モバイルノードは、期限切れからそれらを防ぐためのIKEv2セキュリティアソシエーションを再交渉する必要があります。
If the mobile node moves and its IP address changes, it performs the following steps:
モバイルノードが移動すると、そのIPアドレスが変更された場合、それは、次の手順を実行します。
1. Initiate an IKE mobility exchange to update the VPN gateway with the current address, or if there is no VPN connection, then establish a VPN tunnel with the gateway from the new local IP address. If the new network is trusted, and if the VPN gateway is reachable, this exchange will allow the mobile node to keep the VPN state alive, while in the trusted side. If the new network is trusted and if the VPN gateway is not reachable from inside, then this exchange will fail.
1.現在のアドレスとVPNゲートウェイを更新するために、IKEモビリティ交換を開始、または全くVPN接続が存在しない場合、新しいローカルIPアドレスからのゲートウェイとのVPNトンネルを確立します。新しいネットワークが信頼されている場合、およびVPNゲートウェイが到達可能である場合には、この交換は、信頼できる側の間、移動ノードは、生きているVPNの状態を維持することができます。新しいネットワークが信頼されている場合やVPNゲートウェイが内側から到達可能でない場合には、この交換は失敗します。
2. At the same time as step 1, send a Mobile IPv4 Registration Request to the internal home agent without VPN encapsulation.
2.ステップ1と同時に、VPNのカプセル化せずに内部ホームエージェントにモバイルIPv4登録リクエストを送信します。
3. If the mobile node receives a Registration Reply to the request sent in step 2, then the current subnet is a trusted subnet, and the mobile node can communicate without VPN tunneling, using only Mobile IP with the new care-of address.
前記移動ノードは、ステップ2で送信された要求に対する登録応答を受信した場合、現在のサブネットは信頼サブネットで、移動ノードは新しい気付アドレスのみモバイルIPを使用して、VPNトンネルなしで通信することができます。
4. If the mobile node didn't receive the response in step 3, and if the VPN tunnel is successfully established and registered in step 1, then the mobile node sends a Registration Request over the VPN tunnel to the internal home agent. After receiving a Registration Reply from the home agent, the mobile node can start communicating over the VPN tunnel with the Mobile IP home address.
4.モバイルノードは、ステップ3での応答を受信しなかった場合、およびVPNトンネルが正常に確立し、ステップ1で登録されている場合、モバイルノードは、内部のホームエージェントへのVPNトンネルを介して登録要求を送信します。ホームエージェントからの登録応答を受信した後、モバイルノードは、モバイルIPのホームアドレスとVPNトンネル経由で通信を開始することができます。
There could be a Network Address Translation (NAT) device between the mobile node and the home agent in any of the access modes, 'c', 'f', and 'mc', and between the mobile node and the VPN gateway in the access mode 'mc'. Mobile IPv4 NAT traversal, as described in [RFC3519], should be used by the mobile node and the home agent in access modes 'c' or 'f', when there is a NAT device present. When using access mode, 'mc', IPsec NAT traversal [RFC3947] [RFC3948] should be used by the mobile node and the VPN gateway, if there is a NAT device present. Typically, the TIA would be a routable address inside the enterprise network. But in some cases, the TIA could be from a private address space associated with the VPN gateway. In such a case, Mobile IPv4 NAT traversal should be used in addition to IPsec NAT traversal in the 'mc' mode.
モバイルノードとアクセス・モードのいずれかで、ホームエージェント、「C」、「F」、および「MC」の間、およびモバイルノードとVPNゲートウェイの間でネットワークアドレス変換（NAT）デバイスがあるかもしれませんアクセスモード「MC」。 NATデバイスが存在する場合にモバイルIPv4 NATトラバーサルは、[RFC3519]に記載されているように、モバイルノードとアクセスモード「C」または「F」で、ホームエージェントによって使用されるべきです。アクセスモード、「MC」を使用する場合、NATデバイスが存在した場合、IPsecのNATトラバーサル[RFC3947]、[RFC3948]は、移動ノードとVPNゲートウェイによって使用されるべきです。典型的には、TIAは、企業ネットワーク内のルーティング可能なアドレスであろう。しかし、いくつかのケースでは、TIAは、VPNゲートウェイに関連付けられたプライベートアドレス空間からである可能性があります。このような場合には、モバイルIPv4 NATトラバーサルは、「MC」モードのIPsec NATトラバーサルに加えて使用されるべきです。
Enterprise connectivity typically requires very strong security, and the solution described in this document was designed keeping this in mind.
エンタープライズ接続性は、典型的には非常に強力なセキュリティを必要とし、この文書で説明するソリューションは、このことを念頭に保つように設計されました。
Security concerns related to the mobile node detecting that it is on a trusted network and thereafter dropping the VPN tunnel are described in [RFC5265].
それが信頼されたネットワーク上にあることを検出した後、VPNトンネルをドロップモバイルノードに関連するセキュリティ上の懸念は、[RFC5265]に記載されています。
When the mobile node sends a Registration Request to the i-HA from an untrusted network that does not go through the IPsec tunnel, it will reveal the i-HA's address, its own identity including the NAI and the home address, and the Authenticator value in the authentication extensions to the untrusted network. This may be a concern in some deployments.
モバイルノードは、IPsecトンネルを経由しない、信頼できないネットワークからI-HAに登録要求を送信すると、それがi-HAのアドレス、NAI、ホームアドレスを含む独自のアイデンティティ、及び認証値を明らかにする信頼できないネットワークへの認証の拡張インチこれは、いくつかの展開で問題となる場合があります。
Please see [RFC4555] for MOBIKE-related security considerations, and [RFC3519], [RFC3947] for security concerns related to the use of NAT traversal mechanisms for Mobile IPv4 and IPsec.
モバイルIPv4およびIPsec用のNATトラバーサルメカニズムの使用に関連するセキュリティ上の懸念のためにMOBIKE関連のセキュリティの考慮事項については、[RFC4555]、および[RFC3519]、[RFC3947]を参照してください。
The authors would like to thank Henry Haverinen, Sandro Grech, Dhaval Shah, and John Cruz for their participation in developing this solution.
著者は、このソリューションの開発に参加するためにヘンリーHaverinen、サンドロ・グレック、Dhavalシャー、ジョン・クルスに感謝したいと思います。
The authors would also like to thank Henrik Levkowetz, Jari Arkko, TJ Kniveton, Vidya Narayanan, Yaron Sheffer, Hans Sjostrand, Jouni Korhonen, and Sami Vaarala for reviewing the document.
著者らはまた、文書をレビューするためのHenrik Levkowetz、ヤリArkko、TJ Kniveton、Vidyaナラヤナン、ヤロンシェファー、ハンスSjostrand、Jouni Korhonen、およびサミVaaralaに感謝したいと思います。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[RFC3344]パーキンス、C.、 "IPv4のIPモビリティサポート"、RFC 3344、2002年8月。
[RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", RFC 4555, June 2006.
[RFC4555] Eronen、P.、 "IKEv2のモビリティとマルチホーミングプロトコル（MOBIKE）"、RFC 4555、2006年6月。
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306]カウフマン、C.、 "インターネットキーエクスチェンジ（IKEv2の）プロトコル"、RFC 4306、2005年12月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、2005年12月。
[RFC5265] Vaarala, S. and E. Klovning, "Mobile IPv4 Traversal across IPsec-Based VPN Gateways", RFC 5265, June 2008.
"IPSecベースのVPNゲートウェイを横切るモバイルIPv4トラバーサル" [RFC5265] Vaarala、S.及びE. Klovning、RFC 5265、2008年6月。
[RFC4093] Adrangi, F. and H. Levkowetz, "Problem Statement: Mobile IPv4 Traversal of Virtual Private Network (VPN) Gateways", RFC 4093, August 2005.
[RFC4093] Adrangi、F.およびH. Levkowetz、 "問題文：仮想プライベートネットワーク（VPN）ゲートウェイのモバイルIPv4トラバーサル"、RFC 4093、2005年8月。
[RFC3024] Montenegro, G., "Reverse Tunneling for Mobile IP, revised", RFC 3024, January 2001.
[RFC3024]モンテネグロ、G.は、RFC 3024、2001年1月、 "モバイルIPのためのリバーストンネリングは、改訂されました"。
[MEGHANA] Sahasrabudhe, M. and V. Devarapalli, "Optimizations to Secure Connectivity and Mobility", Work in Progress, February 2008.
[MEGHANA] Sahasrabudhe、M.およびV. Devarapalliは、進歩、2008年2月に作業、 "最適化は、接続性とモビリティを確保するために"。
[RFC3519] Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of Network Address Translation (NAT) Devices", RFC 3519, April 2003.
、RFC 3519、2003年4月、 "ネットワークアドレス変換（NAT）デバイスのモバイルIPトラバーサル" [RFC3519] Levkowetz、H.とS. Vaarala、。
[RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, "Negotiation of NAT-Traversal in the IKE", RFC 3947, January 2005.
[RFC3947] Kivinen、T.、Swander、B.、Huttunen、A.、およびV.ボルペ、 "IKEにおけるNATトラバーサルのネゴシエーション"、RFC 3947、2005年1月。
[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月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409]ハーキンとD.とD.カレル、 "インターネットキー交換（IKE）"、RFC 2409、1998年11月。
Appendix A. Applicability to a Mobile Operator Network
モバイルオペレータのネットワークへの付録A.の適用性
The solution described in this document can also be applied to a Mobile Operator's network when the Operator deploys heterogeneous access networks and some of the access networks are considered as trusted networks and others as untrusted networks. Figure 2 illustrates such a network topology.
この文書で説明するソリューションは、オペレータは、異種アクセスネットワークを展開する場合、モバイルオペレータのネットワークに適用することができ、アクセスネットワークの一部は、信頼できるネットワークと信頼できないネットワークなどの他のものと考えられています。図2は、ネットワークトポロジーを示します。
+----------------------+
| +----+ |
+----------------+ | |i-HA| |
| | | +----+ |
(MN)----+ trusted +---+ |
| access network | | internal network |
+----------------+ | |
| |
+----------+-----------+
|
|
|
[mVPN]
+----------------+ |
| | |
(MN)----+ untrusted +--------------+
{mc} | access network |
+----------------+
Figure 2: Network Topology of a Mobile Operator with Trusted and Untrusted Networks
図2：信頼と信頼できないネットワークを持つモバイルオペレータのネットワークトポロジ
An IPsec VPN gateway provides secure connectivity to the Operator's internal network for mobile nodes attached to an untrusted access network. The VPN gateway supports MOBIKE extensions so that the IPsec tunnels survive any IP address change when the mobile node moves while attached to the untrusted access networks.
IPsec VPNゲートウェイは、信頼できないアクセスネットワークに接続する移動ノードのためのオペレータの内部ネットワークへの安全な接続を提供します。とき、移動ノードが移動し、信頼できないアクセスネットワークに接続しながら、IPsecトンネルは、任意のIPアドレスの変更を生き残るように、VPNゲートウェイは、MOBIKE拡張をサポートしています。
When the mobile node is attached to the trusted access network, it uses Mobile IP with the i-HA. It uses the IP address obtained from the trusted access network as the co-located care-of address to register with the i-HA. If a foreign agent is available in the trusted access network, the mobile node may use a foreign agent care-of address. If the mobile node moves and attaches to an untrusted access network, it sets up an IPsec tunnel with the VPN gateway to access the Operator's internal network. It uses the IPsec TIA as the co-located care-of address to register with the i-HA thereby creating a Mobile IP tunnel inside an IPsec tunnel.
モバイルノードが信頼できるアクセスネットワークに接続されている場合、それがi-HAとモバイルIPを使用しています。これは、同じ場所に配置さ気付アドレスI-HAに登録するなどの信頼できるアクセスネットワークから取得したIPアドレスを使用しています。外国人のエージェントは、信頼できるアクセスネットワークで利用可能な場合、モバイルノードは、外部エージェントの気付アドレスを使用することができます。モバイルノードが移動する場合と、信頼できないアクセスネットワークにアタッチし、それはオペレータの内部ネットワークにアクセスするためにVPNゲートウェイとのIPsecトンネルを設定します。これは、同じ場所に配置さ気付アドレスI-HAは、それによって、IPsecトンネル内のモバイルIPトンネルを作成して登録するようにIPsec TIAを使用します。
When the mobile node is attached to the trusted access network, it can either be attached to a foreign link in the trusted network or to the home link directly. This document does not impose any restrictions.
モバイルノードが信頼できるアクセスネットワークに接続されている場合は、どちらかの信頼できるネットワークまたは直接ホームリンクへの外部リンクに接続することができます。この文書では、制限はありません。
Authors' Addresses
著者のアドレス
Vijay Devarapalli Wichorus 3590 North First Street San Jose, CA 95134 USA
ビジェイDevarapalli Wichorus 3590北まずストリートサンノゼ、CA 95134 USA
EMail: vijay@wichorus.com
メールアドレス：vijay@wichorus.com
Pasi Eronen Nokia Research Center P.O. Box 407 FIN-00045 Nokia Group Finland
ノキア・リサーチセンター私書箱のパシEronenボックス407 FIN-00045 Nokiaのグループフィンランド
EMail: pasi.eronen@nokia.com
メールアドレス：pasi.eronen@nokia.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（2008）。
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に情報を記述してください。