RFC4977 日本語訳

Network Working Group                                        G. Tsirtsis
Request for Comments: 4977                                      Qualcomm
Category: Informational                                       H. Soliman
                                                    Elevate Technologies
                                                             August 2007

Tsirtsisがコメントのために要求するワーキンググループG.をネットワークでつないでください: 4977年のクアルコムカテゴリ: 情報のH.ソリマンは2007年8月に技術を上げます。

                 Problem Statement: Dual Stack Mobility

問題声明: デュアルスタックの移動性

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.

このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。

Abstract

要約

   This document discusses the issues associated with mobility
   management for dual stack mobile nodes.  Currently, two mobility
   management protocols are defined for IPv4 and IPv6.  Deploying both
   in a dual stack mobile node introduces a number of problems.
   Deployment and operational issues motivate the use of a single
   mobility management protocol.  This document discusses such
   motivations.  The document also discusses requirements for the Mobile
   IPv4 (MIPv4) and Mobile IPv6 (MIPv6) protocol so that they can
   support mobility management for a dual stack node.

このドキュメントはデュアルスタックモバイルノードのための移動性管理に関連している問題について議論します。 現在、2つの移動性管理プロトコルがIPv4とIPv6のために定義されます。 デュアルスタックモバイルノードで両方を配布すると、多くの問題が紹介されます。展開と操作上の問題はただ一つの移動性管理プロトコルの使用を動機づけます。 このドキュメントはそのような動機について議論します。 また、ドキュメントは、移動性がデュアルスタックノードのための管理であるとサポートすることができるようにモバイルIPv4(MIPv4)とモバイルIPv6(MIPv6)プロトコルのための要件について議論します。

Table of Contents

目次

   1.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 2
   2.  Introduction and Motivation . . . . . . . . . . . . . . . . . . 2
   3.  Problem Description . . . . . . . . . . . . . . . . . . . . . . 3
     3.1.  The Impossibility of Maintaining IP Connectivity  . . . . . 4
     3.2.  Implementation Burdens  . . . . . . . . . . . . . . . . . . 4
     3.3.  Operational Burdens . . . . . . . . . . . . . . . . . . . . 4
     3.4.  Mobility Management Inefficiencies  . . . . . . . . . . . . 4
     3.5.  IPv4 to IPv6 Transition Mechanisms  . . . . . . . . . . . . 5
   4.  Conclusions and Recommendations . . . . . . . . . . . . . . . . 5
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
     6.1.  Normative References  . . . . . . . . . . . . . . . . . . . 6
     6.2.  Informative References  . . . . . . . . . . . . . . . . . . 6

1. 用語. . . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 序論と動機. . . . . . . . . . . . . . . . . . 2 3。 問題記述. . . . . . . . . . . . . . . . . . . . . . 3 3.1。 IPの接続性. . . . . 4 3.2を維持する不可能。 実装負担. . . . . . . . . . . . . . . . . . 4 3.3。 操作上の負担. . . . . . . . . . . . . . . . . . . . 4 3.4。 移動性管理非能率. . . . . . . . . . . . 4 3.5。 IPv6変遷メカニズム. . . . . . . . . . . . 5 4へのIPv4。 結論と推薦. . . . . . . . . . . . . . . . 5 5。 セキュリティ問題. . . . . . . . . . . . . . . . . . . . 6 6。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 6 6.1。 引用規格. . . . . . . . . . . . . . . . . . . 6 6.2。 有益な参照. . . . . . . . . . . . . . . . . . 6

Tsirtsis & Soliman           Informational                      [Page 1]

RFC 4977         Problem Statement: Dual Stack Mobility      August 2007

Tsirtsisとソリマンの情報[1ページ]のRFC4977問題声明: デュアルスタック移動性2007年8月

1.  Terminology

1. 用語

   This document uses the following terms as defined in Stateless IP/
   ICMP Translation (SIIT) [RFC2765]: IPv4-capable node, IPv4-enabled
   node, IPv6-capable node, IPv6-enabled node.

このドキュメントはStateless IP/ICMP Translation(SIIT)[RFC2765]で定義されるように次の用語を使用します: IPv4できるノード(IPv4によって可能にされたノード、IPv6できるノード)はノードをIPv6可能にしました。

   The following terms are introduced in this document:

次の用語は本書では紹介されます:

   - MIPv4-capable node:

- MIPv4できるノード:

      A node that supports MIPv4 [RFC3344] in its implementation.  This
      allows the mobile node to configure a home address (statically or
      dynamically) and use such address in its Mobile IPv4 signaling.  A
      MIPv4-capable node may also be IPv6-capable or IPv6-enabled and
      must be IPv4-capable.

実装でMIPv4[RFC3344]を支えるノード。 これで、モバイルノードは、ホームアドレス(静的かダイナミックである)を構成して、モバイルIPv4シグナリングにそのようなアドレスを使用します。 MIPv4できるノードは、また、IPv6できるかIPv6が可能にされるかもしれなくて、IPv4できなければなりません。

   - MIPv6-capable node:

- MIPv6できるノード:

      A node that supports MIPv6 [RFC3775] by configuring a home address
      and using such address in its Mobile IPv6 signaling.  A MIPv6-
      enabled node may also be IPv4-capable or IPv4-enabled and must be
      IPv6-capable.

モバイルIPv6シグナリングにホームアドレスを構成して、そのようなアドレスを使用することによってMIPv6[RFC3775]を支えるノード。 MIPv6の可能にされたノードは、また、IPv4できるかIPv4が可能にされるかもしれなくて、IPv6できなければなりません。

2.  Introduction and Motivation

2. 序論と動機

   A MIPv4-capable node can use Mobile IPv4 [RFC3344] to maintain
   connectivity while moving between IPv4 subnets.  Similarly, a MIPv6-
   capable node can use Mobile IPv6 [RFC3775] to maintain connectivity
   while moving between IPv6 subnets.

MIPv4できるノードは、IPv4サブネットの間で移行している間、接続性を維持するのに、モバイルIPv4[RFC3344]を使用できます。 同様に、MIPv6のできるノードは、IPv6サブネットの間で移行している間、接続性を維持するのに、モバイルIPv6[RFC3775]を使用できます。

   One of the ways of migrating to IPv6 is to deploy nodes that are both
   IPv4 and IPv6 capable.  Such nodes will be able to get both IPv4 and
   IPv6 addresses and thus can communicate with the current IPv4
   Internet as well as any IPv6 nodes and networks as they become
   available.

IPv6にわたる方法の1つはIPv4とIPv6のできる両方であるノードを配布することです。 そのようなノードは、IPv4とIPv6アドレスの両方を得ることができて、その結果、利用可能になるのに応じて、どんなIPv6ノードとネットワークと同様に現在のIPv4インターネットで交信できます。

   A node that is both IPv4 and IPv6 capable can use Mobile IPv4 for its
   IPv4 stack and Mobile IPv6 for its IPv6 stack so that it can move
   between IPv4 and IPv6 subnets.  While this is possible, it does not
   ensure connectivity since that also depends on the IP version support
   of the network accessed.  Supporting Mobile IPv4 and Mobile IPv6 is
   also more inefficient since it requires:

IPv4とIPv6のできる両方であるノードは、IPv4とIPv6サブネットの間で移行できるようにIPv4スタックのためのモバイルIPv4とIPv6スタックのためのモバイルIPv6を使用できます。 これが可能である間、また、それがネットワークのサポートがアクセスしたIPバージョンによるので、それは接続性を確実にしません。 また、以下を必要とするので、モバイルIPv4とモバイルIPv6をサポートするのも、より効率が悪いです。

Tsirtsis & Soliman           Informational                      [Page 2]

RFC 4977         Problem Statement: Dual Stack Mobility      August 2007

Tsirtsisとソリマンの情報[2ページ]のRFC4977問題声明: デュアルスタック移動性2007年8月

   -  Mobile nodes to be both MIPv4 and MIPv6 capable.

- MIPv4とMIPv6のできる両方であるモバイルノード。

   -  Mobile nodes to send two sets of signaling messages on every
      handoff.

- 2セットのシグナリングメッセージをあらゆる移管に送るモバイルノード。

   -  Network Administrators to run and maintain two sets of mobility
      management systems on the same network, with each of these systems
      requiring its own set of optimizations.

- それぞれのこれらのシステムがそれ自身のセットに最適化を要求している同じネットワークで2セットの移動性マネージメントシステムをAdministratorsをネットワークでつないで、動かして、維持してください。

   This document discusses the potential inefficiencies, IP connectivity
   problems, and operational issues that are evident when running both
   mobility management protocols simultaneously.  It also proposes a
   work area to be taken up by the IETF on the subject and discusses
   requirements for appropriate solutions.

このドキュメントは同時に両方の移動性管理プロトコルを実行するとき明白な潜在的非能率、IP接続性問題、および操作上の問題について議論します。 それは、また、話題の上のIETFによって始められるように作業領域を提案して、適切なソリューションのために要件について議論します。

3.  Problem Description

3. 問題記述

   Mobile IP (v4 and v6) uses a signaling protocol (Registration
   requests in MIPv4 [RFC3344] and Binding updates in MIPv6 [RFC3775])
   to set up tunnels between two end points.  At the moment, Mobile IP
   signaling is tightly coupled to the address family (i.e., IPv4 or
   IPv6) used, in the connections it attempts to manipulate.  There are
   no fundamental technical reasons for such coupling.  If Mobile IP
   were viewed as a tunnel-setup protocol, it should be able to set up
   IP in IP tunnels, independently of the IP version used in the outer
   and inner headers.  Other protocols -- for example, SIP [RFC3261] --
   are able to use either an IPv4- or IPv6-based signaling plane to
   manipulate IPv4 and IPv6 connections.

モバイルIP(v4とv6)は、2つのエンドポイントの間のトンネルを設立するのに、シグナリングプロトコル(MIPv4での登録要求[RFC3344]とMIPv6でのBindingアップデート[RFC3775])を使用します。 現在、モバイルIPシグナリングは(すなわち、IPv4かIPv6)が使用したアドレスファミリーへの密結合です、それが操るのを試みる接続で。 そのようなカップリングのどんな基本的な技術的な理由もありません。 モバイルIPがトンネルセットアッププロトコルとして見なされるなら、IPトンネルにIPを設立できるでしょうに、外側の、そして、内側のヘッダーで使用されるIPバージョンの如何にかかわらず。 他のプロトコル(例えば、SIP[RFC3261])は、IPv4とIPv6接続を操作するのにIPv4かIPv6ベースのシグナリング飛行機を使用できます。

   A node that is both MIPv4 and MIPv6 capable, will require the
   following to roam within the Internet:

MIPv4とMIPv6ともにできて、インターネットの中を移動するために以下を必要とするということであるノード:

   -  The network operator needs to ensure that the home agent supports
      both protocols or that it has two separate Home Agents supporting
      the two protocols, each requiring its own management.

- ネットワーク・オペレータは、ホームのエージェントが両方のプロトコルをサポートするか、または2人の別々のホームのエージェントがそれで2つのプロトコルをサポートするのを保証する必要があります、それぞれそれ自身の管理を必要として。

   -  Double the amount of configuration in the mobile node and the home
      agent (e.g., security associations).

- モバイルノードとホームのエージェント(例えば、セキュリティ協会)の構成の量を倍にしてください。

   -  IP-layer local network optimizations for handovers will also need
      to be duplicated.

- また、身柄の引き渡しのためのIP-層の企業内情報通信網最適化は、コピーされる必要があるでしょう。

   We argue that all of the above will make the deployment of Mobile
   IPv6, as well as any dual stack solution in a mobile environment,
   harder.  We will discuss some of the issues with the current approach
   separately in the following sections.

私たちは、上記のすべてがモバイルIPv6の展開をすると主張します、モバイル環境におけるどんなデュアルスタック解決と同様に、より困難です。 私たちは別々に以下のセクションで現在のアプローチの問題のいくつかについて議論するつもりです。

Tsirtsis & Soliman           Informational                      [Page 3]

RFC 4977         Problem Statement: Dual Stack Mobility      August 2007

Tsirtsisとソリマンの情報[3ページ]のRFC4977問題声明: デュアルスタック移動性2007年8月

3.1.  The Impossibility of Maintaining IP Connectivity

3.1. IPの接続性を維持する不可能

   Even if a mobile node is both MIPv4 and MIPv6 capable, connectivity
   across different networks would not, in fact, be guaranteed since
   that also depends on the IPv4/IPv6 capabilities of the networks the
   mobile is visiting; i.e., a node attempting to connect via a IPv4-
   only network would not be able to maintain connectivity of its IPv6
   applications and vice versa.  This is potentially the most serious
   problem discussed in this document.

モバイルノードがMIPv4とMIPv6のできる両方であっても、事実上、異なったネットワークの向こう側の接続性はまた、それがネットワークのIPv4/IPv6能力によるのでモバイルが訪問されているのが保証されないでしょう。 すなわち、IPv4だけネットワークを通して接続するのを試みるノードは逆もまた同様にIPv6アプリケーションの接続性を維持できないでしょう。 これは潜在的に本書では議論する中で最も重大な問題です。

3.2.  Implementation Burdens

3.2. 実装負担

   As mentioned above, a node that is IPv4 and IPv6 capable must also be
   MIPv4 and MIPv6 capable to roam within the Internet.  The ability to
   employ both IP versions from one mobility protocol makes it possible
   to implement just that one protocol, assuming the protocol choice is
   known.  However, in situations where the mobile node must be capable
   of working in any network, it may still need two protocols.

以上のように、また、IPv4とできるIPv6であるノードは、インターネットの中を移動できるMIPv4とMIPv6であるに違いありません。 1つの移動性プロトコルから両方のIPバージョンを使う能力でそれがプロトコルであると実装するのが可能になります、プロトコル選択が知られていると仮定して。 しかしながら、モバイルノードがどんなネットワークでも働くことができなければならない状況で、それはまだ2つのプロトコルを必要とするかもしれません。

3.3.  Operational Burdens

3.3. 操作上の負担

   As mentioned earlier, deploying both protocols will require managing
   both protocols in the mobile node and the home agent.  This adds
   significant operational issues for the network operator.  It would
   certainly require the network operator to have deep knowledge in both
   protocols, which is something an operator may not be able to justify
   due to the lack of substantial gains.

先に述べたように、両方のプロトコルを配布するのは、モバイルノードのプロトコルとホームのエージェントの両方を管理するのを必要とするでしょう。 これはネットワーク・オペレータのために重要な操作上の問題を加えます。 確かに、両方のプロトコルの深い知識を持っているのがネットワーク・オペレータを必要とするでしょう。(知識はオペレータが相当な利益の不足のため正当化できないかもしれない何かです)。

   In addition, deploying both protocols will require duplication of
   security credentials on mobile nodes and home agents.  This includes
   IPsec security associations, keying material, and new authentication
   protocols for Mobile IPv6, in addition to the security credentials
   and associations required by Mobile IPv4.  Depending on the security
   mechanisms used and with some further work, it might be possible to
   rely on one set of common credentials.  Assuming nothing else
   changes, however, such duplication is again significant with no gain
   to the operator or the mobile node.

さらに、両方のプロトコルを配布するのはモバイルノードとホームのエージェントにおけるセキュリティー証明書の複製を必要とするでしょう。 材料を合わせて、これはIPsecセキュリティ協会を含んでいます、そして、セキュリティー証明書と協会に加えたモバイルIPv6のための新しい認証プロトコルがモバイルIPv4が必要です。 メカニズムが使用したセキュリティとさらなるいくらかの仕事でよって、1セットの一般的な資格証明書を当てにするのは可能であるかもしれません。 他に何もを仮定するのは変化して、しかしながら、そのような複製は再び、オペレータかモバイルノードに利得のないかなりです。

3.4.  Mobility Management Inefficiencies

3.4. 移動性管理非能率

   Suppose that a mobile node is moving within a dual stack access
   network.  Every time the mobile node moves, it needs to send two
   mobile IP messages to its home agent to allow its IPv4 and IPv6
   connections to survive.  There is no reason for such duplication.  If
   local mobility optimizations were deployed (e.g., Hierarchical Mobile
   IPv6 (HMIPv6) [RFC4140], Fast handovers for Mobile IPv4 [RFC4068]),
   the mobile node will need to update the local agents running each
   protocol.  Ironically, one local agent might be running both HMIPv6

モバイルノードがデュアルスタックアクセスネットワークの中で移行していると仮定してください。 モバイルノードが移行するときはいつも、それは、IPv4とIPv6接続が乗り切るのを許容するホームのエージェントに2つのモバイルIPメッセージを送る必要があります。 そのような複製の理由が全くありません。 地方の移動性最適化が配布されたなら(例えば、HierarchicalのモバイルIPv6(HMIPv6)[RFC4140]、FastはモバイルIPv4のために[RFC4068]を引き渡します)、モバイルノードは、各プロトコルを実行する地元のエージェントをアップデートする必要があるでしょう。 皮肉にも、1人の地元のエージェントは稼働の両方がHMIPv6であるならそうするでしょうに。

Tsirtsis & Soliman           Informational                      [Page 4]

RFC 4977         Problem Statement: Dual Stack Mobility      August 2007

Tsirtsisとソリマンの情報[4ページ]のRFC4977問題声明: デュアルスタック移動性2007年8月

   and local MIPv4 home agent.  Clearly, it is not desirable to have to
   send two messages and complete two sets of transactions for the same
   fundamental optimization.

そして、地元のMIPv4ホームのエージェント。 明確に、同じ基本的な最適化のために2つのメッセージと完全な2セットのトランザクションを送らなければならないのは望ましくはありません。

   Hence, such parallel operation of Mobile IPv4 and Mobile IPv6 will
   complicate mobility management within the Internet and increase the
   amount of bandwidth needed at the critical handover time for no
   apparent gain.

したがって、モバイルIPv4とモバイルIPv6のそのような並列操作は、どんな見かけの利得のためにもインターネットの中で移動性管理を複雑にして、重要な引き渡し時に必要であった帯域幅の量を増強しないでしょう。

3.5.  IPv4 to IPv6 Transition Mechanisms

3.5. IPv6変遷メカニズムへのIPv4

   The IETF has standardized a number of transition mechanisms to allow
   networks and end nodes to gain IPv6 connectivity while the Internet
   is migrating from IPv4 to IPv6.  However, while some transition
   mechanisms can be combined with Mobile IPv4 or Mobile IPv6, none of
   the known mechanisms have been shown to assist with the issues
   described in this document.

インターネットがIPv4からIPv6まで移行している間、IETFは、ネットワークとエンドノードがIPv6の接続性を獲得するのを許容するために多くの変遷メカニズムを標準化しています。 しかしながら、モバイルIPv4かモバイルIPv6にいくつかの変遷メカニズムを結合できる間、知られているメカニズムのいずれも、本書では説明された問題を助けるために見せられていません。

4.  Conclusions and Recommendations

4. 結論と推薦

   The points above highlight the tight coupling in both Mobile IPv4 and
   Mobile IPv6 between signaling and the IP addresses used by upper
   layers.  Given that Mobile IPv4 is currently deployed and Mobile IPv6
   is expected to be deployed, there is a need for gradual transition
   from IPv4 mobility management to IPv6.  Running both protocols
   simultaneously is inefficient and has the problems described above.
   The gradual transition can be done when needed or deemed appropriate
   by operators or implementers.  In the meantime, it is important to
   ensure that the problems listed above can be avoided.  Hence, this
   section lists some actions that should be taken by the IETF to
   address the problems listed above, without mandating the use of two
   mobility management protocols simultaneously.

モバイルIPv4とシグナリングの間のモバイルIPv6の両方の密結合とIPアドレスが上側の層で使用したハイライトを超えたポイント。 モバイルIPv4が現在、配布されて、モバイルIPv6が配布されると予想されるなら、ゆるやかなIPv4移動性管理からIPv6までの変遷の必要があります。 同時に両方のプロトコルを実行するのは、効率が悪く、上で説明された問題を持っています。 オペレータかimplementersが、必要である、または適切であると考えると、ゆるやかな変化ができます。 差し当たり、上に記載された問題は避けることができるのを保証するのが重要です。 したがって、このセクションは上に記載されたその問題を訴えるためにIETFによって取られるはずであるいくつかの行動を記載します、同時に2つの移動性管理プロトコルの使用を強制しないで。

   The Mobile IPv6 Working Group has reached the view that to allow for
   a gradual transition based on current standards and deployment, the
   following work areas would be reasonable:

モバイルIPv6作業部会は現在の規格と展開、以下の作業領域に基づくゆるやかな変遷を考慮するのが妥当であるだろうという意見に達しました:

   -  It should be possible to run one mobility management protocol that
      can manage mobility for both IPv4 and IPv6 addresses used by upper
      layers.  Both Mobile IPv4 and Mobile IPv6 should be able to
      perform such tasks.  It may not be possible to support route
      optimization for Mobile IPv6 in all cases; however, mobility
      management and session continuity can be supported.

- 上側の層によって使用されるIPv4とIPv6アドレスの両方のために移動性に対処できる1つの移動性管理プロトコルを実行するのは可能であるべきです。 モバイルIPv4とモバイルIPv6の両方がそのようなタスクを実行できるべきです。 モバイルIPv6のためにすべての場合で経路最適化をサポートするのは可能でないかもしれません。 しかしながら、移動性管理とセッションの連続をサポートすることができます。

   -  It should be possible to create IPv4 extensions to Mobile IPv6 so
      that an IPv4 and IPv6 capable mobile node can register its IPv4
      and IPv6 home addresses to an IPv4- and IPv6-enabled Home Agent
      using MIPv6 signaling only.

- IPv4拡張子をモバイルIPv6に作成するのは、IPv4とIPv6のできるモバイルノードがMIPv6シグナリングだけを使用することでIPv4とIPv6によって可能にされたホームのエージェントにIPv4とIPv6ホームアドレスを登録できるくらい可能であるべきです。

Tsirtsis & Soliman           Informational                      [Page 5]

RFC 4977         Problem Statement: Dual Stack Mobility      August 2007

Tsirtsisとソリマンの情報[5ページ]のRFC4977問題声明: デュアルスタック移動性2007年8月

   -  It should be possible to create IPv6 extensions to Mobile IPv4 so
      that an IPv4 and IPv6 capable mobile node can register its IPv4
      and IPv6 home addresses to an IPv4- and IPv6-enabled Home Agent
      using Mobile IPv4 signaling only.

- IPv6拡張子をモバイルIPv4に作成するのは、IPv4とIPv6のできるモバイルノードがモバイルIPv4シグナリングだけを使用することでIPv4とIPv6によって可能にされたホームのエージェントにIPv4とIPv6ホームアドレスを登録できるくらい可能であるべきです。

   -  It should also be possible to extend MIPv4 [RFC3344] and MIPv6
      [RFC3775] so that a mobile node can register a single care-of
      address (IPv4 or IPv6) to which IPv4 and/or IPv6 packets can be
      tunneled.

- また、モバイルノードがシングルを示すことができるくらいMIPv4[RFC3344]とMIPv6[RFC3775]を広げるのも可能であるべきである、注意、-、IPv4、そして/または、IPv6パケットにトンネルを堀ることができる(IPv4かIPv6)を扱ってください。

   If the IETF chooses to pursue all these paths, a vendor could choose
   to support one mobility management protocol while avoiding the
   incompatibility and inefficiency problems listed in this document.
   Similarly, operators could decide to continue using one mobility
   management protocol throughout the period of IPv4 and IPv6
   coexistence.  However, a mobile node would be forced to choose one
   approach or the other, or nevertheless to install both and use one or
   the other according to circumstances.

IETFが、これらのすべての経路を追求するのを選ぶなら、ベンダーは、不一致を避けている間の1つの移動性管理プロトコルと非能率が本書では記載された問題であるとサポートするのを選ぶかもしれません。 同様に、オペレータは、IPv4とIPv6共存の一区切りの間中1つの移動性管理プロトコルを使用し続けていると決めることができました。 しかしながら、モバイルノードはそれにもかかわらず、1つのアプローチかもう片方を選ぶか、両方をインストールして、または場合によって1かもう片方を使用するのが強制されるでしょう。

5.  Security Considerations

5. セキュリティ問題

   This document is a problem statement that does not by itself
   introduce any security issues.

このドキュメントは少しの安全保障問題も紹介しない問題声明自体です。

6.  References

6. 参照

6.1.  Normative References

6.1. 引用規格

   [RFC2765]  Nordmark, E., "Stateless IP/ICMP Translation Algorithm
              (SIIT)", RFC 2765, February 2000.

[RFC2765] Nordmark、E.、「状態がないIP/ICMP変換アルゴリズム(SIIT)」、RFC2765、2000年2月。

   [RFC3344]  Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
              August 2002.

[RFC3344] パーキンス、C.、「IPv4"、RFC3344、2002年8月のIP移動性サポート。」

   [RFC3775]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
              in IPv6", RFC 3775, June 2004.

[RFC3775] ジョンソンとD.とパーキンス、C.とJ.Arkko、「IPv6"、RFC3775、2004年6月の移動性サポート。」

6.2.  Informative References

6.2. 有益な参照

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              June 2002.

[RFC3261] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。

   [RFC4068]  Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068,
              July 2005.

[RFC4068]Koodli(R.)は「速く、モバイルIPv6"、RFCのために、4068、2005年7月を引き渡します」。

Tsirtsis & Soliman           Informational                      [Page 6]

RFC 4977         Problem Statement: Dual Stack Mobility      August 2007

Tsirtsisとソリマンの情報[6ページ]のRFC4977問題声明: デュアルスタック移動性2007年8月

   [RFC4140]  Soliman, H., Castelluccia, C., El Malki, K., and L.
              Bellier, "Hierarchical Mobile IPv6 Mobility Management
              (HMIPv6)", RFC 4140, August 2005.

[RFC4140]ソリマン、H.、Castelluccia、C.、高架鉄道Malki、K.、およびL.Bellier、「階層的なモバイルIPv6移動性管理(HMIPv6)」、RFC4140 2005年8月。

Authors' Addresses

作者のアドレス

   George Tsirtsis
   Qualcomm

ジョージTsirtsisクアルコム

   Phone: +908-443-8174
   EMail: tsirtsis@qualcomm.com

以下に電話をしてください。 +908-443-8174はメールされます: tsirtsis@qualcomm.com

   Hesham Soliman
   Elevate Technologies

Heshamソリマンは技術を上げます。

   Phone: +614-111-410-445
   EMail: hesham@elevatemobile.com

以下に電話をしてください。 +614-111-410-445 メールしてください: hesham@elevatemobile.com

Tsirtsis & Soliman           Informational                      [Page 7]

RFC 4977         Problem Statement: Dual Stack Mobility      August 2007

Tsirtsisとソリマンの情報[7ページ]のRFC4977問題声明: デュアルスタック移動性2007年8月

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に情報を記述してください。

Tsirtsis & Soliman           Informational                      [Page 8]

TsirtsisとソリマンInformationalです。[8ページ]