RFC2794 日本語訳
2794 Mobile IP Network Access Identifier Extension for IPv4. P.Calhoun, C. Perkins. March 2000. (Format: TXT=16960 bytes) (Updates RFC2290) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group P. Calhoun
Request for Comments: 2794 Sun Microsystems Laboratories
Updates: 2290 C. Perkins
Category: Standards Track Nokia Research Center
March 2000
コメントを求めるワーキンググループP.カルフーン要求をネットワークでつないでください: 2794のサン・マイクロシステムズ研究所アップデート: 2290年のC.パーキンスカテゴリ: 2000年の標準化過程ノキアのリサーチセンター行進
Mobile IP Network Access Identifier Extension for IPv4
IPv4のためのモバイルIPネットワークアクセス識別子拡張子
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
Abstract
要約
AAA servers are in use within the Internet today to provide authentication and authorization services for dial-up computers. Such services are likely to be equally valuable for mobile nodes using Mobile IP when the nodes are attempting to connect to foreign domains with AAA servers. AAA servers today identify clients by using the Network Access Identifier (NAI). Our proposal defines a way for the mobile node to identify itself, by including the NAI along with the Mobile IP Registration Request. This memo also updates RFC 2290 which specifies the Mobile-IPv4 Configuration option for IPCP, by allowing the Mobile Node's Home Address field of this option to be zero.
AAAサーバは、今日、ダイヤルアップコンピュータのための認証と承認サービスを提供するためにインターネットの中で使用中です。 そのようなサービスはモバイルノードにはノードが、AAAサーバで外国ドメインに接続するのを試みているとき、モバイルIPを使用することで等しく貴重である傾向があります。 AAAサーバは、今日、Network Access Identifier(NAI)を使用することによって、クライアントを特定します。 私たちの提案はモバイルノードがそれ自体を特定する方法を定義します、モバイルIP Registration Requestに伴うNAIを含んでいることによって。 また、このメモはモバイルIPv4 ConfigurationオプションをIPCPに指定するRFC2290をアップデートします、モバイルNodeのこのオプションのホームAddress分野がゼロであることを許容することによって。
Calhoun & Perkins Standards Track [Page 1] RFC 2794 Mobile Node NAI March 2000
2000年のノードNAI行進のモバイルのカルフーンとパーキンス標準化過程[1ページ]RFC2794
1. Introduction
1. 序論
AAA servers are in use within the Internet today to provide authentication and authorization services for dial-up computers. Such services are likely to be equally valuable for mobile nodes using Mobile IP when the nodes are attempting to connect to foreign domains with AAA servers. AAA servers today identify clients by using the Network Access Identifier (NAI) [1]. This document specifies the Mobile Node NAI extension to the Mobile IP Registration Request [7] message from the mobile node.
AAAサーバは、今日、ダイヤルアップコンピュータのための認証と承認サービスを提供するためにインターネットの中で使用中です。 そのようなサービスはモバイルノードにはノードが、AAAサーバで外国ドメインに接続するのを試みているとき、モバイルIPを使用することで等しく貴重である傾向があります。 AAAサーバは、今日、Network Access Identifier(NAI)[1]を使用することによって、クライアントを特定します。 このドキュメントはモバイルノードからのモバイルIP Registration Request[7]メッセージにモバイルNode NAI拡張子を指定します。
Since the NAI is typically used to uniquely identify the mobile node, the mobile node's home address is not always necessary to provide that function. Thus, it is possible for a mobile node to authenticate itself, and be authorized for connection to the foreign domain, without even having a home address. A message containing the Mobile Node NAI extension MAY set the Home Address field to zero (0) in the Registration Request, to request that a home address be assigned.
NAIが唯一モバイルノードを特定するのに通常使用されるので、モバイルノードのホームアドレスがその機能を提供するのにいつも必要であるというわけではありません。 したがって、モバイルノードがそれ自体を認証して、接続のために外国ドメインに認可されるのは、可能です、ホームアドレスを持っていなくてさえいなくて。 モバイルNode NAI拡張子を含むメッセージは、ホームアドレスが割り当てられるよう要求するためにホームAddress分野にRegistration Requestで(0)のゼロを合わせるように設定するかもしれません。
The "Mobile-IPv4 Configuration" option to IPCP has been specified in RFC 2290 [8] for proper interaction between a mobile node and a peer, through which the mobile node connects to the network using PPP. According to that specification the Mobile Node's Home Address field of the option MUST not be zero. However, in the context of this memo which allows a mobile node to be identified by its NAI and to obtain an address after the PPP phase of connection establishment, the Home Address field is allowed to be zero while maintaining all other aspects of RFC 2290. Interpretation of various scenarios from RFC 2290 is given in section 4.
IPCPへの「モバイルIPv4構成」オプションはモバイルノードと同輩の間で適切な相互作用のためのRFC2290[8]で指定されました。そこでは、モバイルノードが、PPPを使用することでネットワークに接続します。 その仕様に従って、モバイルNodeのオプションのホームAddress分野はゼロであるはずがありません。 しかしながら、モバイルノードがアドレスをNAIによって特定されて、コネクション確立のPPPフェーズの後に得るこのメモの文脈では、ホームAddress分野はRFC2290の他のすべての局面を維持している間のゼロであることが許容されています。 セクション4でRFC2290からの様々なシナリオの解釈をします。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [3].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[3]で説明されるように本書では解釈されることであるべきですか?
2. Mobile Node NAI Extension
2. モバイルノードNAI拡張子
The Mobile Node NAI extension, shown in figure 1, contains the user name following the format defined in [1]. When it is present in the Registration Request, the Home Address field MAY be set to zero (0). The Mobile Node NAI extension MUST appear in the Registration Request before both the Mobile-Home Authentication extension and Mobile- Foreign Authentication extension, if present.
[1]で定義された書式に従って、1図に示されたモバイルNode NAI拡張子はユーザ名を含んでいます。 それがRegistration Requestに存在しているとき、ホームAddress分野が(0)のゼロに合うように設定されるかもしれません。 モバイルNode NAI拡張子はモバイルホームAuthentication拡張子とモバイル外国Authentication拡張子の両方の前にRegistration Requestに現れなければなりません、存在しているなら。
Calhoun & Perkins Standards Track [Page 2] RFC 2794 Mobile Node NAI March 2000
2000年のノードNAI行進のモバイルのカルフーンとパーキンス標準化過程[2ページ]RFC2794
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | MN-NAI ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| ミネソタ-NAI… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: The Mobile Node NAI Extension
図1: モバイルノードNAI拡張子
Type 131 (skippable) [7]
131(skippable)をタイプしてください。[7]
Length The length in bytes of the MN-NAI field
長さはミネソタ-NAI分野のバイトで表現される長さです。
MN-NAI A string in the NAI format defined in [1].
[1]で定義されたNAI書式でのミネソタ-NAI五弦。
3. Foreign Agent Considerations
3. 外国エージェント問題
If Home Address is zero in the Registration Request, the foreign agent MUST use the NAI instead in its pending registration request records, along with the Identification field as usual. If the foreign agent cannot manage pending registration request records in this way, it MUST return a Registration Reply with Code indicating NONZERO_HOMEADDR_REQD (see section 5).
ホームAddressがRegistration Requestのゼロであるなら、外国人のエージェントは代わりにIdentification分野に伴う未定の登録要求記録でいつものようにNAIを使用しなければなりません。 外国人のエージェントがこのように未定の登録要求記録に対処できないなら、それはCodeがNONZERO_HOMEADDR_REQDを示しているRegistration Replyを返さなければなりません(セクション5を見てください)。
If the mobile node includes the Mobile Node NAI extension in its Registration Request, then the Registration Reply from the home agent MUST include the Mobile Node NAI extension. If not, the foreign agent SHOULD send the Registration Reply to the mobile node, changing the Code to the value MISSING_NAI (see section 5). The Registration Reply MUST include a nonzero Home Agent address and mobile node's Home Address. If not, the foreign agent SHOULD send the Registration Reply to the mobile node, changing the Code to the value MISSING_HOME_AGENT or MISSING_HOMEADDR, respectively (see section 5).
モバイルノードがRegistration RequestにモバイルNode NAI拡張子を含んでいるなら、ホームのエージェントからのRegistration ReplyはモバイルNode NAI拡張子を含まなければなりません。 そうでなければ、外国人のエージェントSHOULDはモバイルノードにRegistration Replyを送ります、Codeを値のMISSING_NAIに変えて(セクション5を見てください)。 Registration Replyは非零ホームエージェントアドレスとモバイルノードのホームAddressを含まなければなりません。 そうでなければ、外国人のエージェントSHOULDはそれぞれモバイルノード、値のMISSING_ホームの_エージェントへのCodeを変えるか、またはMISSING_HOMEADDRにRegistration Replyを送ります(セクション5を見てください)。
4. Interactions with Mobile-IPv4 Configuration Option to IPCP
4. IPCPへのモバイルIPv4設定オプションとの相互作用
In the Mobile-IPv4 Configuration Option to IPCP [8], the Mobile Node's Home Address field may be zero. In this section, we specify the action to be taken in that case, when the mobile node is using the Mobile Node NAI extension in the Mobile IP Registration Request. Whether or not the IP Address Configuration Option contains a nonzero IP address, the mobile node will subsequently attempt to obtain a home address from the Mobile IP Registration Reply.
IPCP[8]へのモバイルIPv4 Configuration Optionでは、モバイルNodeのホームAddress分野はゼロであるかもしれません。 このセクションでは、私たちはその場合取るために動作を指定します、モバイルノードがモバイルIP Registration RequestでモバイルNode NAI拡張子を使用しているとき。 IP Address Configuration Optionが非零IPアドレスを含んでいるか否かに関係なく、モバイルノードは、次に、モバイルIP Registration Replyからホームアドレスを得るのを試みるでしょう。
If the IP Address Configuration Option to IPCP has IP address equal to zero, the PPP peer is expected to allocate and assign a co-located care-of address to the Mobile Node. If, on the other hand, the IP
IPCPへのIP Address Configuration OptionがIPアドレスをゼロに合わせるために等しくするなら、PPP同輩が共同見つけられたaを割り当てて、割り当てると予想される、注意、-、モバイルNodeへのアドレス。 他方では、IP
Calhoun & Perkins Standards Track [Page 3] RFC 2794 Mobile Node NAI March 2000
2000年のノードNAI行進のモバイルのカルフーンとパーキンス標準化過程[3ページ]RFC2794
Address Configuration Option to IPCP has a nonzero IP address, the PPP peer is expected to assign that address to the Mobile Node as its co-located care-of address.
IPCPへのアドレスConfiguration Optionには非零IPアドレスがあって、それが共同見つけられたのでPPP同輩がそのアドレスをモバイルNodeに割り当てると予想される、注意、-、アドレス。
Finally, if the IP Address Configuration Option is left out of the IPCP Configure-Request, then no co-located care of address is assigned during IPCP. The mobile node will acquire a co-located care of address during a later stage of configuration or will use an FA- located care-of address.
最終的にアドレスの次に、IP Address Configuration OptionがIPCP Configure-要求から外されるなら共同見つけられなかった注意はIPCPの間、割り当てられます。 モバイルノードが構成の後期段階の間、アドレスの共同見つけられた注意を取得するか、または見つけられたFAを使用する、注意、-、アドレス。
5. Error Values
5. 誤り値
Each entry in the following table contains the name and value for the Code [7] to be returned in a Registration Reply, and the section in which the error Code is first mentioned in this specification.
以下のテーブルの各エントリーは、Registration ReplyにCode[7]が返される名前と値を含んでいて、この仕様に誤りCodeが最初に言及されるセクションを含みます。
Error Name Value Section of Document
---------------------- ----- -------------------
NONZERO_HOMEADDR_REQD 96 3
MISSING_NAI 97 3
MISSING_HOME_AGENT 98 3
MISSING_HOMEADDR 99 3
ドキュメントのエラー名値の部---------------------- ----- ------------------- 行方不明の非零_HOMEADDR_NAI97 3行方不明の__REQD96 3ホーム_エージェント98の3のなくなった_HOMEADDR99 3
6. IANA Considerations
6. IANA問題
The Mobile Node NAI extension defined in Section 2 is a Mobile IP registration extension as defined in RFC 2002 [7] and extended in RFC 2356 [6]. IANA should assign a value of 131 for this purpose.
セクション2で定義されたモバイルNode NAI拡張子はRFC2002[7]で定義されて、RFC2356[6]で広げられるようにモバイルIP登録拡大です。 IANAはこのために131の値を割り当てるはずです。
The Code values defined in Section 5 are error codes as defined in RFC 2002 and extended in RFC 2344 [5] and RFC 2356 [6]. They correspond to error values conventionally associated with rejection by the foreign agent (i.e., values from the range 64-127). IANA should record the values as defined in Section 5.
セクション5で定義されたCode値はRFC2002で定義されて、RFC2344[5]とRFC2356[6]で広げられるようにエラーコードです。 彼らは慣習上外国人のエージェント(すなわち、範囲64-127からの値)による拒絶に関連している誤り値に対応します。 IANAはセクション5で定義されるように値を記録するはずです。
7. Security Considerations
7. セキュリティ問題
Mobile IP registration messages are authenticated, and the authentication verified by the recipient. This proposal does not prohibit the mobile node from sending its NAI in the clear over the network, but that is not expected to be a security issue.
モバイルIP登録メッセージは、認証されていて受取人によって確かめられた認証です。 この提案は、モバイルノードがネットワークの上の明確でNAIを送るのを禁止しませんが、それは安全保障問題でないと予想されます。
8. IPv6 Considerations
8. IPv6問題
Supporting NAI-based registrations for Mobile IPv6 [4] is outside the scope of this document. This section contains some ideas how Stateless Address Autoconfiguration [9] and DHCPv6 [2] might be extended to support NAI-based Mobile IPv6 registrations.
このドキュメントの範囲の外にモバイルIPv6[4]のためにNAIベースの登録証明書をサポートするのがあります。 このセクションはStateless Address Autoconfiguration[9]とDHCPv6[2]がNAIベースのモバイルIPv6登録証明書をサポートするためにどのように広げられるかもしれないかといういくつかの考えを含みます。
Calhoun & Perkins Standards Track [Page 4] RFC 2794 Mobile Node NAI March 2000
2000年のノードNAI行進のモバイルのカルフーンとパーキンス標準化過程[4ページ]RFC2794
For mobile nodes using IPv6, there are no commonly deployed mechanisms by which a mobile node may present its credentials, such as exist today with IPv4. Nevertheless, a mobile node using IPv6 mobility may wish to specify the domain in which their credentials may be checked, by using a NAI just as this specification proposes for IPv4. In the case of IPv6, however, there is no foreign agent in place to manage the connectivity of the mobile node, and thus to manage the verification of the credentials offered by the mobile node. To identify the HDAF (see appendix A) that has the expected relationship with the mobile node, the NAI would have to be forwarded to a local AAA by the local agent involved with configuring the care-of address of the mobile node.
IPv6を使用するモバイルノードにおいて、モバイルノードが今日IPv4と共に存在する資格証明書を提示するかもしれないメカニズムは一般的に配布されません。 それにもかかわらず、IPv6の移動性を使用するモバイルノードはそれらの資格証明書がチェックされるかもしれないドメインを指定したがっているかもしれません、ちょうどこの仕様がIPv4のために提案するようにNAIを使用することによって。 しかしながら、IPv6の場合には、モバイルノードの接続性を管理して、その結果、モバイルノードによって提供された資格証明書の検証を管理するために、どんな外国人のエージェントも適所にいません。 モバイルノードとの予想された関係を持っているHDAF(付録Aを見る)を特定するために、NAIが構成にかかわる地元のエージェントによって地方のAAAに送られなければならないだろう、注意、-、モバイルノードのアドレス。
This agent can either be a router sending out Router Advertisements [9], or a DHCPv6 server. In the former case, the router could signal its ability to handle the NAI by attaching some yet to be defined option to the Router Advertisement. In the latter case, for managed links, the mobile node could include a yet to be defined NAI extension in its DHCP Solicitation message. Such an NAI extension and appropriate authentication would also be required on the subsequent DHCP Request sent by the mobile node to the DHCP Server selected on the basis of received DHCP Advertisements. Once a care- of address on the foreign network has been obtained, the mobile node can use regular MIPv6 [4].
このエージェントは、Router Advertisements[9]を出すルータ、またはDHCPv6サーバのどちらかであるかもしれません。前の場合では、ルータは何らかのまだ定義されなかったオプションをRouter Advertisementに付けることによってNAIを扱う性能を示すかもしれません。 後者の場合では、管理されたリンクに関して、モバイルノードはDHCP Solicitationメッセージにまだ定義されなかったNAI拡張子を含むかもしれません。 また、そのようなNAI拡張子と適切な認証がモバイルノードで容認されたDHCP Advertisementsに基づいて選択されたDHCP Serverに送られたその後のDHCP Requestで必要でしょう。 いったん外国ネットワークにおけるアドレスの注意を得ると、モバイルノードは通常のMIPv6[4]を使用できます。
9. Acknowledgements
9. 承認
The authors would like to thank Gabriel Montenegro and Vipul Gupta for their useful discussions. Thanks to Basaravaj Patil and Pete McCann for text describing actions to be taken when the home address is zero but the mobile node wishes to use the Mobile-IPv4 Configuration Option to IPCP defined in RFC 2290.
作者は彼らの役に立つ議論についてガブリエル・モンテネグロとVipulグプタに感謝したがっています。 ホームアドレスがゼロですが、モバイルノードがRFC2290で定義されたIPCPにモバイルIPv4 Configuration Optionを使用したがっているとき、取るために動作について説明するテキストをBasaravajパティルとピートマッキャンをありがとうございます。
References
参照
[1] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC
2486, January 1999.
[1]AbobaとB.とM.用務員、「ネットワークアクセス識別子」、RFC2486、1999年1月。
[2] Bound, J. and C. Perkins, "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)", Work in Progress.
[2] バウンドしてください、そして、「IPv6(DHCPv6)のためのダイナミックなホスト構成プロトコル」というJ.とC.パーキンスは進行中で働いています。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[4] Johnson, D. and C. Perkins "Mobility Support in IPv6", Work in
Progress.
[4] 「移動性はIPv6"、進行中の仕事でサポートする」ジョンソン、D.、およびC.パーキンス。
Calhoun & Perkins Standards Track [Page 5] RFC 2794 Mobile Node NAI March 2000
2000年のノードNAI行進のモバイルのカルフーンとパーキンス標準化過程[5ページ]RFC2794
[5] Montenegro, G., "Reverse Tunneling for Mobile IP", RFC 2344, May
1998.
[5] モンテネグロ(G.、「モバイルIPのための逆のトンネリング」、RFC2344)は1998がそうするかもしれません。
[6] Montenegro, G. and V. Gupta, "Sun's SKIP Firewall Traversal for
Mobile IP", RFC 2356, June 1998.
[6] モンテネグロ、G.、および「モバイルIPのためのSunのスキップファイアウォール縦断」、RFC2356、1998年6月対グプタ
[7] Perkins, C., "IP Mobility Support", RFC 2002, October 1996.
[7] パーキンス、C.、「IP移動性サポート」、RFC2002、1996年10月。
[8] Solomon, J. and S. Glass, "Mobile-IPv4 Configuration Option for
PPP IPCP", RFC 2290, February 1998.
[8] RFC2290、ソロモン、J.、およびS.は「ppp IPCPのためのモバイルIPv4設定オプション」とガラスで覆って、2月は1998です。
[9] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[9] トムソンとS.とT.Narten、「IPv6の状態がないアドレス自動構成」、RFC2462、1998年12月。
Calhoun & Perkins Standards Track [Page 6] RFC 2794 Mobile Node NAI March 2000
2000年のノードNAI行進のモバイルのカルフーンとパーキンス標準化過程[6ページ]RFC2794
A. Home Domain Allocation Function (HDAF)
A。 ホームドメイン配分機能(HDAF)
This appendix introduces a new function named the Home Domain Allocation Function (HDAF) that can dynamically assign a Home Address to the mobile node.
この付録はダイナミックにホームAddressをモバイルノードに割り当てることができるホームDomain Allocation Function(HDAF)という新しい機能を導入します。
Figure 2 illustrates the Home HDAF, which receives messages from foreign agents (e.g., FA) and assigns a Home Address within the Home Domain. The HDAF does not perform any Mobile IP processing on the Registration Request, but simply forwards the request to a Home Agent (HA) within the network that is able to handle the request.
図2はホームHDAFを例証します。(HDAFは外国人のエージェント(例えば、FA)からメッセージを受け取って、ホームDomainの中でホームAddressを割り当てます)。 HDAFは要求を扱うことができるネットワークの中でRegistration Request、しかし、単に前方にホームエージェント(HA)に要求を処理する少しのモバイルIPも実行しません。
+------+
| |
+---+ HA-1 |
+------+ +------+ +------+ | | |
| | | | | | | +------+
| MN |-------| FA |-------| HDAF +---+ ...
| | | | | | | +------+
+------+ +------+ +------+ | | |
+---+ HA-n |
| |
+------+
+------+ | | +---+、ハ、-1| +------+ +------+ +------+ | | | | | | | | | | +------+ | ミネソタ|-------| ファ|-------| HDAF+---+ ... | | | | | | | +------+ +------+ +------+ +------+ | | | +---+、ハ、-n| | | +------+
Figure 2: Home Domain Allocator Function (HDAF)
図2: ホームドメインアロケータ機能(HDAF)
Upon receipt of the Registration Request from the mobile node (MN), FA extracts the NAI and finds the domain name associated with it. FA then finds the HDAF that handles requests for the mobile node's domain. The discovery protocol is outside of the scope of this specification. As an example, however, FA might delegate the duty of finding a HDAF to a local AAA server. The local AAA server may also assist FA in the process of verifying the credentials of the mobile node, using protocols not specified in this document.
モバイルノード(ミネソタ)からのRegistration Requestを受け取り次第、FAはNAIを抽出して、それに関連しているドメイン名を見つけます。 そして、FAはモバイルノードのドメインを求める要求を扱うHDAFを見つけます。 発見プロトコルがこの仕様の範囲の外にあります。 しかしながら、例として、FAはローカルのAAAサーバにHDAFを見つける義務を代表として派遣するかもしれません。また、モバイルノードの資格証明書について確かめることの途中にローカルのAAAサーバはFAを補助するかもしれません、本書では指定されなかったプロトコルを使用して。
Calhoun & Perkins Standards Track [Page 7] RFC 2794 Mobile Node NAI March 2000
2000年のノードNAI行進のモバイルのカルフーンとパーキンス標準化過程[7ページ]RFC2794
Addresses
アドレス
The working group can be contacted via the current chairs:
現在のいすを通してワーキンググループに連絡できます:
Basavaraj Patil Nokia Corporation 6000 Connection Drive M/S M8-540 Irving, TX 75039 USA
Basavarajパティルノキア社6000の接続ドライブM/S M8-540テキサス75039アービング(米国)
Phone: +1 972-894-6709 Fax : +1 972-894-5349 EMail: Basavaraj.Patil@nokia.com
以下に電話をしてください。 +1 972-894-6709 ファックスで以下を送ってください。 +1 972-894-5349 メールしてください: Basavaraj.Patil@nokia.com
Phil Roberts Motorola 1501 West Shure Drive Arlington Heights, IL 60004 USA
西シュアー・Driveフィル・ロバーツ・モトローラ1501IL60004アーリントンハイツ(米国)
Phone: +1 847-632-3148 EMail: QA3445@email.mot.com
以下に電話をしてください。 +1 847-632-3148 メールしてください: QA3445@email.mot.com
Questions about this memo can be directed to:
このメモに関する質問による以下のことよう指示できます。
Charles E. Perkins Nokia Research Center 313 Fairchild Drive Mountain View, California 94043 USA
チャールズE.パーキンスノキアリサーチセンター313フェアチャイルド・Driveカリフォルニア94043マウンテンビュー(米国)
Phone: +1-650 625-2986 Fax: +1 650 625-2502 EMail: charliep@iprg.nokia.com
以下に電話をしてください。 +1-650 625-2986Fax: +1 650 625-2502 メールしてください: charliep@iprg.nokia.com
Pat R. Calhoun Sun Microsystems Laboratories 15 Network Circle Menlo Park, California 94025 USA
パットR.カルフーンサン・マイクロシステムズ研究所15ネットワーク円のカリフォルニア94025メンローパーク(米国)
Phone: +1 650-786-7733 Fax: +1 650-786-6445 EMail: pcalhoun@eng.sun.com
以下に電話をしてください。 +1 650-786-7733Fax: +1 650-786-6445 メールしてください: pcalhoun@eng.sun.com
Calhoun & Perkins Standards Track [Page 8] RFC 2794 Mobile Node NAI March 2000
2000年のノードNAI行進のモバイルのカルフーンとパーキンス標準化過程[8ページ]RFC2794
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 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機能のための基金は現在、インターネット協会によって提供されます。
Calhoun & Perkins Standards Track [Page 9]
カルフーンとパーキンス標準化過程[9ページ]
一覧
スポンサーリンク
