RFC4857 日本語訳
4857 Mobile IPv4 Regional Registration. E. Fogelstroem, A. Jonsson, C.Perkins. June 2007. (Format: TXT=79939 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group E. Fogelstroem
Request for Comments: 4857 A. Jonsson
Category: Experimental Ericsson
C. Perkins
Nokia Siemens Networks
June 2007
Fogelstroemがコメントのために要求するワーキンググループE.をネットワークでつないでください: 4857年のA.イェンソンカテゴリ: 実験的なエリクソンC.パーキンスノキアシーメンスは2007年6月をネットワークでつなぎます。
Mobile IPv4 Regional Registration
モバイルIPv4地方の登録
Status of This Memo
このメモの状態
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 それはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
Abstract
要約
Using Mobile IP, a mobile node registers with its home agent each time it changes care-of address. This document describes a new kind of "regional registrations", i.e., registrations local to the visited domain. The regional registrations are performed via a new network entity called a Gateway Foreign Agent (GFA) and introduce a layer of hierarchy in the visited domain. Regional registrations reduce the number of signaling messages to the home network, and reduce the signaling delay when a mobile node moves from one foreign agent to another within the same visited domain. This document is an optional extension to the Mobile IPv4 protocol.
モバイルIPを使用して、モバイルノードが変化するたびにホームのエージェントとともに記名する、注意、-、アドレス。 このドキュメントは新しい種類の「地方の登録証明書」、すなわち、訪問されたドメインへの地方の登録証明書について説明します。 地方の登録証明書は、ゲートウェイのForeignエージェント(GFA)と呼ばれる新しいネットワーク実体で実行されて、訪問されたドメインで階層構造の層を導入します。 地方の登録証明書は、シグナリングメッセージの数をホームネットワークに減少させて、モバイルノードが同じ訪問されたドメインの中で1人の外国人のエージェントから別のエージェントまで移行すると、シグナリング遅れを減少させます。 このドキュメントはモバイルIPv4プロトコルへの任意の拡大です。
Table of Contents
目次
1. Introduction ....................................................3
2. Overview of Regional Registrations ..............................4
3. Terminology .....................................................5
4. Description of the Protocol .....................................7
4.1. General Assumptions ........................................7
4.1.1. Visited Domain ......................................8
4.1.2. Authentication ......................................8
4.2. Protocol Overview ..........................................9
4.3. Advertising Foreign Agent and GFA .........................10
4.4. Backwards Compatibility with RFC 3344 .....................10
5. Home Registration ..............................................11
5.1. Mobile Node Considerations ................................11
1. 序論…3 2. 地方の登録証明書の概要…4 3. 用語…5 4. プロトコルの記述…7 4.1. 一般仮定…7 4.1.1. ドメインを訪問します…8 4.1.2. 認証…8 4.2. 概要について議定書の中で述べてください…9 4.3. 広告の外国人のエージェントとGFA…10 4.4. RFC3344との遅れている互換性…10 5. ホーム登録…11 5.1. モバイルノード問題…11
Fogelstroem, et al. Experimental [Page 1] RFC 4857 Mobile IPv4 Regional Registration June 2007
Fogelstroem、他 地方のIPv4登録2007年6月のモバイルの実験的な[1ページ]RFC4857
5.2. Foreign Agent Considerations ..............................12
5.3. GFA Considerations ........................................13
5.4. Home Agent Considerations .................................14
6. Regional Registration ..........................................14
6.1. Mobile Node Considerations ................................15
6.2. Foreign Agent Considerations ..............................16
6.3. GFA Considerations ........................................16
7. Dynamic GFA Assignment .........................................17
7.1. Mobile Node Considerations for Dynamic GFA Assignment .....17
7.2. Foreign Agent Considerations for Dynamic GFA Assignment ...17
7.3. GFA Considerations for Dynamic GFA Assignment .............18
7.4. Home Agent Considerations for Dynamic GFA Assignment ......18
7.5. Regional Registration .....................................19
8. Router Discovery Extensions ....................................19
8.1. Regional Registration Flag ................................19
8.2. Foreign Agent NAI Extension ...............................19
9. Regional Extensions to Mobile IPv4 Registration Messages .......20
9.1. GFA IP Address Extension ..................................20
9.2. Hierarchical Foreign Agent Extension ......................21
9.3. Replay Protection Style ...................................22
9.4. Regional Registration Lifetime Extension ..................23
9.5. New Code Values for Registration Reply ....................24
10. Regional Registration Message Formats .........................25
10.1. Regional Registration Request ............................26
10.2. Regional Registration Reply ..............................27
10.3. New Regional Registration Reply Code Values ..............28
11. Authentication Extensions .....................................29
12. Security Considerations .......................................29
13. IANA Considerations ...........................................30
14. Acknowledgements ..............................................31
15. References ....................................................32
15.1. Normative References .....................................32
15.2. Informative References ...................................32
Appendix A. Authentication, Authorization, and Accounting (AAA)
Interactions ..........................................33
Appendix B. Anchoring at a GFA ....................................33
5.2. 外国エージェント問題…12 5.3. GFA問題…13 5.4. ホームエージェント問題…14 6. 地方の登録…14 6.1. モバイルノード問題…15 6.2. 外国エージェント問題…16 6.3. GFA問題…16 7. ダイナミックなGFA課題…17 7.1. ダイナミックなGFA課題のためのモバイルノード問題…17 7.2. ダイナミックなGFA課題のための外国エージェント問題…17 7.3. ダイナミックなGFA課題のためのGFA問題…18 7.4. ダイナミックなGFA課題のためのホームエージェント問題…18 7.5. 地方の登録…19 8. ルータ発見拡大…19 8.1. 地方の登録旗…19 8.2. 外国エージェントNAI拡張子…19 9. モバイルIPv4登録メッセージへの地方の拡大…20 9.1. GFA IPアドレス拡張子…20 9.2. 階層的な外国エージェント拡大…21 9.3. 保護様式を再演してください…22 9.4. 地方の登録生涯拡大…23 9.5. 登録のための新法値は返答します…24 10. 地方の登録メッセージ・フォーマット…25 10.1. 地方の登録要求…26 10.2. 地方の登録回答…27 10.3. 新しい地方の登録回答コード値…28 11. 認証拡大…29 12. セキュリティ問題…29 13. IANA問題…30 14. 承認…31 15. 参照…32 15.1. 標準の参照…32 15.2. 有益な参照…32 付録A.認証、承認、および会計(AAA)相互作用…33 GFAで投錨される付録B.…33
Fogelstroem, et al. Experimental [Page 2] RFC 4857 Mobile IPv4 Regional Registration June 2007
Fogelstroem、他 地方のIPv4登録2007年6月のモバイルの実験的な[2ページ]RFC4857
1. Introduction
1. 序論
This document is an optional extension to the Mobile IPv4 protocol, and proposes a means for mobile nodes to register locally within a visited domain. By registering locally, the number of signaling messages to the home network are kept to a minimum, and the signaling delay is reduced.
このドキュメントは、モバイルIPv4プロトコルへの任意の拡大であり、訪問されたドメインの中でモバイルノードが局所的に登録する手段を提案します。 局所的に登録することによって、ホームネットワークへのシグナリングメッセージの数は最小限に保たれます、そして、シグナリング遅れは減少します。
In Mobile IP, as specified in [RFC3344], a mobile node registers with its home agent each time it changes care-of address. If the distance between the visited network and the home network of the mobile node is large, the signaling delay for these registrations may be long. We propose a solution for performing registrations locally in the visited domain: regional registrations. Regional registrations minimize the number of signaling messages to the home network, and reduce the signaling delay when a mobile node moves from one foreign agent to another within the same visited domain. This will both decrease the load on the home network, and speed up the process of handover within the visited domain.
モバイルIPでは、モバイルノードが変化するたびに[RFC3344]で指定されるようにホームのエージェントとともに記名する、注意、-、アドレス。 訪問されたネットワークとモバイルノードのホームネットワークの間の距離が大きいなら、これらの登録証明書のためのシグナリング遅れは長いかもしれません。 私たちは訪問されたドメインで局所的に登録証明書を実行するためにソリューションを提案します: 地方の登録証明書。 地方の登録証明書は、シグナリングメッセージの数をホームネットワークに最小にして、モバイルノードが同じ訪問されたドメインの中で1人の外国人のエージェントから別のエージェントまで移行すると、シグナリング遅れを減少させます。 これは訪問されたドメインの中でホームネットワークの負荷、および引き渡しのプロセスへの速度をともに減少させるでしょう。
Regional registrations introduce a new network node: the Gateway Foreign Agent (GFA). The address of the GFA is advertised by the foreign agents in a visited domain. When a mobile node first arrives at this visited domain, it performs a home registration -- that is, a registration with its home agent. At this registration, the mobile node registers the address of the GFA as its care-of address with its home agent. When moving between different foreign agents within the same visited domain, the mobile node only needs to make a regional registration to the GFA.
地方の登録証明書は新しいネットワーク・ノードを紹介します: ゲートウェイの外国人のエージェント(GFA)。 GFAのアドレスは訪問されたドメインに外国人のエージェントによって広告を出されます。 モバイルノードが最初にこの訪問されたドメインに到着するとき、本国登録を実行します--すなわち、ホームのエージェントとの登録。 この登録、ノードがGFAのアドレスを登録するモバイル、それ、注意、-、ホームのエージェントとのアドレス。 同じ訪問されたドメインの中の異なった外国人のエージェントの間で移行するとき、モバイルノードは、地方の登録をGFAにする必要があるだけです。
In their simplest form, regional registrations are performed transparently to the home agent. Additionally, regional registrations may also allow dynamic assignment of GFA. The solution for dynamic GFA assignment requires support in the mobile node, the foreign agent, the GFA, and the home agent.
それらの最も簡単なフォームでは、地方の登録証明書は透過的にホームのエージェントに実行されます。 また、さらに、地方の登録証明書はGFAのダイナミックな課題を許容するかもしれません。 ダイナミックなGFA課題のためのソリューションはモバイルノード、外国人のエージェント(GFA)、およびホームのエージェントで支持を要します。
The proposed regional registration protocol supports one level of foreign agent hierarchy beneath the GFA, but the protocol may be utilized to support several levels of hierarchy. Multiple levels of hierarchy are not discussed in this document.
提案された地方の登録プロトコルはGFAの下で1つのレベルの外国エージェント階層構造をサポートしますが、プロトコルは、いくつかのレベルの階層構造をサポートするのに利用されるかもしれません。 本書では階層構造の複数のレベルについて議論しません。
Although this document focuses on regional registrations in visited domains, regional registrations are also possible in the home domain.
このドキュメントは訪問されたドメインで地方の登録証明書に焦点を合わせますが、また、地方の登録証明書もホームドメインで可能です。
Foreign agents that support regional registrations are also required to support registrations according to Mobile IPv4 [RFC3344].
また、モバイルIPv4[RFC3344]によると、地方の登録証明書をサポートする外国人のエージェントは登録証明書をサポートしなければなりません。
The following section gives an overview of regional registrations.
以下のセクションは地方の登録証明書の概要を与えます。
Fogelstroem, et al. Experimental [Page 3] RFC 4857 Mobile IPv4 Regional Registration June 2007
Fogelstroem、他 地方のIPv4登録2007年6月のモバイルの実験的な[3ページ]RFC4857
2. Overview of Regional Registrations
2. 地方の登録証明書の概要
In standard Mobile IP, there are three entities of interest. The Mobile Node (MN), the Foreign Agent (FA), and the Home Agent (HA). The MN communicates with the HA, either through an FA or directly (if it has a co-located care-of address). With Regional Registrations, a new entity is defined: the Gateway Foreign Agent (GFA). The GFA sits between the MN/FA and HA, and to the HA, it appears as if the MN's temporary care-of address is that of the GFA. When a MN moves within a site, it only need interact with the GFA, so that the GFA knows at what temporary address the MN is currently reachable.
標準のモバイルIPには、興味がある3つの実体があります。 モバイルノード(ミネソタ)、外国人のエージェント(ファ)、およびホームのエージェント(ハ)。 ミネソタがHAと、どちらかFAか直接交信する、(それでaの共同見つけている、注意、-、アドレス) Regional Registrationsと共に、新しい実体は定義されます: ゲートウェイの外国人のエージェント(GFA)。 GFAがミネソタ/FAとHAの間に座っていて、HAにおいて、まるでミネソタが一時的であるかのように見える、注意、-、アドレスはGFAのものです。 ミネソタがサイトの中で移行すると、GFAと対話するだけでよいです、GFAが、ミネソタが現在どんな仮の住所で届いているかを知るように。
Two types of registration messages are used. Regular [RFC3344] Registration Requests/Replies are still used for when the MN exchanges Registration Requests/Replies with the HA, but these messages get forwarded through a GFA, and include new extensions.
2つのタイプの登録メッセージは使用されています。 定期的な[RFC3344]登録Requests/回答がミネソタがRegistration Requests/回答をHAと交換する時の間、まだ使用されていますが、これらのメッセージは、GFAを通して進められて、新しい拡大を含んでいます。
In addition, a new pair of registration messages, Regional Registration Requests/Replies, are used between MNs/FAs/GFAs for intra-site signaling. A MN uses these messages to communicate its new addresses to the GFA as it moves around within a site.
さらに、登録メッセージの新しい組(Regional Registration Requests/回答)はイントラサイトシグナリングにMNs/FAs/GFAsの間で使用されます。 ミネソタはサイトの中を動き回るとき新しいアドレスをGFAに伝えるこれらのメッセージを使用します。
There are two models of how the MN uses Regional Registrations. The FA can advertise a GFA to the MN. Alternatively, the FA can indicate that dynamic assignment of GFA is to be used. With dynamic GFA assignment, the MN does not choose the GFA, rather the FA (or GFA) does so after receiving a Registration Request from the MN. However, in this mode the HA must understand (and support) Regional Registrations in order for them to be used. This last form is not transparent because the MN doesn't know in advance what GFA will be used, and cannot include it in a signed message to the HA.
ミネソタがどうRegional Registrationsを使用するかに関する2つのモデルがあります。 FAはミネソタにGFAの広告を出すことができます。 あるいはまた、FAは、GFAのダイナミックな課題が使用されていることであることを示すことができます。 ダイナミックなGFA課題で、ミネソタはGFAを選ばないで、ミネソタからRegistration Requestを受けた後に、むしろFA(または、GFA)はそうします。 しかしながら、このモードで、HAは、彼らにとって、整然としている(そして、サポート)地方のRegistrationsが使用されるのを理解しなければなりません。 ミネソタがあらかじめGFAが何になるかを使用されていた状態で知らないで、署名しているメッセージでHAにそれを含めることができないので、この最後のフォームは透明ではありません。
When a MN moves to a new domain (determined by comparing its Network Access Identifier (NAI) [RFC4282] with the FA-NAI included in received Agent Advertisements), it can opt to use Regional Registrations. A site indicates support for Regional Registrations by setting the I-bit of the Mobile IP Agent Advertisement extension. In addition, such advertisements include a list of one or more care- of addresses. If there is only one care-of address, this is the address of the FA itself. In addition, the advertisement may include the address of the GFA. A GFA care-of address of all-ones indicates that dynamic assignment of GFA is supported.
ミネソタが新しいドメイン(Network Access Identifier(NAI)[RFC4282]を容認されたエージェントAdvertisementsに含まれているFA-NAIと比較することによって断固とした)に移行すると、それは、Regional Registrationsを使用するために選ばれることができます。 サイトは、モバイルIPエージェントAdvertisement拡張子のI-ビットを設定することによって、Regional Registrationsのサポートを示します。 さらに、そのような広告はアドレスの1つ以上の注意のリストを含んでいます。 1つしかない、注意、-、アドレス、これはFA自身のアドレスです。 さらに、広告はGFAのアドレスを含むかもしれません。 GFA、注意、-、オールもののアドレスは、GFAのダイナミックな課題がサポートされるのを示します。
A MN requests initial Regional Registration by sending a normal Registration Request to the FA, but setting the care-of address to that of the GFA (i.e., if it has selected it wishes to use this GFA) or all-zeros (which signals a dynamic GFA assignment request). The FA adds a Hierarchical FA (HFA) extension and relays the request to
ミネソタがFAへの正常なRegistration Request、しかし、設定を送ることによって初期のRegional Registrationを要求する、注意、-、GFA(すなわち、そうしたなら、選択されて、それはこのGFAを使用したがっている)かオールゼロのもの(ダイナミックなGFA課題要求に合図する)へのアドレス。 FAはHierarchical FA(HFA)拡張子を加えて、要求をリレーします。
Fogelstroem, et al. Experimental [Page 4] RFC 4857 Mobile IPv4 Regional Registration June 2007
Fogelstroem、他 地方のIPv4登録2007年6月のモバイルの実験的な[4ページ]RFC4857
the appropriate GFA. The HFA extension contains a single field: the IP address of the FA.
適切なGFA。 HFA拡張子はただ一つの分野を含んでいます: FAのIPアドレス。
Note: the algorithm for MNs with co-located care-of addresses is similar, except that there is no FA, so the MN behaves as the FA in terms of the messages it sends.
以下に注意してください。 共同見つけられるのがあるMNsのためのアルゴリズム、注意、-、アドレスは同様です、ミネソタがFAとしてそれが送るメッセージに関して振る舞ってFAが全くないのを除いて。
A GFA receives Registration Requests relayed from an FA. If the care-of address in the received Registration Request is zero, the GFA assigns one. A GFA IP Address extension is then added to the Registration Request, and the message is forwarded to the HA. The GFA IP Address extension contains a single field: the IP address of the GFA. (A separate field is needed for this because the Registration Request message between the MN/HA is signed and cannot be modified.)
GFAはFAからリレーされたRegistration Requestsを受けます。 注意、-、容認されたRegistration Requestのアドレスはゼロ、GFA案配1です。 次に、GFA IP Address拡張子をRegistration Requestに加えます、そして、メッセージをHAに転送します。 GFA IP Address拡張子はただ一つの分野を含んでいます: GFAのIPアドレス。 (別々の分野がミネソタ/HAの間のRegistration Requestメッセージに署名して、変更できないので、これに必要です。)
HAs process received Registration Requests in the same way as before, except in the case of dynamic GFA assignment. In this case, the HA uses the GFA address from the GFA IP Address extension as the MN's current care-of address. In addition, the Registration Reply message must include the GFA IP Address extension.
同様に、ダイナミックなGFA課題に関するケースを除いて、HAsは従来と同様容認されたRegistration Requestsを処理します。 この場合HAがGFA IP Address拡張子からのGFAアドレスを使用する、ミネソタの電流、注意、-、アドレス さらに、Registration ReplyメッセージはGFA IP Address拡張子を含まなければなりません。
The regular Registration Requests/Replies are protected as described in [RFC3344], by use of the mobility security association between the MN and the HA. For regional registrations, it is assumed that a mobility security association is established between the MN and GFA during registration with the HA. Regional Registration Requests/ Replies are protected by use of this security association between the MN and the GFA, e.g., by use of a MN-GFA Authentication extension.
定期的なRegistration Requests/回答は[RFC3344]でミネソタとHAとの移動性セキュリティ協会の使用で説明されるように保護されます。 地方の登録証明書において、移動性セキュリティ協会がHAとの登録の間ミネソタとGFAの間に設立されると思われます。 地方のRegistration Requests/回答はミネソタとGFAとのこのセキュリティ協会の使用で保護されます、例えば、ミネソタ-GFA Authentication拡張子の使用で。
HFA extensions, added by an FA to a Registration Request or Regional Registration Request, are protected by an FA-FA Authentication extension. Security associations between FAs and GFAs within a domain are assumed to exist prior to regional registrations.
FAによってRegistration RequestかRegional Registration Requestに加えられたHFA拡張子はFA-FA Authentication拡張子で保護されます。 ドメインの中のFAsとGFAsとのセキュリティ協会が地方の登録証明書の前に存在すると思われます。
Dynamic GFA assignment requires means for securely sending Registration Requests from the GFA to the HA, in order to protect the GFA IP Address extension.
ダイナミックなGFA課題はしっかりと発信しているRegistration RequestsのためにGFAからHAまで手段を必要とします、GFA IP Address拡張子を保護するために。
3. Terminology
3. 用語
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 RFC 2119 [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[RFC2119]で説明されるように本書では解釈されることであるべきですか?
Fogelstroem, et al. Experimental [Page 5] RFC 4857 Mobile IPv4 Regional Registration June 2007
Fogelstroem、他 地方のIPv4登録2007年6月のモバイルの実験的な[5ページ]RFC4857
This document uses the following terms:
このドキュメントは次の用語を使用します:
Critical type
A type value for an extension in the range 0-127, which indicates
that the extension MUST either be known to the recipient, or that
the message containing the extension MUST be rejected. In other
words, an extension with a critical type value is non-skippable.
重要なタイプAは範囲0-127での拡大のために値をタイプします。(範囲は受取人にとって拡大を知っていなければならないか、または拡大を含むメッセージを拒絶しなければならないのを示します)。 言い換えれば、重要なタイプ値がある拡張子は非skippableです。
Domain
A collection of networks sharing a common network administration.
一般的なネットワーク管理を共有するネットワークのドメインA収集。
Foreign Agent (FA)
As defined in [RFC3344].
[RFC3344]で定義される外国人のエージェント(FA)。
Gateway Foreign Agent (GFA)
A Foreign Agent which has a publicly routable IP address. A GFA
may, for instance, be placed in or near a firewall.
公的に発送可能なIPアドレスを持っているゲートウェイForeignエージェント(GFA)のA Foreignエージェント。 例えば、GFAはファイアウォールかファイアウォールの近くに置かれるかもしれません。
Home Agent (HA)
As defined in [RFC3344].
定義されるとしてのエージェント(HA)を帰着させてください[RFC3344]。
Home domain
The domain where the home network and home agent are located.
ホームドメイン、ホームネットワークとホームのエージェントが位置しているドメイン。
Home network
As defined in [RFC3344].
[RFC3344]で定義されたホームネットワークAs。
Home Registration
A registration, processed by the home agent and the GFA, using the
specification in [RFC3344] possibly with additional extensions
defined in this document.
ことによると本書では定義される追加拡大と共に[RFC3344]の仕様を使用するホームのエージェントとGFAによって処理されたホームRegistration A登録。
Local Care-of Address
A care-of address that is assigned to either a mobile node or a
foreign agent offering local connectivity to a mobile node. A
registration message from the mobile node is subsequently sent to
a GFA via the local care-of address.
地方、Care、-、Address A、注意、-、ローカルの接続性をモバイルノードに提供するモバイルノードか外国人のエージェントのどちらかに割り当てられるアドレス。 を通して次にモバイルノードからの登録メッセージをGFAに送る、地方、注意、-、アドレス
Mobile Node (MN)
As defined in [RFC3344].
[RFC3344]で定義されるモバイルNode(ミネソタ)。
Mobility Agent (MA)
As defined in [RFC3344].
[RFC3344]で定義される移動性エージェント(MA。)
Network Access Identifier(NAI)
Some features of this protocol specification rely on use of the
Network Access Identifier (NAI) [RFC2794].
Access Identifier(NAI)をネットワークでつないでください。このプロトコル仕様のいくつかの特徴がNetwork Access Identifier(NAI)[RFC2794]の使用に依存します。
Fogelstroem, et al. Experimental [Page 6] RFC 4857 Mobile IPv4 Regional Registration June 2007
Fogelstroem、他 地方のIPv4登録2007年6月のモバイルの実験的な[6ページ]RFC4857
Regional Registration
A mobile node performs registration locally at the visited domain,
by sending a Regional Registration Request to a GFA, and receiving
a Regional Registration Reply in return.
A地方のRegistrationモバイルノードは訪問されたドメインで局所的に登録を実行します、Regional Registration RequestをGFAに送って、代わりにRegional Registration Replyを受けることによって。
Registration Key
A key used by mobile nodes and mobility agents to secure certain
signals and control messages specified by Mobile IP.
ある信号とコントロールメッセージを固定するのにモバイルノードと移動性エージェントによって使用された登録Key AキーはモバイルIPで指定しました。
Visited domain
The domain where the visited network, the current foreign agent,
and the GFA are located.
訪問されたドメイン、訪問されたネットワーク、現在の外国人のエージェント、およびGFAが位置しているドメイン。
Visited network
As defined in [RFC3344].
[RFC3344]で定義されたネットワークAsを訪問しました。
4. Description of the Protocol
4. プロトコルの記述
This section provides an overview of the regional registration protocol.
このセクションは地方の登録プロトコルの概要を提供します。
4.1. General Assumptions
4.1. 一般仮定
Our general model of operation is illustrated in Figure 1, showing a visited domain with FA and GFA, and a home network with a HA:
私たちの操作の一般的なモデルは図1で例証されます、HAと共にFA、GFA、およびホームネットワークで訪問されたドメインを示して:
+---------------------------+ +----------------+
| Visited Domain | | Home |
| | +---------+ | Network |
| | | | | |
| +------+ +-------+ | | Public | | +------+ |
| | FA |------| GFA |-------------------------| HA | |
| +--+---+ +-------+ | | Network | | +------+ |
| | | | | | |
+-----|---------------------+ +---------+ +----------------+
|
+--+---+
| MN |
+------+
+---------------------------+ +----------------+ | 訪問されたドメイン| | ホーム| | | +---------+ | ネットワーク| | | | | | | | +------+ +-------+ | | 公衆| | +------+ | | | ファ|------| GFA|-------------------------| ハ| | | +--+---+ +-------+ | | ネットワーク| | +------+ | | | | | | | | +-----|---------------------+ +---------+ +----------------+ | +--+---+ | ミネソタ| +------+
Figure 1: Model of Operation
図1: 操作のモデル
For MNs that cannot process a NAI, or with mobility agents that are not configured to advertise their NAI, regional registration is still useful, but processing the NAI makes it easier for the mobile node to reliably detect domain changes.
NAIを処理できないMNs、または彼らのNAIの広告を出すために構成されない移動性エージェントにとって、地方の登録はまだ役に立っていますが、NAIを処理するのに、ドメイン変化を確かに検出するのはモバイルノードには、より簡単になります。
Fogelstroem, et al. Experimental [Page 7] RFC 4857 Mobile IPv4 Regional Registration June 2007
Fogelstroem、他 地方のIPv4登録2007年6月のモバイルの実験的な[7ページ]RFC4857
4.1.1. Visited Domain
4.1.1. 訪問されたドメイン
We assume two hierarchy levels of FAs in the visited domain. At the top level of the hierarchy, there is at least one GFA, which is an FA with additional features. A GFA must have a publicly routable address. Beneath a GFA, there are one or more FAs. We assume that there exist established security associations between a GFA and the FAs beneath it. When designing a domain supporting regional registrations, the FAs and GFAs in this domain must be compatible. That is, they should support the same encapsulation types, compression mechanisms, etc.
私たちは訪問されたドメインのFAsの2つの階層構造レベルに就きます。 階層構造のトップレベルに、少なくとも1GFAがあります。(GFAは付加的な機能があるFAです)。 GFAには、公的に発送可能なアドレスがなければなりません。 GFAの下に、1FAsがあります。 私たちは、GFAとそれの下のFAsとの設立されたセキュリティ協会が存在すると思います。 地方の登録証明書をサポートするドメインを設計するとき、このドメインのFAsとGFAsは互換性があるに違いありません。 すなわち、彼らは、同じカプセル化がタイプ、圧縮機構であるのなどとサポートするべきです。
When a MN changes care-of address under the same GFA, it MAY perform a regional registration. If the MN changes GFA, within a visited domain or between visited domains, it MUST perform a home registration.
ミネソタが変化する、注意、-、同じ下のGFAを扱ってください、そして、それは地方の登録を実行してもよいです。 ミネソタが訪問されたドメイン以内か訪問されたドメインの間でGFAを変えるなら、それは本国登録を実行しなければなりません。
4.1.2. Authentication
4.1.2. 認証
With regional registrations, a GFA address is registered at the HA as the care-of address of the MN. If a Mobile-Foreign (MN-FA) Authentication extension is present in a Registration Request message directed to the HA, the GFA will perform the authentication. Similarly, if a Foreign-Home (FA-HA) Authentication extension is present in a Registration Request message, the authentication is performed between the GFA and the HA. To summarize, the GFA takes the role of an FA with regard to security associations in the home registrations.
地方の登録証明書に、GFAアドレスがHAに登録される、注意、-、ミネソタのアドレス。 モバイルに外国(ミネソタ-FA)の認証拡大がHAに向けられたRegistration Requestメッセージに存在していると、GFAは認証を実行するでしょう。 同様に、Foreign-ホーム(FA-HA)認証拡大がRegistration Requestメッセージに存在しているなら、認証はGFAとHAの間で実行されます。 まとめるために果たす、GFAはセキュリティ協会に関してホーム登録証明書でFAの役割を果たします。
Regional registration messages also need to be protected with authentication extensions in the same way as registrations with the HA. This means that the MN and the GFA MUST have received the keys needed to construct the authentication extensions before any regional registration is performed. As described above, since the GFA address is the registered care-of address of the MN at its home network, the GFA is the agent within the visited domain that has to have the appropriate security associations with the HA and the MN. The GFA's security association with the MN is then used to enable proper authentication for regional registrations (see Section 6). How the keys are distributed is outside the scope of this draft. One example is to distribute the keys as part of the home registration, for example according to [RFC4004] and [RFC3957]. Another example is pre-configured keys.
また、地方の登録メッセージは、HAとの登録証明書と同様に、認証拡大で保護される必要があります。 これは、ミネソタとGFA MUSTがどんな地方の登録も実行される前に認証拡大を構成するのに必要であるキーを受けたことを意味します。 GFAアドレスが登録であった時から上で説明される、注意、-、ホームネットワークにおけるミネソタのアドレス、GFAはHAとミネソタとの適切なセキュリティ協会を持たなければならない訪問されたドメインの中のエージェントです。 そして、ミネソタとのGFAのセキュリティ協会は、地方の登録証明書のための適切な認証を可能にするのに使用されます(セクション6を見てください)。 この草稿の範囲の外にキーがどう分配されているかがあります。 1つの例は本国登録の一部、例えば、[RFC4004]と[RFC3957]に従ってキーを分配することです。 別の例はあらかじめ設定されたキーです。
Fogelstroem, et al. Experimental [Page 8] RFC 4857 Mobile IPv4 Regional Registration June 2007
Fogelstroem、他 地方のIPv4登録2007年6月のモバイルの実験的な[8ページ]RFC4857
4.2. Protocol Overview
4.2. プロトコル概要
When a MN first arrives at a visited domain, it performs a registration with its home network. During this registration, the HA registers the care-of address of the MN. In case the visited domain supports regional registrations, the care-of address that is registered at the HA is the address of a GFA. The GFA keeps a visitor list of all the MNs currently registered with it.
ミネソタが最初に訪問されたドメインに到着するとき、それはホームネットワークで登録を実行します。 この登録の間、HAが登録する、注意、-、ミネソタのアドレス。 場合では、訪問されたドメインが地方の登録証明書をサポートする、注意、-、HAに登録されるアドレスはGFAのアドレスです。 GFAは、現在すべてのMNsの訪問者リストをそれに登録し続けます。
Since the care-of address registered at the HA is the GFA address, it will not change when the MN changes FA under the same GFA. Thus, the HA does not need to be informed of further MN movements within the visited domain.
以来、注意、-、HAに登録されたアドレスがGFAアドレスである、それはミネソタがいつ同じGFAの下でFAを変えるかを変えないでしょう。 したがって、HAは訪問されたドメインの中でさらなるミネソタの運動において知識がある必要はありません。
Figure 2 illustrates the signaling message flow for home registration. During the home registration, the HA records the GFA address as the care-of address of the MN.
図2は本国登録のためにシグナリングメッセージ流動を例証します。 本国登録の間、HAがGFAアドレスを記録する、注意、-、ミネソタのアドレス。
MN FA1 GFA HA
| | | |
| Registration Request | | |
|---------------------->| Reg. Request | |
| |---------------------->| Reg. Request |
| | |--------------->|
| | | Reg. Reply |
| | Reg. Reply |<---------------|
| Registration Reply |<----------------------| |
|<----------------------| | |
| | | |
ミネソタFA1 GFA、ハ。| | | | | 登録要求| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| レッジ要求| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| レッジ要求| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| レッジ返答してください。| | | レッジ返答してください。| <、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| 登録回答| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、|、|、|、|
Figure 2: Home Registration
図2: 本国登録
Figure 3 illustrates the signaling message flow for regional registration. Even though the MN's local care-of address changes, the HA continues to use the GFA address as the care-of address of the MN. We introduce two new message types for regional registrations: Regional Registration Request and Regional Registration Reply.
図3は地方の登録のためにシグナリングメッセージ流動を例証します。 ミネソタが地方である、注意、-、変化を扱ってください、とHAがGFAが扱う使用に続けている、注意、-、ミネソタのアドレス。 私たちは地方の登録証明書のための2つの新しいメッセージタイプを導入します: 地方の登録要求と地方の登録は返答します。
Fogelstroem, et al. Experimental [Page 9] RFC 4857 Mobile IPv4 Regional Registration June 2007
Fogelstroem、他 地方のIPv4登録2007年6月のモバイルの実験的な[9ページ]RFC4857
MN FA2 GFA HA
| | | |
| Regional Reg. Req. | | |
|---------------------->| Regional Registration Req. | |
| |----------------------------->| |
| | Regional Registration Reply | |
| Regional Reg. Reply |<-----------------------------| |
|<----------------------| | |
| | | |
ミネソタFA2 GFA、ハ。| | | | | 地方のレッジReq。 | | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| 地方の登録Req。 | | | |----------------------------->| | | | 地方の登録回答| | | 地方のレッジ返答してください。|<-----------------------------| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、|、|、|、|
Figure 3: Regional Registration
図3: 地方の登録
4.3. Advertising Foreign Agent and GFA
4.3. 広告の外国人のエージェントとGFA
A FA typically announces its presence via an Agent Advertisement message [RFC3344]. If the domain to which an FA belongs supports regional registrations, the following changes apply to the Agent Advertisement.
エージェントAdvertisementメッセージ[RFC3344]でFAは存在を通常示します。 FAが属するドメインが地方の登録証明書をサポートするなら、以下の変化はエージェントAdvertisementに適用されます。
The 'I' flag (see Section 8.1) MUST be set to indicate that the domain supports regional registrations. If the 'I' flag is set, there MUST be at least one care-of address in the Agent Advertisement. If the 'I' flag is set and there is only one care-of address, it is the address of the FA. If the 'I' flag is set, and there is more than one care-of address, the first care-of address is the local FA, and the last care-of address is the GFA. (Any care-of addresses advertised in addition to these two are out of scope for this document).
ドメインが地方の登録証明書をサポートするのを示すように'私'旗(セクション8.1を見る)を設定しなければなりません。 '私'旗が設定されるなら、少なくとも1つがあるに違いない、注意、-、エージェントでAdvertisementを扱ってください。 '私'旗が設定されて、1つしかない、注意、-、アドレス、それはFAのアドレスです。 '私'旗が設定されて、ある、1以上、注意、-、アドレス、1番目、注意、-、アドレスが地方のFAと、最終である、注意、-、アドレスはGFAです。 (いくらか、注意、-、このドキュメントのための範囲の外にこれらの2に加えての広告に掲載されたアドレスがある、)
The FA-NAI (see Section 8.2) SHOULD also be present in the Agent Advertisement to enable the MN to decide whether or not it has moved to a new domain since its last registration. The decision is based on whether the realm part of the advertised FA-NAI matches the realm of the FA-NAI advertised by the MN's previous FA.
FA-NAI、(ミネソタが、最後の登録以来それが新しいドメインに移行しているかどうか決めるのを可能にするエージェントAdvertisementでまた、セクション8.2) SHOULDも存在しているのを見てください。 決定は広告を出しているFA-NAIの分野の部分がミネソタの前のFAによって広告に掲載されたFA-NAIの分野に合っているかどうか基づいています。
4.4. Backwards Compatibility with RFC 3344
4.4. RFC3344との遅れている互換性
A domain that supports regional registrations should also be backwards compatible.
また、地方の登録証明書をサポートするドメインは後方にそうであるべきです。互換性がある。
An FA MUST support registrations according to Mobile IPv4 as defined in [RFC3344]. This allows MNs that don't support regional registrations to register via this FA using standard Mobile IPv4. If the FA advertises both its own care-of address and a GFA care-of address, a MN that supports regional registrations but has a HA that doesn't, will still be able to make use of regional registrations through that GFA care-of address.
[RFC3344]で定義されるモバイルIPv4に従ったFA MUSTサポート登録証明書。 これで、地方の登録証明書をサポートしないMNsは、このFAを通して標準のモバイルIPv4を使用することで登録できます。 そして、FAが両方の広告を出す、それ自身、注意、-、アドレス、GFA、注意、-、アドレス、地方の登録証明書をサポートしますが、そうしないHAを持っているミネソタ、まだそのGFAを通した地方の登録証明書を利用できる、注意、-、アドレス。
Fogelstroem, et al. Experimental [Page 10] RFC 4857 Mobile IPv4 Regional Registration June 2007
Fogelstroem、他 地方のIPv4登録2007年6月のモバイルの実験的な[10ページ]RFC4857
The advertised GFA care-of address MAY be set to all-ones, to indicate dynamic GFA assignment. If the MN supports regional registrations, and an all-ones GFA care-of address is advertised, the MN SHOULD use dynamic GFA assignment (see Section 7.1).
広告を出しているGFA、注意、-、オールものにアドレスがダイナミックなGFA課題を示すように設定されるかもしれません。 ミネソタが地方の登録証明書、およびオールものGFAをサポートする、注意、-、アドレスの広告を出して、MN SHOULDはダイナミックなGFA課題を使用します(セクション7.1を見てください)。
5. Home Registration
5. 本国登録
This section gives a detailed description of home registration, i.e., registration with the HA (on the home network). Home registration is performed when a MN first arrives at a visited domain, when it requests a new HA, or when it changes GFA. Home registration is also performed to renew bindings which would otherwise expire.
このセクションは本国登録の詳述、すなわち、HA(ホームネットワークの)との登録を与えます。 ミネソタが最初に訪問されたドメインに到着するとき、本国登録は実行されます、新しいHAを要求するか、またはGFAを変えると。 また、本国登録は、そうでなければ期限が切れる結合を更新するために実行されます。
5.1. Mobile Node Considerations
5.1. モバイルノード問題
Upon receipt of an Agent Advertisement message with the 'I' flag set and an FA-NAI extension, the MN compares the domain part of the FA NAI with the one received in the previous Agent Advertisement, to determine whether it has moved to a new domain since its last registration. If the NAIs do not match, the MN MUST assume it has moved to a new domain.
'私'旗のセットとFA-NAI拡張子があるエージェントAdvertisementメッセージを受け取り次第、ミネソタは最後の登録以来それが新しいドメインに動いているかどうか決定するために前のエージェントAdvertisementに受け取られたものとFA NAIのドメイン部分を比べます。 NAIsが合っていないなら、ミネソタは、それが新しいドメインに動いたと仮定しなければなりません。
If the MN determines that it has moved to a new domain, it SHOULD insert the advertised GFA address in the care-of address field in the Registration Request message. For dynamic GFA assignment, see Section 7.1.
ミネソタが新しいドメインに動いて、広告を出しているGFAが中に記述するSHOULD差し込みであることを決定する、注意、-、Registration Requestメッセージの分野を記述してください。 ダイナミックなGFA課題に関しては、セクション7.1を見てください。
A MN with a co-located care-of address might also want to use regional registrations. It then finds out the address of a GFA, either from Agent Advertisements sent by an FA, or by some means not described in this document. The MN MAY then generate a Registration Request message, with the GFA address in the care-of address field, and send it directly to the GFA (not via an FA). In this case, the MN MUST add a Hierarchical Foreign Agent (HFA) extension (see Section 9.2), including its co-located care-of address, to the Registration Request before sending it. The HFA extension MUST be protected by an authentication extension. If the MN has established a mobility security association with the GFA, the HFA extension MUST be placed before the MN-FA Authentication extension, and it SHOULD be placed after the Mobile-Home (MN-HA) Authentication extension. Otherwise, if the MN has no established mobility security association with the GFA, the HFA extension MUST be placed before the MN-HA authentication extension.
aがあるミネソタが共同場所を見つけた、注意、-、また、アドレスは地方の登録証明書を使用したがっているかもしれません。 そして、それはどちらかFAによって送られるか、またはどうでも本書では説明されなかったエージェントAdvertisementsからGFAのアドレスを見つけます。 次に、ミネソタはRegistration Requestメッセージを発生させるかもしれません、中にGFAアドレスがある状態で注意、-、分野を記述してください、そして、直接GFA(FAを通した)にそれを送ってください。 この場合ミネソタがHierarchical Foreignエージェント(HFA)拡大を加えなければならなくて(セクション9.2を見てください)、包含して、それが共同見つけられた、注意、-、それを送る前のRegistration Requestへのアドレス。 認証拡大でHFA拡張子を保護しなければなりません。 ミネソタがGFAとの移動性セキュリティ協会を設立したなら、ミネソタ-FA Authentication拡張子、およびそれの前にHFA拡張子を置かなければならない、SHOULD、モバイルホーム(ミネソタ-HA)認証拡大の後に置かれてください。 さもなければ、ミネソタにGFAとのどんな設立された移動性セキュリティ協会もないなら、ミネソタ-HA認証拡張子の前にHFA拡張子を置かなければなりません。
If the MN receives an Agent Advertisement with the 'R' bit set, even if it has a co-located care-of address, it still formulates the same Registration Request message with extensions, but it sends the message to the advertising FA instead of to the GFA.
ミネソタがそれでaの共同見つけても設定された'R'ビットでエージェントAdvertisementを受ける、注意、-、アドレス、拡大でまだ同じRegistration Requestメッセージを定式化していますが、それはGFAの代わりに広告FAにメッセージを送ります。
Fogelstroem, et al. Experimental [Page 11] RFC 4857 Mobile IPv4 Regional Registration June 2007
Fogelstroem、他 地方のIPv4登録2007年6月のモバイルの実験的な[11ページ]RFC4857
If the home registration is about to expire, the MN performs a new home registration using the same GFA care-of address to refresh the binding [RFC3344]. If the MN has just moved to a new FA and not yet sent a Regional Registration Request when the home registration is due to expire, the MN sends only a Registration Request, as this will update both the GFA and the HA.
本国登録が期限が切れようとしているなら、ミネソタが同じGFAを使用することで新しい本国登録を実行する、注意、-、結合[RFC3344]をリフレッシュするために、記述します。 本国登録が期限が切れることになっているとき、ミネソタがただ新しいFAに動いて、まだRegional Registration Requestを送らないなら、ミネソタはRegistration Requestだけを送ります、これがGFAとHAの両方をアップデートするとき。
If the Registration Reply includes a Replay Protection Style extension, the value in the Initial Identification field is the value to be used for replay protection in the next Regional Registration Request (see Section 6.1).
Registration ReplyがReplay Protection様式拡張子を含んでいるなら、Initial Identification分野の値は次のRegional Registration Requestの反復操作による保護に使用されるべき値(セクション6.1を見る)です。
5.2. Foreign Agent Considerations
5.2. 外国エージェント問題
When the FA receives a Registration Request message from a MN, it extracts the care-of address field to find the GFA to which the message shall be relayed. All FAs that advertise the 'I' flag MUST also be able to handle Registration Requests with an all-zeros care- of address (used for dynamic GFA assignment).
FAがミネソタからRegistration Requestメッセージを受け取って、それが抜粋である、注意、-、分野を記述して、メッセージがリレーされるものとするGFAを見つけてください。 また、'私'旗の広告を出すすべてのFAsがアドレス(ダイナミックなGFA課題のために、使用される)のオールゼロ注意でRegistration Requestsを扱うことができなければなりません。
If the FA receives a Registration Request where the care-of address is set to all-ones (which could happen if a MN that doesn't support Regional Registrations copied an all-ones care-of address from an Agent Advertisement), it MUST reply with the Code field set to "poorly formed request" [RFC3344].
FAがRegistration Requestを受ける、どこ、注意、-、アドレス、オールものに設定されるか、(Regional Registrationsを支持しないミネソタがオールものをコピーするならどれが起こることができるか、注意、-、エージェントAdvertisementからのアドレス)、それはCode分野セットで「不十分に形成された要求」[RFC3344]に関して返答しなければなりません。
If the Registration Request has the 'T' bit set, the MN is requesting Reverse Tunneling [RFC3024]. In this case, the FA has to tunnel packets from the MN to the GFA for further handling.
Registration Requestが'T'ビットを設定させるなら、ミネソタはReverse Tunneling[RFC3024]を要求しています。 この場合、FAはさらなる取り扱いのためにミネソタからGFAまでパケットにトンネルを堀らなければなりません。
If the care-of address in the Registration Request is the address of the FA, the FA relays the message directly to the HA, as described in [RFC3344]. For each pending or current home registration, the FA maintains a visitor list entry as described in [RFC3344]. If reverse tunneling is being used, the visitor list MUST contain the address of the GFA, in addition to the fields required in [RFC3344].
注意、-、Registration RequestのアドレスがFAのアドレスである、FAは直接HAにメッセージをリレーします、[RFC3344]で説明されるように。 それぞれの未定の、または、現在の本国登録のために、FAは[RFC3344]で説明されるように訪問者リストエントリーを維持します。 逆のトンネリングが使用されているなら、訪問者リストはGFAのアドレスを含まなければなりません、[RFC3344]で必要である分野に加えて。
Otherwise, if the care-of address in the Registration Request is the address of a GFA (or all-zeros), the FA adds a Hierarchical Foreign Agent (HFA) extension, including its own address, to the Registration Request, and relays it to the GFA. The HFA extension MUST be appended at the end of all previous extensions that were included in the Registration Request when the FA received it, and it MUST be protected by a Foreign-Foreign (FA-FA) Authentication extension (see Section 11).
そうでなければ、注意、-、Registration RequestのアドレスがGFA(または、オールゼロ)のアドレスであり、FAはそれ自身のアドレスを含むHierarchical Foreignエージェント(HFA)拡大をRegistration Requestに加えて、GFAにそれをリレーします。 FAがRegistration Requestに含まれていた前のすべての拡大の終わりにそれを受けたとき、HFA拡張子を追加しなければなりません、そして、Foreign外国の(FA-FA)認証拡大でそれを保護しなければなりません(セクション11を見てください)。
Fogelstroem, et al. Experimental [Page 12] RFC 4857 Mobile IPv4 Regional Registration June 2007
Fogelstroem、他 地方のIPv4登録2007年6月のモバイルの実験的な[12ページ]RFC4857
5.3. GFA Considerations
5.3. GFA問題
For each pending or current home registration, the GFA maintains a visitor list entry as described in [RFC3344]. This visitor list entry is also updated for the regional registrations performed by the MN. In addition to the fields required in [RFC3344], the list entry MUST contain:
それぞれの未定の、または、現在の本国登録のために、GFAは[RFC3344]で説明されるように訪問者リストエントリーを維持します。 また、ミネソタによって実行された地方の登録証明書のためにこの訪問者リストエントリーをアップデートします。 [RFC3344]で必要である分野に加えて、リストエントリーは以下を含まなければなりません。
o the current care-of address of the MN (i.e., the FA or co-located
address) received in the HFA extension
o the remaining Lifetime of the regional registration
o the style of replay protection in use for the regional
registration
o the Identification value for the regional registration.
o 電流、注意、-、ミネソタ(すなわち、FAか共同位置しているアドレス)のアドレスはHFA拡張子oで反復操作による保護のスタイルがIdentificationが地方の登録のために評価する地方の登録oに中で使用する地方の登録oの残っているLifetimeを受けました。
The default replay protection style for regional registrations is timestamp-based replay protection, as defined in Mobile IPv4 [RFC3344]. If the timestamp sent by the MN in the Registration Request is not close enough to the GFA's time-of-day clock, the GFA adds a Replay Protection Style extension (see Section 9.3) to the Registration Reply, with the GFA's time of day in the Identification field to synchronize the MN with the GFA for the regional registrations.
地方の登録証明書のためのデフォルト反復操作による保護スタイルはモバイルIPv4[RFC3344]で定義されるようにタイムスタンプベースの反復操作による保護です。 Registration Requestのミネソタによって送られたタイムスタンプがGFAの時刻時計に十分近くないなら、GFAの時刻がIdentification分野にある状態で、GFAは、地方の登録証明書のためのGFAにミネソタを連動させるように、Replay Protection様式拡張子(セクション9.3を見る)をRegistration Replyに加えます。
If nonce-based replay protection is used, the GFA adds a Replay Protection Style extension to the Registration Reply, where the high- order 32 bits in the Identification fields is the nonce that should be used by the MN in the following regional registration.
一回だけベースの反復操作による保護が使用されているなら、GFAはReplay Protection様式拡張子をRegistration Replyに加えます。そこでは、Identificationの32ビットがさばく高いオーダーが以下の地方の登録にミネソタによって使用されるべきである一回だけです。
If the Registration Request contains a Replay Protection Style extension (see Section 9.3) requesting a style of replay protection not supported by the GFA, the GFA MUST reject the Registration Request and send a Registration Reply with the value in the Code field set to REPLAY_PROT_UNAVAIL (see Section 9.5).
Registration RequestがGFAによって支持されなかった反復操作による保護のスタイルを要求しながらReplay Protection様式拡張子(セクション9.3を見る)を含んでいるなら、GFA MUSTはCode分野セットでREPLAY_PROT_UNAVAILにRegistration Requestを拒絶して、値があるRegistration Replyを送ります(セクション9.5を見てください)。
If the Hierarchical Foreign Agent (HFA) extension comes after the MN-FA Authentication extension, the GFA MUST remove it from the Registration Request. The GFA then sends the Registration Request to the HA. Upon receipt of the Registration Reply, the GFA consults its pending registration record to find the care-of address within its domain that is currently used by the MN, and sends the Registration Reply to that care-of address.
Hierarchical Foreignエージェント(HFA)拡大がミネソタ-FA Authentication拡張子に続いているなら、GFA MUSTはRegistration Requestからそれを取り除きます。 そして、GFAはRegistration RequestをHAに送ります。 Registration Replyを受け取り次第GFAが見つける未定の登録記録に相談する、注意、-、現在ミネソタによって使用されて、Registration Replyをそれに送るドメインの中のアドレス、注意、-、アドレス。
If the Replay Protection Style extension (see Section 9.3) is present in a Registration Request, and follows the MN-HA Authentication extension, the GFA SHOULD remove the Replay Protection Style extension after performing any necessary processing and before sending the Registration Request to the HA.
Replay Protection様式拡張子(セクション9.3を見る)がRegistration Requestに存在していて、ミネソタ-HA Authentication拡張子に従うなら、どんな必要な処理も実行した後とRegistration RequestをHAに送る前に、GFA SHOULDはReplay Protection様式拡張子を取り除きます。
Fogelstroem, et al. Experimental [Page 13] RFC 4857 Mobile IPv4 Regional Registration June 2007
Fogelstroem、他 地方のIPv4登録2007年6月のモバイルの実験的な[13ページ]RFC4857
If the GFA receives a Registration Request from a MN that it already has a mobility binding for, this is an update of a binding that is about to expire. If the address in the Hierarchical Foreign Agent (HFA) extension is the same as the current care-of address in the visitor list for the MN, the entries in the visitor list concerning regional registrations are not changed, except to update the lifetime. If the address in the HFA extension is a new address, the values for the regional registration are updated.
GFAがそれが既に移動性結合を持っているミネソタからRegistration Requestを受けるなら、これは期限が切れようとしている結合のアップデートです。 Hierarchical Foreignエージェント(HFA)拡大におけるアドレスが電流と同じである、注意、-、ミネソタへの訪問者リストのアドレス、地方の登録証明書に関する訪問者リストにおけるエントリーは変えられません、生涯アップデートするのを除いて。 HFA拡張子におけるアドレスが新しいアドレスであるなら、地方の登録のための値をアップデートします。
If the Registration Request has the 'T' bit set, the GFA has to decapsulate the packets from the FA and re-encapsulate them for further delivery back to the HA. These actions are required because the HA has to receive such packets from the expected care-of address (i.e., that of the GFA) instead of the local care-of address (i.e., that of the FA).
Registration Requestが'T'ビットを設定させるなら、GFAはHAへのさらなる配送のためにFAと再要約のそれらからのパケットをdecapsulateに持っています。 HAが予想からそのようなパケットを受けなければならないのでこれらの動作が必要である、注意、-、地方の代わりに(すなわち、GFAのもの)を記述してください、注意、-、(すなわち、FAのもの)を記述してください。
When receiving a Registration Reply from the HA, the GFA MAY add a Regional Registration Lifetime extension to the message before relaying it to the FA. The extension defines the lifetime that the GFA allows the MN before it has to renew its regional registration. The GFA MUST set the lifetime of the regional registration to be no greater than the remaining lifetime of the MN's registration with its HA. If used, the Regional Registration Lifetime extension MUST be added after any other extensions, and MUST be protected by an MN-FA Authentication extension.
HAからRegistration Replyを受けるとき、FAにそれをリレーする前に、GFA MAYはRegional Registration Lifetime拡張子をメッセージに追加します。 拡大は地方の登録を更新しなければならない前にGFAがミネソタを許容する生涯を定義します。 GFA MUSTは、地方の登録の生涯にHAとのミネソタの登録の残っているより生涯であるように設定します。 使用されるなら、Regional Registration Lifetime拡張子をいかなる他の拡大の後にも加えなければならなくて、ミネソタ-FA Authentication拡張子で保護しなければなりません。
5.4. Home Agent Considerations
5.4. ホームエージェント問題
The Registration Request is processed by the HA as described in [RFC3344].
Registration Requestは[RFC3344]で説明されるようにHAによって処理されます。
6. Regional Registration
6. 地方の登録
This section describes regional registrations. Once the HA has registered the GFA address as the care-of address of the MN, the MN may perform regional registrations. When performing regional registrations, the MN may either register an FA care-of address or a co-located address with the GFA. In the following, we assume that a home registration has already occurred, as described in Section 5, and that the GFA has a mobility security association with the MN.
このセクションは地方の登録証明書について説明します。 一度、HAがGFAアドレスを登録した、注意、-、ミネソタ(ミネソタ)のアドレスは地方の登録証明書を実行するかもしれません。 地方の登録証明書を実行するとき、ミネソタがFAを登録するかもしれない、注意、-、アドレスかGFAとの共同見つけられたアドレス。 以下では、私たちは本国登録がセクション5で説明されるように既に起こって、GFAにはミネソタとの移動性セキュリティ協会があると思います。
Suppose the MN moves from one FA to another FA within the same visited domain. It will then receive an Agent Advertisement from the new FA. Suppose further that the Agent Advertisement indicates that the visited domain supports regional registrations, and either that the advertised GFA address is the same as the one the MN has registered as its care-of address during its last home registration, or that the realm part of the newly advertised FA-NAI matches the FA-
ミネソタが同じ訪問されたドメインの中を1FAから別のFAまで動くと仮定してください。 そして、それは新しいFAからエージェントAdvertisementを受けるでしょう。 エージェントAdvertisementが訪問されたドメインが地方の登録証明書を支持して、広告を出しているGFAが記述するどちらかがミネソタが登録したものに同じであることを示すとさらに仮定してください、それ、注意、-、最後の家の間、登録を記述してください。さもないと、分野が新たに広告を出したFA-NAIを離れさせているのがFAに合っています。
Fogelstroem, et al. Experimental [Page 14] RFC 4857 Mobile IPv4 Regional Registration June 2007
Fogelstroem、他 地方のIPv4登録2007年6月のモバイルの実験的な[14ページ]RFC4857
NAI advertised by the MN's previous FA. Then, the MN can perform a regional registration with this FA and GFA. The MN issues a Regional Registration Request to the GFA via the new FA. The request is authenticated using the existing mobility security association between the GFA and the MN and the message is authenticated by the MN-GFA Authentication extension (see Section 11). The care-of address should be set to the address of the local FA.
NAIはミネソタの前のFAで広告を出しました。 そして、ミネソタはこのFAとGFAとの地方の登録を実行できます。 ミネソタは新しいFAを通してGFAにRegional Registration Requestを発行します。 要求はGFAとミネソタとの既存の移動性セキュリティ協会を使用することで認証されます、そして、メッセージはミネソタ-GFA Authentication拡張子で認証されます(セクション11を見てください)。 注意、-、アドレスは地方のFAのアドレスに設定されるべきです。
If the Regional Registration Request contains a care-of address field of all-zeros, the FA adds a Hierarchical Foreign Agent (HFA) extension to the message and relays it to the GFA. Based on the information in the HFA extension, the GFA updates the MN's current point of attachment in its visitor list. The GFA then issues a Regional Registration Reply to the MN via the FA.
Regional Registration Requestがaを含んでいる、注意、-、オールゼロのアドレス・フィールド、FAはHierarchical Foreignエージェント(HFA)拡大をメッセージに追加して、GFAにそれをリレーします。 HFA拡張子における情報に基づいて、GFAはミネソタの訪問者リストでの付属の現在のポイントをアップデートします。 そして、GFAはFAを通してミネソタにRegional Registration Replyを発行します。
If the advertised GFA is not the same as the one the MN has registered as its care-of address, and if the MN is still within the same domain as it was when it registered that care-of address, the MN MAY try to perform a regional registration with its registered GFA. If the FA cannot support regional registration to a GFA, other than advertised, the FA denies the Regional Registration Request with code UNKNOWN_GFA (see Section 10.3). In this case, the MN has to do a new home registration via the new GFA.
広告を出しているGFAがミネソタが登録したものに同じでない、それ、注意、-、アドレス、それがそれを登録した時であるときにミネソタがまだ同じドメインの中のそうである、注意、-、アドレス、ミネソタは登録されたGFAとの地方の登録を実行しようとするかもしれません。 FAが地方の登録をGFAに支持できないなら、広告を出されるのを除いて、FAはコードUNKNOWN_GFAと共にRegional Registration Requestを否定します(セクション10.3を見てください)。 この場合、ミネソタは新しいGFAを通して新しい本国登録をしなければなりません。
New message types are introduced for the Regional Registration Request and Reply. The motivation for introducing new message types, rather than using the Registration Request and Reply defined in [RFC3344] is: (1) the MN must be able to distinguish regional registrations from home registrations, since in the former case the timestamps/nonces are synchronized with its GFA and in the latter with its HA; and (2) a home registration MUST be directed to the home network before the lifetime of the GFA care-of address expires.
Regional Registration RequestとReplyのために新しいメッセージタイプを導入します。 [RFC3344]で定義されたRegistration RequestとReplyを使用するよりむしろ新しいメッセージタイプを導入することに関する動機は以下の通りです。 (1) ミネソタは家の登録証明書と地方の登録証明書を区別できなければなりません、タイムスタンプ/一回だけがGFAとHAがある後者で前の場合では、連動するので。 (2) そして、GFAの生涯の前にホームネットワークに本国登録を向けなければならない、注意、-、アドレスは期限が切れます。
6.1. Mobile Node Considerations
6.1. モバイルノード問題
For each pending or current home registration, the MN maintains the information described in [RFC3344]. The information is also updated for the regional registrations performed by the MN. In addition to the information described in [RFC3344], the MN MUST maintain the following information, if present:
それぞれの未定の、または、現在の本国登録のために、ミネソタは[RFC3344]で説明された情報を保守します。 また、ミネソタによって実行された地方の登録証明書のために情報をアップデートします。 [RFC3344]で説明された情報に加えて、存在しているなら、ミネソタは以下の情報を保守しなければなりません:
o the GFA address
o the remaining Lifetime of the regional registration
o the style of replay protection in use for the regional
registration
o the Identification value for the regional registration.
o GFAは○ 反復操作による保護のスタイルがIdentificationが地方の登録のために評価する地方の登録oに中で使用する地方の登録oの残っているLifetimeを記述します。
Fogelstroem, et al. Experimental [Page 15] RFC 4857 Mobile IPv4 Regional Registration June 2007
Fogelstroem、他 地方のIPv4登録2007年6月のモバイルの実験的な[15ページ]RFC4857
The replay protection for home registrations and regional registrations is performed as described in [RFC3344]. Since the MN performs regional registrations at the GFA in parallel with home registrations at the HA, the MN MUST be able to keep one replay protection mechanism and sequence for the GFA, and a separate mechanism and sequence for the HA.
家の登録証明書と地方の登録証明書のための反復操作による保護は[RFC3344]で説明されるように実行されます。 ミネソタがGFAでHAの家の登録証明書と平行して地方の登録証明書を実行するので、ミネソタは、GFAのために1つの反復操作による保護メカニズムと系列を保って、HAのために別々のメカニズムと系列を保つことができなければなりません。
For regional registrations, replay protection may also be provided at the FA by the challenge-response mechanism, as described in [RFC4721].
また、地方の登録証明書において、チャレンジレスポンスメカニズムは[RFC4721]で説明されるようにFAで反復操作による保護を提供するかもしれません。
6.2. Foreign Agent Considerations
6.2. 外国エージェント問題
When the FA receives a Regional Registration Request from a MN, addressed to a GFA, it generally processes the message according to the rules of processing a Registration Request addressed to a HA (see Section 5.2). The only difference is that the GFA IP address field replaces the HA address field. If that address belongs to a known GFA, the FA forwards the request to the indicated GFA. Otherwise, the FA MUST generate a Regional Registration Reply with error code UNKNOWN_GFA.
FAがGFAに演説されたミネソタからRegional Registration Requestを受けるとき、Registration RequestがHAに記述した処理の規則に従って、一般に、それはメッセージを処理します(セクション5.2を見てください)。 唯一の違いはGFA IPアドレス・フィールドがHAアドレス・フィールドを取り替えるということです。 そのアドレスが知られているGFAに属すなら、FAは示されたGFAに要求を転送します。 さもなければ、FA MUSTはエラーコードUNKNOWN_GFAと共にRegional Registration Replyを発生させます。
For each pending or current registration, the FA maintains a visitor list entry as described in [RFC3344]. If reverse tunneling is being used, the visitor list MUST contain the address of the GFA, in addition to the fields required in [RFC3344]. This is required so that the FA can tunnel datagrams, sent by the MN, to the GFA. The GFA then decapsulates the datagrams, re-encapsulates them, and sends them to the HA.
それぞれの未定の、または、現在の登録のために、FAは[RFC3344]で説明されるように訪問者リストエントリーを維持します。 逆のトンネリングが使用されているなら、訪問者リストはGFAのアドレスを含まなければなりません、[RFC3344]で必要である分野に加えて。 これが、FAがミネソタによって送られたデータグラムにGFAにトンネルを堀ることができるくらい必要です。 GFAは次に、データグラムをdecapsulatesして、それらを再要約して、それらをHAに送ります。
6.3. GFA Considerations
6.3. GFA問題
If the GFA accepts a Regional Registration Request, it MUST set the lifetime of the regional registration to be no greater than the remaining lifetime of the MN's registration with its HA, and put this lifetime into the corresponding Regional Registration Reply. The GFA MUST NOT accept a request for a regional registration if the lifetime of the MN's registration with its HA has expired. In that case, the GFA sends a Regional Registration Reply with the value in the Code field set to NO_HOME_REG.
GFAがRegional Registration Requestを受け入れるなら、それは、HAとのミネソタの登録の残っているより生涯であるように地方の登録の生涯に決めて、対応するRegional Registration Replyにこの生涯を入れなければなりません。 HAとのミネソタの登録の寿命が期限が切れたなら、GFA MUST NOTは地方の登録のために申し込みに応じます。 その場合、GFAはCode分野セットで__ホームがないREGに値があるRegional Registration Replyを送ります。
If the GFA receives a tunneled packet from an FA in its domain, then after decapsulation the GFA looks to see whether it has an entry in its visitor list for the source IP address of the inner IP header after decapsulation. If so, it checks the visitor list to see whether reverse tunneling has been requested; if it was requested, the GFA re-encapsulates the packet with its own address as the source IP address, and the address of the HA as the destination IP address.
GFAがドメインのFAからトンネルを堀られたパケットを受けるなら、GFAが当てにする被膜剥離術の後に、それには内側のIPヘッダーのソースIPアドレスのための訪問者リストにおけるエントリーが被膜剥離術の後にあるかどうかを見てください。 そうだとすれば、逆のトンネリングが要求されているかどうか確認するために訪問者リストをチェックします。 それが要求されたなら、GFAは送付先IPアドレスとしてソースIPアドレスとしてのそれ自身のアドレス、およびHAのアドレスでパケットを再カプセルに入れります。
Fogelstroem, et al. Experimental [Page 16] RFC 4857 Mobile IPv4 Regional Registration June 2007
Fogelstroem、他 地方のIPv4登録2007年6月のモバイルの実験的な[16ページ]RFC4857
7. Dynamic GFA Assignment
7. ダイナミックなGFA課題
Regional registrations may also allow dynamic assignment of a GFA to a MN. The visited network (i.e., the FA) indicates support for dynamic GFA assignment by advertising an all-ones care-of address in the Agent Advertisement. The MN then sets the care-of address in the Registration Request to all-zeros to request a dynamically assigned GFA. Upon receiving this Registration Request, the FA relays it to the appropriate GFA, and the GFA assigns its address to the MN by means of a GFA IP Address extension added to the Registration Request.
また、地方の登録証明書はGFAのダイナミックな課題をミネソタに許容するかもしれません。 訪問されたネットワーク(すなわち、FA)がオールものの広告を出すことによってダイナミックなGFA課題のサポートを示す、注意、-、エージェントにAdvertisementを記述してください。 次に、ミネソタがセットする、注意、-、Registration Requestでは、ダイナミックに割り当てられたGFAを要求するためにオールゼロまで記述します。 このRegistration Requestを受けると、FAは適切なGFAにそれをリレーします、そして、GFAはRegistration Requestに加えられたGFA IP Address拡張子によってミネソタにアドレスを配属します。
In order for dynamic GFA assignment to work, the MN, GFA, and HA, respectively, MUST support the GFA IP Address extension. Also, the FA MUST be able to advertise an all-ones care-of address and handle a Registration Request with an all-zeros care-of address.
ダイナミックなGFA課題が働く命令でミネソタ、GFA、HAはそれぞれGFA IP Address拡張子をサポートしなければなりません。 FA MUST、もオールものの広告を出すことができてください、注意、-、オールゼロでRegistration Requestを記述して、扱ってください、注意、-、アドレス。
Note also that protection of the GFA IP Address extension, added to the Registration Request, requires either the use of an FA-HA Authentication extension or other means to secure the Registration Request when forwarded from the GFA to the HA.
また、GFAからHAまで進めるとRegistration Requestに加えられたGFA IP Address拡張子の保護がFA-HA Authentication拡張子の使用かRegistration Requestを固定する手段のどちらかを他の必要とすることに注意してください。
7.1. Mobile Node Considerations for Dynamic GFA Assignment
7.1. ダイナミックなGFA課題のためのモバイルノード問題
If the 'I' flag in the Agent Advertisement sent out by the FA is set, and the care-of address indicating the GFA is set to all-ones, this indicates support for dynamic GFA assignment.
そして、'私'がエージェントで弛むならFAによって出されたAdvertisementが用意ができている、注意、-、GFAを示すアドレスがオールものに設定されて、これはダイナミックなGFA課題のサポートを示します。
If the MN supports dynamic GFA assignment, and if the advertised GFA address is all-ones, the MN SHOULD set the care-of address field in the Registration Request to all-zeros to request to be assigned a GFA.
MN SHOULDがミネソタがダイナミックなGFA課題をサポートして、広告を出しているGFAアドレスがオールものであるなら、セットした、注意、-、Registration Requestの分野をGFAが割り当てられるよう要求するオールゼロまで記述してください。
When requesting dynamic GFA assignment, the MN MUST check to make sure that it receives a GFA IP Address extension in the Registration Reply.
ダイナミックなGFA課題を要求するとき、ミネソタは、Registration ReplyにGFA IP Address拡張子を受け取るのを念のためチェックしなければなりません。
7.2. Foreign Agent Considerations for Dynamic GFA Assignment
7.2. ダイナミックなGFA課題のための外国エージェント問題
If an FA supports dynamic GFA assignment, and receives a Registration Request with the care-of address field set to all-zeros, the FA assigns a GFA to the MN. A FA can either have a default GFA that it assigns to all MNs or it can assign a GFA by some means not described in this specification.
FAがダイナミックなGFA課題をサポートして、Registration Requestを受ける、注意、-、オールゼロに設定されたアドレス・フィールド、FAはミネソタにGFAを配属します。 FAがそれがすべてのMNsに割り当てるデフォルトGFAを持つことができますか、またはそれはどうでもこの仕様で説明されなかったGFAを割り当てることができます。
If an FA that does not support dynamic GFA assignment receives a Registration Request with the care-of address field set to all-zeros, the FA will deny the request as described in [RFC3344], i.e., by
GFA課題がRegistration Requestを受ける動力を支持しないFAである、注意、-、オールゼロに設定されたアドレス・フィールド、FAはすなわち、[RFC3344]で説明されるように要求を否定するでしょう。
Fogelstroem, et al. Experimental [Page 17] RFC 4857 Mobile IPv4 Regional Registration June 2007
Fogelstroem、他 地方のIPv4登録2007年6月のモバイルの実験的な[17ページ]RFC4857
sending a Registration Reply with the Code field set to "invalid care-of address".
Code分野をセットしてある状態でRegistration Replyを送る、「無効である、注意、-、アドレス、」
7.3. GFA Considerations for Dynamic GFA Assignment
7.3. ダイナミックなGFA課題のためのGFA問題
If a GFA supports dynamic GFA assignment, and receives a Registration Request with the care-of address field set to all-zeros, the GFA assigns its own IP address as care-of address for this MN, and adds a GFA IP Address extension with this address to the Registration Request. The GFA MUST NOT insert the GFA IP address directly in the care-of address field in the Registration Request, since that would cause the MN-HA authentication to fail.
GFAがダイナミックなGFA課題をサポートして、Registration Requestを受ける、注意、-、アドレス・フィールドがオールゼロ、自分自身のIPが記述するGFA案配にセットした、注意、-、このアドレスでa GFA IP Address拡張子をRegistration Requestにこのミネソタに記述して、加えます。 GFA MUST NOTが直接GFA IPアドレスを差し込む、注意、-、Registration Requestの分野を記述してください、それはミネソタ-HA認証に失敗されるでしょう、したがって。
The GFA IP Address extension has to be protected so that it cannot be changed by a malicious node when the Registration Request is forwarded to the HA. If the HA and the GFA have a mobility security association, the GFA IP Address extension MUST be protected by the FA-HA authentication extension. Otherwise, the Registration Request MUST be sent to the HA in a secure way, for example via a secure AAA protocol (e.g., [RFC4004], [RFC3957]).
GFA IP Address拡張子は、Registration RequestをHAに送るとき、悪意があるノードでそれを変えることができないように保護されなければなりません。 HAとGFAに移動性セキュリティ協会があるなら、FA-HA認証拡張子でGFA IP Address拡張子を保護しなければなりません。 さもなければ、安全な方法でRegistration RequestをHAに送らなければなりません、例えば、安全なAAAプロトコル(例えば、[RFC4004]、[RFC3957])で。
If the GFA does not support dynamic GFA assignment, it will deny the request by sending a Registration Reply with the Code field set to ZERO_COA_NOT_SUPP (see Section 9.5).
GFAがダイナミックなGFA課題をサポートしないと、それは、Code分野があるRegistration Replyを送るのによる要求が__どんなZERO_コア川SUPPにもセットしなかったことを(セクション9.5を見てください)否定するでしょう。
7.4. Home Agent Considerations for Dynamic GFA Assignment
7.4. ダイナミックなGFA課題のためのホームエージェント問題
If a HA receives a Registration Request with a GFA IP Address extension, and the HA does not allow the use of this extension, the HA MUST return a Registration Reply with the Code value set to DYN_GFA_NOT_SUPP (see Section 9.5).
HAがGFA IP Address拡張子があるRegistration Requestを受けて、HAがこの拡張子の使用を許さないなら、HA MUSTは_SUPPではなく、DYN_GFA_にCode選択値群があるRegistration Replyを返します(セクション9.5を見てください)。
If a HA receives a Registration Request message with the care-of address set to all-zeros, but no GFA IP Address extension, it MUST deny the request by sending a Registration Reply message with the Code field set to ZERO_CAREOF_ADDRESS (see Section 9.5).
HAがRegistration Requestメッセージを受け取る、注意、-、オールゼロにもかかわらず、GFA IP Address拡張子がないのに設定されたアドレス、それはCode分野があるRegistration Replyメッセージを送るのによる要求がZERO_CAREOF_ADDRESSにセットしたことを(セクション9.5を見てください)否定しなければなりません。
If a HA that does not support dynamic GFA assignment receives a Registration Request with a GFA IP Address extension, the request will be denied by the HA, as described in [RFC3344].
ダイナミックなGFA課題をサポートしないHAがGFA IP Address拡張子があるRegistration Requestを受けると、要求はHAによって否定されるでしょう、[RFC3344]で説明されるように。
If a HA that supports dynamic GFA assignment receives a Registration Request with the care-of address set to all-zeros and a GFA IP Address extension, it MUST register the IP address of the GFA as the care-of address of the MN in its mobility binding list. If the Registration Request is accepted, the HA MUST include the GFA IP Address extension in the Registration Reply, before the MN-HA Authentication extension.
GFA課題がRegistration Requestを受ける動力を支持するHAである、注意、-、オールゼロとGFA IP Address拡張子に設定されたアドレス、GFAのIPアドレスを登録しなければならない、注意、-、移動性の拘束力があるリストのミネソタのアドレス。 Registration Requestを受け入れるなら、HA MUSTはRegistration ReplyにGFA IP Address拡張子を含んでいます、ミネソタ-HA Authentication拡張子の前に。
Fogelstroem, et al. Experimental [Page 18] RFC 4857 Mobile IPv4 Regional Registration June 2007
Fogelstroem、他 地方のIPv4登録2007年6月のモバイルの実験的な[18ページ]RFC4857
7.5. Regional Registration
7.5. 地方の登録
If the MN receives an Agent Advertisement with the care-of address field indicating the GFA set to all-ones, and if the MN determines that it is within the same visited domain as when it did its last home registration, it MAY send a Regional Registration Request to its current GFA. Otherwise, it MUST send a Registration Request to its HA as described in Section 7.1.
ミネソタがエージェントAdvertisementを受ける、注意、-、GFAを示すアドレス・フィールドがオールものにセットして、ミネソタが、それが最後の本国登録をした時と同じ訪問されたドメインの中にそれがあることを決定するなら、それは現在のGFAにRegional Registration Requestを送るかもしれません。 さもなければ、それはセクション7.1で説明されるようにRegistration RequestをHAに送らなければなりません。
8. Router Discovery Extensions
8. ルータ発見拡大
This section specifies a new flag within the Mobile IP Agent Advertisement, and an optional extension to the ICMP Router Discovery Protocol [RFC1256].
このセクションは、モバイルIPエージェントAdvertisementの中で新しい旗を指定して、ICMP Routerディスカバリープロトコル[RFC1256]に任意の拡大を指定します。
8.1. Regional Registration Flag
8.1. 地方の登録旗
The only change to the Mobility Agent Advertisement Extension defined in [RFC3344] is a flag indicating that the domain, to which the FA generating the Agent Advertisement belongs, supports regional registrations. The flag is inserted after the flags defined in [RFC3344], [RFC3024], and [RFC3519].
[RFC3344]で定義されたMobilityエージェントAdvertisement Extensionへの唯一の変化がドメイン(エージェントAdvertisementを発生させるFAは属する)が地方の登録証明書を支持するのを示す旗です。 旗は[RFC3344]、[RFC3024]、および[RFC3519]で定義された旗の後に挿入されます。
Regional Registration flag:
地方のRegistrationは弛みます:
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 | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |R|B|H|F|M|G|r|T|U|I| reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| zero or more Care-of Addresses |
| ... |
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| 一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 生涯|R|B|H|F|M|G|r|T|U|I| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ゼロか以上、Care、-、Addresses| | ... |
The flag is defined as follows:
旗は以下の通り定義されます:
Type 16 (Mobility Agent Advertisement)
16をタイプしてください。(移動性エージェント広告)
I Regional Registration. This domain supports
regional registration as specified in this document.
I地方の登録。 このドメインは本書では指定されるとしての地方の登録を支持します。
8.2. Foreign Agent NAI Extension
8.2. 外国エージェントNAI拡張子
The FA-NAI extension is defined as subtype 3 of the NAI Carrying Extension [RFC3846].
FA-NAI拡張子は3「副-タイプ」NAI Carrying Extension[RFC3846]と定義されます。
Fogelstroem, et al. Experimental [Page 19] RFC 4857 Mobile IPv4 Regional Registration June 2007
Fogelstroem、他 地方のIPv4登録2007年6月のモバイルの実験的な[19ページ]RFC4857
The FA SHOULD include its NAI in the Agent Advertisement message. If present, the Foreign Agent NAI (FA-NAI) extension MUST appear in the Agent Advertisement message after any of the advertisement extensions defined in [RFC3344].
FA SHOULDはエージェントAdvertisementメッセージにNAIを含んでいます。 存在しているなら、ForeignエージェントNAI(FA-NAI)拡張子は[RFC3344]で定義された広告拡大のどれかの後にエージェントAdvertisementメッセージに現れなければなりません。
By comparing the domain part of the FA-NAI with the domain part of the FA-NAI it received in the previous Agent Advertisement, the MN can determine whether it has moved to a new domain since it last registered.
それが前のエージェントAdvertisementで受けたFA-NAIのドメイン部分とFA-NAIのドメイン部分を比べることによって、ミネソタは、最後に登録して以来それが新しいドメインに動いているかどうか決定できます。
9. Regional Extensions to Mobile IPv4 Registration Messages
9. モバイルIPv4登録メッセージへの地方の拡大
In this section, we specify new Mobile IP registration extensions for the purpose of managing regional registrations.
このセクションでは、私たちは地方の登録証明書を管理する目的のための新しいモバイルIP登録拡大を指定します。
9.1. GFA IP Address Extension
9.1. GFA IPアドレス拡張子
The GFA IP Address extension is defined for the purpose of supporting dynamic GFA assignment. If the MN requests a dynamically assigned GFA, the GFA adds a GFA IP Address extension to the Registration Request before relaying it to the HA. The MN indicates that it wants a GFA to be assigned by sending a Registration Request with the care-of address field set to all-zeros. The GFA IP Address extension MUST appear in the Registration Request before the FA-HA Authentication extension, if present.
GFA IP Address拡張子はダイナミックなGFA課題をサポートする目的のために定義されます。 ミネソタがダイナミックに割り当てられたGFAを要求するなら、HAにそれをリレーする前に、GFAはGFA IP Address拡張子をRegistration Requestに加えます。 ミネソタが、Registration Requestを送るのが割り当てられるためにGFAが欲しいのを示す、注意、-、アドレス・フィールドはオールゼロにセットしました。 存在しているなら、GFA IP Address拡張子はFA-HA Authentication拡張子の前にRegistration Requestに現れなければなりません。
If a HA receives a Registration Request message with the care-of address set to all-zeros, and a GFA IP Address extension, it MUST register the IP address of the GFA as the care-of address of the MN. When generating a Registration Reply message, the HA MUST include the GFA IP Address extension from the Registration Request in the Registration Reply message. The GFA IP Address extension MUST appear in the Registration Reply message before the MN-HA Authentication extension.
HAがRegistration Requestメッセージを受け取る、注意、-、オールゼロ、およびGFA IP Address拡張子に設定されたアドレス、GFAのIPアドレスを登録しなければならない、注意、-、ミネソタのアドレス。 Registration Replyメッセージを発生させるとき、HA MUSTはRegistration ReplyメッセージのRegistration RequestからのGFA IP Address拡張子を含んでいます。 GFA IP Address拡張子はミネソタ-HA Authentication拡張子の前にRegistration Replyメッセージに現れなければなりません。
The GFA IP Address Extension is defined as follows:
GFA IP Address Extensionは以下の通り定義されます:
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 | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GFA IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GFA IPアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
46 (GFA IP Address) (non-skippable)
46(GFA IPアドレス)をタイプしてください。(非skippable)
Fogelstroem, et al. Experimental [Page 20] RFC 4857 Mobile IPv4 Regional Registration June 2007
Fogelstroem、他 地方のIPv4登録2007年6月のモバイルの実験的な[20ページ]RFC4857
Length
6
長さ6
GFA IP Address
The GFA IP Address field contains the Gateway Foreign Agent's
(GFA) publicly routable address.
GFA IP AddressがさばくGFA IP AddressはゲートウェイのForeignエージェント(GFA)の公的に発送可能なアドレスを含んでいます。
9.2. Hierarchical Foreign Agent Extension
9.2. 階層的な外国エージェント拡大
The Hierarchical Foreign Agent (HFA) extension may be present in a Registration Request or Regional Registration Request. When an FA adds this extension to a Registration Request, the receiving mobility agent (GFA) sets up a pending registration record for the MN, using the IP address in the HFA extension as the care-of address for the MN. Furthermore, in this case, the extension MUST be appended at the end of all previous extensions that had been included in the registration message as received by the FA. The HFA extension MUST be protected by an FA-FA Authentication extension. When the receiving mobility agent (GFA) receives the registration message, it MUST remove the HFA extension added by the sending FA.
Hierarchical Foreignエージェント(HFA)拡大はRegistration RequestかRegional Registration Requestに存在しているかもしれません。 FAはRegistration Request、移動性エージェント(GFA)がミネソタのための未定の登録記録に設定する受信にこの拡大を加えます、HFA拡張子にIPアドレスを使用していつとして注意、-、ミネソタへのアドレス。 その上、この場合、FAによって受け取られるように登録メッセージに含まれていた前のすべての拡大の終わりに拡大を追加しなければなりません。 FA-FA Authentication拡張子でHFA拡張子を保護しなければなりません。 受信の移動性エージェント(GFA)が登録メッセージを受け取るとき、それは発信しているFAによって加えられたHFA拡張子を取り除かなければなりません。
If a MN with a co-located care-of address adds the HFA extension to a Registration Request, the receiving mobility agent (GFA) sets up a pending registration record for the MN, using the IP address in the HFA extension as the care-of address for the MN. The extension MUST be protected by an authentication extension. If the MN has established a mobility security association with the GFA, the HFA extension MUST be placed before the MN-FA Authentication extension, and it SHOULD be placed after the Mobile-Home (MN-HA) Authentication extension. Otherwise, if the MN has no established mobility security association with the GFA, the HFA extension MUST be placed before the MN-HA authentication extension. If the HFA extension is placed after all other extensions, the receiving mobility agent (GFA) MUST remove the HFA extension added by the MN. Otherwise, when the HA receives the registration message, it ignores the HFA extension.
aが共同見つけられているミネソタである、注意、-、アドレスはHFA拡張子をRegistration Requestに加えます、移動性エージェント(GFA)がHFA拡張子にIPアドレスを使用するミネソタのための未定の登録記録にセットする受信、注意、-、ミネソタへのアドレス。 認証拡大で拡大を保護しなければなりません。 ミネソタがGFAとの移動性セキュリティ協会を設立したなら、ミネソタ-FA Authentication拡張子、およびそれの前にHFA拡張子を置かなければならない、SHOULD、モバイルホーム(ミネソタ-HA)認証拡大の後に置かれてください。 さもなければ、ミネソタにGFAとのどんな設立された移動性セキュリティ協会もないなら、ミネソタ-HA認証拡張子の前にHFA拡張子を置かなければなりません。 HFA拡張子が他のすべての拡大の後に置かれるなら、受信の移動性エージェント(GFA)はミネソタによって加えられたHFA拡張子を取り除かなければなりません。 HAが登録メッセージを受け取るとき、さもなければ、それはHFA拡張子を無視します。
The Hierarchical Foreign Agent (HFA) Extension is defined as follows:
Hierarchical Foreignエージェント(HFA)拡大は以下の通り定義されます:
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 | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FA IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ファIPアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
140 (Hierarchical Foreign Agent) (skippable)
140(階層的な外国人のエージェント)をタイプしてください。(skippable)
Fogelstroem, et al. Experimental [Page 21] RFC 4857 Mobile IPv4 Regional Registration June 2007
Fogelstroem、他 地方のIPv4登録2007年6月のモバイルの実験的な[21ページ]RFC4857
Length
6
長さ6
FA IP Address
The IP Address of the FA relaying the Registration Request.
Registration RequestをリレーするFAのFA IP Address IP Address。
9.3. Replay Protection Style
9.3. 反復操作による保護様式
When a MN uses Mobile IPv4 to register a care-of address with its HA, the style of replay protection used for the registration messages is assumed to be known by way of a mobility security association that is required to exist between the MN and the HA receiving the request. No such pre-existing security association between the MN and the GFA is likely to be available. By default, the MN SHOULD treat replay protection for Regional Registration messages exactly as specified in Mobile IPv4 [RFC3344] for timestamp-based replay protection.
ミネソタが登録するのにモバイルIPv4を使用する、注意、-、アドレス、HAと共に、要求を受け取るミネソタとHAの間に存在するのに必要である移動性セキュリティ協会を通して登録メッセージに使用される反復操作による保護のスタイルが知られていると思われます。 ミネソタとGFAとのセキュリティ協会をそのような先在させるのでないのは利用可能である傾向があります。 デフォルトで、MN SHOULDはタイムスタンプベースの反復操作による保護のためにモバイルIPv4[RFC3344]のちょうど指定されるとしてのRegional Registrationメッセージのための反復操作による保護を扱います。
If the MN requires nonce-based replay protection, also as specified in Mobile IPv4, it MAY append a Replay Protection Style extension to a Registration Request. Since Registration Requests are forwarded to the HA by way of the GFA, the GFA will be able to establish the selected replay protection (see Section 5.3).
ミネソタがまた、モバイルIPv4で指定されるように一回だけベースの反復操作による保護を必要とするなら、それはReplay Protection様式拡張子をRegistration Requestに追加するかもしれません。 GFAを通してRegistration RequestsをHAに送るので、GFAは選択された反復操作による保護を確立できるでしょう(セクション5.3を見てください)。
The GFA also uses this extension by adding a Replay Protection Style extension to a Registration Reply to synchronize the replay protection for Regional Registrations (see Section 5.3).
また、GFAは、Regional Registrationsに反復操作による保護を同時にさせるためにReplay Protection様式拡張子をRegistration Replyに加えることによって、この拡張子を使用します(セクション5.3を見てください)。
The format of the Replay Protection Style extension is:
Replay Protection様式拡張子の形式は以下の通りです。
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 | Replay Protection Style |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Initial Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
141 (Replay Protection Style) (skippable)
141(反復操作による保護様式)をタイプしてください。(skippable)
Length
2
長さ2
Replay Protection Style
An integer specifying the style of replay protection desired by
the MN.
反復操作による保護のスタイルがミネソタで望んでいたProtection様式An整数指定を再演してください。
Fogelstroem, et al. Experimental [Page 22] RFC 4857 Mobile IPv4 Regional Registration June 2007
Fogelstroem、他 地方のIPv4登録2007年6月のモバイルの実験的な[22ページ]RFC4857
Initial Identification
The timestamp or nonce to be used for initial synchronization for
the replay mechanism.
Identificationにタイムスタンプか再生メカニズムのための初並列において使用されているために一回だけで頭文字をつけてください。
Admissible values for the Replay Protection Style are as follows:
Replay Protection様式のための容認できる値は以下の通りです:
+-------+-------------------------+
| Value | Replay Protection Style |
+-------+-------------------------+
| 0 | timestamp [RFC3344] |
| 1 | nonce [RFC3344] |
+-------+-------------------------+
+-------+-------------------------+ | 値| 反復操作による保護様式| +-------+-------------------------+ | 0 | タイムスタンプ[RFC3344]| | 1 | 一回だけ[RFC3344]| +-------+-------------------------+
The Replay Protection Style extension MUST be protected by an authentication extension. If the MN has an established mobility security association with the GFA, the Replay Protection Style extension MUST be placed before the MN-FA Authentication extension in the Registration Request, and SHOULD be placed after the MN-HA Authentication extension. Otherwise, the Replay Protection Style extension MUST be placed before the MN-HA Authentication extension in the Registration Request.
認証拡大でReplay Protection様式拡張子を保護しなければなりません。 ミネソタにGFAとの設立された移動性セキュリティ協会があるなら、ミネソタ-FA Authentication拡張子の前にReplay Protection様式拡張子をRegistration Request、およびSHOULDに置かなければなりません。ミネソタ-HA Authentication拡張子の後に置かれます。 さもなければ、ミネソタ-HA Authentication拡張子の前にReplay Protection様式拡張子をRegistration Requestに置かなければなりません。
If the GFA adds a Replay Protection Style extension to a Registration Reply, it SHOULD be placed before the MN-FA Authentication extension. The MN-FA Authentication extension should be based on security associations between the MN and GFA established during home registration.
GFAはReplay Protection様式拡張子をRegistration Replyに加えて、それはSHOULDです。ミネソタ-FA Authentication拡張子の前に置かれます。 ミネソタ-FA Authentication拡張子は本国登録の間に設置されたミネソタとGFAとのセキュリティ協会に基づくべきです。
Replay protection MAY also be provided through a challenge-response mechanism, at the FA issuing the Agent Advertisement, as described in [RFC4721].
また、チャレンジレスポンスメカニズムを通して反復操作による保護を提供するかもしれません、エージェントAdvertisementを発行するFAで、[RFC4721]で説明されるように。
9.4. Regional Registration Lifetime Extension
9.4. 地方の登録生涯拡大
The Regional Registration Lifetime extension allows the GFA to set a lifetime for the regional registration with an MN during its home registration. When receiving a Registration Reply from the HA, the GFA MAY add this extension to the Registration Reply before relaying it to the FA. The GFA MUST set the Regional Registration Lifetime to be no greater than the remaining lifetime of the MN's home registration.
Regional Registration Lifetime拡張子で、GFAは本国登録の間、ミネソタとの地方の登録に生涯を決めることができます。 HAからRegistration Replyを受けるとき、FAにそれをリレーする前に、GFA MAYはこの拡大をRegistration Replyに加えます。 GFA MUSTは、Regional Registration Lifetimeにミネソタの本国登録の残っているより生涯であるように設定します。
Fogelstroem, et al. Experimental [Page 23] RFC 4857 Mobile IPv4 Regional Registration June 2007
Fogelstroem、他 地方のIPv4登録2007年6月のモバイルの実験的な[23ページ]RFC4857
The Regional Registration Lifetime Extension is defined as follows:
Regional Registration Lifetime Extensionは以下の通り定義されます:
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 | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Regional Registration Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
142 (Regional Registration Lifetime) (skippable)
142(地方の登録生涯)をタイプしてください。(skippable)
Length
6
長さ6
Regional Registration Lifetime
If the Code field indicates that the registration was accepted,
the Regional Registration Lifetime field is set to the number of
seconds remaining before the regional registration is considered
expired. A value of zero indicates that the MN has been
deregistered with the GFA. A value of 0xffff indicates infinity.
If the Code field indicates that the home registration was denied,
the contents of the Regional Registration Lifetime field are
unspecified and MUST be ignored on reception.
分野が示す登録がそうであった地方のRegistration Lifetime If Codeを受け入れて、Regional Registration Lifetime分野は地方の登録が満期であると考えられる前に残っている秒数に設定されます。 ゼロの値は、GFAと共にミネソタを反登録してあるのを示します。 0xffffの値は無限を示します。 Code分野が、本国登録が否定されたのを示すなら、Regional Registration Lifetime分野の内容を不特定であり、レセプションで無視しなければなりません。
If the GFA adds a Regional Registration Lifetime extension to a Registration Reply, it MUST be placed before the MN-FA Authentication extension. The MN-FA Authentication extension should be based on security associations between the MN and GFA established during home registration.
GFAがRegional Registration Lifetime拡張子をRegistration Replyに加えるなら、ミネソタ-FA Authentication拡張子の前にそれを置かなければなりません。 ミネソタ-FA Authentication拡張子は本国登録の間に設置されたミネソタとGFAとのセキュリティ協会に基づくべきです。
9.5. New Code Values for Registration Reply
9.5. 登録のための新法値は返答します。
The values to use within the Code field of the Registration Reply are defined in [RFC3344]. In addition, the following values are defined:
Registration ReplyのCode分野の中で使用する値は[RFC3344]で定義されます。 さらに、以下の値は定義されます:
Registration denied by the GFA:
登録はGFAで否定しました:
+---------------------+-------+---------------------+
| Error Name | Value | Section of Document |
+---------------------+-------+---------------------+
| REPLAY_PROT_UNAVAIL | 110 | Section 5.3 |
| ZERO_COA_NOT_SUPP | 111 | Section 7.3 |
+---------------------+-------+---------------------+
+---------------------+-------+---------------------+ | エラー名| 値| ドキュメントのセクション| +---------------------+-------+---------------------+ | _PROT_UNAVAILを再演してください。| 110 | セクション5.3| | __ゼロ_コア川SUPPでない| 111 | セクション7.3| +---------------------+-------+---------------------+
Fogelstroem, et al. Experimental [Page 24] RFC 4857 Mobile IPv4 Regional Registration June 2007
Fogelstroem、他 地方のIPv4登録2007年6月のモバイルの実験的な[24ページ]RFC4857
Registration denied by the HA (for dynamic GFA assignment):
HA(ダイナミックなGFA課題のための)によって否定された登録:
+---------------------+-------+---------------------+
| Error Name | Value | Section of Document |
+---------------------+-------+---------------------+
| ZERO_CAREOF_ADDRESS | 145 | Section 7.4 |
| DYN_GFA_NOT_SUPP | 146 | Section 7.4 |
+---------------------+-------+---------------------+
+---------------------+-------+---------------------+ | エラー名| 値| ドキュメントのセクション| +---------------------+-------+---------------------+ | ゼロ_CAREOF_アドレス| 145 | セクション7.4| | __SUPPではなく、ダインGFA_| 146 | セクション7.4| +---------------------+-------+---------------------+
10. Regional Registration Message Formats
10. 地方の登録メッセージ・フォーマット
This section specifies two new registration message types: Regional Registration Request and Regional Registration Reply. These messages are used by the MN instead of the existing Mobile IPv4 Registration Request and Registration Reply, as described in Section 6.
このセクションは2つの新規登録メッセージタイプを指定します: 地方の登録要求と地方の登録は返答します。 これらのメッセージは既存のモバイルIPv4 Registration RequestとRegistration Replyの代わりにミネソタによって使用されます、セクション6で説明されるように。
Regional registration messages are protected by required authentication extensions, in the same way as the existing Mobile IPv4 registration messages are protected. The following rules apply to authentication extensions:
地方の登録メッセージは必要な認証拡大で保護されます、既存のモバイルIPv4登録メッセージが保護されるのと同様に。 以下の規則は認証拡大に適用されます:
o The MN-GFA Authentication extension [RFC3344] MUST be included in
all regional registration messages.
o The MN-FA Authentication extension [RFC3344] MAY be included in
regional registration messages.
o The FA-HA Authentication extension [RFC3344] MUST NOT be included
in any regional registration message.
o すべての地方の登録メッセージにミネソタ-GFA Authentication拡張子[RFC3344]を含まなければなりません。○ 地方の登録メッセージにミネソタ-FA Authentication拡張子[RFC3344]を含むかもしれません。○ どんな地方の登録メッセージにもFA-HA Authentication拡張子[RFC3344]は含んではいけません。
Fogelstroem, et al. Experimental [Page 25] RFC 4857 Mobile IPv4 Regional Registration June 2007
Fogelstroem、他 地方のIPv4登録2007年6月のモバイルの実験的な[25ページ]RFC4857
10.1. Regional Registration Request
10.1. 地方の登録要求
The Regional Registration Request is used by a MN to register with its current GFA.
Regional Registration Requestは、現在のGFAとともに記名するのにミネソタによって使用されます。
Regional Registration Request:
地方の登録要求:
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 |S|B|D|M|G|r|T|x| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GFA IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Care-of Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ...
+-+-+-+-+-+-+-+-
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ|S|B|D|M|G|r|T|x| 生涯| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ホームアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GFA IPアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 注意、-、アドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + 識別+| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 拡大… +-+-+-+-+-+-+-+-
The Regional Registration Request is defined as the Registration Request in [RFC3344], but with the following changes:
Regional Registration Requestは[RFC3344]でRegistration Requestと定義されますが、以下の変化で定義されます:
Type
18 (Regional Registration Request)
18をタイプしてください。(地方の登録要求)
Lifetime
The number of seconds remaining before the Regional Registration
is considered expired. A value of zero indicates a request for
deregistration with the GFA. A value of 0xffff indicates
infinity.
寿命は期限が切れましたRegional Registrationの前の秒の残りの数が考えられる。 ゼロの値はGFAと共に反登録を求める要求を示します。 0xffffの値は無限を示します。
GFA IP Address
The IP address of the Gateway Foreign Agent (GFA). (Replaces Home
Agent field in Registration Request message in [RFC3344].)
IPが扱うゲートウェイのForeignエージェント(GFA)のGFA IP Address。 ([RFC3344]のRegistration Requestメッセージのホームエージェント野原を取り替えます。)
Care-of Address
Care-of address of local FA; MAY be set to all-ones.
注意、-、Address Care、-、地方のFAのアドレス。 オールものに設定されるかもしれません。
Fogelstroem, et al. Experimental [Page 26] RFC 4857 Mobile IPv4 Regional Registration June 2007
Fogelstroem、他 地方のIPv4登録2007年6月のモバイルの実験的な[26ページ]RFC4857
Identification
A 64-bit number, constructed by the MN, used for matching Regional
Registration Requests with Regional Registration Replies, and for
protecting against replay attacks of regional registration
messages.
ミネソタによって構成された識別のA64ビットの番号はマッチングにRegional Registration Repliesと、地方の登録メッセージの反射攻撃から守るためのRegional Registration Requestsを使用しました。
Extensions
For the Regional Registration Request, the Hierarchical Foreign
Agent (HFA) Extension is an allowable extension (in addition to
those which are allowable for the Registration Request).
拡大For Regional Registration Request、Hierarchical Foreignエージェント(HFA)拡大は許容できる拡大(Registration Requestにおいて、許容できるものに加えて)です。
10.2. Regional Registration Reply
10.2. 地方の登録回答
The Regional Registration Reply delivers the indication of regional registration acceptance or denial to a MN.
Regional Registration Replyは地方の登録承認か否定のしるしをミネソタに提供します。
In the Regional Registration Reply, the UDP header is followed by the Mobile IP fields shown below:
Regional Registration Replyでは、以下に示されたモバイルIP分野はUDPヘッダーのあとに続いています:
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 | Code | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GFA IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ...
+-+-+-+-+-+-+-+-
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| コード| 生涯| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ホームアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GFA IPアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + 識別+| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 拡大… +-+-+-+-+-+-+-+-
This message is defined as the Registration Reply message in [RFC3344], but with the following changes:
このメッセージは[RFC3344]のRegistration Replyメッセージと定義されますが、以下の変化で定義されます:
Type
19 (Regional Registration Reply)
19をタイプしてください。(地方の登録回答)
Code
A value indicating the result of the Regional Registration
Request. See [RFC3344] for a list of currently defined Code
values.
Regional Registration Requestの結果を示すA値をコード化してください。 現在定義されたCode値のリストに関して[RFC3344]を見てください。
Fogelstroem, et al. Experimental [Page 27] RFC 4857 Mobile IPv4 Regional Registration June 2007
Fogelstroem、他 地方のIPv4登録2007年6月のモバイルの実験的な[27ページ]RFC4857
Lifetime
If the Code field indicates that the regional registration was
accepted, the Lifetime field is set to the number of seconds
remaining before the regional registration is considered expired.
A value of zero indicates that the MN has been deregistered with
the GFA. A value of 0xffff indicates infinity. If the Code field
indicates that the regional registration was denied, the contents
of the Lifetime field are unspecified and MUST be ignored on
reception.
If Codeがさばく寿命は地方の登録を受け入れて、地方の登録が満期であると考えられる前に残っている秒数にLifetime分野を設定するのを示します。 ゼロの値は、GFAと共にミネソタを反登録してあるのを示します。 0xffffの値は無限を示します。 Code分野が、地方の登録が否定されたのを示すなら、Lifetime分野の内容を不特定であり、レセプションで無視しなければなりません。
GFA IP Address
The IP address of the Gateway Foreign Agent (GFA) generating the
Regional Registration Reply. (Replaces Home Agent field specified
in Mobile IPv4 [RFC3344].)
IPが扱うRegional Registration Replyを生成するゲートウェイのForeignエージェント(GFA)のGFA IP Address。 (モバイルIPv4[RFC3344]で指定されたホームエージェント野原を取り替えます。)
Identification
A 64-bit number used for matching Regional Registration Requests
with Regional Registration Replies, and for protecting against
replay attacks of regional registration messages. The value is
based on the Identification field from the Regional Registration
Request message from the MN, and on the style of replay protection
used in the security context between the MN and its GFA (defined
by the mobility security association between them).
識別のA64ビットの番号はマッチングにRegional Registration Repliesと、地方の登録メッセージの反射攻撃から守るためのRegional Registration Requestsを使用しました。 値はミネソタからのRegional Registration Requestメッセージと、ミネソタとそのGFA(それらの間の移動性セキュリティ協会によって定義される)の間のセキュリティ文脈で使用される反復操作による保護のスタイルの上のIdentification分野に基づいています。
10.3. New Regional Registration Reply Code Values
10.3. 新しい地方の登録回答コード値
For a Regional Registration Reply, the following additional Code values are defined in addition to those specified in Mobile IPv4 [RFC3344].
Regional Registration Replyに関しては、以下の追加Code値はモバイルIPv4[RFC3344]で指定されたものに加えて定義されます。
Registration denied by the FA:
登録はFAで否定しました:
+----------------------+-------+---------------------+
| Error Name | Value | Section of Document |
+----------------------+-------+---------------------+
| UNKNOWN_GFA | 112 | Section 6.2 |
| GFA_UNREACHABLE | 113 | |
| GFA_HOST_UNREACHABLE | 114 | |
| GFA_PORT_UNREACHABLE | 115 | |
+----------------------+-------+---------------------+
+----------------------+-------+---------------------+ | エラー名| 値| ドキュメントのセクション| +----------------------+-------+---------------------+ | 未知_GFA| 112 | セクション6.2| | GFA_手が届きません。| 113 | | | GFA_ホスト_手が届きません。| 114 | | | GFA_ポート_手が届きません。| 115 | | +----------------------+-------+---------------------+
Registration denied by the GFA:
登録はGFAで否定しました:
+-------------+-------+---------------------+
| Error Name | Value | Section of Document |
+-------------+-------+---------------------+
| NO_HOME_REG | 193 | Section 6.3 |
+-------------+-------+---------------------+
+-------------+-------+---------------------+ | エラー名| 値| ドキュメントのセクション| +-------------+-------+---------------------+ | _ホーム_レッジがありません。| 193 | セクション6.3| +-------------+-------+---------------------+
Fogelstroem, et al. Experimental [Page 28] RFC 4857 Mobile IPv4 Regional Registration June 2007
Fogelstroem、他 地方のIPv4登録2007年6月のモバイルの実験的な[28ページ]RFC4857
The four first Code values are returned to the MN in response to ICMP errors that may be received by the FA.
FAによって受けられるかもしれないICMP誤りに対応して4/1のCode値をミネソタに返します。
11. Authentication Extensions
11. 認証拡大
In this section, two new subtypes for the Generalized Authentication Extension [RFC4721] are specified. First, the FA-FA Authentication extension is used by FAs to secure the HFA extension to the Registration Request and Regional Registration Request messages. A new authentication extension is necessary because the HFA extension is typically added after the MN-HA Authentication extension or, e.g., the MN-AAA Authentication extension [RFC4721].
このセクションでは、Generalized Authentication Extension[RFC4721]のための2の新しい血液型亜型は指定されています。 まず最初に、FA-FA Authentication拡張子は、Registration RequestとRegional Registration RequestメッセージにHFA拡張子を保証するのにFAsによって使用されます。 または、HFA拡張子がミネソタ-HA Authentication拡張子の後に通常加えられるので新しい認証拡大が必要である、例えば、ミネソタ-AAA Authentication拡張子[RFC4721]。
The MN-GFA Authentication extension is used whenever the MN has a co- located address. The MN-GFA Authentication extension is also used to provide authentication for a Regional Registration Request.
ミネソタに共同見つけられたアドレスがあるときはいつも、ミネソタ-GFA Authentication拡張子は使用されています。 また、ミネソタ-GFA Authentication拡張子は、認証をRegional Registration Requestに供給するのに使用されます。
The subtype values for these new subtypes are as follows:
これらの新しい血液型亜型のための「副-タイプ」値は以下の通りです:
+-----------------------+-------+
| Subtype Name | Value |
+-----------------------+-------+
| FA-FA authentication | 2 |
| MN-GFA authentication | 3 |
+-----------------------+-------+
+-----------------------+-------+ | Subtype名| 値| +-----------------------+-------+ | FA-FA認証| 2 | | ミネソタ-GFA認証| 3 | +-----------------------+-------+
The default algorithm for computation of the authenticator is the same as for the MN-AAA Authentication subtype defined in [RFC4721].
固有識別文字の計算のためのデフォルトアルゴリズムはAuthentication subtypeが[RFC4721]で定義したミネソタ-AAAのように同じです。
12. Security Considerations
12. セキュリティ問題
This document proposes a method for a MN to register locally in a visited domain. The authentication extensions to be used are those defined in [RFC3344] and [RFC4721]. Key distribution, assumed to take place during home registration, is to be performed, for instance, according to [RFC4004] or [RFC3957]. Alternatively, the keys can be pre-configured.
このドキュメントはミネソタが訪問されたドメインに局所的に登録されるメソッドを提案します。 使用されるべき認証拡大は[RFC3344]と[RFC4721]で定義されたものです。 本国登録の間、行われると思われた主要な分配は例えば、[RFC4004]か[RFC3957]に従って実行されることです。 あるいはまた、キーをあらかじめ設定できます。
If the Hierarchical Foreign Agent (HFA) extension is appended to a Registration Request, this extension is to be followed by an FA-FA Authentication extension (see Section 11) to prevent any modification to the data. Security associations between FAs and GFAs within a domain are assumed to exist prior to regional registrations.
Hierarchical Foreignエージェント(HFA)拡大をRegistration Requestに追加するなら、この拡大はFA-FA Authentication拡張子(セクション11を見る)があとに続いて、データへのどんな変更も防ぐことです。 ドメインの中のFAsとGFAsとのセキュリティ協会が地方の登録証明書の前に存在すると思われます。
If the GFA IP Address extension is added to a registration message, it is to be followed by a authentication extension. In case of the GFA IP Address extension being added to a Registration Request, it should be protected by an FA-HA Authentication extension. If no
GFA IP Address拡張子が登録メッセージに追加されるなら、認証拡大はそれのあとに続くことになっています。 Registration Requestに加えられるGFA IP Address拡張子の場合には、それはFA-HA Authentication拡張子で保護されるべきです。 いいえ。
Fogelstroem, et al. Experimental [Page 29] RFC 4857 Mobile IPv4 Regional Registration June 2007
Fogelstroem、他 地方のIPv4登録2007年6月のモバイルの実験的な[29ページ]RFC4857
security association exists between the GFA and the HA, the Registration Request needs to be protected by other means not defined in this document. When a GFA IP Address extension is added to a Registration Reply, it is protected by the Mobile-Home Authentication extension as defined in [RFC3344].
セキュリティ協会はGFAとHA(本書では定義されなかった他の手段で保護されるべきRegistration Requestの必要性)の間に存在します。 GFA IP Address拡張子がRegistration Replyに加えられるとき、それは[RFC3344]で定義されるようにモバイルホームAuthentication拡張子で保護されます。
Replay protection for regional registrations is defined similarly to [RFC3344], with the addition of a Replay Protection Style extension. If this extension is added to a Registration Reply by a GFA, it needs to be protected by a MN-FA Authentication extension.
地方の登録証明書のための反復操作による保護はReplay Protection様式拡張子の追加で同様に[RFC3344]と定義されます。 この拡大がGFAによってRegistration Replyに加えられるなら、それは、ミネソタ-FA Authentication拡張子で保護される必要があります。
A co-operating malicious MN-HA pair can trick the GFA into setting up state for an incorrect MN home address. This would result in redirection of data of the node that actually owns that IP address to the malicious MN. Given that the forwarding happens based on the home address at the GFA, such an attack is scoped to the prefix of the HA, not that of the GFA. This type of attack, or its consequences, is not considered in this document.
協力関係を持っている悪意があるミネソタ-HA組は、GFAが不正確なミネソタホームアドレスのために状態を設立するようにだますことができます。 これは実際にそのIPアドレスを悪意があるミネソタとして所有しているノードに関するデータのリダイレクションをもたらすでしょう。 推進がGFAのホームアドレスに基づいて起こるなら、そのような攻撃はGFAのものではなく、HAの接頭語に見られます。 このタイプの攻撃、またはその結果が本書では考えられません。
13. IANA Considerations
13. IANA問題
This document defines:
このドキュメントは以下を定義します。
o A subtype for the NAI Carrying Extension [RFC3846] is specified in
Section 8.2, which needs to have a value assigned from the space
of NAI Carrying Extension subtypes.
o NAI Carrying Extension[RFC3846]のための「副-タイプ」はセクション8.2で指定されます。(それは、NAI Carrying Extension血液型亜型のスペースから値を割り当てさせる必要があります)。
o Four new extensions to Mobile IP Registration messages: GFA IP
Address, Hierarchical Foreign Agent, Replay Protection Style, and
Regional Registration Lifetime (see Sections 9.1, 9.2, 9.3, and
9.4). The Type values for the GFA IP Address extension must be
within the range 0 through 127, while the other three must be
within the range 128 through 255.
o モバイルIP Registrationメッセージへの4つの新しい拡大: GFA IPアドレス、階層的な外国人のエージェントは保護様式、および地方の登録生涯を再演します(セクション9.1、9.2、9.3、および9.4を見てください)。 範囲の中にGFA IP Address拡張子のためのType値が0〜127にあるに違いありません、範囲の中に他の3は128〜255にあるに違いありませんが。
o New Code values for Registration Reply messages (see Section 9.5).
o 新しいCodeはRegistration Replyのためにメッセージを評価します(セクション9.5を見てください)。
o Two new subtypes for the Generalized Authentication Extension
[RFC4721]; see Section 11.
o Generalized Authentication Extension[RFC4721]のための2の新しい血液型亜型。 セクション11を見てください。
o Two new message types for Mobile IP: Regional Registration Request
and Regional Registration Reply (see Sections 10.1 and 10.2).
o 2の新しいメッセージはモバイルIPのために以下をタイプします。 地方の登録要求と地方の登録は返答します(セクション10.1と10.2を見てください)。
o Code values for Regional Registration Reply messages (see Section
10.3).
o コードはRegional Registration Replyのためにメッセージを評価します(セクション10.3を見てください)。
Fogelstroem, et al. Experimental [Page 30] RFC 4857 Mobile IPv4 Regional Registration June 2007
Fogelstroem、他 地方のIPv4登録2007年6月のモバイルの実験的な[30ページ]RFC4857
14. Acknowledgements
14. 承認
This document is a logical successor to documents written with Pat Calhoun and Gabriel Montenegro; thanks to them and their many efforts to help explore this problem space. Many thanks also to Jari Malinen for his commentary on a rough version of this document.
このドキュメントはパットCalhounとガブリエル・モンテネグロと共に書かれたドキュメントの論理的な後継者です。 それらへの感謝と助けるそれらの多くの取り組みがこの問題スペースを探検します。 また、このドキュメントの荒いバージョンの彼の論評のためにヤリMalinenをありがとうございます。
Fogelstroem, et al. Experimental [Page 31] RFC 4857 Mobile IPv4 Regional Registration June 2007
Fogelstroem、他 地方のIPv4登録2007年6月のモバイルの実験的な[31ページ]RFC4857
15. References
15. 参照
15.1. Normative References
15.1. 引用規格
[RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256,
September 1991.
[RFC1256] デアリング、S.、「ICMPルータ発見メッセージ」、RFC1256、1991年9月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
Network Access Identifier", RFC 4282, December 2005.
2005年12月の[RFC4282]AbobaとB.と用務員とM.とArkko、J.とP.Eronen、「ネットワークアクセス識別子」RFC4282。
[RFC2794] Calhoun, P. and C. Perkins, "Mobile IP Network Access
Identifier Extension for IPv4", RFC 2794, March 2000.
[RFC2794] カルフーンとP.とC.パーキンス、「IPv4"、RFC2794、2000年3月のためのモバイルIPネットワークアクセス識別子拡張子。」
[RFC3024] Montenegro, G., "Reverse Tunneling for Mobile IP,
revised", RFC 3024, January 2001.
[RFC3024]モンテネグロ、G. RFC3024、「モバイルIPのためにTunnelingを逆にして、改訂され」て、2001年1月。
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August 2002.
[RFC3344] パーキンス、C.、「IPv4"、RFC3344、2002年8月のIP移動性サポート。」
[RFC3519] Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of
Network Address Translation (NAT) Devices", RFC 3519, May
2003.
[RFC3519] Levkowetz、H.、およびS.Vaarala(「ネットワークアドレス変換(NAT)デバイスのモバイルIP縦断」、RFC3519)は2003がそうするかもしれません。
[RFC3846] Johansson, F. and T. Johansson, "Mobile IPv4 Extension for
Carrying Network Access Identifiers", RFC 3846, June 2004.
[RFC3846] ヨハンソンとF.とT.ヨハンソン、「ネットワークアクセス識別子を運ぶためのモバイルIPv4拡張子」、RFC3846、2004年6月。
[RFC4721] Perkins, C., Calhoun, P., and J. Bharatia, "Mobile IPv4
Challenge/Response Extensions (Revised)", RFC 4721,
January 2007.
[RFC4721] パーキンス、C.、カルフーン、P.、およびJ.Bharatia、「モバイルIPv4挑戦/応答拡大(改訂される)」、RFC4721、2007年1月。
15.2. Informative References
15.2. 有益な参照
[RFC3957] Perkins, C. and P. Calhoun, "Authentication,
Authorization, and Accounting (AAA) Registration Keys for
Mobile IPv4", RFC 3957, March 2005.
[RFC3957] パーキンス、C.、P.カルフーン、「認証、認可、2005年3月にモバイルIPv4"、RFC3957年のためにRegistrationキーズを説明(AAA)であること」。
[RFC4004] Calhoun, P., Johansson, T., Perkins, C., Hiller, T., and
P. McCann, "Diameter Mobile IPv4 Application", RFC 4004,
August 2005.
[RFC4004] カルフーンとP.とヨハンソンとT.とパーキンスとC.とヒラー、T.とP.マッキャン、「直径のモバイルIPv4アプリケーション」、RFC4004、2005年8月。
Fogelstroem, et al. Experimental [Page 32] RFC 4857 Mobile IPv4 Regional Registration June 2007
Fogelstroem、他 地方のIPv4登録2007年6月のモバイルの実験的な[32ページ]RFC4857
Appendix A. Authentication, Authorization, and Accounting (AAA)
Interactions
付録A.認証、認可、および会計(AAA)相互作用
When the mobile node has to obtain authorization by way of Authentication, Authorization, and Accounting (AAA) infrastructure services, the control flow implicit in the main body of this specification is likely to be modified. Typically, the mobile node will supply credentials for authorization by AAA as part of its registration messages. The GFA will parse the credentials supplied by the mobile and forward the appropriate authorization request to a local AAA server (see [RFC3012] and [RFC4004]).
可動のノードがAuthentication、Authorization、およびAccounting(AAA)インフラストラクチャサービスを通して認可を得なければならないとき、この仕様の本体の暗黙のコントロール流動は変更されそうです。 通常、可動のノードは登録メッセージの一部としてAAAによる認可に信任状を供給するでしょう。 GFAは可動によって供給された信任状を分析して、適切な認可要求をローカルのAAAサーバに転送するでしょう([RFC3012]と[RFC4004]を見てください)。
Concretely, this means that:
具体的に、これは、以下のことを意味します。
o The GFA MAY include the Mobile IP Registration Request data inside
an authorization request, directed to a local AAA server.
o GFA MAYはローカルのAAAサーバに向けられた認可要求でモバイルIP Registration Requestデータを含んでいます。
o The GFA MAY receive the Mobile IP Registration Reply data from a
message granting authorization, received from the AAA
infrastructure.
o GFA MAYは、AAAインフラストラクチャから受けられた認可を承諾しながら、メッセージからモバイルIP Registration Replyデータを受け取ります。
Appendix B. Anchoring at a GFA
GFAで投錨される付録B.
As described earlier in this draft, once a mobile node has registered the address of a GFA as its care-of address with its home agent, it MAY perform regional registrations when changing foreign agent under the same GFA. When detecting that is has changed foreign agent, and if the new foreign agent advertises the 'I' flag, the mobile node MAY address a Regional Registration Request message to its registered GFA, even if the address of that particular GFA is not advertised by the new foreign agent. The foreign agent MAY then relay the request to the GFA in question, or deny the request with error code UNKNOWN_GFA.
可動のノードがいったんGFAのアドレスを登録すると、より早くこの草稿で説明される、それ、注意、-、家のエージェントとのアドレス、同じGFAの下で外国人のエージェントを変えるとき、それは地方の登録証明書を実行するかもしれません。 それを検出するのが、いつかが外国人のエージェントを変えました、そして、新しい外国人のエージェントが'私'旗の広告を出すなら、可動のノードは登録されたGFAにRegional Registration Requestメッセージを記述するかもしれません、その特定のGFAのアドレスが新しい外国人のエージェントによって広告に掲載されないでも。 外国人のエージェントは、次に、問題のGFAに要求をリレーするか、またはエラーコードUNKNOWN_GFAと共に要求を否定するかもしれません。
Fogelstroem, et al. Experimental [Page 33] RFC 4857 Mobile IPv4 Regional Registration June 2007
Fogelstroem、他 地方のIPv4登録2007年6月のモバイルの実験的な[33ページ]RFC4857
Authors' Addresses
作者のアドレス
Eva Fogelstroem Ericsson Torshamnsgatan 23 SE-164 80 Stockholm Sweden
エバFogelstroemエリクソンTorshamnsgatan23SE-164 80ストックホルムスウェーデン
EMail: eva.fogelstrom@ericsson.com
メール: eva.fogelstrom@ericsson.com
Annika Jonsson Ericsson Tellusborgsvagen 83-87 S-126 37 Hagersten Sweden
アニカイェンソンエリクソンTellusborgsvagen87秒間126の83 37Hagerstenスウェーデン
EMail: annika.jonsson@ericsson.com
メール: annika.jonsson@ericsson.com
Charles E. Perkins Nokia Siemens Networks 313 Fairchild Drive Mountain View, California 94043 USA
チャールズE.パーキンスノキアジーメンスネットワーク313フェアチャイルドはマウンテンビュー、カリフォルニア94043米国を運転します。
EMail: charles.perkins@nsn.com
メール: charles.perkins@nsn.com
Fogelstroem, et al. Experimental [Page 34] RFC 4857 Mobile IPv4 Regional Registration June 2007
Fogelstroem、他 地方のIPv4登録2007年6月のモバイルの実験的な[34ページ]RFC4857
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Fogelstroem, et al. Experimental [Page 35]
Fogelstroem、他 実験的[35ページ]
一覧
スポンサーリンク
