[要約] RFC 5266は、Mobile IPv4とIKEv2 Mobility and Multihoming（MOBIKE）を使用した安全な接続性とモビリティに関する規格です。このRFCの目的は、モバイルデバイスのセキュアな接続と移動性を実現するための手法を提供することです。
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)
モバイルIPv4およびIKEV2モビリティとマルチホミング（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.
このドキュメントは、インターネットコミュニティのインターネットの最良のプラクティスを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
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アドレスを取得する場合に有益です。このドキュメントでは、モバイルIPv4（MIPV4）とIKEV2（Mobike）へのモビリティ拡張を使用して、安全な接続性とモビリティを提供するソリューションについて説明します。
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 VPNSの使用は、イントラネットへのこのような安全な接続を可能にするために非常に一般的です。ユーザーが信頼できるネットワーク上にいる場合、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.
モバイルIPv4およびIPSEC VPNSを使用して、ローミングとエンタープライズへの安全性のある接続を提供するためにいくつかの作業が行われています[RFC5265] [RFC4093]。[RFC5265]に記載されているソリューションは、VPNゲートウェイの変更を必要とせずに特定の制限で設計されており、MIPV4の2層の使用を伴い、イントラネット内に1つのホームエージェントが、1つはインターネット内またはDMZの前に1つのホームエージェントを使用します。VPNゲートウェイ。このソリューションでは、パケットごとのオーバーヘッドが非常に高くなっています。また、モバイルノードで同時にMIPV4の2つのインスタンスを実装し、2つのインスタンスをアクティブにすることも困難です。ただし、ここで説明するソリューションは、Internet Key Exchange Protocolバージョン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.
このドキュメントでは、2層のMIPV4を必要としない代替ソリューションについて説明します。このドキュメントで説明されているソリューションでは、モバイルノードが信頼できるネットワーク上にあるときにモバイルIPv4とモバイクに対応するIPSEC VPNSが不信感のないネットワーク上にあるときにMobike対応のIPSEC VPNを使用します。モバイルノードは、IPSEC VPNゲートウェイによって与えられたトンネル内側アドレス（TIA）を、MIPV4登録の共同配置されたケアオブアドレス（COA）として使用します。これにより、外部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].
o VPNゲートウェイとモバイルノードは、[RFC4555]で定義されているMobike Extensionsをサポートします。
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では必要ありません。
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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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.
Co-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
F：FA-CoaでiMip
c: i-MIP with Co-CoA
C：CO-COAでIMIP
mc: i-MIP with MOBIKE-enabled VPN, with VPN-TIA as Co-CoA
MC：Mobike対応のVPNを使用して、VPN-TIAを共同CoAとしてマップします
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トンネルを設定します。ただし、I-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.
モバイルノードがエンタープライズの外側で移動し、アクセスネットワークが変更された場合、Mobikeプロトコルを使用して、現在のアドレスのVPNゲートウェイを更新します。内部ホームエージェントは、モバイルノードが同じ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.
このアクセスモードでは、モバイルIPv4とMobike対応のIPSEC VPNゲートウェイの両方を使用して、IPSECトンネル内にモバイルIPトンネルが作成されます。モバイルノードは、VPN-TIAをホームエージェントに登録するための共同配置COAとして使用します。このモードは、モバイルノードが信頼されていないネットワークに接続されている場合にのみ使用され、信頼できるネットワークにアクセスするために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アドレスが変更された場合、Mobikeプロトコル[RFC4555]を開始して、VPNゲートウェイのアドレスを更新します。
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.
モバイルノードは、エンタープライズネットワークの外側にある場合でも、ホームエージェントのバインディングを維持します。モバイルノードがVPNゲートウェイに再接続するか、別のVPNゲートウェイに接続するためにTIAが変更された場合、モバイルノードはホームエージェントに登録要求を送信して、新しい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トンネルがある場合、IPアドレスが変更されるたびにi-HAに登録要求と同時にMobikeメッセージを送信する必要があります。モバイルノードがI-HAからではなくVPNゲートウェイから応答を受信した場合、エンタープライズネットワークの外側にあると仮定します。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ゲートウェイを備えたIPSEC VPNトンネルと、VPN-TIAのイントラネットのホームエージェントとの有効な登録があります。住所。
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。IKEモビリティ交換を開始して、現在のアドレスでVPNゲートウェイを更新します。新しいネットワークも信頼されていない場合、これは接続をセットアップするのに十分です。新しいネットワークが信頼されており、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.
2. モバイルノードがステップ1Bで送信されたリクエストへの登録返信を受信した場合、現在のサブネットは信頼できるサブネットであり、モバイルノードはVPNトンネリングなしで通信できます。モバイルノードは、VPNトンネルを取り壊す場合があります。
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. IKE Mobility Exchangeを開始して、現在のアドレスでVPNゲートウェイを更新するか、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.
3. モバイルノードがステップ2で送信されたリクエストへの登録返信を受信した場合、現在のサブネットは信頼できるサブネットであり、モバイルノードは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」。[RFC3519]に記載されているように、モバイルIPv4 NATトラバーサルは、NATデバイスが存在する場合、モバイルノードとアクセスモード「C '」または「F」でモバイルノードとホームエージェントが使用する必要があります。アクセスモード「MC」を使用する場合、IPSEC NAT Traversal [RFC3947] [RFC3948]は、NATデバイスが存在する場合は、モバイルノードと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.
モバイル関連のセキュリティに関する考慮事項については[RFC 4555]、およびモバイルIPv4およびIPSECのNATトラバーサルメカニズムの使用に関連するセキュリティの懸念については[RFC 3519]、[RFC 3947]を参照してください。
The authors would like to thank Henry Haverinen, Sandro Grech, Dhaval Shah, and John Cruz for their participation in developing this solution.
著者は、このソリューションの開発に参加してくれたHenry Haverinen、Sandro Grech、Dhaval Shah、John Cruzに感謝したいと思います。
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、Jari Arkko、Tj Kniveton、Vidya Narayanan、Yaron Sheffer、Hans Sjostrand、Jouni Korhonen、Sami Vaaralaにも感謝したいと思います。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[RFC3344] Perkins、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] Kaufman、C。、「Internet Key Exchange（IKEV2）プロトコル」、RFC 4306、2005年12月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent、S。およびK. SEO、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[RFC5265] Vaarala, S. and E. Klovning, "Mobile IPv4 Traversal across IPsec-Based VPN Gateways", RFC 5265, June 2008.
[RFC5265] Vaarala、S。およびE. Klovning、「IPSECベースのVPNゲートウェイ全体のモバイルIPv4トラバーサル」、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。、「モバイルIPの逆トンネル、改訂版」、RFC 3024、2001年1月。
[MEGHANA] Sahasrabudhe, M. and V. Devarapalli, "Optimizations to Secure Connectivity and Mobility", Work in Progress, February 2008.
[Meghana] Sahasrabudhe、M。and V. Devarapalli、「接続性とモビリティを保護するための最適化」、2008年2月、進行中の作業。
[RFC3519] Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of Network Address Translation (NAT) Devices", RFC 3519, April 2003.
[RFC3519] Levkowetz、H。およびS. Vaarala、「ネットワークアドレス変換（NAT）デバイスのモバイルIPトラバーサル」、RFC 3519、2003年4月。
[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. Volpe、「IKEにおけるNat-Traversalの交渉」、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.、Volpe、V.、Diburro、L。、およびM. Stenberg、「IPSEC ESPパケットのUDPカプセル化」、RFC 3948、2005年1月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409] Harkins、D。およびD. Carrel、「The Internet Key Exchange（IKE）」、RFC 2409、1998年11月。
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ゲートウェイは、信頼できないアクセスネットワークに接続されたモバイルノードのオペレーターの内部ネットワークへの安全な接続を提供します。VPNゲートウェイはMobike Extensionsをサポートしているため、IPSECトンネルは、信頼できないアクセスネットワークに取り付けられている間にモバイルノードが移動すると、IPアドレスが変更されます。
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を使用します。信頼できるAccessネットワークから取得したIPアドレスを、共同住宅のケアオブアドレスとして使用して、I-HAに登録します。信頼できるアクセスネットワークで外国人エージェントが利用可能な場合、モバイルノードは外国のエージェントケアオブアドレスを使用する場合があります。モバイルノードが移動して信頼されていないアクセスネットワークに接続すると、VPNゲートウェイを備えたIPSECトンネルを設定して、オペレーターの内部ネットワークにアクセスします。IPSEC TIAを共同配置されたケアオブアドレスとして使用して、I-HAに登録し、IPSECトンネル内にモバイルIPトンネルを作成します。
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
Vijay Devarapalli Wichorus 3590 North First Street San Jose、CA 95134 USA
EMail: vijay@wichorus.com
Pasi Eronen Nokia Research Center P.O. Box 407 FIN-00045 Nokia Group Finland
Pasi Eronen Nokia Research Center P.O.Box 407 Fin-00045 Nokia Group Finland
EMail: pasi.eronen@nokia.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。