RFC3154 日本語訳
3154 Requirements and Functional Architecture for an IP Host AlertingProtocol. J. Kempf, C. Castelluccia, P. Mutaf, N. Nakajima, Y. Ohba,R. Ramjee, Y. Saifullah, B. Sarikaya, X. Xu. August 2001. (Format: TXT=31534 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Kempf
Request for Comments: 3154 C. Castelluccia
Category: Informational P. Mutaf
N. Nakajima
Y. Ohba
R. Ramjee
Y. Saifullah
B. Sarikaya
X. Xu
August 2001
コメントを求めるワーキンググループJ.ケンフの要求をネットワークでつないでください: 3154年のC.Castellucciaカテゴリ: 情報のP.のSaifullah B.Sarikaya X.シューMutaf N.Nakajima Y.オオバR.Ramjee Y.2001年8月
Requirements and Functional Architecture for
an IP Host Alerting Protocol
プロトコルを警告しているIPホストのための要件と機能的な建築
Status of this Memo
この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 (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
Abstract
要約
This document develops an architecture and a set of requirements needed to support alerting of hosts that are in dormant mode. The architecture and requirements are designed to guide development of an IP protocol for alerting dormant IP mobile hosts, commonly called paging.
このドキュメントは眠っているモードでいるホストの警告をサポートするのに必要である要件のアーキテクチャとセットを発展させます。 アーキテクチャと要件は、一般的にページングと呼ばれる眠っているIPモバイルホストを警告するためにIPプロトコルの開発を誘導するように設計されています。
Kempf, et al. Informational [Page 1] RFC 3154 Paging Requirements August 2001
ケンフ、他 2001年8月に要件を呼び出す情報[1ページ]のRFC3154
Table of Contents
目次
1. Introduction ...................................................3
2. Terminology ....................................................3
3. Security Considerations ........................................3
3.1. DoS Amplification .........................................3
3.2. Queue Overflow ............................................4
3.3. Selective DoS against Hosts ...............................4
4. Requirements ...................................................5
4.1. Impact on Power Consumption ...............................5
4.2. Scalability ...............................................5
4.3. Control of Broadcast/Multicast/Anycast ....................5
4.4. Efficient Signaling for Inactive Mode .....................6
4.5. No Routers ................................................6
4.6. Multiple Dormant Modes ....................................6
4.7. Independence of Mobility Protocol .........................6
4.8. Support for Existing Mobility Protocols ...................6
4.9. Dormant Mode Termination ..................................6
4.10. Network Updates ...........................................6
4.11. Efficient Utilization of L2 ...............................7
4.12. Orthogonality of Paging Area and Subnets ..................7
4.13. Future L3 Paging Support ..................................7
4.14. Robustness Against Failure of Network Elements ............7
4.15. Reliability of Packet Delivery ............................7
4.16. Robustness Against Message Loss ...........................7
4.17. Flexibility of Administration .............................7
4.18. Flexibility of Paging Area Design .........................8
4.19. Availability of Security Support ..........................8
4.20. Authentication of Paging Location Registration ............8
4.21. Authentication of Paging Area Information .................8
4.22. Authentication of Paging Messages .........................8
4.23. Paging Volume .............................................8
4.24. Parsimonious Security Messaging ...........................8
4.25. Noninterference with Host's Security Policy ...............8
4.26. Noninterference with End-to-end Security ..................9
4.27. Detection of Bogus Correspondent Nodes ....................9
5. Functional Architecture ........................................9
5.1. Functional Entities .......................................9
5.2. Interfaces ...............................................10
5.3. Functional Architecture Diagram ..........................12
6. Acknowledgements ..............................................12
7. References ....................................................13
8. Authors' Addresses ............................................13
9. Full Copyright Statement ......................................16
1. 序論…3 2. 用語…3 3. セキュリティ問題…3 3.1. DoS増幅…3 3.2. オーバーフローを列に並ばせてください…4 3.3. ホストに対する選択しているDoS…4 4. 要件…5 4.1. 消費電力で影響を与えてください…5 4.2. スケーラビリティ…5 4.3. 放送/マルチキャスト/Anycastのコントロール…5 4.4. 不活発なモードのための効率的なシグナリング…6 4.5. ルータがありません…6 4.6. 複数の眠っているモード…6 4.7. 移動性プロトコルからの独立…6 4.8. 存在するには、移動性がプロトコルであるとサポートしてください…6 4.9. 眠っているモード終了…6 4.10. アップデートをネットワークでつないでください…6 4.11. L2の効率的な利用…7 4.12. ページング領域とサブネットの直交性…7 4.13. 今後のL3ページングサポート…7 4.14. ネットワークElementsの失敗に対する丈夫さ…7 4.15. パケット配信の信頼性…7 4.16. メッセージの損失に対する丈夫さ…7 4.17. 政権の柔軟性…7 4.18. ページング領域デザインの柔軟性…8 4.19. セキュリティサポートの有用性…8 4.20. ページング位置登録の認証…8 4.21. ページング領域情報の認証…8 4.22. ページングメッセージの認証…8 4.23. ページングボリューム…8 4.24. けちなセキュリティメッセージング…8 4.25. ホストの安全保障政策との放任…8 4.26. 終わりから終わりへのセキュリティとの放任…9 4.27. にせの通信員ノードの検出…9 5. 機能的なアーキテクチャ…9 5.1. 機能的な実体…9 5.2. インタフェース…10 5.3. 機能的な建築ダイヤグラム…12 6. 承認…12 7. 参照…13 8. 作者のアドレス…13 9. 完全な著作権宣言文…16
Kempf, et al. Informational [Page 2] RFC 3154 Paging Requirements August 2001
ケンフ、他 2001年8月に要件を呼び出す情報[2ページ]のRFC3154
1. Introduction
1. 序論
In [1], a problem statement was developed to explain why an IP protocol was desirable for alerting hosts in dormant mode, commonly called paging. In this document, a set of requirements is developed for guiding the development of an IP paging protocol. Based on the requirements, an architecture is developed to represent the functional relationships between logical functional entities involved.
[1]では、問題声明は、一般的にページングと呼ばれる眠っているモードでホストを警告するには、IPプロトコルがなぜ望ましかったかを説明するために開発されました。 本書では、1セットの要件は、IPページングプロトコルの開発を誘導するために開発されます。 要件に基づいて、アーキテクチャは、かかわった論理的な機能的な実体の間の機能的な関係を表すために開発されます。
2. Terminology
2. 用語
Please see [1] for definition of terms used in describing paging. In addition, this document defines the following terms:
呼び出すと説明する際に用語の定義のための[1]が使用されるのを見てください。 さらに、このドキュメントは次の用語を定義します:
Wide Casting - Either broadcasting or multicasting.
広いCasting--放送かマルチキャスティングのどちらか。
Inactive Mode - The host is no longer listening for any
packets, not even periodically, and not sending packets. The
host may be in a powered off state, it may have shut down all
interfaces to drastically conserve power, or it may be out of
range of a radio access point.
不活発なMode--ホストは、もう定期的でなくさえどんなパケットも聞こうとしないで、またパケットを送りません。 ホストが動力付きのオフ状態にあるかもしれませんか、パワーを抜本的に保存するためにすべてのインタフェースを止めたかもしれませんか、またはそれはラジオアクセスポイントの範囲から脱しているかもしれません。
3. Security Considerations
3. セキュリティ問題
An IP paging protocol introduces new security issues. In this section, security issues with relevance to formulating requirements for an IP paging protocol are discussed.
IPページングプロトコルは新しい安全保障問題を紹介します。 このセクションで、IPページングプロトコルのための要件を定式化することへの関連性の安全保障問題について議論します。
3.1. DoS Amplification
3.1. DoS増幅
A DoS (Denial-of-Service) or DDoS (Distributed DoS) attack generally consists of flooding a target network with bogus IP packets in order to cause degraded network performance at victim nodes and/or routers. Performance can be degraded to the point that the network cannot be used. Currently, there is no preventive solution against these attacks, and the impacts can be very important.
一般に、DoS(サービス妨害)かDDoS(分配されたDoS)攻撃は犠牲者ノード、そして/または、ルータにおける降格しているネットワーク性能を引き起こすためににせのIPパケットで目標ネットワークをあふれさせるのから成ります。 パフォーマンスはネットワークを使用できないというポイントまで下がることができます。 現在、どんな予防ソリューションもこれらの攻撃に反対していません、そして、影響は非常に重要である場合があります。
In general a DoS attacker profits from a so-called "amplifier" in order to increase the damage caused by his attack. Paging can serve for an attacker as a DoS amplifier.
一般に、DoS攻撃者は、彼の攻撃でもたらされた損害を増強するためにいわゆる「アンプ」から利益を得ます。 ページングはDoSアンプとして攻撃者を満たすことができます。
An attacker (a malicious correspondent node) can send large numbers of packets pretending to be sent from different (bogus) correspondent nodes and destined for large numbers of hosts in inactive and dormant modes. This attack, in turn, will be amplified by the paging agent which wide casts paging messages over a paging area, resulting in more than one networks being flooded. Clearly, the damage can be
攻撃者(悪意がある通信員ノード)は多くのパケットに不活発で眠っているモードで異なった(にせの)通信員ノードから送られて、多くのホストのために運命づけられるふりをさせることができます。 この攻撃はページングエージェントによって順番に増幅されるでしょう(1つのネットワークより以上をもたらして、広いキャストがページング領域の上にメッセージを呼び出して、浸水しました)。 明確に、損害はそうであることができます。
Kempf, et al. Informational [Page 3] RFC 3154 Paging Requirements August 2001
ケンフ、他 2001年8月に要件を呼び出す情報[3ページ]のRFC3154
more important in wireless networks that already suffer from scarce radio bandwidth.
不十分なラジオ帯域幅が既に欠点であるワイヤレス・ネットワークでは、より重要です。
Alternatively, an attacker can sort out a host which:
あるいはまた、攻撃者はホストからどれを分類できるか:
1. sends periodic messages declaring that it is in dormant mode,
1.、周期的なメッセージにそれが眠っているモードであると宣言させます。
2. never replies to paging requests.
2. 決してページング要求に関する回答でない。
Such a node may be the attacker's node itself, or a second node participating in the attack.
そのようなノードは、攻撃者のノード自体、または攻撃に参加する2番目のノードであるかもしれません。
That node is never in inactive mode because of behavior 1 above. In this case, the attacker can send large numbers of packets destined for that host which periodically declares that it is in dormant mode but never replies to paging messages. The impact will be the same as above however in this case the attack will be amplified indefinitely.
そのノードは振舞い1のために上に決してどんな不活発なモードでもありません。 この場合、攻撃者はそのホストのために運命づけられた多くのパケットを送ることができます(定期的にそれが眠っているモードであると宣言しますが、ページングメッセージに決して答えません)。 攻撃がどんなにこの場合無期限に増幅されても、影響は同じくらい上で同じになるでしょう。
3.2. Queue Overflow
3.2. 待ち行列オーバーフロー
For reliability reasons, the paging protocol may need to make provisions for a paging queue where a paging request is buffered until the requested host replies by sending a location registration message.
信頼性の理由で、ページングプロトコルは、ページング待ち行列のための要求されたホストが位置登録メッセージを送ることによって返答するまでページング要求がバッファリングされる条項を作る必要があるかもしれません。
An attacker can exploit that by sending large numbers of packets having different (bogus) correspondent node addresses and destined for one or more inactive hosts. These packets will be buffered in the paging queue. However, since the hosts are inactive, the paging queue may quickly overflow, blocking the incoming traffic from legitimate correspondent nodes. As a result, all registered dormant hosts may be inaccessible for a while. The attacker can re-launch the attack in a continuous fashion.
攻撃者は1人以上の不活発なホストのために異なった(にせの)通信員ノードアドレスを持って、運命づけられた送付の大きい番号のパケットでそれを利用できます。 これらのパケットはページング待ち行列でバッファリングされるでしょう。 しかしながら、ホストが不活発であるので、正統の通信員ノードから入って来るトラフィックを妨げて、ページング待ち行列は急速にあふれるかもしれません。 その結果、すべての登録された眠っているホストがしばらく、近づきがたいかもしれません。 攻撃者は連続したファッションで攻撃を再展開できます。
An attacker together with a bogus host that fails to respond to pages can overflow the buffering provided to hold packets for dormant mode hosts. If the attacker keeps sending packets while the dormant mode host fails to reply, the buffer can overflow.
ページに応じないにせのホストに伴う攻撃者を眠っているモードホストのためのパケットを保持するために提供されたバッファリングからはみ出させることができます。 攻撃者が眠っているモードホストが返答していない間、パケットを送り続けるなら、バッファはあふれることができます。
3.3. Selective DoS against Hosts
3.3. ホストに対する選択しているDoS
The following vulnerabilities already exist in the absence of IP paging. However, they are included here since they can affect the correct operation of the IP paging protocol.
以下の脆弱性はIPページングがないとき既に存在しています。 しかしながら、それらは、IPページングプロトコルの正しい操作に影響できるので、ここに含まれています。
These vulnerabilities can be exploited by an attacker in order to eliminate a particular host. This, in turn, can be used by an attacker as a stepping stone to launch other attacks.
攻撃者は、特定のホストを排除するのにこれらの脆弱性を利用できます。 攻撃者は、他の攻撃に着手するのに飛び石として順番にこれを使用できます。
Kempf, et al. Informational [Page 4] RFC 3154 Paging Requirements August 2001
ケンフ、他 2001年8月に要件を呼び出す情報[4ページ]のRFC3154
Forced Battery Consumption
無理矢理のバッテリー消費
An attacker can frequently send packets to a host in order to prevent that host from switching to dormant mode. As a result the host may quickly run out of battery.
攻撃者は、そのホストが眠っているモードに切り替わるのを防ぐために頻繁にパケットをホストに送ることができます。 その結果、ホストはすぐにバッテリーを使い果たすかもしれません。
Bogus Paging Areas
にせのページング領域
An attacker can periodically emit malicious packets in order to confuse one or more hosts about their actual locations. Currently, there is no efficient way to authenticate such packets.
攻撃者は、彼らの実際の場所に関して1人以上のホストを混乱させるように定期的に悪意があるパケットを放つことができます。 現在、そのようなパケットを認証するどんな効率的な方法もありません。
In the case of IP paging, these packets may also contain bogus paging area information. Upon receipt of such a packet, a host may move and send a location registration message pointing to a non-existing or wrong paging area. The functional entities of the IP paging protocol may loose contact with the host.
また、IPページングの場合では、これらのパケットはにせのページング領域情報を含むかもしれません。 そのようなパケットを受け取り次第、ホストは、移行して、位置登録メッセージに間違った非存在かページング領域を示させるかもしれません。 IPページングプロトコルの機能的な実体はホストとの接触を発射するかもしれません。
More importantly, this attack can serve for sorting out a host which shows the behaviors 1 and 2 described in Section 3.1.
より重要に、この攻撃は、ホストを整理するために振舞い1と2がセクション3.1で説明したどちらのショーに役立つことができるか。
Bogus Paging Agents
にせのページングエージェント
An attacker can wide cast fake paging messages pretending to be sent by a paging agent. The impacts will be similar to the ones described in Sections 4.1 and 4.3.1. However, depending on how the IP paging protocol is designed, additional harm may be caused.
広いキャスト偽物がメッセージを呼び出して、ページングエージェントによって送られるふりをしながら、攻撃者はそうすることができます。 影響はセクション4.1と4.3.1で説明されたものと同様になるでしょう。 しかしながら、IPページングプロトコルがどう設計されているかによって、追加害は引き起こされるかもしれません。
4. Requirements
4. 要件
The following requirements are identified for the IP paging protocol.
以下の要件はIPページングプロトコルのために特定されます。
4.1. Impact on Power Consumption
4.1. 消費電力で影響を与えてください。
The IP paging protocol MUST minimize impact on the Host's dormant mode operation, in order to minimize excessive power drain.
IPページングプロトコルは、Hostの眠っているモード操作のときに過度のパワードレインを最小にするために影響を最小にしなければなりません。
4.2. Scalability
4.2. スケーラビリティ
The IP paging protocol MUST be scalable to millions of Hosts.
IPページングプロトコルは何百万Hostsにスケーラブルであるに違いありません。
4.3. Control of Broadcast/Multicast/Anycast
4.3. 放送/マルチキャスト/Anycastのコントロール
The protocol SHOULD provide a filter mechanism to allow a Host prior to entering dormant mode to filter which broadcast/multicast/anycast packets active a page. This prevents the Host from awakening out of dormant mode for all broadcast/multicast/anycast traffic.
プロトコルSHOULDは、眠っているモードを入れる前のHostがどの放送/マルチキャスト/anycastパケット能動態を1ページフィルターにかけるかを許容するためにフィルタメカニズムを提供します。 これは、Hostがすべての放送/マルチキャスト/anycastトラフィックのために眠っているモードから目を覚ますのを防ぎます。
Kempf, et al. Informational [Page 5] RFC 3154 Paging Requirements August 2001
ケンフ、他 2001年8月に要件を呼び出す情報[5ページ]のRFC3154
4.4. Efficient Signaling for Inactive Mode
4.4. 不活発なモードのための効率的なシグナリング
The IP paging protocol SHOULD provide a mechanism for the Tracking Agent to determine whether the Host is in inactive mode, to avoid paging when a host is completely unreachable.
Trackingエージェントが、ホストが完全に手が届かないときに、呼び出すのを避けるためにHostが不活発なモードであるかを決心するように、IPページングプロトコルSHOULDはメカニズムを提供します。
4.5. No Routers
4.5. ルータがありません。
Since the basic issues involved in handling mobile routers are not well understood and since mobile routers have not exhibited a requirement for paging, the IP paging protocol MAY NOT support routers. However, the IP paging protocol MAY support a router acting as a Host.
モバイルルータを扱うのにかかわる初版がよく理解されないで、またモバイルルータがページングのための要件を示していないので、IPページングプロトコルはルータをサポートしないかもしれません。 しかしながら、IPページングプロトコルはHostとして機能するルータをサポートするかもしれません。
4.6. Multiple Dormant Modes
4.6. 複数の眠っているモード
Recognizing that there are multiple possible dormant modes on the Host, the IP paging protocol MUST work with different implementations of dormant mode on the Host.
複数の可能な眠っているモードがHostにあると認めて、IPページングプロトコルは眠っているモードの異なった実装でHostに働かなければなりません。
4.7. Independence of Mobility Protocol
4.7. 移動性プロトコルからの独立
Recognizing that IETF may support multiple mobility protocols in the future and that paging may be of value to hosts that do not support a mobility protocol, the IP paging protocol MUST be designed so there is no dependence on the underlying mobility protocol or on any mobility protocol at all. The protocol SHOULD specify and provide support for a mobility protocol, if the Host supports one.
IETFが、将来複数の移動性がプロトコルであるとサポートするかもしれないと認めて、そのページングには移動性プロトコルをサポートしないホストには価値があるかもしれません、IPページングプロトコルを設計しなければなりません、したがって、基本的な移動性プロトコル、または、全くどんな移動性プロトコルへの依存は全くありません。 Hostが1つをサポートするなら、プロトコルSHOULDは移動性プロトコルのサポートを指定して、提供します。
4.8. Support for Existing Mobility Protocols
4.8. 存在するには、移動性がプロトコルであるとサポートしてください。
The IP paging protocol MUST specify the binding to the existing IP mobility protocols, namely mobile IPv4 [2] and mobile IPv6 [3]. The IP paging protocol SHOULD make use of existing registration support.
IPページングプロトコルはすなわち、既存のIP移動性プロトコル、モバイルIPv4[2]とモバイルIPv6[3]に結合を指定しなければなりません。 IPページングプロトコルSHOULDは既存の登録サポートを利用します。
4.9. Dormant Mode Termination
4.9. 眠っているモード終了
Upon receipt of a page (either with or without an accompanying L3 packet), the Host MUST execute the steps in its mobility protocol to re-establish a routable L3 link with the Internet.
1ページ(パケットも付随のL3パケットのない)を受け取り次第、Hostは、インターネットとのroutable L3リンクを復職させるために移動性プロトコルにおけるステップを実行しなければなりません。
4.10. Network Updates
4.10. ネットワークアップデート
Recognizing that locating a dormant mode mobile requires the network to have a rough idea of where the Host is located, the IP paging protocol SHOULD provide the network a way for the Paging Agent to inform a dormant mode Host what paging area it is in and the IP paging protocol SHOULD provide a means whereby the Host can inform
眠っているモードモバイルの場所を見つけるのが、ネットワークにはHostが見つけられていて、IPページングプロトコルSHOULDがPagingエージェントが、それがどんなページング領域であるかを眠っているモードHostに知らせる方法をネットワークに提供して、IPページングプロトコルSHOULDがHostが知らせることができる手段を提供するところに関するおよその考えがあるのを必要とすると認めます。
Kempf, et al. Informational [Page 6] RFC 3154 Paging Requirements August 2001
ケンフ、他 2001年8月に要件を呼び出す情報[6ページ]のRFC3154
the Target Agent when it changes paging area. The IP paging protocol MAY additionally provide a way for the Host to inform the Tracking Agent what paging area it is in at some indeterminate point prior to entering dormant mode.
それであるときに、Targetエージェントは、領域を呼び出しながら、変化します。 IPページングプロトコルはさらに、Hostが、眠っているモードを入れる前に、それが何らかの不確定のポイントにどんなページング領域であるかをTrackingエージェントに知らせる方法を提供するかもしれません。
4.11. Efficient Utilization of L2
4.11. L2の効率的な利用
Recognizing that many existing wireless link protocols support paging at L2 and that these protocols are often intimately tied into the Host's dormant mode support, the IP paging protocol SHOULD provide support to efficiently utilize an L2 paging protocol if available.
多くの既存のワイヤレスのリンク・プロトコルがL2でページングをサポートして、これらのプロトコルがしばしば親密にHostの眠っているモードサポートに結び付けられると認めて、利用可能であるなら、IPページングプロトコルSHOULDは、効率的にL2ページングプロトコルを利用するためにサポートを提供します。
4.12. Orthogonality of Paging Area and Subnets
4.12. ページング領域とサブネットの直交性
The IP paging protocol MUST allow an arbitrary mapping between subnets and paging areas.
IPページングプロトコルはサブネットとページング領域の間の任意のマッピングを許容しなければなりません。
4.13. Future L3 Paging Support
4.13. 今後のL3ページングサポート
Recognizing that future dormant mode and wireless link protocols may be designed that more efficiently utilize IP, the IP paging protocol SHOULD NOT require L2 support for paging.
より効率的にIPを利用する将来の眠っているモードとワイヤレスのリンク・プロトコルが設計されるかもしれないと認めて、IPページングプロトコルSHOULD NOTはページングのL2サポートを必要とします。
4.14. Robustness Against Failure of Network Elements
4.14. ネットワークElementsの失敗に対する丈夫さ
The IP paging protocol MUST be designed to be robust with respect to failure of network elements involved in the protocol. The self- healing characteristics SHOULD NOT be any worse than existing routing protocols.
プロトコルに伴われるネットワーク要素の失敗に関して強健になるようにIPページングプロトコルを設計しなければなりません。 いずれかプロトコルを発送しながら存在するより悪かったなら特性のSHOULD NOTを癒している自己。
4.15. Reliability of Packet Delivery
4.15. パケット配信の信頼性
The IP paging protocol MUST be designed so that packet delivery is reliable to a high degree of probability. This does not necessarily mean that a reliable transport protocol is required.
パケット配信が高度合いの確率に信頼できるように、IPページングプロトコルを設計しなければなりません。 これは、必ず信頼できるトランスポート・プロトコルが必要であることを意味するというわけではありません。
4.16. Robustness Against Message Loss
4.16. メッセージの損失に対する丈夫さ
The IP paging protocol MUST be designed to be robust with respect to loss of messages.
メッセージの損失に関して強健になるようにIPページングプロトコルを設計しなければなりません。
4.17. Flexibility of Administration
4.17. 政権の柔軟性
The IP paging protocol SHOULD provide a way to flexibly auto- configure Paging Agents to reduce the amount of administration necessary in maintaining a wireless network with paging.
IPページングプロトコルSHOULDが柔軟に道を提供する、自動、構成、ワイヤレス・ネットワークを維持するのにおいてページングで必要な管理の量を減少させるPagingエージェント。
Kempf, et al. Informational [Page 7] RFC 3154 Paging Requirements August 2001
ケンフ、他 2001年8月に要件を呼び出す情報[7ページ]のRFC3154
4.18. Flexibility of Paging Area Design
4.18. ページング領域デザインの柔軟性
The IP paging protocol MUST be flexible in the support of different types of paging areas. Examples are fixed paging areas, where a fixed set of bases stations belong to the paging area for all Hosts, and customized paging areas, where the set of base stations is customized for each Host.
IPページングプロトコルは異なったタイプのページング領域のサポートでフレキシブルであるに違いありません。 例は領域を呼び出しながら、固定されています、固定セットのベースステーションはすべてのHostsのためにページング領域に属して、各Hostのために、カスタム設計されたページング領域(基地局のセットはカスタム設計される)に属すところで。
4.19. Availability of Security Support
4.19. セキュリティサポートの有用性
The IP paging protocol MUST have available authentication and encryption functionality at least equivalent to that provided by IPSEC [5].
IPページングプロトコルで、利用可能な認証と暗号化の機能性はIPSEC[5]によって提供されたそれに少なくとも同等にならなければなりません。
4.20. Authentication of Paging Location Registration
4.20. ページング位置登録の認証
The IP paging protocol MUST provide mutually authenticated paging location registration to insulate against replay attacks and to avoid the danger of malicious nodes registering for paging.
呼び出して、IPページングプロトコルは悪意があるノードが登録するという危険を反射攻撃に対して絶縁して、避ける互いに認証されたページング位置登録を提供しなければなりません。
4.21. Authentication of Paging Area Information
4.21. ページング領域情報の認証
The IP paging protocol MUST provide a mechanism for authenticating paging area information distributed by the Paging Agent.
IPページングプロトコルはPagingエージェントによって分配されたページング領域情報を認証するのにメカニズムを提供しなければなりません。
4.22. Authentication of Paging Messages
4.22. ページングメッセージの認証
The IP paging protocol MUST provide a mechanism for authenticating L3 paging messages sent by the Paging Agent to dormant mode Hosts. The protocol MUST support the use of L2 security mechanisms so implementations that take advantage of L2 paging can also be secured.
IPページングプロトコルはPagingエージェントによって眠っているモードHostsに送られたL3ページングメッセージを認証するのにメカニズムを提供しなければなりません。 プロトコルは、また、L2ページングを利用する実装を保証できるようにL2セキュリティー対策の使用をサポートしなければなりません。
4.23. Paging Volume
4.23. ページングボリューム
The IP paging protocol SHOULD be able to handle large numbers of paging requests without denying access to any legitimate Host nor degrading its performance.
どんな正統のHostへのアクセスも拒絶しないで多くのページング要求を扱うことができて、性能を下げながらプロトコルSHOULDを呼び出すIP。
4.24. Parsimonious Security Messaging
4.24. けちなセキュリティメッセージング
The security of the IP paging protocol SHOULD NOT call for additional power consumption while the Host is in dormant mode, nor require excessive message exchanges.
IPページングプロトコルSHOULD NOTのセキュリティは、Hostが眠っているモードである間、追加電力消費量を求めて、過度の交換処理を必要とします。
4.25. Noninterference with Host's Security Policy
4.25. ホストの安全保障政策との放任
The IP paging protocol MUST NOT impose any limitations on a Host's security policies.
IPページングプロトコルは少しの制限もHostの安全保障政策に課してはいけません。
Kempf, et al. Informational [Page 8] RFC 3154 Paging Requirements August 2001
ケンフ、他 2001年8月に要件を呼び出す情報[8ページ]のRFC3154
4.26. Noninterference with End-to-end Security
4.26. 終わりから終わりへのセキュリティとの放任
The IP paging protocol MUST NOT impose any limitations on a Host's ability to conduct end-to-end security.
IPページングプロトコルは終わりから終わりへのセキュリティを行うHostの性能に少しの制限も課してはいけません。
4.27. Detection of Bogus Correspondent Nodes
4.27. にせの通信員ノードの検出
The IP paging protocol SHOULD make provisions for detecting and ignoring bogus correspondent nodes prior to paging messages being wide cast on behalf of the correspondent node.
IPページングプロトコルSHOULDは通信員ノードを代表して広いメッセージを呼び出す前ににせの通信員ノードを検出して、無視するための条項を投げかけさせます。
5. Functional Architecture
5. 機能的な建築
In this section, a functional architecture is developed that describes the logical functional entities involved in IP paging and the interfaces between them. Please note that the logical architecture makes absolutely no commitment to any physical implementation of these functional entities whatsoever. A physical implementation may merge particular functional entities. For example, the Paging Agent, Tracking Agent, and Dormant Monitoring Agent may all be merged into one in a particular physical implementation. The purpose of the functional architecture is to identify the relevant system interfaces upon which protocol development may be required, but not to mandate that protocol development will be required on all.
このセクションに、論理的な機能的な実体について説明する開発された機能的な建築はそれらの間のIPにおけるページングとインタフェースにかかわりました。 論理的なアーキテクチャはこれらのどんな物理的な実装に関する公約も全く全く機能的な実体に絶対にしません。物理的な実装は特定の機能的な実体を合併するかもしれません。 例えば、Pagingエージェント、Trackingエージェント、およびDormant Monitoringエージェントは特定の物理的な実装で1つにすべて合併されるかもしれません。 機能的な建築の目的はプロトコル開発がすべてで必要であることを強制するのではなく、プロトコル開発が必要であるかもしれない関連システム・インタフェースを特定することです。
5.1. Functional Entities
5.1. 機能的な実体
The functional architecture contains the following elements:
機能的な建築は以下の要素を含んでいます:
Host - The Host (H) is a standard IP host in the sense of [4]. The
Host may be connected to a wired IP backbone through a wireless
link over which IP datagrams are exchanged (mobile usage pattern),
or it may be connected directly to a wired IP network, either
intermittently (nomadic usage pattern) or constantly (wired usage
pattern). The Host may support some type of IP mobility protocol
(for example, mobile IP [2] [3]). The Host is capable of entering
dormant mode in order to save power (see [1] for a detailed
discussion of dormant mode). The Host also supports a protocol
allowing the network to awaken it from dormant mode if a packet
arrives. This protocol may be a specialized L2 paging channel or
it may be a time-slotted dormant mode in which the Host
periodically wakes up and listens to L2 for IP traffic, the
details of the L2 implementation are not important. A dormant
Host is also responsible for determining when its paging area has
changed and for responding to changes in paging area by directly
ホスト--Host(H)は[4]の意味で標準のIPホストです。 HostがIPデータグラムが交換されるワイヤレスのリンク(モバイル用法パターン)を通してワイヤードなIPバックボーンに接続されるかもしれませんか、またはそれは断続的(遊牧民的な用法パターン)に絶えず(用法パターンを配線する)直接ワイヤードなIPネットワークに関連づけられるかもしれません。 Hostは、タイプのIPの移動性がプロトコルであるとサポートするかもしれません。(例えば、モバイルIP[2][3])。 Hostは、パワーを節約するために眠っているモードを入れることができます(眠っているモードの詳細な論議のための[1]を見てください)。 また、Hostはパケットが到着するならネットワークが眠っているモードからそれを目覚めさせることができるプロトコルをサポートします。 それがHostがIPトラフィックに関してL2を定期的に起こして、聞く時間で溝をつけられた眠っているモードであるかもしれない、このプロトコルは専門化しているL2ページングチャンネルであるかもしれませんかL2実装の詳細が重要ではありません。 また、休止状態のHostもページング領域がいつ変化したかを決定して、直接ページング領域の変化にこたえるのに責任があります。
Kempf, et al. Informational [Page 9] RFC 3154 Paging Requirements August 2001
ケンフ、他 2001年8月に要件を呼び出す情報[9ページ]のRFC3154
or indirectly informing the Tracking Agent about its location.
Since routers are presumed not to require dormant mode support, a
Host is never a router.
または、間接的に位置に関してTrackingエージェントに知らせること。 眠っているモードサポートはあえてルータが必要でないので、Hostは決してルータではありません。
Paging Agent - The Paging Agent is responsible for alerting the
Host when a packet arrives and the Host is in dormant mode.
Alerting of the Host proceeds through a protocol that is peculiar
to the L2 link and to the Host's dormant mode implementation,
though it may involve IP if supported by the L2. Additionally,
the Paging Agent maintains paging areas by periodically wide
casting information over the Host's link to identify the paging
area. The paging area information may be wide cast at L2 or it
may also involve IP. Each paging area is served by a unique
Paging Agent.
ページングエージェント--Pagingエージェントはパケットが到着して、Hostが眠っているモードであるときHostを警告するのに責任があります。 L2リンクと、そして、Hostの眠っているモード実装に独特のプロトコルを通したHostに関する警告しかける、L2によってサポートされるなら、IPにかかわるかもしれませんが。 さらに、Pagingエージェントは、ページング領域を特定するためにHostのリンクの上に定期的に広いキャスティング情報でページング領域を維持します。 ページング領域情報はL2の広いキャストであるかもしれませんかまた、それがIPにかかわるかもしれません。 それぞれのページング領域はユニークなPagingエージェントによって勤められます。
Tracking Agent - The Tracking Agent is responsible for tracking a
Host's location while it is in dormant mode or active mode, and
for determining when Host enters inactive mode. It receives
updates from a dormant Host when the Host changes paging area.
When a packet arrives for the Host at the Dormant Monitoring
Agent, the Tracking Agent is responsible for notifying the Dormant
Monitoring Agent, upon request, what Paging Agent is in the Host's
last reported paging area. There is a one to one mapping between
a Host and a Tracking Agent.
追跡エージェント--それが眠っているモードかアクティブなモードである間、Hostの位置を追跡して、Hostがいつ不活発なモードを入れるかを決定するのにTrackingエージェントは責任があります。 Hostが領域を呼び出しながら変化するとき、それは休止状態のHostからアップデートを受けます。 パケットがHostのためにDormant Monitoringエージェントに到着するとき、TrackingエージェントはDormant Monitoringエージェントに通知するのに責任があります、Pagingエージェントが要求、Hostの最後に報告されたページング領域の者であるのに。 HostとTrackingエージェントの間には、1〜1つのマッピングがあります。
Dormant Monitoring Agent - The Dormant Monitoring Agent detects
the delivery of packets to a Host that is in Dormant Mode (and
thus does not have an active L2 connection to the Internet). It
is the responsibility of the Dormant Monitoring Agent to query the
Tracking Agent for the last known Paging Agent for the Host, and
inform the Paging Agent to page the Host. Once the Paging Agent
has reported that a routable connection to the Internet exists to
the Host, the Dormant Monitoring Agent arranges for delivery of
the packet to the Host. In addition, the Host or its Tracking
Agent may select a Dormant Monitoring Agent for a Host when the
Host enters dormant mode, and periodically as the Host changes
paging area.
眠っているMonitoringエージェント--Dormant MonitoringエージェントはDormant Mode(そして、その結果、インターネットには活発なL2接続がない)にあるHostにパケットの配信を検出します。 Hostの最後に知られているPagingエージェントのためにTrackingエージェントについて質問して、Hostを呼び出すためにPagingエージェントに知らせるのは、Dormant Monitoringエージェントの責任です。 Pagingエージェントが、インターネットとの発送可能接続がHostに存在するといったん報告すると、Dormant Monitoringエージェントはパケットの配送をHostに準備します。 Hostが領域を呼び出しながら変化するのに従ってHostが定期的に眠っているモードを入れるとき、さらに、HostかそのTrackingエージェントがHostのためにDormant Monitoringエージェントを選ぶかもしれません。
5.2. Interfaces
5.2. インタフェース
The functional architecture generates the following list of interfaces. Note that the interfaces between functional entities that are combined into a single network element will require no protocol development.
機能的な建築はインタフェースの以下のリストを生成します。 ただ一つのネットワーク要素に結合される機能的な実体の間のインタフェースがプロトコル開発を全く必要としないことに注意してください。
Host - Paging Agent (H-PA) - The H-PA interface supports the
following types of traffic:
ホスト--ページングエージェント(H-PA)--H-PAインタフェースは以下のタイプのトラフィックをサポートします:
Kempf, et al. Informational [Page 10] RFC 3154 Paging Requirements August 2001
ケンフ、他 2001年8月に要件を呼び出す情報[10ページ]のRFC3154
- Wide casting of paging area information from the Paging
Agent.
- Pagingエージェントからのページング領域情報の広いキャスティング。
- The Paging Agent alerting the Host when informed by the
Dormant Monitoring Agent that a packet has arrived.
- パケットにはいるDormant Monitoringエージェントによって知らされると、Hostを警告しているPagingエージェントは到着しました。
Host - Tracking Agent (H-TA) - The H-TA interface supports the
following types of traffic:
ホスト--追跡エージェント(H-TA)--H-TAインタフェースは以下のタイプのトラフィックをサポートします:
- The Host informing the Tracking Agent when it has changed
paging area, and, optionally, prior to entering dormant
mode, in what paging area it is located.
- 領域を呼び出しながら変化したときに時とそれがどんなページング領域であるかで位置する眠っているモードを入れる任意に前にTrackingエージェントに知らせるHost。
- Optionally, the Host informs the Tracking Agent at a planned
transition to inactive mode.
- 任意に、Hostは不活発なモードへの計画された変遷のときにTrackingエージェントに知らせます。
Dormant Monitoring Agent - Tracking Agent (DMA-TA) - The DMA-TA
interface supports the following types of traffic:
眠っているMonitoringエージェント--追跡エージェント(DMA-TA)--DMA-TAインタフェースは以下のタイプのトラフィックをサポートします:
- A report from the Dormant Monitoring Agent to the Tracking
Agent that a packet has arrived for a dormant Host for which
no route is available.
- パケットがルートがないのが利用可能である休止状態のHostのために到着したというDormant MonitoringエージェントからTrackingエージェントまでのレポート。
- A report from the Tracking Agent to the Dormant Monitoring
Agent giving the Paging Agent to contact in order to page
the Host.
- TrackingエージェントからHostを呼び出すために連絡するPagingエージェントに与えるDormant Monitoringエージェントまでのレポート。
- A report from the Tracking Agent to the Dormant Monitoring
Agent that a Host has entered inactive mode, if not provided
directly by the Host
- 直接Hostによって提供されないならHostが不活発なモードを入れたというTrackingエージェントからDormant Monitoringエージェントまでのレポート
- A report from the Tracking Agent to the Dormant Monitoring
Agent that a Host has entered dormant mode, if not provided
directly by the Host.
- 直接Hostによって提供されないならHostが眠っているモードを入れたというTrackingエージェントからDormant Monitoringエージェントまでのレポート。
Dormant Monitoring Agent - Paging Agent (DMA-PA) - The DMA-PA
interface supports the following types of traffic:
眠っているMonitoringエージェント--ページングエージェント(DMA-PA)--DMA-PAインタフェースは以下のタイプのトラフィックをサポートします:
- A request from the Dormant Monitoring Agent to the Paging
Agent to page a particular Host in dormant mode because a
packet has arrived for the Host.
- Dormant MonitoringエージェントからパケットがHostのために到着したので眠っているモードで特定のHostを呼び出すPagingエージェントまでの要求。
- Negative response indication from the Paging Agent if the
Host does not respond to a page.
- Pagingエージェントからの否定応答指示はHostであるなら1ページまで応じません。
- Positive response from the Paging Agent indication if the
Host does respond to a page.
- Pagingエージェント指示からの積極的な応答はHostであるなら1ページまで応じます。
Kempf, et al. Informational [Page 11] RFC 3154 Paging Requirements August 2001
ケンフ、他 2001年8月に要件を呼び出す情報[11ページ]のRFC3154
- Delivery of the packet to the Host.
- Hostへのパケットの配送。
Host - Dormant Monitoring Agent (H-DMA) - The H-DMA interface
supports the following types of traffic:
ホスト--眠っているMonitoringエージェント(H-DMA)--H-DMAインタフェースは以下のタイプの交通を支持します:
- The Host registers to the Dormant Monitoring Agent prior to
entering dormant mode, (if needed) with filtering
information on which broadcast/multicast/anycast packets
trigger a page.
- 眠っているモードを入れる前にHostはDormant Monitoringエージェントに登録して、フィルタリング情報がオンのどの(必要であるなら)放送/マルチキャスト/anycastパケット引き金が1ページであるか。
- The Host informs the Dormant Monitoring Agent, when it
directly deregisters from the Dormant Monitoring Agent due
to a change from dormant mode to active or inactive mode.
- それであるときに、aのため、HostはDormant Monitoringエージェントに知らせて、直接、Dormant Monitoringエージェントからの「反-レジスタ」は眠っているモードからアクティブであるか不活発なモードに変化します。
5.3. Functional Architecture Diagram
5.3. 機能的な建築ダイヤグラム
The functional architecture and interfaces lead to the following diagram.
機能的な建築とインタフェースは以下のダイヤグラムにつながります。
+------+ H-TA +----------+
| Host | <----------------------> | Tracking |
+------+ | Agent |
^ ^ +----------+
| | H-DMA ^
| +------------------------------+ |
| | | DMA-TA
| | |
| H-PA | |
v v v
+--------+ DMA-PA +------------+
| Paging | <--------------------> | Dormant |
| Agent | | Monitoring |
+--------+ | Agent |
+------------+
+------+、H、-、バイバイ、+----------+ | ホスト| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| 追跡| +------+ | エージェント| ^ ^ +----------+ | | H-DMA^| +------------------------------+ | | | | DMA、-、バイバイ。| | | | H-PA| | v対+に--------+ DMA-PA+------------+ | ページング| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| 眠る| | エージェント| | モニターであること| +--------+ | エージェント| +------------+
Figure 1 - Paging Functional Architecture
図1--ページング機能的な建築
6. Acknowledgements
6. 承認
The authors would like to thank Arthur Ross for helpful comments on this memo.
作者はこのメモの上で役に立つコメントについてアーサー・ロスに感謝したがっています。
Kempf, et al. Informational [Page 12] RFC 3154 Paging Requirements August 2001
ケンフ、他 2001年8月に要件を呼び出す情報[12ページ]のRFC3154
7. References
7. 参照
[1] Kempf, J., "Dormant Mode Host Alerting ("IP Paging") Problem
Statement", RFC 3132, June 2001.
[1] ケンフ、J.、「眠っているモードホスト警告(「IPページング」)問題声明」、RFC3132、2001年6月。
[2] Perkins, C., ed., "IP Mobility Support", RFC 2002, October,
1996.
[2] パーキンス、C.、教育、「IP移動性サポート」、RFC2002、10月、1996
[3] Johnson, D., and Perkins, C., "Mobility Support in Ipv6", Work
in Progress.
[3] ジョンソン、D.とパーキンス、C.、「Ipv6"での移動性サポート、進行中の仕事。」
[4] Braden, R., "Requirements for Internet Hosts - Communication
Layers", STD 3, RFC 1122, October 1989.
[4] ブレーデン、R.、「インターネットのためのホスト--コミュニケーションが層にされるという要件」、STD3、RFC1122、10月1989日
[5] Kent, S., and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
1998年11月の[5] ケント、S.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」RFC2401。
8. Authors' Addresses
8. 作者のアドレス
James Kempf Sun Microsystems Laboratories 901 San Antonio Rd. UMTV29-235 Palo Alto, CA 95303-4900 USA
ジェームスケンフサン・マイクロシステムズ研究所901サンアントニオ通り UMTV29-235カリフォルニア95303-4900パロアルト(米国)
Phone: +1 650 336 1684 Fax: +1 650 691 0893 EMail: James.Kempf@Sun.COM
以下に電話をしてください。 +1 650 336、1684Fax: +1 0893年の650 691メール: James.Kempf@Sun.COM
Pars Mutaf INRIA Rhone-Alpes 655 avenue de l'Europe 38330 Montbonnot Saint-Martin FRANCE
パルスMutaf INRIAローヌアルプ655大通りde l'Europe38330Montbonnotサンマルタンフランス
Phone: Fax: +33 4 76 61 52 52 EMail: pars.mutaf@inria.fr
以下に電話をしてください。 Fax: +33 4 76 61 52 52はメールされます: pars.mutaf@inria.fr
Kempf, et al. Informational [Page 13] RFC 3154 Paging Requirements August 2001
ケンフ、他 2001年8月に要件を呼び出す情報[13ページ]のRFC3154
Claude Castelluccia INRIA Rhone-Alpes 655 avenue de l'Europe 38330 Montbonnot Saint-Martin FRANCE
クロードCastelluccia INRIAローヌアルプ655大通りde l'Europe38330Montbonnotサンマルタンフランス
Phone: +33 4 76 61 52 15 Fax: +33 4 76 61 52 52 EMail: claude.castelluccia@inria.fr
以下に電話をしてください。 +33 4 76 61 52 15、Fax: +33 4 76 61 52 52はメールされます: claude.castelluccia@inria.fr
Nobuyasu Nakajima Toshiba America Research, Inc. P.O. Box 136 Convent Station, NJ 07961-0136 USA
Nobuyasu Nakajima東芝アメリカ研究Inc.私書箱136修道院駅、ニュージャージー07961-0136米国
Phone: +1 973 829 4752 EMail: nnakajima@tari.toshiba.com
以下に電話をしてください。 +1 4752年の973 829メール: nnakajima@tari.toshiba.com
Yoshihiro Ohba Toshiba America Research, Inc. P.O. Box 136 Convent Station, NJ 07961-0136 USA
芳広オオバ東芝アメリカ研究Inc.私書箱136修道院駅、ニュージャージー07961-0136米国
Phone: +1 973 829 5174 Fax: +1 973 829 5601 EMail: yohba@tari.toshiba.com
以下に電話をしてください。 +1 973 829、5174Fax: +1 5601年の973 829メール: yohba@tari.toshiba.com
Ramachandran Ramjee Bell Labs, Lucent Technologies Room 4g-526 101 Crawfords Corner Road Holmdel, NJ 07733 USA
ラマチャンドランRamjeeベル研究所、余地の4g-526 101Crawfordsコーナー道路Holmdel、ルーセントテクノロジーズニュージャージー07733米国
Phone: +1 732 949 3306 Fax: +1 732 949 4513 EMail: ramjee@bell-labs.com
以下に電話をしてください。 +1 732 949、3306Fax: +1 4513年の732 949メール: ramjee@bell-labs.com
Kempf, et al. Informational [Page 14] RFC 3154 Paging Requirements August 2001
ケンフ、他 2001年8月に要件を呼び出す情報[14ページ]のRFC3154
Yousuf Saifullah Nokia Research Center 6000 Connection Dr. Irving, TX 75039 USA
ユーセフSaifullahノキアResearch Center6000接続アービングテキサス75039博士(米国)
Phone: +1 972 894 6966 Fax: +1 972 894 4589 EMail: Yousuf.Saifullah@nokia.com
以下に電話をしてください。 +1 972 894、6966Fax: +1 4589年の972 894メール: Yousuf.Saifullah@nokia.com
Behcet Sarikaya Alcatel USA, M/S CT02 1201 Campbell Rd. Richardson, TX 75081-1936 USA
Behcet Sarikayaアルカテル米国、M/S CT02 1201キャンベル通り テキサス75081-1936リチャードソン(米国)
Phone: +1 972 996 5075 Fax: +1 972 996 5174 EMail: Behcet.Sarikaya@usa.alcatel.com
以下に電話をしてください。 +1 972 996、5075Fax: +1 5174年の972 996メール: Behcet.Sarikaya@usa.alcatel.com
Xiaofeng Xu Alcatel USA, M/S CT02 1201 Campbell Rd. Richardson, TX 75081-1936 USA
Xiaofengシューアルカテル米国、M/S CT02 1201キャンベル通り テキサス75081-1936リチャードソン(米国)
Phone: +1 972 996 2047 Fax: +1 972 996 5174 Email: xiaofeng.xu@usa.alcatel.com
以下に電話をしてください。 +1 972 996、2047Fax: +1 5174年の972 996メール: xiaofeng.xu@usa.alcatel.com
Kempf, et al. Informational [Page 15] RFC 3154 Paging Requirements August 2001
ケンフ、他 2001年8月に要件を呼び出す情報[15ページ]のRFC3154
9. Full Copyright Statement
9. 完全な著作権宣言文
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Kempf, et al. Informational [Page 16]
ケンフ、他 情報[16ページ]
一覧
スポンサーリンク
