Network Working Group W. Simpson Request for Comments: 1688 Daydreamer Category: Informational August 1994 IPng Mobility Considerations |次世代IPのモバイル性考察 Status of this Memo |このメモの状態 This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited. |このメモはインターネットコミュニティに対し情報を提供するものである。 |このメモはいかなるインターネット標準をも規定するものではない。この |メモの配布に制限はない。 Abstract |概要 This document was submitted to the IPng Area in response to RFC 1550. Publication of this document does not imply acceptance by the IPng Area of any ideas expressed within. Comments should be submitted to the big-internet@munnari.oz.au mailing list. This RFC specifies criteria related to mobility for consideration in design and selection of the Next Generation of IP. |このドキュメントは RFC1550 に対する回答として IPngエリア に提出された。 |このドキュメントの公開が、この中で表現されている幾つかのアイデアが、 |IPngエリアによって受理されたことを示しているわけではない。コメントは |big-internet@munnari.oz.au メーリングリストに提出すべきである。この |RFCは 次世代(Next Generation)IPの設計と選択を考察する際の、モバイル |性に関する基準について記述する。 Table of Contents |内容一覧 1. Introduction .......................................... 2 2. Addressing ............................................ 2 2.1 Ownership ....................................... 2 2.2 Topology ........................................ 3 2.3 Manufacturer .................................... 3 2.4 Numbering ....................................... 3 2.5 Configuration ................................... 3 3. Communication ......................................... 3 3.1 Topological Changes ............................. 4 3.2 Routing Updates ................................. 4 3.3 Path Optimization ............................... 5 3.4 At Home ......................................... 5 3.5 Away From Home .................................. 5 4. Security .............................................. 5 4.1 Authentication .................................. 5 4.2 Anonymity ....................................... 6 4.3 Location Privacy ................................ 6 4.4 Content Privacy ................................. 6 5. Bandwidth ............................................. 6 5.1 Administrative Messages ......................... 7 5.2 Response Time ................................... 7 5.3 Header Prediction ............................... 8 6. Processing ............................................ 8 6.1 Fixed Location .................................. 8 6.2 Simple Fields ................................... 9 6.3 Simple Tests .................................... 9 6.4 Type, Length, Value ............................. 9 Acknowledgements ............................................. 9 Security Considerations ...................................... 9 Author's Address ............................................. 9 1. Introduction |はじめに Current versions of the Internet Protocol make an implicit assumption that a node's point of attachment remains fixed. Datagrams are sent to a node based on the location information contained in the node's IP address. |インターネットプロトコルの現在のバージョンは、ノードの接続ポイントが |固定されたままであることを事実上の仮定としている。データグラムはノード |の IPアドレスに含まれた位置情報を基準にしてノードに送信される。 If a node moves while keeping its IP address unchanged, its IP network number will not reflect its new point of attachment. The routing protocols will not be able to route datagrams to it correctly. |その IPアドレスを変更しないままでノードが移動するならば、その IPネット |ワーク番号はその新しい接続ポイントを示さなくなるであろう。ルーティング・ |プロトコルはデータグラムを正しくルーティングすることができなくなる。 A number of considerations arise for routing these datagrams to a Mobile Node. |モバイルノードのための、これらのデータグラムのルーティングに対する |多数の研究課題が発生している。 2. Addressing |アドレッシング Each Mobile Node must have at least one Home-Address which identifies it to other nodes. This Home-Address must be globally unique. |各モバイルノードは、ほかのノードとそれを識別する少なくとも1つのホーム |アドレスを持たなければならない。このホームアドレスはグローバルでユニーク |でなければならない。 2.1. Ownership |所有者 The presence of ownership information in the Home-Address would be beneficial. A Mobile Node will be assigned a Home-Address by the organization that owns the machine, and will be able to use that Home-Address regardless of the current point of attachment. |ホームアドレスの中の所有者情報の存在は有益である。モバイルノード |にはマシンを所持する組織・団体によってホームアドレスが割当てられ、 |現在の接続ポイントに関係なく、ホームアドレスを使用することが可能 |になる。 The ownership information must be organized in such a fashion to facilitate "inverse" lookup in the Domain Name Service, and other future services. |所有者情報は DNS(Domain Name Service)の「逆」検索や、その他の |将来のサービスを容易にするような形に構成されなければならない。 Ownership information could be used by other nodes to ascertain the current topological location of the Mobile Node. |所有者情報はモバイルモードの現在のトポロジカル・ロケーションを |確かめるために他のノードによって使用されることが可能である。 Ownership information could also be used for generation of accounting records. |所有者情報は課金記録を作成するために使用されることもまた可能である。 2.2. Topology |トポロジー There is no requirement that the Home-Address contain topological information. Indeed, by the very nature of mobility, any such topological information is irrelevant. |ホームアドレスにトポロジカル情報を含める必要はない。実際、モバイル性の |まさにその性質によって、いかなるそのようなトポロジカル情報も重要でない。 Topological information in the Home-Address must not hinder mobility, whether by prevention of relocation, or by wasting bandwidth or processing efficiency. |ホームアドレス内のトポロジカル情報が、再配置を抑止するか、帯域又は |プロセッサ効率を無駄にする、そのいずれかによって、モバイル性を妨げて |はならない。 2.3. Manufacturer |製造元 There is no requirement that the Home-Address contain manufacturer information. |ホームアドレスに製造元情報を含める必要はない。 Manufacturer information in the Home-Address must not hinder mobility, whether by prevention of relocation, or by wasting bandwidth or processing efficiency. |ホームアドレス内の製造元情報が、再配置を抑止するか、帯域又はプロセッサ |効率を無駄にする、そのいずれかによって、モバイル性を妨げてはならない。 2.4. Numbering |番号付け The number of mobile nodes is expected to be constrained by the population of users within the lifetime of the IPng protocol. The maximum world-wide sustainable population is estimated as 16e9, although during the lifetime of IPng the population is not expected to exceed 8e9. |モバイルノードの数は次世代IPプロトコルの生存時間内のユーザ人口に |よって制約されることが予想される。世界中で耐えうる人口の最大は |160億と見積もられているが、次世代IP人口の生存時間の間では、80億を |越えないと予測されている。 Each user is assumed to be mobile, and to have a maximum combined personal mobile and home network(s) on the order of 4e3 nodes. |各ユーザは移動し、パーソナルモバイルとホームネットワークを合わせて |最大で 4000ノードを持っていると仮定する。 The expectation is that only 46 bits will be needed to densely number all mobile and home nodes. |この予測は、全モバイル及びノード数に連続した数で 46ビットだけ必要と |されるということである。 The size of addressing elements is also constrained by bandwidth efficiency and processing efficiency, as described later. |後で記述するように、アドレッシング・エレメントのサイズは帯域効率と |処理効率によっても制約される。 2.5. Configuration |構成 Since the typical user would be unlikely to be aware of or willing and able to maintain 4e3 nodes, the assignment of Home-Addresses must be automatically configurable. Registration of the nodes must be dynamic and transparent to the user, both at home and away from home. |典型的なユーザが、4000のノードを自発的にいとわずメンテナンスできると |は考えられないので、ホームアドレスの割当ては自動で設定可能でなければ |ならない。ノードの登録は、ホームの中とホームから離れた両方で、動的で |かつ、ユーザに透過でなければならない。 3. Communication |通信 A Mobile Node must continue to be capable of communicating directly with other nodes which do not implement mobility functions. |モバイルノードはモバイル機能が実装されていない他のノードとも直接に |通信することが可能であり続けなければならない。 No protocol enhancements are required in hosts or routers that are not serving any of the mobility functions. Similarly, no additional protocols are needed by a router (that is not acting as a Home Agent or a Foreign Agent) to route datagrams to or from a Mobile Node. |いかなるモバイル機能も提供されないホスト又はルータには、プロトコルの |拡張が必要とされない。同様に(ホームエージェント又は外部エージェント |として動作しない)ルータによる、モバイルノードへ/モバイルノードから |データグラムをルーティングするための追加プロトコルは必要とされない。 A Mobile Node using its Home-Address must be able to communicate with other nodes after having been disconnected from the Internet, and then reconnected at a different point of attachment. |そのホームアドレスを使用するモバイルノードはインターネットから切断 |した後で他のノードと通信可能でなければならず、異なる接続ポイントで |再接続できなければならない。 A Mobile Node using its Home-Address must be able to communicate with other nodes while roaming between different points of attachment, without loss of transport connections. |そのホームアドレスを使用するモバイルノードは、トランスポートのコネク |ションを失うことなく、異なる接続ポイント間でローミングしている間も、 |他のノードと通信できなければならない。 3.1. Topological Changes |トポロジカル・チェンジ In order that transport connections be maintained while roaming, topological changes must not affect transport connections. |ローミング中もトランスポートのコネクションを維持するために、 |トポロジカル・チェンジはトランスポート・コネクションに影響を |与えてはならない。 For correspondent nodes which do not implement mobility functions, topological changes should not be communicated to the correspondent. |モバイル機能を実装していない相手ノードのために、トポロジカル・ |チェンジは通信相手に対し伝達される必要がない。 For correspondent nodes which implement mobility functions, the correspondent should be capable of determining topological changes. |モバイル機能を実装している相手ノードのために、その通信相手は |トポロジカル・チェンジを判断することが可能であるべきである。 Topological change information must be capable of insertion and removal by routers in the datagram path, as well as by the correspondent and Mobile Node. |トポロジカル・チェンジ情報は、通信相手やモバイルノード |によるものと同じように、データグラムパス内のルータに |よって挿入と除去が可能でなければならない。 3.2. Routing Updates |ルーティング・アップデート Mobile Nodes are expected to be able to change their point of attachment no more frequently than once per second. |モバイルノードは1秒間に1回よりも多くない頻度での接続ポイントの変更 |が可能であること期待される。 Changes in topology which occur more frequently must be handled at the link layer transparently to the internetwork layer. It is further noted that engineering margins may require the link layer to handle all changes at a frequency in the neighborhood of 10 seconds. |より頻繁に生じるトポロジーでの変更は、インターネットワーク・レイヤ |に対し透過なリンクレイヤで扱われなければならない。技術的なマージン |が、ほぼ 10秒の間隔で全ての変更を処理することをリンクレイヤに要求 |することに注意。 Changes in topology which occur less frequently must be immediately reflected in the mobility updates. This may preclude the use of the Domain Name Service as the repository of mobility topological information. |あまり頻繁でないトポロジーの変更は、モビリティ・アップデートですぐに |反映されなければならない。これは、モビリティ・トポロジカル・インフォ |メーションのリポジトリ(/貯蔵庫)として DNS を使用することを妨げるかも |しれない。 It must be noted that global routing updates do not operate at this frequency. As old topological information may be obsoleted faster than global routing updates, access to the repository of mobility topological information must be independent of prior topological information. |グローバルなルーティング・アップデートがこの頻度で動作しないことに |注意しなければならない。グローバルなルーティング・アップデートよりも |早く、古いトポロジカル情報が破棄される際には、モビリティ・トポロジカル |情報のリポジトリへのアクセスは、先のトポロジカル情報と独立して行なわ |なければならない。 The mobility specific repository should use ownership information in the Home-Address for access to the repository. |モビリティ・スペシフィック・レポジトリはレポジトリにアクセスするための |ホームアドレスの所有者情報を使用すべきである。 3.3. Path Optimization |パス最適化 Optimization of the path from a correspondent to a mobile node is not required. However, such optimization is desirable. |通信相手からモバイルノードへのパスの最適化は必要ではない。しかし、 |このような最適化は望ましい。 For correspondent nodes which implement mobility functions, the correspondent should be capable of determining the optimal path. |モバイル機能を実装した相手ノードに対し、通信相手は最適なパスを |決定することが可能であるべきである。 The optimization mechanism is also constrained by security, bandwidth efficiency and processing efficiency, as described later. |最適化メカニズムは後で記述するように、セキュリティ、帯域効率、及び |処理効率によっても制約される。 3.4. At Home |ホームで Mobile Nodes do not require special "virtual" home network addresses. The assumption that extra addresses or multiple routers are available is unwarranted in small networks. |モバイルノードは特別な「仮想」ホーム・ネットワーク・アドレスを必要と |しない。余分なアドレス又は複数のルータか使用可能であるという仮定は、 |小さなネットワークにおいて不適切である。 Mobile Nodes must operate without special assistance from routers in order to communicate directly with other nodes on the home subnetwork link. |モバイルノードはホームのサブネットリンクで他のノードと直接通信する |ためのルータから特別な支援なしに動作しなければならない。 3.5. Away From Home |ホームから離れて When a router is present, and the correspondent does not implement mobility functions, the router must be capable of redirecting the correspondent to communicate directly with the Mobile Node. |ルータが存在し、その通信相手がモバイル機能を実装していないならば、 |ルータは通信相手がモバイルノードと直接に通信できるよう、リダイレクト |が可能でなければならない。 When no router is present, Mobile Nodes must be capable of communicating directly with other nodes on the same link. |ルータが存在しないならば、モバイルノードは同じリンク上の他のノードと |直接通信が可能でなければならない。 Mobility must not create an environment which is less secure than the current Internet. |モバイルは現在のインターネットよりも安全でない環境を作ってはならない。 Changes in topology must not affect internode security mechanisms. |トポロジーの変更は内部ノードのセキュリティ・メカニズムに影響を与えては |ならない。 4. Security |セキュリティ 4.1. Authentication |認証 Mobility registration messages must be authenticated between the home topological repository and Mobile Node. |モビリティ・レジストレーション・メッセージはホーム・トポロジカル・ |レポジトリとモバイルノード間で認証されなければならない。 When the correspondent implements mobility functions, redirection or path optimization must be authenticated between the correspondent and Mobile Node. |通信相手がモバイル機能を実装しているならば、リダイレクション又は |パスの最適化は、その通信相手とモバイルノード間で認証されなければ |ならない。 4.2. Anonymity |匿名性 The capability to attach to a foreign administrative domain without the awareness of the foreign administration is not prohibited. However, any mobility mechanism must provide the ability to prevent such attachment. |外部管理であることを認識することなく、外部管理ドメインに対して接続 |する能力は禁止されない。しかしながら、いかなるモバイル・メカニズムも |このような接続を抑止する能力を提供しなければならない 4.3. Location Privacy |ロケーション・プライバシ The capability to attach to a foreign administrative domain without the awareness of correspondents is not prohibited. However, any mobility mechanism must provide the ability for the home administration to trace the current path to the point of attachment. |相手を認識することなく外部管理ドメインに接続する能力は禁止されない。 |しかしながら、いかなるモバイル・メカニズムも、ホーム管理に現在の |接続ポイントへのパスをトレースする能力を提供しなければならない。 4.4. Content Privacy |コンテンツ・プライバシ Security mechanisms which provide content privacy must not obscure or have a dependency on the topological location of Mobile Nodes. |コンテンツ・プライバシを提供するセキュリティ・メカニズムはモバイル |ノードのトポロジカル・ローケーションに隠蔽又は依存していてはならない。 5. Bandwidth |帯域 Mobility must operate in the current link environment, and must not be dependent on bandwidth improvements. The Mobile Node's directly attached link is likely to be bandwidth limited. |モバイルは現在のリンク環境で動作しなければならず、帯域が改善される |ことに頼っていてはならない。モバイルノードの直接接続リンクは、帯域 |が制限されがちである。 In particular, radio frequency spectrum is already a scarce commodity. Higher bandwidth links are likely to continue to be scarce in the mobile environment. |特に、無線周波数スペクトラムは既に不足している。より高い帯域リンクは |モバイル環境で不足しつづけるであろう。 Current applications of mobility using radio links include HF links which are subject to serious fading and noise constraints, VHF and UHF line of sight radio between ships or field sites, and UHF Satellite Communications links. |無線リンクを使用するモバイルの現在のアプリケーションには、重大な |フェージングとノイズ制約を受けやすいHFリンクと、船又は地上サイト |間でのサイト無線の VHF 及び UHF ラインと、UHF衛生通信リンクが含ま |れている。 The HF radio bandwidth is fixed at 1200 or 2400 bps by international treaty, statute, and custom, and is not likely to change. |HF無線帯域は、国際条約、法令、及び慣習によって、1200又は2400bpsに |固定されていて、変化しそうにない。 The European standard for cellular radio is 2400 bps GSM. |セルラー無線のヨーロッパの標準は 2400 bps GSM である。 The most prevalent deployed analog cellular and land-line modulation used by mobile nodes is 2400 bps. |最も普及して配置されたアナログセルラーとモバイルノードによって使用 |された陸上ライン変調は 2400bps である。 Current digital cellular deployment is 19,200 bps CDPD shared among many users. At early installations, under light loads, effective FTP throughput has been observed as low as 200 bps. |現在展開されているデジタルセルラーは 19200bps CDPD を多くのユーザ間 |で共有している。初期の設備で軽い負荷の下で、有効 FTP スループットは |200bsp 程度の遅さで観測されている。 Future digital cellular deployment is 9,600 and 14,400 bps CDMA, which is shared between voice and data on a per user basis. |将来展開されるデジタルセルラーは 9600 と 14400 bps CDMA で、 |ユーザベース毎に音声とデータを共有する。 Effective FTP throughput has been measured as low as 7,200 bps. |有効なFTPスループットは 7200bps 程度の遅さで測定されている。 Future Personal Communications Services (PCS) will also have relatively little bandwidth. In industrialized nations, the bandwidth available to each user is constrained by the density of deployment, and is commensurate with planned digital cellular deployment. |将来の PCS(Personal Communications Services) もまた比較的小さい |帯域幅を持つであろう。先進国において、各ユーザへの利用可能帯域は、 |展開の密度に制約され、計画されたデジタルセルラの展開と一致する。 It appears likely that satellite-based PCS will be widely deployed for basic telephony communications in many newly-industrialized and lesser-developed countries. There is already significant PCS interest in East and SouthEast Asia, India, and South America. |多くの新興国と未発展な国では基本的な電話通信にサテライトベースPCSが |広く展開されると思われる。東及び東南アジア、インド、及び南アメリカ |では、すでに重要な PCS への関心がある。 Van Jacobson header prediction is widely used, and essential to making the use of such links viable. |ヴァン・ジャコブソンのヘッダ予測は広く使用されていて、このような |リンクの使用を可能にするために必須である。 5.1. Administrative Messages |管理メッセージ The number of administrative mobility messages sent or received by the Mobile Node must be limited to as few as possible. In order to meet the frequency requirement of changing point of attachment once per second, registration of changes must not require more than a single request and reply. |モバイルノードによって送信され又は受信される管理モビリティ・メッ |セージの数は可能な限り少なく制限されなければならない。1秒毎に1回 |の接続ポイントの周期的な変更の要求を満たすために、変更の登録に1回 |のリクエストとリプライをこえた要求をしてはならない。 The size of administrative mobility messages must be kept as short as possible. In order to meet the frequency requirement of changing point of attachment once per second, the registration messages must not total more than 120 bytes for a complete transaction, including link and internet headers. |管理モビリティ・メッセージのサイズは可能な限り短く維持しなければ |ならない。1秒毎に1回の接続ポイントの周期的な変更の要求を満たす |ための登録メッセージは、リンクとインターネットヘッダーを含み、完全 |なトランザクションで、合計で120バイトを越えてはならない。 5.2. Response Time |レスポンスタイム For most mobile links in current use, the typical TCP/IPv4 datagram overhead of 40 bytes is too large to maintain an acceptable typing response of 200 milliseconds round trip time. |現在使用されているほとんどのモバイルリンクで、40バイトの典型的な |TCP/IPv4データグラムのオーバーヘッドは、受け付け可能な200ミリ秒の |タイピング応答を維持するには大きすぎる。 Therefore, the criteria for IPng mobility is that the response time not be perceptably worse than IPv4. |したがって、次世代IPモバイルの基準は、レスポンス・タイムが IPv4 |よりも際立って悪くないことである。 This allows no more than 6 bytes of additional overhead per datagram to be added by IPng. |これは、6バイトを越えない次世代IPによって追加されるデータグラム毎の |追加オーバーヘッドを許す。 This was a primary concern in the design of mobility forwarding headers. Larger headers were rejected outright, and negotiation is provided for smaller headers than the default method. Topological headers are removed by the Foreign Agent prior to datagram transmission over the slower link to the Mobile Node, which also aids header prediction, as described below. |これはモビリティ・フォワーディング・ヘッダを設計する際の基本的な |関心である。より大きなヘッダは完全に拒絶され、ネゴシエーションは |デフォルトの方法よりもより小さなヘッダで提供される。トポロジカル |ヘッダは以下に記述するように、モバイルモードへのより遅いリンク上 |でデータグラム転送の前に外部エージェント優先によって削除され、 |ヘッダ予測の補助も行なう。 5.3. Header Prediction |ヘッダ予測 Header prediction can be useful in reducing bandwidth usage on multiple related datagrams. It requires a point-to-point peer relationship between nodes, so that a header history can be maintained between the peers. |ヘッダ予測は複数の関連するデータグラムで帯域使用の削減に利用することが |できる。これはノード間はポイント・ツー・ポイントのピアの関係であり、 |ヘッダの履歴がそのピア間で保持されていることが要求される。 Header prediction is less effective in mobile environments, as the header history is lost each time a Mobile Node changes its point of attachment. The new Foreign Agent will not have the same history as the previous Agent. |ヘッダ履歴がモバイルノードのその接続ポイントの変更の度に毎回失われる |ようなモバイル環境では、ヘッダ予測の効果が失われる。新しい外部エージェ |ントは、以前のエージェントと同じ履歴を持っていないであろう。 In order for header prediction to operate successfully, changing topological information must be removed from datagram overhead prior to transmission of the datagram on any final hop's directly attached link. This applies to both the Mobile Node peering with a Foreign Agent, and also the final link to a Correspondent. Otherwise, header prediction cannot be relied upon to improve bandwidth utilization on low-speed Mobile and Correspondent links. |ヘッダ予測の動作を成功させるために、トポロジカル情報の変更は、 |リンクに直接接続された最終ホップでデータグラムを転送する前に |データグラムのオーバーヘッドから削除されなければならない。 |これは外部エージェントの両方のモバイル・ノードのピアと、通信 |相手への最終リンクに用いられる。一方、ヘッダ予測は低速モバイル |及び通信相手とのリンクでは、帯域利用の改善を当てにすることは |できない。 Since the changing topological information cannot be removed in the forwarding path of the datagram, header prediction will also be affected at any other pair of routers in the datagram path. Each time that a Mobile Node moves, the topological portion of the header will change, and header history used at those routers will be updated. Unless topological information is limited to as few headers as possible, this may render header prediction ineffective as more Mobile Nodes are deployed. |トポロジカル情報の変更がデータグラムのフォワーディングパスで削除 |できないので、ヘッダ予測もまた、データグラムパスの他の1組のルータ |で影響される。モバイルノードが移動する度にヘッダのトポロジカル分割 |は変更され、これらのルータで使用されているヘッダ履歴は更新される。 |トポロジカル情報が可能な限り小さいヘッダーに制限されなければ、 |これはモバイルノードがより展開されるときに、ヘッダ予測を無効に |してしまうであろう。 6. Processing |プロセッサ Mobility must operate in the current processor environment, and must not be dependent on hardware improvements. |モバイルは現在のプロセッサ環境で動作しなければならず、ハードウェア |の改善に期待してはならない。 Common hardware implementations of Mobile Nodes include lower speed processors, and highly integrated components. These are not readily upgradable. |共通的なモバイルノードのハードウェアの実装は、より低速なプロセッサと、 |より高いコンポーネントの統合を含んでいる。これらを容易にアップグレード |することは可能でない。 The most prevalent mobile platform is a low speed i86, i286 or i386. |最も普及しているモバイル・プラットフォームは低速 i86、i286 及び |i386 である。 The most common ASIC processor is a low speed i186. |最大共通の ASIC プロセッサは低速 i186 である。 6.1. Fixed Location |固定された位置 The processing limitations require that datagram header fields which are frequently examined by Mobile Nodes, or used for datagram forwarding to or from Mobile Nodes, are in a fixed location and do not require lengths and offsets. |プロセッサの制約は、モバイルノードによって周期的に検査され、又は |モバイルノードに向けて/からのデータグラム・フォワーディングに使用 |されるデータグラム・ヘッダ・フィールドに、位置が固定されていること |を要求し、その長さ及びオフセットは要求しない。 Varied number of fields was explicitly rejected in the design of mobility registration and forwarding headers. |可変長フィールドは、モビリティ・レジストレーションとフォワー |ディング・ヘッダの設計で明示的に拒絶された 6.2. Simple Fields |シンプルなフィールド The processing limitations require that datagram header fields which are frequently examined by Mobile Nodes, or used for datagram forwarding to or from Mobile Nodes, are simple and fixed size. |プロセッサの制約は、データグラムのモバイルノードによって周期的に |検査され又はモバイルノードに向けて/からのデータグラム・フォワー |ディングに使用されるデータグラムフィールドが、シンプルで固定長で |あることを要求する。 Varied length of fields was explicitly rejected in the design of mobility forwarding headers. |モビリティ・フォワーディング・ヘッダの設計で、可変長フィールドは |明示的に拒絶された。 6.3. Simple Tests |シンプルなテスト Because the most prevalent processors are "little-endian", while network protocols are in practice "big-endian", the field processing must primarily use simple equality tests, rather than variable shifts and prefix matches. |ネットワーク・プロトコルは実際「ビッグ・エンディアン」であるが、 |最も普及しているプロセッサは「リトル・エンディアン」であるので、 |フィールド処理は変数のシフトとプリフィックス・マッチよりもむしろ、 |シンプルなイコールテストを優先して使用しなければならない。 6.4. Type, Length, Value |Type、Length、Value Fields which are not frequently examined, whether due to infrequent transmission or content that is not relevant in every message, must be of the Type, Length, Value format. |まれな転送又は、毎メッセージで関係しない内容のどちらかで、周期的に |検査されないフィールドは、Type、Length、Value フォーマットである。 Acknowledgements |謝辞 This compilation is primarily based on the work in progress of the IETF Mobile IP Working Group. |この編集物は主に、IETFモバイルIPワーキンググループの進行中の作業を |ベースにしている。 Security Considerations |セキュリティに関する考察 Security issues are discussed in section 4. |セキュリティに関する問題はセクション4で議論している。 Author's Address |著者のアドレス Questions about this memo can also be directed to: |このメモに対する質問も直接下記に: William Allen Simpson Daydreamer Computer Systems Consulting Services 1384 Fontaine Madison Heights, Michigan 48071 EMail: Bill.Simpson@um.cc.umich.edu or bsimpson@MorningStar.com -- 訳: O.K.U. ( oku@olive.plala.or.jp ) ( http://kotekote.zatunen.com/rfc/ ) 注: 翻訳内容に関していかなる保障もいたしません。