この文書はRFC3374の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
Network Working Group J. Kempf, Ed.
Request for Comments: 3374 September 2002
Category: Informational
Problem Description: Reasons For Performing Context Transfers
Between Nodes in an IP Access Network
問題記述：ＩＰアクセスネットワークでノード間の状況転送をする行う理由
Status of this Memo
この文書の状態
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
このメモはインターネット共同体のための情報を供給します。これはインター
ネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
概要
In IP access networks that support host mobility, the routing paths
between the host and the network may change frequently and rapidly.
In some cases, the host may establish certain context transfer
candidate services on subnets that are left behind when the host
moves. Examples of such services are Authentication, Authorization,
and Accounting (AAA), header compression, and Quality of Service
(QoS). In order for the host to obtain those services on the new
subnet, the host must explicitly re-establish the service by
performing the necessary signaling flows from scratch. In some
cases, this process would considerably slow the process of
establishing the mobile host on the new subnet. An alternative is to
transfer information on the existing state associated with these
services, or context, to the new subnet, a process called "context
transfer". This document discusses the desirability of context
transfer for facilitating seamless IP mobility.
ホスト移動性をサポートするＩＰアクセスネットワークで、ホストとネット
ワークの間のルーティングパスはしばしば、そして急速に変化するかもしれ
ません。ある場合には、ホスト移動後もサブネット上で継続するある特定の
状況転送サービスを、ホストは確立してもよいです。このようなサービスの
例は認証・認可・課金（ＡＡＡ）と、ヘッダ圧縮と、サービス品質（ＱｏＳ）
です。ホストが新しいサブネット上でそれらのサービスを得るために、ホス
トはゼロから必要な信号を送って明示的にサービスを再確立しなくてはなり
ません。ある場合には、このプロセスは新しいサブネット上で移動ホストを
確立するプロセスをかなり遅くするでしょう。代案は、「状況転送」と呼ば
れるプロセスで、新しいサブネットにこれらのサービスや状況と結び付けら
れた既存の状態の情報を転送する事です。この文書はスムーズなＩＰ移動を
容易にするらめ状況転送の望ましさを論じます。
Table of Contents
目次
1.0 Introduction
1.0 はじめに
2.0 Reference Definitions
2.0 参照定義
3.0 Scope of the Context Transfer Problem
3.0 状況転送問題の扱う範囲
4.0 The Need for Context Transfer
4.0 状況転送の必要性
4.1 Fast Context Transfer-candidate Service Re-establishment
4.1 早い状況転送の候補のサービスの再建
4.1.1 Authentication, Authorization, and Accounting (AAA)
4.1.1 認証と認可と課金（ＡＡＡ）
4.1.2 Header Compression
4.1.2 ヘッダ圧縮
4.1.3 Quality of Service (QoS)
4.1.3 サービス品質（ＱｏＳ）
4.2 Interoperability
4.2 互換性
5.0 Limitations on Context Transfer
5.0 状況転送の限界
5.1 Router Compatibility
5.1 ルータ互換性
5.2 Requirement to Re-initialize Service from Scratch
5.2 ゼロからサービスを再度初期化する必要条件
5.3 Suitability for the Particular Service
5.3 特定のサービスの適合性
5.4 Layer 2 Solutions Better
5.4 よりよいレイヤ２つの解決策
6.0 Performance Considerations
6.0 性能の考察
7.0 Security Considerations
7.0 セキュリティの考察
8.0 Recommendations
8.0 推薦
9.0 Acknowledgements
9.0 謝辞
10.0 References
10.0 参考文献
11.0 Complete List of Authors' Addresses
11.0 著者のアドレスの完全なリスト
12.0 Full Copyright Statement
12.0 著作権表示全文
1.0 Introduction
1.0 はじめに
In networks where the hosts are mobile, the routing path through the
network must often be changed in order to deliver the host's IP
traffic to the new point of access. Changing the basic routing path
is the job of a IP mobility protocol, such as Mobile IPv4 [1] and
Mobile IPv6 [2]. But the success of real time services such as VoIP
telephony, video, etc., in a mobile environment depends heavily upon
the minimization of the impact of this traffic redirection. In the
process of establishing the new routing path, the nodes along the new
path must be prepared to provide similar routing treatment to the IP
packets as was provided along the old routing path.
ホストが移動であるネットワークで、ネットワークを通るルーティングパス
はしばしば新しいアクセスポイントにホストのＩＰトラフィックを届けるた
めに変えられなくてはなりません。基本的なルーティングパスを変えること
はＩＰ移動プロトコルの、モバイルＩＰｖ４[1]とモバイルＩＰｖ６[2]のよ
うな仕事です。けれども移動環境での、ＶｏＩＰ電話やビデオなどの、リア
ルタイムサービスの成功は、このトラフィック方向変更の影響の最小化に依
存します。新しいルーティングパスを確立するプロセスで、新しいパスに沿っ
たノードは古いルーティングパスに沿って供給されたＩＰパケットに類似の
ルーティング待遇を供給する用意ができているに違いありません。
In many cases, the routing treatment of IP packets within a network
may be regulated by a collection of context transfer-candidate
services that influence how packets for the host are treated. For
example, whether a particular host has the right to obtain any
routing at all out of the local subnet may depend on whether the host
negotiated a successful AAA exchange with a network access server at
some point in the past. Establishing these services initially
results in a certain amount of related state within the network and
requires a perhaps considerable amount of time for the protocol
exchanges. If the host is required to re-establish those services by
the same process as it uses to initially establish them, delay-
sensitive real time traffic may be seriously impacted.
多くの場合、ネットワーク内のＩＰパケットのルーティングの扱いは、どの
ようにホストのパケットを扱うかに影響を与える状況転送サービスの集合に
よって統制されるかもしれません。例えば、特定のホストがローカルサブネッ
ト外へのルーティングを得るべき権利を持っているかどうかは、ホストが過
去にある時点でネットワークアクセスサーバと成功したＡＡＡ交換交渉をし
たかどうかによるかもしれません。初めにこれらのサービスを確立すること
はネットワーク内にある量の関連した状態をもたらして、そしてプロトコル
交換のために多分重要な量の時間を必要とします。もしホストが初めと同じ
手順でサービスを再確立するように要求されるなら、遅延要求が高いリアル
タイムトラフィックにひどく影響を与えらるかもしれません。
An alternative is to transfer enough information on the context
transfer-candidate service state, or context, to the new subnet so
that the services can be re-established quickly, rather than require
the mobile host to establish them from scratch. The transfer of
service context may be advantageous in minimizing the impact of host
mobility on, for example, AAA, header compression, QoS, policy, and
possibly sub-IP protocols and services such as PPP. Context transfer
at a minimum can be used to replicate the configuration information
needed to establish the respective protocols and services. In
addition, it may also provide the capability to replicate state
information, allowing stateful protocols and services at the new node
to be activated along the new path with less delay and less signaling
overhead.
代案は、移動ホストがゼロからサービスを確立するように要求するより速く
再確立できるように、十分な状況転送サービスで状態や状況の情報を新しい
サブネットに転送する事です。サービス状況の転送は、例えば、ＡＡＡやヘッ
ダ圧縮やＱｏＳやポリシーやＰＰＰの様なサブＩＰプロトコルとサービスで、
ホスト移動の影響を最小にする際に有利であるかもしれません。少なくとも
状況転送はそれぞれのプロトコルとサービスを確立するために必要な設定情
報の複製に使うことができます。加えて、新しいノードの新しいパスで、ス
テートフルなプロトコルとサービスを、より少ない遅延とより少ない信号オー
バーヘッドで、活性化されることを許す状態情報を複製する能力を供給する
かもしれません。
In this document, a case is made for why the Seamoby Working Group
should investigate context transfer.
この文書で、事例はSeamoby作業グループが状況転送を調査するべきである理
由に対してされます。
2.0 Reference Definitions
2.0 参照定義
Context
状況
The information on the current state of a service required to re-
establish the service on a new subnet without having to perform
the entire protocol exchange with the mobile host from scratch.
新しいサブネット上でサービスを再確立する際に、ゼロから移動ホストが
全部のプロトコル交換を行う必要がないために必要な、サービスの現在の
状態についての情報。
Context Transfer
状況転送
The movement of context from one router or other network entity to
another as a means of re-establishing specific services on a new
subnet or collection of subnets.
１つのルータあるいは他のネットワーク参加者から他へ、新しいサブネッ
トあるいはサブネット集合上に特定のサービスを再確立する手段としての、
状況の動き。
Context Transfer Candidate Service
状況転送候補サービス
A service that is a candidate for context transfer. In this
document, only services that are concerned with the forwarding
treatment of packets, such as QoS and security, or involve
granting or denying the mobile host access to the network, such as
AAA, are considered to be context transfer-candidate services.
状況転送の検討の候補となってるサービス。この文書では、パケットの転
送処理に関係している、ＱｏＳやセキュリティや移動ホストがネットワー
クへのアクセスの可否を与えるＡＡＡのようなサービスだけが状況転送の
検討の候補となるサービスであると考えられます。
3.0 Scope of the Context Transfer Problem
3.0 状況転送問題の扱う範囲
The context transfer problem examined in this document is restricted
to re-establishing services for a mobile host that are, in some
sense, related to the forwarding treatment of the mobile host's
packets or network access for the mobile host. It is not concerned
with actually re-establishing routing information. Routing changes
due to mobility are the domain of the IP mobility protocol. In
addition, transfer of context related to application-level services,
such as those associated with the mobile host's HTTP proxy, is also
not considered in this document, although a generic context transfer
protocol for transferring the context of services related to
forwarding treatment or network access may also function for
application-level services as well.
この文書で調べる状況転送問題は移動ホストのサービス再確立に限定され、
ある意味でこれは、移動ホストのパケットや移動ホストのネットワークアク
セスの転送の扱いに関連します。これは実際にルーティング情報を再度確立
することに関わっていません。移動のためのルーティング変更はＩＰ移動性
ロトコルの管轄です。加えて、転送の扱いやネットワークアクセスのサービ
ス状況を転送することのための一般的な状況転送プロトコルがアプリケーショ
ンレベルサービスの機能かもしれないが、移動ホストのＨＴＴＰプロクシに
関するもののような、アプリケーションレベルサービスと関係がある状況転
送が、この文書で考慮されません。
An important consideration in whether a service is a candidate for
context transfer is whether it is possible to obtain a "correct"
context transfer for the service in a given implementation and
deployment, that is, one which will result in the same context at the
new access router as would have resulted had the mobile host
undergone a protocol exchange with the access router from scratch.
For some services, the circumstances under which context transfer may
result in correctness may be very limited [11].
サービスが状況転送の候補であるか否かにかかわらず、重要な考慮は、与え
られた実装と配置でのサービスのための「正しい」状況転送を得ることは可
能であるかどうか、つまり、新しいアクセスルータで移動ホストがゼロから
アクセスルータとプロトコル交換を経た結果として生じたのと同じ状況とな
るかどうかです。あるサービスで、状況転送が正当な結果をもたらす状況は
非常に限定されているかもしれません[11]。
4.0 The Need for Context Transfer
4.0 状況転送の必要性
There are two basic motivations for context transfer:
状況転送の２つの基本的な動機があります：
1) The primary motivation, as mentioned in the introduction, is the
need to quickly re-establish context transfer-candidate services
without requiring the mobile host to explicitly perform all
protocol flows for those services from scratch.
1) 主要な動機は、はじめにで述べたように、移動ホストが明示的にゼロから
サービスのすべてのプロトコル流れを行わずに速く状況転送の候補となる
サービスを再確立することです。
2) An additional motivation is to provide an interoperable solution
that works for any Layer 2 radio access technology.
2) 追加の動機が、任意のレイヤ２無線アクセス技術で動く共通解決策を提供
することです。
These points are discussed in more detail in the following
subsections.
これらのポイントは次の章で詳細に論じられます。
4.1 Fast Context Transfer-candidate Service Re-establishment
4.1 早い状況転送の候補のサービスの再建
As mentioned in the introduction, there are a variety of context
transfer-candidate services that could utilize a context transfer
solution. In this section, three representative services are
examined. The consequences of not having a context transfer solution
are examined as a means of motivating the need for such a solution.
はじめにで述べたように、状況転送解決策を利用することができるいろいろ
な状況転送の候補のサービスがあります。この章で、３つの代表サービスが
調べられます。状況転送解決策を持たない結果はこのような解決策の必要に
興味を起こす手段として調べられます。
4.1.1 Authentication, Authorization, and Accounting (AAA)
4.1.1 認証と認可と課金（ＡＡＡ）
One of the more compelling applications of context transfer is
facilitating the re-authentication of the mobile host and
re-establishment of the mobile host's authorization for network
access in a new subnet by transferring the AAA context from the
mobile host's previous AAA server to another. This would allow the
mobile host to continue access in the new subnet without having to
redo an AAA exchange with the new subnet's AAA server. Naturally, a
security association between the AAA servers is necessary so that the
mobile host's sensitive authentication information can be securely
transferred.
状況転送のより説得的なアプリケーションの１つが、移動ホストの再認証と
移動ホストの新しいサブネットネットワークアクセスの再認可を、移動ホス
トの前のＡＡＡサーバから新しいのへＡＡＡ状況を転送することによって容
易にすることです。これは移動ホストに新しいサブネットのＡＡＡサーバと
ＡＡＡ交換をやり直さずに新しいサブネットアクセスを続けることを許すで
しょう。移動ホストの重要な認証情報を安全に転送するために、当然、ＡＡ
Ａサーバ間のセキュリティアソシエーションが必要です。
In the absence of context transfer, there are two ways that can
currently be used for AAA:
状況転送がない場合に、現在ＡＡＡに使える２つの方法があります：
1) Layer 2 mechanisms, such as EAP [3] in PPP [4] or 802.1x [5] can
be used to redo the initial protocol exchange, or possibly to
update it. Currently, there is no general Layer 3 mechanism for
conducting an AAA exchange between a host and an AAA server in the
network.
1) ２層メカニズム、例えばＰＰＰ[4]のＥＡＰ[3]や８０２.１ｘ[5]が最初の
プロトコル交換をやり直すか更新するために使えます。現在、ネットワー
ク内のホストとＡＡＡサーバ間でＡＡＡ交換を行う一般的なレイヤ３メカ
ニズムがありません。
2) If the mobile host is using Mobile IPv4 (but not Mobile IPv6
currently), the host can use the AAA registration keys [6]
extension for Mobile IPv4 to establish a security association with
the new Foreign Agent.
2) もし移動ホストがモバイルＩＰｖ４を使っているなら（しかし現在のモバ
イルＩＰｖ６ではないなら）、ホストが外部エージェントとセキュリティ
アソシエーションを確立するためにモバイルＩＰｖ４のＡＡＡ登録鍵[6]
拡張を使えます。
Since 2) is piggybacked on the Mobile IPv4 signaling, the performance
is less likely to be an issue, but 2) is not a general solution. The
performance of 1) is likely to be considerably less than is necessary
for maintaining good real time stream performance.
２）がＩＰｖ４に便乗するので、性能低下が問題ではないが、２)は一般的な
解決ではありません。１）の性能は良いリアルタイムフロー性能を持続する
ことに必要なよりかなりより低い可能性が高です。
4.1.2 Header Compression
4.1.2 ヘッダ圧縮
In [7], protocols are described for efficient compression of IP
headers to avoid sending large headers over low bandwidth radio
network links. Establishing header compression generally requires
from 1 to 4 exchanges between the last hop router and the mobile host
with full or partially compressed headers before full compression is
available. During this period, the mobile host will experience an
effective reduction in the application-available bandwidth equivalent
to the uncompressed header information sent over the air. Limiting
the uncompressed traffic required to establish full header
compression on a new last hop router facilitates maintaining adequate
application-available bandwidth for real time streams, especially for
IPv6 where the headers are larger.
[7]に、大きいヘッダを低帯域無線ネットワークリンク上に送るのを避けるた
めのＩＰヘッダの効率的な圧縮のプロトコルが記述されます。一般にヘッダ
圧縮を確立することは、完全な圧縮が利用可能になる前に、最終ホップルー
タと移動ホスト間で、完全あるいは部分的に圧縮されたヘッダによる１から
４回の情報交換を必要とします。この期間は、移動ホストは無線上で送られ
た圧縮されないヘッダ情報に等しいアプリケーション利用可能帯域を経験す
るでしょう。新しい最終ホップルータ上で完全ヘッダ圧縮を確立する際の非
圧縮トラフィックを制限することは、特にヘッダが大きいＩＰｖ６でのリア
ルタイムストリームで、適切なアプリケーション利用可能帯域幅を保守する
ことを容易にします。
Context transfer can help in this case by allowing the network entity
performing header compression, usually the last hop router, to
transfer the header compression context to the new router. The
timing of context transfer must be arranged so that the header
context is transferred from the old router as soon as the mobile host
is no longer receiving packets through the old router, and installed
on the new router before any packets are delivered to or forwarded
from the mobile host.
状況転送がこの場合、通常最終ルータが新しいルータにヘッダ圧縮状況を転
送する事で、ネットワーク装置がヘッダ圧縮をするのを助けることができま
す。状況転送のタイミングは、移動ホストが古いルータからパケットを受け
取らなくなってすぐにヘッダ状況が古いルータから転送され、新しいルータ
に移動ホストからパケットが届くか届ける前に設定されるように、取り決め
られなくてはなりません。
4.1.3 Quality of Service (QoS)
4.1.3 サービス品質（ＱｏＳ）
Significant QoS protocol exchanges between the mobile host and
routers in the network may be required in order to establish the
initial QoS treatment for a mobile host's packets. The exact
mechanism whereby QoS for a mobile host should be established is
currently an active topic of investigation in the IETF. For existing
QoS approaches (Diffsrv and Intsrv) preliminary studies have
indicated that the protocol flows necessary to re-establish QoS in a
new subnet from scratch can be very time consuming for Mobile IP, and
other mobility protocols may suffer as well.
移動ホストとネットワークのルータの間の重要なＱｏＳプロトコル交換が移
動ホストのパケットの最初のＱｏＳ待遇を確立するために要求されるかもし
れません。移動ホストのためのＱｏＳが確立されるべきである正確なメカニ
ズムはＩＥＴＦの現在調査のアクティブなトピックです。既存のＱｏＳ手法
（ＤｉｆｆｓｒｖとＩｎｔｓｒｖ）で、予備調査では新しいサブネットでゼ
ロからＱｏＳを再確立するために必要なプロトコルフローがモバイルＩＰで
非常に時間がかかり得ることを示しました、そして他の移動プロトコルが同
様に苦しむかもしれません。
A method of transferring the mobile host's QoS context from the old
network to the new could facilitate faster re-establishment of the
mobile host's QoS treatment on the new subnet. However, for QoS
mechanisms that are end-to-end, transferring context at the last hop
router may be insufficient to completely re-initialize the mobile
host's QoS treatment, since some number of additional routers in the
path between the mobile host and corresponding node may also need to
be involved.
古いネットワークから新しいネットワークへ移動ホストのＱｏＳ状況を転送
する方法が新しいサブネット上の移動ホストのＱｏＳ待遇のより速い再建を
容易にすることができます。しかしながら、エンドエンドＱｏＳメカニズム
で、最終ホップルータで状況を転送することは、移動ホストと対応ノードの
間のパスに追加されるいくつかのルータの対応を必要とするかもしれないの
で、完全に移動ホストのＱｏＳ待遇を再度初期化するには不十分であるかも
しれません。
4.2 Interoperability
4.2 互換性
A particular concern for seamless handover is that different Layer 2
radio protocols may define their own solutions for context transfer.
There are ongoing efforts within 3GPP [8] and IEEE [9] to define such
solutions. These solutions are primarily designed to facilitate the
transfer of Layer 2-related context over a wired IP network between
two radio access networks or two radio access points. However, the
designs can include extensibility features that would allow Layer 3
context to be transferred. Such is the case with [10], for example.
スムーズハンドオーバの特定の懸念は、異なったレイヤ２無線プロトコルが、
それら自身で異なる状況転送解決策を定義するかもしれないということです。
３ＧＰＰ[8]とＩＥＥＥ[9]はこのような解決策を定義する進行中の努力があ
ります。これらの解決策は主に２つの無線アクセスネットワークあるいは２
無線アクセスポイント間の有線ＩＰネットワーク上でレイヤ２関連の状況の
転送を容易にするよう意図されます。しかしながら、デザインはレイヤ３の
状況転送を許すように拡張機能を含むことができます。例えばこれは[10]で
本当です。
If Layer 2 protocols were to be widely adopted as an optimization
measure for Layer 3 context transfer, seamless mobility of a mobile
host having Layer 2 network interfaces that support multiple radio
protocols would be difficult to achieve. Essentially, a gateway or
translator between Layer 2 protocols would be required, or the mobile
host would be required to perform a full re-initialization of its
context transfer-candidate services on the new radio network, if no
translator were available, in order to hand over a mobile host
between two access technologies.
もしレイヤ２プロトコルがレイヤ３の状況転送の広く最適化手法として採用
されるなら、多数の無線プロトコルをサポートするレイヤ２ネットワークイ
ンタフェースを持つ移動ホストのスムーズな移動を成し遂げることが難しい
でしょう。本質的に、ゲートウェイあるいはレイヤ２のプロトコルの間の翻
訳が必要とされるでしょう、あるいはもし翻訳が利用可能でないなら、２つ
のアクセス技術の間で移動ホストをハンドオーバするのに、移動ホストは新
しい無線ネットワーク上で状況転送の候補となるサービスの完全な最初期化
を行う必要があるでしょう。
A general Layer 3 context transfer solution may also be useful for
Layer 2 protocols that do not define their own context transfer
protocol. Consideration of this issue is outside the scope of the
Seamoby Working Group, however, since it depends on the details of
the particular Layer 2 protocol.
一般的なレイヤ３の状況転送解決策が、自身の状況転送プロトコルを定義し
ないレイヤ２プロトコルの役立つかもしれません。この問題の考察は、しか
しながら、特定の２層プロトコルの詳細に依存するので、Seamoby作業グルー
プの範囲外です。
5.0 Limitations on Context Transfer
5.0 状況転送の限界
Context transfer may not always be the best solution for
re-establishing context transfer-candidate services on a new subnet.
There are certain limitations on when context transfer may be
useful. These limitations are discussed in the following subsections.
状況転送が常に新しいサブネットの上に状況転送の候補のサービスを再確立
する最も良い解決策ではないかもしれません。いつ状況転送が有用であるか
について、ある特定の限界があります。これらの限界は次の章で論じられま
す。
5.1 Router Compatibility
5.1 ルータ互換性
Context transfer between two routers is possible only if the
receiving router supports the same context transfer-candidate
services as the sending router. This does not mean that the two
nodes are identical in their implementation, nor does it even imply
that they must have identical capabilities. A router that cannot
make use of received context should refuse the transfer. This
results in a situation no different than a mobile host handover
without context transfer, and should not be considered an error or
failure situation.
２つのルータ間の状況転送は、受信ルータが送信ルータと同じ状況転送の候
補のサービスをサポート支援する場合に限り、可能です。これは２つのノー
ドの実装で同一であることを意味しませんし、同様に同一の能力を持ってい
なくてはならないことを意味しさえしません。受信した状況を利用すること
ができないルータが転送を断るべきです。これは状況転送がない移動ホスト
ハンドオーバーと同じで、エラーや失敗状態と思われるべきでありません。
5.2 Requirement to Re-initialize Service from Scratch
5.2 ゼロからサービスを再度初期化する必要条件
The primary motivation for context transfer assumes that quickly
re-establishing the same level of context transfer-candidate service
on the new subnet is desirable. And yet, there may be situations
where either the device or the access network would prefer to
re-establish or re-negotiate the level of service. For example, if
the mobile host crosses administrative domains where the operational
policies change, negotiation of a different level of service may be
required.
状況転送のための主要な動機は、状況転送の候補となるサービスを、速く新
しいサブネット上で同じレベルで再確立することが望ましいとの想定です。
それにも拘わらず、装置あるいはアクセスネットワークがサービスレベルを
再確立するか、あるいは再度交渉することをより好む状態があるかもしれま
せん。例えば、もし移動ホストが運用上のポリシーが変化する管理ドメイン
に移動するなら、異なったレベルのサービスの交渉が必要とされるかもしれ
ません。
5.3 Suitability for the Particular Service
5.3 特定のサービスの適合性
Context transfer assumes that it is faster to establish the service
by context transfer rather than from scratch. This may not be true
for certain types of service, for example, multicast, "push"
information services.
状況転送は、状況転送によるサービス確立が、ゼロからより速いと想定しま
す。これはある特定のタイプのサービス、例えばマルチキャストや「プッシ」
情報サービスで、真ではないかもしれません。
5.4 Layer 2 Solutions Better
5.4 よりよいレイヤ２つの解決策
Context transfer is an enhancement to improve upon the performance of
a handover for Layer 3 context transfer-candidate services. Many
networks provide support for handover at Layer 2, within and between
subnets. Layer 3 context transfer may not provide a significant
improvement over Layer 2 solutions, even for Layer 3 context, if the
handover is occurring between two subnets supporting the same Layer 2
radio access technology.
状況転送がレイヤ３の状況転送の候補のサービスのためのハンドオーバの性
能を改善するための拡張です。多くのネットワークがレイヤ２でサブネット
内とサブネット間のハンドオーバのサポートを供給します。もしハンドオー
バが同じレイヤ２の無線アクセス技術をサポートしている２つのサブネット
の間でおこるなら、レイヤ３の状況のためであっても、レイヤ３の状況転送
がレイヤ２の解決に重要な改良を供給しないかもしれません。
6.0 Performance Considerations
6.0 性能の考察
The purpose of context transfer is to sustain the context
transfer-candidate services being provided to a mobile host's traffic
during handover. It is essentially an enhancement to IP mobility
that ultimately must result in an improvement in handover
performance. A context transfer solution must provide performance
that is equal to or better than re-initializing the context
transfer-candidate service between the mobile host and the network
from scratch. Otherwise, context transfer is of no benefit.
状況転送の目的は、状況転送の候補ちなるサービスをハンドオーバの間も移
動ホストのトラフィックに供給することです。ＩＰ移動性への拡張で、究極
的なハンドオーバ性能の改良は本質です。状況転送解決策が移動ホストとネッ
トワークの間でゼロから状況転送の候補のサービスを再度初期化するのより
も、同等以上の性能を供給しなくてはなりません。さもなければ、状況転送
の利益がありません。
7.0 Security Considerations
7.0 セキュリティの考察
Any context transfer standard must provide mechanism for adequately
securely the context transfer process, and a recommendation to deploy
security, as is typically the case for Internet standards. Some
general considerations for context transfer security include:
どのような状況転送標準でも、典型的なインターネット標準同様に、十分に
安全なセキュリティメカニズムを供給しなくてはならず、安全に配置する勧
告をしなければなりません。状況転送セキュリティに対する一般的な考察は
以下を含みます：
- Information privacy: the context may contain information which the
end user or network operator would prefer to keep hidden from
unauthorized viewers.
- 情報プライバシー：状況はエンドユーザやネットワークオペレータが無許
可の者から隠される状態にすることを求める情報を含んでいるかもしれま
せん。
- Transfer legitimacy: a false or purposely corrupted context
transfer could have a severe impact upon the operation of the
receiving router, and therefore could potentially affect the
operation of the access network itself. The potential threats
include denial of service and theft of service attacks.
- 転送正当性：誤りや偽造した状況転送は、受信ルータの運用にひどい影響
を与えることができ、従って潜在的にアクセスネットワーク自身の運用に
影響を与えることができます。可能性がある脅威はサービス妨害とサービ
ス横取を含みます。
- Security preservation: part of the context transfer may include
information pertinent to a security association established between
the mobile host and another entity on the network. For this
security association to be preserved during handover, the transfer
of the security context must include the appropriate security
measures.
- セキュリティ維持：状況転送の一部にネットワークの移動ホストと他の要
素間で確立されたセキュリティアソシエーションと関係がある情報を含む
かもしれません。このセキュリティアソシエーションがハンドオーバーの
間に維持されるために、セキュリティ状態の転送は適切なセキュリティ手
段を含まなくてはなりません。
It is expected that the measures used to secure the transport of
information between peers (e.g., IPSEC [10]) in an IP network should
be sufficient for context transfer. However, given the above
considerations, there may be reason to provide for additional
security measures beyond the available IETF solutions.
ＩＰネットワークでピアの間で情報を転送するのを保証する使われた方法
（例えばＩＰＳＥＣ[10]）が状況転送に十分である事が期待されます。しか
しながら、上記の考慮の条件下で、利用可能なＩＥＴＦ解決策を越えて追加
のセキュリティ手段を備える理由があるかもしれません。
Since context transfer requires a trust relationship between network
entities, the compromise of only one of the network entities that
transfer context may be sufficient to reduce the security of the
whole system, if for example the context transferred includes
encryption keying material. When the host moves from the compromised
network entity to an uncompromised network entity in the presence of
context transfer, the compromised context may be used to decrypt the
communication channel. When context transfer is not used, a
compromise of only one network entity only gives access to what that
network entity can see. When the mobile host moves to an
uncompromised network entity in the absence of context transfer,
security can be re-established at the new entity. However, to the
extent that context transfer happens primarily between routers, the
security of context transfer will depend on the security of the
routers. Any compromise of security on a router that affects context
transfer may also lead to other, equally serious disruptions in
network traffic.
状況転送がネットワーク装置間の信頼関係を必要とするので、状況転送をす
るネットワーク装置の１つが汚染され、もし例えば転送された状況が暗号化
の鍵の材料を含むなら、システム全体のセキュリティを悪化させるかもしれ
ません。ホストが状況転送の汚染された装置から汚染されたない装置に移動
する時、汚染された状況は通信チャネルを解読するために使われるかもしれ
ません。状況転送が使われない時、１つのネットワーク装置の汚染は、その
ネットワーク装置が見ることができるものへのアクセスを与えるだけです。
移動ホストが状況転送がなければ、汚染されてないネットワーク装置に移動
する時、セキュリティが新しい装置で再度確立できます。しかしながら、状
況転送が主にルータ間で起きる限り、状況転送の安全管理はルータのセキュ
リティに依存するでしょう。状況転送に影響を与えるルータ上のセキュリ
ティの汚染は、ネットワークトラフィックに他の同様な重大な混乱を導くか
もしれません。
The context transfer investigation must identify any novel security
measures required for context transfer that exceed the capabilities
of the existing or emerging IETF solutions.
状況転送の調査は、既存や議論中のＩＥＴＦ解決策の能力を越える、状況転
送のために必要とされる新しいセキュリティ処置を、識別しなくてはなりま
せん。
8.0 Recommendations
8.0 推薦
The following steps are recommended for Seamoby:
次のステップはＳｅａｍｏｂｙに勧められます：
- Investigation into candidate router-related services for context
and an analysis of the transfer requirements for each candidate;
- 状況の候補となるルータ関連のサービスと、それぞれの候補の転送条件の
分析調査；
- The development of a framework and protocol(s) that will support
the transfer of context between the routing nodes of an IP network.
- ＩＰネットワークのルーティングノード間で状況の転送をサポートするフ
レームワークとプロトコルの開発。
The context transfer solution must inter-work with existing and
emerging IP protocols, in particular, those protocols supporting
mobility in an IP network.
状況転送解決策は、既存と検討中のＩＰプロトコル、特に、ＩＰネットワー
クで移動性をサポートしているプロトコル、との相互動作が必要です。
9.0 Acknowledgements
9.0 謝辞
The editor would like to thank the Seamoby CT design team (listed at
the end of the document as co-authors), who were largely responsible
for the initial content of this document, for their hard work, and
especially Gary Kenward, who shepherded the document through its
initial versions.
エディタは、主にこの文書の最初の内容に関して責任があった（共著者とし
て文書の終わりにおいてリストアップされた）Ｓｅａｍｏｂｙ ＣＴデザイン
チーム、特にその最初のバージョンを書いたGary Kenwardに対して、にその
努力の感謝をしたいです。
10.0 References
10.0 参考文献
[1] Perkins, C., "IP Mobility Support", RFC 3220, January 2002.
[2] Johnson, D. and C. Perkins, "Mobility Support in IPv6", Work in
Progress.
[3] Blunk, L. and Vollbrecht, J., "PPP Extensible Authentication
Protocol (EAP)", RFC 2284, March 1998.
[4] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC
1661, July 1994.
[5] IEEE Std. P802.1X/D11, "Standard for Port based Network Access
Control", March 2001.
[6] Perkins, C., and P. Calhoun, "AAA Registration Keys for Mobile
IP", Work in Progress.
[7] Borman, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu,
H., Jonsson, L., Hakenberg, R., Koren T., Le, K., Martensson,
A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T. and H.
Zheng, "RObust Header Compression (ROHC): Framework and four
profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001.
[8] 3GPP TR 25.936 V4.0.0, "Handovers for Real Time Services from PS
Domain," 3GPP, March 2001.
[9] IEEE Std. 802.11f/D2.0, "Draft Recommended Practice for Multi-
Vendor Access Point Interoperability via an Inter-Access Point
Protocol Across Distribution Systems Supporting IEEE 802.11
Operation," July 2001.
[10] Kent, S. and Atkinson, R., "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[11] Aboba, B. and M. Moore, "A Model for Context Transfer in IEEE
802", Work in Progress.
11.0 Complete List of Authors' Addresses
11.0 著者のアドレスの完全なリスト
O. Henrik Levkowetz
A Brand New World
Osterogatan 1
S-164 28 Kista
SWEDEN
Phone: +46 8 477 9942
EMail: henrik@levkowetz.com
Pat R. Calhoun
Black Storm Networks
110 Nortech Parkway
San Jose CA 95134
USA
Phone: +1 408-941-0500
EMail: pcalhoun@bstormnetworks.com
James Kempf
NTT DoCoMo USA Laboratories
181 Metro Drive, Suite 300
San Jose, CA 95110
USA
Phone: 408-451-4711
EMail: kempf@docomolabs-usa.com
Gary Kenward
Nortel Networks
3500 Carling Avenue
Nepean, Ontario K2G 6J8
CANADA
Phone: +1 613-765-1437
EMail: gkenward@nortelnetworks.com
Hamid Syed
Nortel Networks
100 Constellation Crescent
Nepean Ontario K2G 6J8
CANADA
Phone: +1 613 763-6553
EMail: hmsyed@nortelnetworks.com
Jukka Manner
Department of Computer Science
University of Helsinki
P.O. Box 26 (Teollisuuskatu 23)
FIN-00014 Helsinki
FINLAND
Phone: +358-9-191-44210
EMail: jmanner@cs.helsinki.fi
Madjid Nakhjiri
Motorola
1501 West Shure Drive
Arlington Heights IL 60004
USA
Phone: +1 847-632-5030
EMail: madjid.nakhjiri@motorola.com
Govind Krishnamurthi
Communications Systems Laboratory, Nokia Research Center
5 Wayside Road
Burlington MA 01803
USA
Phone: +1 781 993 3627
EMail: govind.krishnamurthi@nokia.com
Rajeev Koodli
Communications Systems Lab, Nokia Research Center
313 Fairchild Drive
Mountain View CA 94043
USA
Phone: +1 650 625 2359
EMail: rajeev.koodli@nokia.com
Kulwinder S. Atwal
Zucotto Wireless Inc.
Ottawa Ontario K1P 6E2
CANADA
Phone: +1 613 789 0090
EMail: kulwinder.atwal@zucotto.com
Michael Thomas
Cisco Systems
375 E Tasman Rd
San Jose CA 95134
USA
Phone: +1 408 525 5386
EMail: mat@cisco.com
Mat Horan
COM DEV Wireless Group
San Luis Obispo CA 93401
USA
Phone: +1 805 544 1089
EMail: mat.horan@comdev.cc
Phillip Neumiller
3Com Corporation
1800 W. Central Road
Mount Prospect IL 60056
USA
EMail: phil_neumiller@3com.com
12.0 Full Copyright Statement
12.0 著作権表示全文
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（Ｃ）インターネット学会（２００２）。すべての権利は保留される。
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
上記著作権表示とこの段落が全ての複写や派生的な仕事につけられていれば、
この文書と翻訳は複写や他者への提供ができ、そしてコメントや説明や実装
を支援する派生的な仕事のためにこの文書の全部か一部を制約なく複写や出
版や配布できます。しかし、この文書自身は、英語以外の言葉への翻訳やイ
ンターネット標準を開発する目的で必要な場合以外は、インターネット学会
や他のインターネット組織は著作権表示や参照を削除されるような変更がで
きません、インターネット標準を開発する場合はインターネット標準化プロ
セスで定義された著作権の手順に従われます。
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
上に与えられた限定された許可は永久で、インターネット学会やその後継者
や譲渡者によって無効にされません。
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
この文書とここに含む情報は無保証で供給され、そしてインターネット学会
とインターネット技術標準化タスクフォースは、特別にも暗黙にも、この情
報の利用が権利を侵害しないことや商業利用や特別の目的への利用に適当で
ある事の保障を含め、すべての保証を拒否します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the
Internet Society.
ＲＦＣエディタ機能のための資金供給が現在インターネット学会によって
供給されます。