Internet Engineering Task Force (IETF) H. Deng
Request for Comments: 6098 China Mobile
Category: Standards Track H. Levkowetz
ISSN: 2070-1721 Netnod
V. Devarapalli
Vasona Networks
S. Gundavelli
Cisco
B. Haley
Hewlett-Packard Company
April 2012
Generic Notification Message for Mobile IPv4
Abstract
抽象
This document specifies protocol enhancements that allow Mobile IPv4 entities to send and receive explicit notification messages using a Mobile IPv4 message type designed for this purpose.
この文書では、モバイルIPv4エンティティは、この目的のために設計されたモバイルIPv4メッセージタイプを使用して明示的に通知メッセージを送受信できるようにするプロトコルの拡張機能を指定します。
Status of This Memo
このメモのステータス
This is an Internet Standards Track document.
これは、インターネット標準化過程文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。インターネット標準の詳細については、RFC 5741のセクション2で利用可能です。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6098.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6098で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2012 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Notification Message - Usage Scenarios ..........................4
3.1. Notification Message - Examples ............................4
3.2. Notification Message - Topology ............................5
3.2.1. Notification Message between a Home Agent
and a Mobile Node ...................................6
3.2.2. Notification Message between a Foreign Agent
and a Mobile Node ...................................6
3.2.3. Notification Message between a Home Agent
and a Foreign Agent .................................7
4. Generic Notification Message and Considerations .................7
4.1. Generic Notification Message ...............................7
4.2. Generic Notification Acknowledgement Message ..............11
4.3. Notification Retransmission ...............................14
4.4. General Implementation Considerations .....................15
4.5. Mobile Node Considerations ................................15
4.5.1. Receiving Generic Notification Messages ............15
4.5.2. Sending Generic Notification
Acknowledgement Messages ...........................16
4.5.3. Sending Generic Notification Messages ..............17
4.5.4. Receiving Generic Notification
Acknowledgement Messages ...........................18
4.6. Foreign Agent Consideration ...............................18
4.6.1. Receiving Generic Notification Messages ............19
4.6.2. Sending Generic Notification
Acknowledgement Messages ...........................21
4.6.3. Sending Generic Notification Messages ..............21
4.6.4. Receiving Generic Notification
Acknowledgement Messages ...........................22
4.7. Home Agent Consideration ..................................23
4.7.1. Sending Generic Notification Messages ..............23
4.7.2. Receiving Generic Notification
Acknowledgement Messages ...........................24
4.7.3. Receiving Generic Notification Messages ............24
4.7.4. Sending Generic Notification
Acknowledgement Messages ...........................26
5. Future Extensibility ...........................................26
5.1. Examples of Possible Extensions ...........................26
5.2. Extension Specification ...................................27
6. IANA Considerations ............................................28
7. Security Considerations ........................................28
7.1. Replay Protection for GNMs and GNAMs ......................29
7.1.1. Replay Protection Using Timestamps .................29
7.1.2. Replay Protection Using Nonces .....................30
7.2. Non-Authentication Extensions Handling in the
Foreign Agent .............................................31
8. Acknowledgements ...............................................31
9. References .....................................................32
9.1. Normative References ......................................32
9.2. Informative References ....................................32
In some situations, there is a need for Mobile IPv4 entities, such as the home agent (HA), foreign agent (FA) and mobile node (MN) to send and receive asynchronous notification messages during a mobility session. In this context, 'Asynchronous messages' is used to mean messages that are not synchronous with the Registration Request and Registration Reply messages of the base Mobile IP (MIP) specification [RFC5944]. The base Mobile IP specification does not have a provision for this.
いくつかの状況では、このようなホームエージェント（HA）としてモバイルIPv4エンティティ、する必要がある、外部エージェント（FA）とモビリティセッション中に非同期通知メッセージを送受信するために、モバイルノード（MN）。この文脈で、「非同期メッセージは、」ベースのモバイルIP（MIP）仕様[RFC5944]のメッセージを返信する登録要求と登録と同期していないメッセージを意味するために使用されます。ベースのモバイルIPの仕様では、このための規定を持っていません。
In order to rectify that, this document defines a generic notification message and a notification model that can be used by Mobile IPv4 entities to send various notifications. It also defines a corresponding acknowledgement message to make it possible to ensure reliable delivery of notifications. Only the following extensions may be present in these new messages, as defined by this document:
これを是正するために、この文書は、一般的な通知メッセージや各種通知を送信するモバイルIPv4エンティティによって使用することができる通知モデルを定義します。また、通知の信頼性の高い配信を確保することを可能にする対応する受信確認メッセージを定義します。この文書で定義されている唯一の次の拡張子は、これらの新しいメッセージに存在することができます。
- MN-HA Authentication Extension
- MN-HA認証拡張
- MN-FA Authentication Extension
- MN-FA認証拡張
- FA-HA Authentication Extension
- FA-HA認証拡張
- Message String Extension
- メッセージ文字列の拡張
The semantics of receiving a generic notification message with a Message String Extension are null; i.e., it has no effect on the state of a mobile node's existing registration. See Section 3.1 for some application examples that motivate the new messages defined in this document.
メッセージ文字列の拡張子を持つ一般的な通知メッセージを受信するセマンティクスはNULLです。すなわち、それはモバイルノードの既存の登録の状態に影響を及ぼしません。この文書で定義された新しいメッセージをやる気いくつかの応用例については、セクション3.1を参照してください。
It is assumed that the reader is familiar with the terminology used in [RFC4917] and [RFC5944]. In addition, this document frequently uses the following terms:
読者が[RFC4917]で使用される用語及び[RFC5944]に精通しているものとします。また、このドキュメントは頻繁に次の用語を使用しています：
Notification Message
通知メッセージ
A message from a mobility agent to a an MN or other mobility agent, or from an MN to a mobility agent, to asynchronously notify it about an event that is relevant to the mobility service it is currently providing.
MNまたは他のモビリティエージェント、またはモビリティエージェントへMNからのモビリティエージェントからのメッセージは、非同期的にそれが現在提供しているモビリティ・サービスに関連するイベントについて、それを通知します。
Generic Notification Message
一般的な通知メッセージ
A Notification Message in the context of Mobile IPv4 with a well-defined envelope format and extensibility, and with certain limitations on how extensions may be defined and used, but otherwise generally available for notification purposes within the Mobile IPv4 protocol. Abbreviated 'GNM' in this document.
明確に定義されたエンベロープのフォーマットと拡張と、拡張機能が定義され、使用されるが、モバイルIPv4プロトコル内通知の目的のためにそうでなければ、一般に利用可能なことができる方法について一定の制限を有するモバイルIPv4の文脈における通知メッセージ。このドキュメントの「GNM」を略し。
Generic Notification Acknowledgement Message
ジェネリック通知確認メッセージ
An acknowledgement of a received Generic Notification Message. Abbreviated 'GNAM' in this document.
受信ジェネリック通知メッセージの受信確認。このドキュメントの「GNAM」を略し。
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", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
The simplest usage scenario for a notification message is one where the notification has no semantic meaning within the protocol; it is only carrying a message that can be displayed to a user or an operator (depending on which is the receiving entity -- see more on this below, in Section 3.2). Examples of such usage are messages from operator to user about billing- or service-related events ("You have used nearly all of your prepaid quota; there are only XX MB left -- please purchase further service if you are going to need it."; or
通知メッセージのための最も単純な使用シナリオは、通知プロトコル内にはセマンティックな意味を持たないものです。それだけでユーザまたはオペレータに表示することができるメッセージ伝送している（ - 3.2で、以下これについての詳細を参照しているに応じて、受信エンティティです）。このような使用の例としては、（ "あなたは、ほぼすべての前払いクォータのを使用しているオペレータからユーザーに関するbilling-やサービス関連のイベントへのメッセージであり、唯一のXX MBが残っている - あなたがそれを必要としている場合は、さらにサービスを購入してください。 "; または
"You have now used data transfer services for the amount of $XXX since your last bill; this is above the notification threshold for your account.") or messages about service interruptions, and more. These examples are all supported by the use of the Mobile IPv4 Generic Notification Message together with the Message String Extension, as defined in this document.
）またはサービスの中断などに関するメッセージが、「これはあなたのアカウントの通知しきい値を超えている。今、あなたの最後の法案以来の$ XXXの量のデータ転送サービスを使用していました」。この文書で定義されるようにこれらの実施例は全て、メッセージ文字列の拡張と共にモバイルIPv4汎用通知メッセージの使用によってサポートされています。
There are also other examples, which cannot be implemented solely using the messages and extensions defined in this document. Some of these are described briefly below, and covered slightly more extensively in Section 5.
もっぱらこの文書で定義されたメッセージや拡張を使用して実装することができない他の例もあります。これらのいくつかを以下に簡単に説明し、5章でもう少し広く覆われています。
One example of an application of an extended Generic Notification Message is that during handover between CDMA 2000 1x EV-DO and Wireless LAN, the PPP resource on the CDMA side has to be removed on the FA (Packet Data Serving Node) to avoid over-charging subscribers. To address this, the Registration Revocation Message was defined in [RFC3543], but it would have been preferable to have had it defined as a separate message (i.e., the Generic Notification Message) with a Registration Revocation extension.
拡張された一般的な通知メッセージの応用の一例は、CDMA2000 1X EV-DOと無線LAN、CDMA側のPPPリソース間のハンドオーバー時にオーバー回避するFA（パケットデータサービングノード）上で除去しなければならないことです加入者を充電します。これに対処するために、登録取り消しメッセージは[RFC3543]で定義されたが、登録失効拡張と別のメッセージ（すなわち、一般的な通知メッセージ）として定義されていた有することが好ましいであったであろう。
Other applications are:
その他の用途は以下のとおりです。
o HA switch-over (before the HA decides to go off-line, it would like to notify the MNs to register with another candidate HA),
O HA切り替えを（HAがオフラインで行くことにしました前に、それは他の候補HAに登録するのMNに通知したいと思います）、
o Network Mobility (NEMO) prefix changes (an MN is notified by the HA about NEMO prefix changes and service- or billing-related events; this is an operational requirement),
Oネットワークモビリティ（NEMO）プレフィックスの変更（MNがNEMOのプレフィックスの変更及びservice-や課金関連のイベントについてのHAによって通知され、これは運用の要件です）、
o load balancing (the HA wants to move some of the registered MNs to other HAs),
O負荷分散（HAが持っている他に登録するMNの一部を移動したいです）、
o service termination (due to end of prepaid time), and
（プリペイド時間の終わりのために）Oサービスの終了、および
o service interruption (due to system maintenance).
（システムメンテナンスのために）Oサービスの中断。
There are several scenarios where a mobility agent could initiate notification events. Some of these are described in the following sections.
モビリティエージェントは、通知イベントを開始することができ、いくつかのシナリオがあります。これらのいくつかは、次のセクションで説明されています。
In this case, the HA cannot directly notify the MN, but must send the notification via the FA, and vice versa.
この場合、HAは、直接MNに通知することはできませんが、その逆のFAを経由して通知を送信し、必要があります。
+----+ notification +----+ notification +----+
| MN |<================>| FA |<=============>| HA |
+----+ +----+ +----+
Figure 1: HA notifies MN or MN notifies HA through FA
図1：HAは、MNに通知またはMNがFAを通じてHAに通知
In this case, the MN has registered with the home agent directly, so the notification message can go directly to the MN.
この場合、MNは、直接ホームエージェントに登録したので、通知メッセージがMNに直接行くことができます。
The notification mechanism as specified here does not support the case of co-located Care-of Address (CoA) mode with registration through an FA (due to the 'R' bit being set in the FA's advertisement messages).
ここで指定された通知メカニズムは、（原因「R」FAの広告メッセージに設定されているビットに）FAを通じて登録と同じ場所に配置さ気付アドレス（CoA）モードの場合には対応していません。
+----+ notification +----+
| MN |<===================================>| HA |
+----+ +----+
Figure 2: HA directly notifies MN or MN directly notifies HA
There are two cases where an FA may send notification messages to an MN -- one where it is relaying a message, the other where the notification is triggered by a message from another network entity, for example, an Authentication, Authorization, and Accounting (AAA) node. (Notification messages between a AAA entity and the FA could be based on RADIUS or Diameter, but this is out of scope for this document.) If the notification is initiated by an FA, the FA may also need to notify the HA about the event.
それがメッセージを中継したもの、他の通知は、例えば、他のネットワークエンティティからのメッセージ、認証、許可、およびアカウンティング（によってトリガされる - FAは、MNに通知メッセージを送信することができる2つのケースがありますAAA）ノード。 （AAAエンティティとFAとの間の通知メッセージは、RADIUSまたはDIAMETERに基づくことができるが、これはこの文書の範囲外である。）通知がFAによって開始された場合、FAはまた、イベントについてHAに通知する必要があるかもしれません。
+----+ notification +----+ trigger +--------+
| MN |<================>| FA |<=============| AAA |
+----+ +----+ +--------+
|| notification +----+
================>| HA |
+----+
Figure 3: FA notifies MN
図3：FAはMNに通知
The HA may also need to send a notification to the FA, but not to the MN. The FA may also need to send a notification to the HA, as illustrated below:
HAはまたFAのではなく、MNに通知を送信する必要があるかもしれません。 FAはまた、以下に示すように、HAに通知を送信する必要があるかもしれません。
+----+ notification +----+
| FA |<=============>| HA |
+----+ +----+
Figure 4: HA notifies FA or FA notifies HA
図4：HA HA通知通知FA又はFA
This section describes in detail the Generic Notification Message (GNM), Generic Notification Acknowledgement Message (GNAM), and some considerations related to the handling of these messages in the MN, FA, and HA.
このセクションでは、詳細にジェネリック通知メッセージ（GNM）、ジェネリック通知確認メッセージ（GNAM）、およびMN、FA、およびHAでこれらのメッセージの処理に関連するいくつかの考慮事項について説明します。
The MN and HA MUST maintain the following information:
MNとHAは、以下の情報を維持しなければなりません。
- the IP source address of the Registration Request/Reply
- 登録要求/応答のIP送信元アドレス
- the IP destination address of the Registration Request/Reply
- 登録要求/応答のIP宛先アドレス
- the UDP source port of the Registration Request/Reply
- 登録要求のUDPソースポートは/返信
- the UDP destination port of the Registration Request/Reply
- /返信登録要求のUDP宛先ポート
The sending node always sends the GNM following the same procedure for sending a Registration Request as in Section 3.3 of [RFC5944], and the receiving node follows the same procedure for Registration Reply as in Section 3.4 of [RFC5944] when sending GNAM.
GNAMを送信するときは常に[RFC5944]のセクション3.3、及び受信ノードのように登録要求を送信するための同じ手順に従ってGNMを送信する送信ノードは、[RFC5944]のセクション3.4のように登録応答のために同じ手順に従います。
A GNM is sent by a mobility agent to inform another mobility agent, or an MN, of MIP-related information in the form of a Message String Extension [RFC4917]. These messages MUST use the same IP and UDP
GNMは、メッセージ文字列の拡張[RFC4917]の形でMIP関連情報の他のモビリティエージェント、またはMNを通知するモビリティエージェントによって送信されます。これらのメッセージは、同じIPやUDPを使用しなければなりません
headers as any previous Registration Request (RRQ) or Reply (RRP) message to the same entity. This would support NAT traversal and ensure the same security association used for GNM/GNAM and RRQ/RRP. The GNM is defined as follows:
同じエンティティに以前の登録要求（RRQ）または応答（RRP）メッセージとしてヘッダ。これは、NATトラバーサルをサポートし、GNM / GNAMとRRQ / RRPのために使用したのと同じセキュリティアソシエーションを保証するであろう。次のようにGNMが定義されています。
IP Fields:
IPフィールド：
Source Address
送信元アドレス
Typically, copied from the destination address of the last Registration Reply/ Request message that the agent received from the agent to which it is sending the GNM.
典型的には、エージェントがGNMを送信している先のエージェントから受信した最後の登録要求/応答メッセージの宛先アドレスからコピーされました。
Destination Address
宛先アドレス
Copied from the source address of the last Registration Reply/Request message that the agent received from the agent to which it is sending the GNM.
エージェントがGNMを送信しているためにどのエージェントから受信した最後の登録要求/応答メッセージの送信元アドレスからコピーされました。
UDP Fields:
UDPフィールド：
Source Port
ソースポート
Typically, copied from the destination port of the last Registration Reply/Request message that the agent received from the agent to which it is sending the GNM.
典型的には、エージェントがGNMを送信している先のエージェントから受信した最後の登録要求/応答メッセージの宛先ポートからコピーされました。
Destination Port
宛先ポート
Copied from the source port of the last Registration Reply/Request message that the agent received from the agent to which it is sending the GNM.
エージェントがGNMを送信しているためにどのエージェントから受信した最後の登録要求/応答メッセージの送信元ポートからコピーされました。
The UDP header is followed by the Mobile IP fields shown below:
UDPヘッダは、以下に示すモバイルIPフィールドが続きます。
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 | MD |A| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Care-of Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions...
+-+-+-+-+-+-+-+-+-+-+-+-+-
Type 22
タイプ22
MD: Message Direction
MD：メッセージの方向
This memo defines the semantics of the following MD field value:
このメモは、次のMDフィールド値のセマンティクスを定義します。
0 -- Message sent by the HA to the MN
0 - MNにHAによって送信されるメッセージ
1 -- Message sent by the HA to the FA
1 - FAにHAによって送信されるメッセージ
2 -- Message sent by the MN to the HA
2 - HAにMNによって送られたメッセージ
3 -- Message sent by the MN to the FA
3 - FAにMNによって送られたメッセージ
4 -- Message sent by the FA to the MN
4 - MNにFAで送られたメッセージ
5 -- Message sent by the FA to the HA
5 - HAにFAで送られたメッセージ
A
A
This bit indicates whether the notification message MUST be acknowledged by the recipient. If the "A" bit has been set during the message, but the sender doesn't receive any acknowledgement message, then the sender will have to re-send the notification message again.
このビットは、通知メッセージが受信者によって確認されなければならないかどうかを示します。 「」ビットは、メッセージ中に設定されていますが、送信者が任意の確認メッセージを受信しない場合、送信者は、再び通知メッセージを再送信する必要があります。
Set to "1" to indicate that acknowledgement is REQUIRED.
「1」は、その承認を示すために設定が必要です。
Set to "0" to indicate that acknowledgement is OPTIONAL.
その確認がオプションであることを示すために「0」に設定します。
Reserved
予約済み
MUST be sent as 0, and ignored when received.
0として送信し、受信した際に無視しなければなりません。
Home Address
ホームアドレス
The home address of the mobile node.
モバイルノードのホームアドレス。
Home Agent Address
ホームエージェントアドレス
The IP address of the mobile node's HA.
移動ノードのHAのIPアドレス。
Care-of Address
気付アドレス
The mobile node's care-of address, either the co-located care-of address or the foreign agent care-of address.
モバイルノードの気付アドレス、住所共同設置のケア、または外部エージェントの気付アドレスのいずれか。
Identification
識別
A 64-bit number, constructed by the sender, used for matching GNM with GNAM and for protecting against replay attacks of notification messages. See Sections 7.1.1 and 7.1.2 for more on the use of timestamps and nonces in this field. Support for the use of timestamps is REQUIRED, and support for nonces is OPTIONAL.
送信者によって構成され、64ビットの数は、GNAMとGNMを一致させるため、通知メッセージのリプレイ攻撃から保護するために使用されます。この分野でのタイムスタンプとナンスの使用の詳細については、セクション7.1.1と7.1.2を参照してください。タイムスタンプを使用するためのサポートが必要であり、ナンスのためのサポートはオプションです。
Extensions
拡張機能
The fixed portion of the GNM is followed by one or more extensions that may be used with this message, and by one or more authentication extensions as defined in Section 3.5 of [RFC5944].
[RFC5944]のセクション3.5で定義されるようにGNMの固定部分は、1つ以上の認証拡張でこのメッセージに使用され得る1つ以上の拡張が続くとされています。
Apart from the Authentication Extensions mentioned below, only one extension is defined in this document as permitted for use with the GNM: the Message String Extension defined in [RFC4917].
[RFC4917]で定義されたメッセージ文字列エクステンション：GNMで使用するために許可さ離れ後述認証拡張から、唯一の拡張は、この文書で定義されています。
This document requires the MN-HA Authentication Extension (AE) to be used when this message is sent between the MN and the HA; MN-FA AE and FA-HA AE are OPTIONAL. This document also requires the use of the MN-FA AE when this message is sent between the MN and the FA, where the MN-HA AE and FA-HA AE are not needed. This document finally requires the use of the FA-HA AE when this message is sent between the FA and the HA, and the MN-HA AE and MN-FA AE are not needed. This could be determined based on the "MD" value. See Sections 3.6.1.3 and 3.8.3.3 of [RFC5944] for the rules on the order of these extensions as they appear in Mobile IPv4 RRQ and RRP messages. The same rules are applicable to GNM and GNAM.
この文書は、このメッセージは、MNとHAの間で送信されるときに使用されるMN-HA認証拡張（AE）を必要とします。 MN-FA AEとFA-HA AEはオプションです。この文書はまた、このメッセージは、MN-HA AEとFA-HA AEが必要とされていないMNとFA、間で送信されるMN-FA AEを使用する必要があります。この文書では、最終的にはこのメッセージがFAとHA、およびMN-HA AEとMN-FA AE必要とされていない間で送信されるFA-HA AEを使用する必要があります。これは、「MD」の値に基づいて決定することができました。彼らはモバイルIPv4 RRQとRRPメッセージに表示されるこれらの拡張機能のためのルールのセクション3.6.1.3と[RFC5944]の3.8.3.3を参照してください。同じルールがGNMとGNAMに適用されます。
A GNAM is sent by mobility agents or MNs to indicate the successful receipt of a GNM.
GNAMはGNMの受信に成功したことを示すために、モビリティエージェントまたはのMNによって送信されます。
IP Fields:
IPフィールド：
Source Address
送信元アドレス
Typically, copied from the destination address of the GNM to which the agent is replying.
典型的には、エージェントが返信されるGNMの宛先アドレスからコピーされました。
Destination Address
宛先アドレス
Copied from the source address of the GNM to which the agent is replying.
エージェントが返信されているGNMの送信元アドレスからコピーされました。
UDP Fields:
UDPフィールド：
Source Port
ソースポート
Copied from the destination port of the corresponding GNM.
対応GNMの宛先ポートからコピーされました。
Destination Port
宛先ポート
Copied from the source port of the corresponding GNM.
対応GNMの送信元ポートからコピーされました。
The UDP header is followed by the Mobile IP fields shown below:
UDPヘッダは、以下に示すモバイルIPフィールドが続きます。
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 | MD | Code | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Care-of Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions...
+-+-+-+-+-+-+-+-+-+-+-+-+-
Type 23
タイプ23
MD: Message Direction
MD：メッセージの方向
This memo defines the semantics of the following MD field value:
このメモは、次のMDフィールド値のセマンティクスを定義します。
0 -- Message sent by the HA to the MN
0 - MNにHAによって送信されるメッセージ
1 -- Message sent by the HA to the FA
1 - FAにHAによって送信されるメッセージ
2 -- Message sent by the MN to the HA
2 - HAにMNによって送られたメッセージ
3 -- Message sent by the MN to the FA
3 - FAにMNによって送られたメッセージ
4 -- Message sent by the FA to the MN
4 - MNにFAで送られたメッセージ
5 -- Message sent by the FA to the HA
5 - HAにFAで送られたメッセージ
Code
コード
A value indicating the result of the GNM. See below for a list of currently defined Code values.
GNMの結果を示す値。現在定義されているコード値のリストについては、以下を参照してください。
Notification successful
成功通知
0 -- notification accepted
0 - 通知の受理
Notification denied by the HA
HAによって拒否された通知
128 -- reason unspecified
128 - 指定されていない理由
129 -- administratively prohibited
129 - 管理上禁止
130 -- insufficient resources
130 - リソース不足
131 -- mobile node failed authentication
131 - モバイルノード失敗した認証
132 -- foreign agent failed authentication
132 - 外国人のエージェントが認証に失敗しました
133 -- notification Identification mismatch
133 - 通知識別ミスマッチ
Notification denied by the FA
FAによって拒否された通知
64 -- reason unspecified
64 - 指定されていない理由
65 -- administratively prohibited
65 - 管理上禁止
66 -- insufficient resources
66 - リソース不足
67 -- mobile node failed authentication
67 - モバイルノード失敗した認証
68 -- home agent failed authentication
68 - ホームエージェントは、認証に失敗しました
69 -- notification Identification mismatch
69 - 通知識別の不一致
Notification denied by the mobile node
モバイルノードによって拒否された通知
192 -- reason unspecified
192 - 指定されていない理由
193 -- administratively prohibited
193 - 管理上禁止
194 -- insufficient resources
194 - リソース不足
195 -- foreign agent failed authentication
195 - 外国人のエージェントが認証に失敗しました
196 -- home agent failed authentication
196 - ホームエージェントは、認証に失敗しました
197 -- notification Identification mismatch
197 - 通知識別の不一致
Home Address
ホームアドレス
The home address of the mobile node.
モバイルノードのホームアドレス。
Home Agent Address
ホームエージェントアドレス
The IP address of the sender's home agent.
送信者のホーム・エージェントのIPアドレス。
Care-of Address
気付アドレス
The mobile node's care-of address, either the co-located care-of address or the foreign agent care-of address.
モバイルノードの気付アドレス、住所共同設置のケア、または外部エージェントの気付アドレスのいずれか。
Identification
識別
A 64-bit number used for matching the GNM with the GNAM and for protecting against replay attacks of notification messages. See Sections 7.1.1 and 7.1.2 for more on the use of timestamps and nonces in this field. Support for the use of timestamps is REQUIRED, and support for nonces is OPTIONAL. The value is based on the Identification field from the GNM from the sender, and on the style of replay protection used in the security context between the sender and its receiver (defined by the mobility security association between them, and the Security Parameter Index (SPI) value in the authorization-enabling extension).
GNAMとGNMを一致させるため、通知メッセージのリプレイ攻撃から保護するために使用される64ビット数。この分野でのタイムスタンプとナンスの使用の詳細については、セクション7.1.1と7.1.2を参照してください。タイムスタンプを使用するためのサポートが必要であり、ナンスのためのサポートはオプションです。値は、SPI（送信者からGNMから識別フィールドに基づいて、送信者とその受信機の間のセキュリティコンテキストで使用されるリプレイ保護のスタイルに（それらの間のモビリティセキュリティアソシエーション、およびセキュリティパラメータインデックスによって定義されます認可可能エクステンションで）値）。
Extensions
拡張機能
The fixed portion of the GNAM is followed by one or more extensions that may be used with this message, and by one or more authentication extensions as defined in Section 3.5 of [RFC5944].
[RFC5944]のセクション3.5で定義されるようGNAMの固定部分は、1つ以上の認証拡張でこのメッセージに使用され得る1つ以上の拡張が続くとされています。
This document REQUIRES the MN-HA Authentication Extension (AE) to be used when this message is sent between the MN and the HA; MN-FA AE and FA-HA AE are OPTIONAL. This document also requires the use of the MN-FA AE when this message is sent between the MN and the FA, where the MN-HA AE and FA-HA AE are not needed. This document finally requires the use of the FA-HA AE when this message is sent between the FA and the HA, and the MN-HA AE and MN-FA AE are not needed. This could be determined based on the "MD" value. See Sections 3.6.1.3 and 3.8.3.3 of [RFC5944] for the rules on the order of these extensions as they appear in Mobile IPv4 RRQ and RRP messages. The same rules are applicable to GNM and GNAM.
この文書は、このメッセージは、MNとHAの間で送信されるときに使用されるMN-HA認証拡張（AE）を必要とします。 MN-FA AEとFA-HA AEはオプションです。この文書はまた、このメッセージは、MN-HA AEとFA-HA AEが必要とされていないMNとFA、間で送信されるMN-FA AEを使用する必要があります。この文書では、最終的にはこのメッセージがFAとHA、およびMN-HA AEとMN-FA AE必要とされていない間で送信されるFA-HA AEを使用する必要があります。これは、「MD」の値に基づいて決定することができました。彼らはモバイルIPv4 RRQとRRPメッセージに表示されるこれらの拡張機能のためのルールのセクション3.6.1.3と[RFC5944]の3.8.3.3を参照してください。同じルールがGNMとGNAMに適用されます。
If the "A" flag has been set during the GNM, but the sender doesn't receive any GNAM within a reasonable time, then the GNM SHOULD be retransmitted. When timestamps are used, a new notification Identification is chosen for each retransmission; thus, it counts as a new GNM. When nonces are used, the unanswered GNM is retransmitted unchanged; thus, the retransmission does not count as a new GNM (Section 7.1). In this way, a retransmission will not require the receiver to re-synchronize with the sender by issuing another nonce in the case in which the original GNM (rather than its GNAM) was lost by the network.
「A」フラグがGNM時に設定されていますが、送信者が合理的な期間内の任意のGNAMを受信しない場合は、GNMが再送されるべきです。タイムスタンプが使用される場合、新たな通知の識別が各再送信のために選択されます。したがって、それは新しいGNMとしてカウントされます。ナンスを使用する場合には、未回答GNMはそのまま再送されます。このように、再送は新しいGNM（7.1節）としてカウントされません。このように、再送は、（むしろそのGNAMより）オリジナルGNMがネットワークによって失われた場合に別のnonceを発行することにより、送信側で再同期するために受信機を必要としません。
The maximum time until a new GNM is sent SHOULD be no greater than the requested Lifetime of the last GNM. The minimum value SHOULD be large enough to account for the size of the messages, twice the round-trip time for transmission to the receiver, and at least an additional 100 milliseconds to allow for processing the messages before responding. The round-trip time for transmission to the receiver will be at least as large as the time REQUIRED to transmit the messages at the link speed of the sender's current point of attachment. Some circuits add another 200 milliseconds of satellite delay in the total round-trip time to the receiver. The minimum time between GNMs MUST NOT be less than 1 second. Each successive retransmission timeout period SHOULD be at least twice the previous period, as long as that is less than the maximum as specified above.
新しいGNMが送信されるまでの最大時間は、最後のGNMの要求寿命よりも大きくてはなりません。最小値は、受信機に送信するために二回のラウンドトリップ時間メッセージのサイズを説明するために十分な大きさであるべきであり、少なくとも追加の100ミリ秒は、応答する前に、メッセージの処理を可能にします。受信機に送信するための往復時間は、添付ファイルの送信者の現在地点のリンク速度でメッセージを送信するために必要な時間と少なくとも同じ大きさになります。いくつかの回路は、受信機への総ラウンドトリップ時間に衛星遅延の別の200ミリ秒を追加します。 GNMs間の最小時間は1秒未満であってはいけません。各連続する再送タイムアウト期間があればそれが上記のように最大値未満であるように、少なくとも二回前の期間であるべきです。
Implementations of this specifications should provide support for management of the various settings related to the notification messages. In particular, it should be possible to do the following:
この仕様の実装は、通知メッセージに関連した各種設定を管理するためのサポートを提供する必要があります。特に、次の操作を行うことが可能であるべきです：
o List the notification messages supported.
Oサポート通知メッセージの一覧を表示します。
o Show enabled/disabled status for notification message support, overall and in detail.
Oショーは全体的かつ詳細に、通知メッセージのサポートのために/無効の状態を可能にしました。
o Show the value of the maximum and minimum retransmission times.
O最大と最小の再送回数の値を表示します。
o Enable and disable notification support entirely.
O完全に通知サポートを有効または無効にします。
o Enable and disable the individual notification messages supported.
Oサポート、個々の通知メッセージを有効または無効にします。
o Set the values of the maximum and minimum retransmission times described in Section 4.3.
O 4.3節で説明した最大値と最小再送回数の値を設定します。
It is possible that the MN MAY receive a GNM from an FA or HA. Both in the case of FA-CoA and co-located CoA, the MN MAY reply with a GNAM based on the "A" flag in the GNM.
MNがFAまたはHAからGNMを受ける可能性があります。両方のFA-CoAのと同一位置のCoAの場合には、MNはGNMの「A」フラグに基づいGNAMで応答することができます。
When the MN is using an FA-CoA and receives a notification message, if the "MD" value is 0, it means that the notification message came from the HA. If the "MD" value is 4, the notification came from the FA. If the MN is using a co-located CoA and receives a notification message, the "MD" value will be 0, indicating that the notification message came from the HA.
MNは、FA-CoAを使用して、通知メッセージを受信した場合、「MD」の値が0であれば、それは、通知メッセージがHAから来たことを意味します。 「MD」の値が4である場合は、通知がFAから来ました。 MNは、同じ場所に配置CoAを使用して、通知メッセージを受信している場合は、「MD」の値は、通知メッセージがHAから来たことを示し、0になります。
The MN MUST check for the presence of an authorization-enabling extension and perform the indicated authentication. Exactly one authorization-enabling extension MUST be present in the GNM.
MNは、認可-有効延長の有無をチェックし、指示された認証を実行しなければなりません。正確に一つの認可有効化拡張は、GNM中に存在しなければなりません。
If this message came from an FA, then an MN-FA AE MUST be present. If no MN-FA AE is found, or if more than one MN-FA AE is found, or if the Authenticator is invalid, then the MN MUST reject the GNM and MAY send a GNAM to the FA with Code 195, including an Identification field computed in accordance with the rules specified in Section 7.1. The MN MUST do no further processing with such a notification, though it SHOULD log the error as a security exception.
このメッセージは、FAから来た場合には、MN-FA AEが存在しなければなりません。何のMN-FA AEが見つからない場合、または複数のMN-FA AEが発見された場合、または認証が無効である場合には、MNは、GNM拒絶しなければなりませんし、識別を含め、コード195でFAにGNAMを送るかもしれませんフィールドは、7.1節で指定されたルールに従って計算します。それはセキュリティ例外としてエラーをログに記録すべきであるにもかかわらずMNは、このような通知とは、さらに処理してはいけません。
If this notification message came from the HA, relayed by the FA, or if the MN is using a co-located CoA, then the MN-HA AE MUST be checked and the MN MUST check the Authenticator value in the Extension. If no MN-HA AE is found, or if more than one MN-HA AE is found, or if the Authenticator is invalid, then the MN MUST reject the GNM and MAY send a GNAM to the initiator with Code 196, including an Identification field computed in accordance with the rules specified in Section 7.1. The MN MUST do no further processing with such a notification, though it SHOULD log the error as a security exception.
この通知メッセージは、HAから来た場合は、FAによって中継され、またはMNは同じ場所に配置CoAを使用している場合は、MN-HA AEをチェックしなければなりませんし、MNはExtensionでAuthenticator値をチェックしなければなりません。何のMN-HA AEが見つからない場合、または複数のMN-HA AEが発見された場合、または認証が無効である場合には、MNは、GNM拒絶しなければなりませんし、識別を含め、コード196をイニシエータにGNAMを送るかもしれませんフィールドは、7.1節で指定されたルールに従って計算します。それはセキュリティ例外としてエラーをログに記録すべきであるにもかかわらずMNは、このような通知とは、さらに処理してはいけません。
The MN MUST check that the Identification field is correct using the context selected by the SPI within a mandatory authentication extension like the MN-FA AE or MN-HA AE. See Section 7.1 for a description of how this is performed. If incorrect, the MN MUST reject the GNM and MAY send a GNAM to the initiator with Code 197, including an Identification field computed in accordance with the rules specified in Section 7.1. The MN MUST do no further processing with such a notification, though it SHOULD log the error as a security exception.
MNは、識別フィールドは、MN-FA AEまたはMN-HA AEのような必須の認証拡張内SPIによって選択されたコンテキストを使用して正しいことをチェックしなければなりません。これが実行される方法については、7.1項を参照してください。正しくない場合は、MNは、GNMを拒絶しなければなりませんし、7.1節で指定されたルールに従って計算識別フィールドを含む、コード197をイニシエータにGNAMを送信することができます。それはセキュリティ例外としてエラーをログに記録すべきであるにもかかわらずMNは、このような通知とは、さらに処理してはいけません。
The MN MUST also check that the extensions present in the Generic Notification Message are permitted for use with the GNM. If not, the MN MUST silently discard the message. It MUST NOT do any further processing with such a notification, though it SHOULD log the error.
MNはまた、一般的な通知メッセージに存在する拡張機能がGNMで使用するために許可されていることをチェックしなければなりません。そうでない場合、MNは静かにメッセージを捨てなければなりません。それがエラーを記録すべきであるけれどもそれは、このような通知と任意の更なる処理を行うてはなりません。
If the MN accepts a GNM, then it will process it according to the specific rules for the extensions. After that, the MN MAY reply to the originator with a GNAM with Code 0 based on the "A" flag in the GNM.
MNはGNMを受け入れる場合、それは拡張のための特定のルールに従ってそれを処理します。その後、MNはGNMで「A」のフラグに基づいてコード0とGNAMで発信元に応答することができます。
Both in the case of a co-located CoA and FA-CoA, the MN MAY reply with a GNAM based on the "A" flag in the GNM as follows:
両方共に位置-CoAおよびFA-CoAの場合に、MNは、以下のようにGNMに「A」フラグに基づいGNAMで応答することができます。
If the GNM was initiated from the FA to the MN ("MD" value is set to 4), then the MN-FA AE MUST be the last extension in order to protect all other non-authentication extensions as defined in Section 3.5.3 of [RFC5944].
GNMがMNにFAから開始された場合は、セクション3.5.3で定義された後、MN-FA AEは、他のすべての非認証の拡張機能を保護するための最後の拡張子でなければならない、（「MD」値は4に設定されています） [RFC5944]の。
In the case of an FA-CoA, the source address is the MN's address, the destination address is the FA's address.
FA-CoAの場合には、送信元アドレスはMNのアドレスであり、宛先アドレスはFAのアドレスです。
The Code field of the GNAM is chosen in accordance with the rules specified in Section 4.2. When replying to an accepted notification, an MN SHOULD respond with Code 0.
GNAMのコードフィールドは、セクション4.2で指定された規則に従って選択されます。受理通知に返信するとき、MNはコード0で応答する必要があります。
There are a number of reasons why the MN might reject a notification, such as for example not being permitted to receive notifications, which could be for a number of reasons, causing the return of a GNAM with Code value 193 (administratively prohibited); or being unable to act on or display the notification, or otherwise being resource constrained, causing the use of Code value 194 (insufficient resources); or other reasons for which no other specific Code value is available, which would cause the use of Code value 192 (reason unspecified).
例えば、コード値193（行政上禁止）とGNAMの復帰を引き起こす、多くの理由かもしれない通知を受け取ることを許可されていないとして、MNは、通知を拒否するかもしれない理由の数があります。またはコード値194（不十分なリソース）の使用を引き起こし、に作用または通知、または他のリソースが制約さを表示することができません。またはコード値192（詳細不明の理由）の使用が原因となる他の特定のコード値が利用できないため、他の理由、。
If the GNM was initiated from the HA to the MN ("MD" value is set to 0) and in the case of a co-located CoA, then the MN-HA AE MUST be the last extension in order to protect all other non-authentication extensions as defined in Section 3.5.2 of [RFC5944].
GNMがMNにHAから開始された場合（「MD」の値が0に設定されている）と共同設置のCoAの場合には、その後、MN-HA AE以外の他のすべてのを保護するための最後の拡張子でなければなりません[RFC5944]のセクション3.5.2で定義されるよう - 認証拡張機能。
When replying to a GNM from an HA to an MN with an FA-CoA, the source address is the MN's home address and the destination address is the FA's address ("MD" value is set to 2). The ordering of the extension is: any non-authentication Extensions intended for the HA, followed by the MN-HA AE defined in Section 3.5.2 of [RFC5944], followed by any non-authentication Extensions intended for the FA, followed by the MN-FA AE defined in Section 3.5.3 of [RFC5944].
FA-CoAを持つMNにHAからGNMに返信すると、送信元アドレスは、MNのホームアドレスであり、宛先アドレスはFAのアドレス（「MD」の値が2に設定されている）です。拡張子の順序は次のとおりです。MN-HA AE続いHAのために意図任意の非認証Extensionsは、続く、FAのために意図任意の非認証の拡張に続いて、[RFC5944]のセクション3.5.2で定義されています[RFC5944]のセクション3.5.3で定義されたMN-FA AE。
The MN may send a GNM to notify either the FA or HA.
MNは、FAまたはHAのいずれかを通知するGNMを送信することができます。
If the message is sent to the FA, then the source address is the MN's address, and the destination address is the FA's address
メッセージをFAに送信された場合、送信元アドレスはMNのアドレスであり、宛先アドレスはFAのアドレスです
If the FA is the target of this notification message, then the "MD" value is set to 3, and the MN-FA AE MUST be the last extension in order to protect all other non-authentication extensions. Computing the Authentication Extension Values is done in the same manner as in Section 3.5.1 of [RFC5944].
FAは、この通知メッセージの対象である場合には、「MD」値が3に設定され、MN-FA AEは、他のすべての非認証の拡張機能を保護するための最後の拡張子でなければなりません。認証拡張値を計算することは、[RFC5944]のセクション3.5.1と同様に行われます。
If the FA is working only as a relay agent, then the "MD" value is set to 2, and the ordering of the extension is: the notification extension, followed by any non-authentication extension expected to be used by HA, followed by the MN-HA AE defined in Section 3.5.2 of [RFC5944], followed by any non-authentication Extensions intended for the FA, followed by the MN-FA AE defined in Section 3.5.3 of [RFC5944]. Computing the Authentication Extension Values is done in the same manner as in Section 3.5.1 of [RFC5944].
FAが唯一のリレーエージェントとして働いている場合は、「MD」値が2に設定され、延長の順序は次のとおりです。HAによって使用されることが期待任意の非認証拡張に続いて、通知の拡張機能、続きます[RFC5944]のセクション3.5.3で定義されたMN-FA AE続いFAためのもの以外の認証拡張機能、続く[RFC5944]のセクション3.5.2で定義されたMN-HA AE、。認証拡張値を計算することは、[RFC5944]のセクション3.5.1と同様に行われます。
In the case of a co-located CoA, the MN MAY send a notification message directly to the HA if it needs to be notified. The "MD" value is set to 2, and the ordering of the extension is: the notification extension, followed by any non-authentication extension expected to be used by HA, followed by the MN-HA AE defined in Section 3.5.2 of [RFC5944].
それが通知する必要がある場合は同じ場所に配置アシルCoAの場合には、MNはHAに直接通知メッセージを送信することができます。 「MD」の値を2に設定し、延長の順序はあるさ：MN-HA AEのセクション3.5.2で定義されているが続くHAによって使用されることが期待任意の非認証拡張に続いて、通知の拡張機能、 [RFC5944]。
The MN chooses the Identification field in accordance with the style of replay protection it uses with its HA. This is part of the mobility security association the MN shares with its HA. See Section 7.1 for the method by which the MN computes the Identification field.
MNは、そのHAを使用してリプレイ保護のスタイルに合わせて識別フィールドを選択します。これは、モビリティセキュリティアソシエーションそのHAとMNの株式の一部です。 MNは、識別フィールドを計算する方法については、セクション7.1を参照してください。
In the case of an FA-CoA, if the MN receives this message, and the "MD" value is set to 0, it means that the GNAM came from the HA.
MNがこのメッセージを受信し、「MD」の値が0に設定されている場合、FA-CoAの場合には、それはGNAMはHAから来たことを意味します。
If the "MD" value is set to 4, then the MN-FA AE MUST be checked, and the MN MUST check the Authenticator value in the Extension. If no MN-FA AE is found, or if more than one MN-FA AE is found, or if the Authenticator is invalid, then the MN MUST silently discard the GNAM.
「MD」の値が4に設定されている場合、MN-FA AEをチェックしなければなりませんし、MNはExtensionでAuthenticator値をチェックしなければなりません。何のMN-FA AEが見つからない場合、または場合は、複数のMN-FA AEが発見された、または認証が無効である場合には、MNは黙っGNAMを捨てなければなりません。
In addition, the low-order 32 bits of the Identification field in the GNAM MUST be compared to the low-order 32 bits of the Identification field in the most recent GNM sent to the replying agent. If they do not match, then the GNAM MUST be silently discarded.
また、GNAMにおける識別フィールドの下位32ビットが応答エージェントに送信された最新のGNMに下位するための識別フィールドの32ビットを比較しなければなりません。それらが一致しない場合は、GNAMは黙って捨てなければなりません。
If the "MD" value is set to 0, then the MN-HA AE MUST be checked, and the MN MUST check the Authenticator value in the Extension. If no MN-HA AE is found, or if more than one MN-HA AE is found, or if the Authenticator is invalid, then the MN MUST silently discard the GNAM. If the MN accepted this message, then the MN MAY also process it based on the notification event.
「MD」の値が0に設定されている場合、MN-HA AEをチェックしなければなりませんし、MNはExtensionでAuthenticator値をチェックしなければなりません。何のMN-HA AEが検出されない、または、複数のMN-HA AEが発見された場合に認証が無効な場合、または、その後、MNは黙っGNAMを捨てなければなりません場合。 MNはこのメッセージを受け入れた場合、MNはまた、通知イベントに基づいて処理することができます。
In the case of a co-located CoA, if the MN received this message, then the MN-HA AE MUST be checked, and the MN MUST check the Authenticator value in the Extension. If no MN-HA AE is found, or if more than one MN-HA AE is found, or if the Authenticator is invalid, then the MN MUST silently discard the Notification Acknowledgement message.
MNがこのメッセージを受信した場合に同一位置のCoAの場合には、その後、MN-HA AEをチェックしなければなりません、そしてMNはExtensionでAuthenticator値をチェックしなければなりません。何のMN-HA AEが見つからない場合、または複数のMN-HA AEが検出された、または認証が無効である場合には、MNは静かに通知確認メッセージを破棄しなければなりません。
The FA may initiate a GNM to the MN or the HA. Additionally, the FA also relays GNMs and GNAMs between the MN and its HA as long as there is an active binding for the MN at the FA.
FAは、MNまたはHAにGNMを開始することができます。また、FAはまた、長いFAでのMNのための活性結合があるとしてMNとそのHA間GNMsとGNAMsを中継します。
If the FA receives a GNM, and the "MD" value is set to 0, then it means that the HA is asking the FA to relay the message to the MN. If the "MD" value is set to 1, then it means that the target of the notification is the FA. If the "MD" value is set to 2, then it means that the MN is asking the FA to relay the message to the HA. If the "MD" value is set to 3, then it means that the notification came from the MN to the FA.
FAはGNMを受け、「MD」の値が0に設定されている場合、それはHAがMNにメッセージを中継するためにFAを求めていることを意味します。 「MD」の値が1に設定されている場合、それは、通知の対象がFAであることを意味します。 「MD」の値が2に設定されている場合、それはMNがHAにメッセージを中継するためにFAを求めていることを意味します。 「MD」の値が3に設定されている場合、それは通知がMNからFAになったことを意味します。
If the "MD" value is set to 0, then the FA MAY validate the FA-HA AE if present. If the FA-HA AE is invalid, then all extensions between the HA-MN AE and the HA-FA AE MUST be removed, the FA SHOULD relay the GNM to the MN's home address as specified in the Home Address field of the GNM, and the MN will eventually validate the MN-HA AE to ensure that all information sent to the MN is integrity protected. If the FA-HA AE is valid, the FA MUST relay the GNM to the MN's home address as specified in the Home Address field of the GNM. The FA MUST NOT modify any of the fields beginning with the fixed portion of the GNM through the MN-HA AE or other authentication extension supplied by the HA as an authorization-enabling extension for the MN.
「MD」の値が0に設定されている場合、FAは、FA-HA AE存在する場合を検証することができます。 FA-HA AEが無効の場合はGNMのホームアドレスフィールドで指定され、その後、HA-MN AEおよびHA-FA AE間のすべての拡張機能を削除する必要があり、FAは、MNのホームアドレスにGNMを中継すべきですそしてMNは、最終的にMNに送信されたすべての情報は整合性が保護されることを保証するために、MN-HA AEを検証します。 FA-HA AEが有効な場合GNMのホームアドレスフィールドで指定され、FAは、MNのホームアドレスにGNMをリレーしなければなりません。 FAは、MN-HA AEまたはMNの認可有効化拡張機能としてHAが提供するその他の認証拡張を介してGNMの固定部分で始まるフィールドのいずれかを変更してはいけません。
Furthermore, the FA MUST process and remove any extensions following the MN-HA AE. If the FA shares a mobility security association with the MN, the FA MAY append any of its own non-authentication extensions that are relevant to the MN. In this case, the FA MUST append the MN-FA AE after these non-authentication extensions.
さらに、FAは、MN-HA AE、次のいずれかの拡張子を処理し、削除する必要があります。 FAは、MNとのモビリティセキュリティアソシエーションを共有している場合、FAは、MNに関連する独自の非認証の拡張機能のいずれかを追加するかもしれません。この場合、FAは、これらの非認証の拡張後にMN-FA AEを追加しなければなりません。
If the "MD" value is set to 1, the FA-HA AE MUST be checked, and the FA MUST check the Authenticator value in the Extension. If no FA-HA AE is found, or if more than one FA-HA AE is found, or if the Authenticator is invalid, the FA MUST reject the GNM and MAY send a GNAM to the HA with Code 68, including an Identification field computed in accordance with the rules specified in Section 7.1. The FA MUST do no further processing with such a notification, though it SHOULD log the error as a security exception.
「MD」の値が1に設定されている場合は、FA-HA AEをチェックしなければなりません、そしてFAはExtensionでAuthenticator値をチェックしなければなりません。何のFA-HA AEが見つからない場合、または複数のFA-HA AEが検出された、または認証が無効である場合、FAはGNMを拒絶しなければなりませんし、識別フィールドを含む、コード68とのHAにGNAMを送る可能性がある場合7.1節で指定されたルールに従って計算。それはセキュリティ例外としてエラーをログに記録すべきであるもののFAは、このような通知とは、さらに処理してはいけません。
The FA MUST check that the Identification field is correct using the context selected by the SPI within the mandatory FA-HA AE. See Section 7.1 for a description of how this is performed. If incorrect, the FA MUST reject the GNM and MAY send a GNAM to the initiator with Code 69, including an Identification field computed in accordance with the rules specified in Section 7.1. The FA MUST do no further processing with such a notification, though it SHOULD log the error as a security exception.
FAは、識別フィールドが必須FA-HA AE内SPIによって選択されたコンテキストを使用して正しいことをチェックしなければなりません。これが実行される方法については、7.1項を参照してください。正しくない場合は、FAはGNMを拒絶しなければなりませんし、7.1節で指定されたルールに従って計算識別フィールドを含む、コード69でイニシエータにGNAMを送信することができます。それはセキュリティ例外としてエラーをログに記録すべきであるもののFAは、このような通知とは、さらに処理してはいけません。
The FA MUST also check that the extensions present in the Generic Notification Message are permitted for use with the GNM. If not, the FA MUST silently discard the message. It MUST NOT do any further processing with such a notification, though it SHOULD log the error.
FAはまた、一般的な通知メッセージに存在する拡張機能がGNMで使用するために許可されていることをチェックしなければなりません。そうでない場合、FAは静かにメッセージを捨てなければなりません。それがエラーを記録すべきであるけれどもそれは、このような通知と任意の更なる処理を行うてはなりません。
If the FA accepts the HA's GNM, it will process it based on the specific rules for the extensions it contains. The FA MAY then reply to the HA with a GNAM with Code 0 based on the "A" flag in the GNM.
FAは、HAのGNMを受け入れる場合、それが含まれている拡張のための特定のルールに基づいて、それを処理します。 FAは次にGNMで「」フラグに基づいてコード0とGNAMでHAに応答することができます。
In the case of an FA-CoA and if the "MD" value is set to 2, if the FA received this message, and if the MN-FA AE is present, the MN-FA AE MUST be checked, and the FA MUST check the Authenticator value in the Extension. If no MN-FA AE is found, or if more than one MN-FA AE is found, or if the Authenticator is invalid, the FA MUST silently discard the GNM. If the MN-FA is valid, the FA MUST relay the GNM to the HA's address as specified in the Home Agent Address field of the GNM. The HA will eventually validate the MN-HA AE to ensure that all information sent to the HA is integrity protected. The FA MUST NOT modify any of the fields beginning with the fixed portion of the GNM through the MN-HA AE or other authentication extension supplied by the MN as an authorization-enabling extension for the HA.
FA-CoAの場合に及びFAは、このメッセージを受信し、MN-FA AEが存在する場合、MN-FA AEをチェックしなければなりません、そしてFAがなければならない場合は「MD」値は、2に設定されている場合ExtensionでAuthenticator値をチェック。何のMN-FA AEが見つからない場合、または場合は、複数のMN-FA AEが発見された、または認証が無効の場合、FAは黙っGNMを捨てなければなりません。 MN-FAが有効な場合GNMのホームエージェントアドレスフィールドで指定され、FAはHAのアドレスにGNMをリレーしなければなりません。 HAは、最終的にはHAに送信されたすべての情報が完全性保護されていることを保証するために、MN-HA AEを検証します。 FAは、MN-HA AEまたはHAの認可有効化拡張機能としてMNによって提供される他の認証拡張を介してGNMの固定部分で始まるフィールドのいずれかを変更してはいけません。
Furthermore, the FA MUST process and remove any extensions following the MN-HA AE, and MAY append any of its own non-authentication extensions of relevance to the HA, if applicable. Also, it MUST append the FA-HA AE if the FA shares a mobility security association with the HA.
さらに、FA、プロセスおよびMN-HA AE、次のいずれかの拡張子を削除し、該当する場合は、HAとの関連性の独自の非認証の拡張機能のいずれかを追加してもよい（MAY）しなければなりません。 FAは、HAとのモビリティセキュリティアソシエーションを共有する場合にも、それはFA-HA AEを追加しなければなりません。
If the "MD" value is set to 3, the MN-FA AE MUST be checked, and the FA MUST check the Authenticator value in the Extension, as described in Section 3.7.2.1 of [RFC5944]. If no MN-FA AE is found, or if more than one MN-FA AE is found, or if the Authenticator is invalid, the FA MUST reject the GNM and MAY send a GNAM to the MN with Code 67, including an Identification field computed in accordance with the rules specified in Section 7.1. The FA MUST do no further processing with such a notification, though it SHOULD log the error as a security exception.
「MD」の値が3に設定されている場合は、MN-FA AEをチェックしなければなりません、そして、[RFC5944]のセクション3.7.2.1で説明したようにFAは、ExtensionでAuthenticator値をチェックしなければなりません。何のMN-FA AEが見つからない場合、または複数のMN-FA AEが発見された場合、または認証が無効の場合、FAはGNM拒絶しなければなりませんし、識別フィールドを含む、コード67でMNにGNAMを送るかもしれません7.1節で指定されたルールに従って計算。それはセキュリティ例外としてエラーをログに記録すべきであるもののFAは、このような通知とは、さらに処理してはいけません。
The FA MUST check that the Identification field is correct using the context selected by the SPI within mandatory MN-FA AE. See Section 7.1 for a description of how this is performed. If incorrect, the FA MUST reject the GNM and MAY send a GNAM to the initiator with Code 69, including an Identification field computed in accordance with the rules specified in Section 7.1. The FA MUST do no further processing with such a notification, though it SHOULD log the error as a security exception.
FAは、識別フィールドは必須MN-FA AE内SPIによって選択されたコンテキストを使用して正しいことをチェックしなければなりません。これが実行される方法については、7.1項を参照してください。正しくない場合は、FAはGNMを拒絶しなければなりませんし、7.1節で指定されたルールに従って計算識別フィールドを含む、コード69でイニシエータにGNAMを送信することができます。それはセキュリティ例外としてエラーをログに記録すべきであるもののFAは、このような通知とは、さらに処理してはいけません。
If the FA accepts the MN's GNM, it will process it based on the specific rules for the extensions it contains. The FA MAY then reply to the MN with a GNAM with Code 0 based on the "A" flag in the GNM.
FAは、MNのGNMを受け入れる場合、それが含まれている拡張のための特定のルールに基づいて、それを処理します。 FAは、GNMで「」フラグに基づいてコード0でGNAMでMNに応答することができます。
The FA may need either to relay a GNAM between the MN and the HA or to send one as a response to a GNM that was sent to it. In both cases, the GNAM is defined as follows.
FAは、どちらかがMNとHAの間GNAMを中継するか、それに送られたGNMへの応答として1を送信する必要があるかもしれません。次のように両方の場合において、GNAMが定義されています。
The source address is the FA address, and the destination address is the HA's or MN's home address.
送信元アドレスは、FAのアドレスであり、宛先アドレスは、HAのか、MNのホームアドレスです。
The Code field of the GNAM is chosen in accordance with the rules specified in Section 4.2. When replying to an accepted notification, an FA SHOULD respond with Code 0.
GNAMのコードフィールドは、セクション4.2で指定された規則に従って選択されます。受理通知に返信すると、FAはコード0で応答する必要があります。
The FA might reject a notification by returning a GNAM with the Code value 65 (administratively prohibited), which could be for a number of reasons; 64 (reason unspecified); or 66 (insufficient resources).
FAは、多くの理由であり得るコード値65（管理上禁止）とGNAMを返すことによって、通知を拒否するかもしれません。 64（不特定の理由）。または66（不十分なリソース）。
If the FA is relaying this message to only the HA, the FA MUST NOT modify any of the fields beginning with the fixed portion of the GNAM up through and including the MN-HA AE or other authentication extension supplied by the MN as an authorization-enabling extension for the MN. Furthermore, the foreign agent MUST process and remove any extensions following the MN-HA AE. If the FA shares a mobility security association with the HA, the FA MAY append any of its own non-authentication extensions that are relevant to the HA. In this case, the FA MUST append the FA-HA AE after these non-authentication extensions.
FAのみHAへこのメッセージを中継している場合、FAは、MN-HA AEまたはauthorization-としてMNによって供給された他の認証拡張を介してGNAMの固定部分で始まり、を含む任意のフィールドを変更してはいけませんMNのための拡張機能を有効にします。さらに、外国人のエージェントが処理し、MN-HA AE、次のいずれかの拡張子を削除する必要があります。 FAは、HAとのモビリティセキュリティアソシエーションを共有している場合、FAはHAに関連する独自の非認証の拡張機能のいずれかを追加するかもしれません。この場合、FAは、これらの非認証の拡張後にFA-HA AEを追加しなければなりません。
If the notification message is from the HA to the FA, then the "MD" value is set to 5 and the ordering of the extension is: any non-authentication Extensions intended for the FA, followed by the FA-HA AE defined in Section 3.5.4 of [RFC5944].
通知メッセージは、HAからFAにある場合には、「MD」値が5に設定され、延長の順序は次のとおりです。セクションで定義されたFA-HA AE続いFAのために意図任意の非認証の拡張、 [RFC5944]の3.5.4。
If the notification message is from the MN to the FA, then the "MD" value is set to 4 and the ordering of the extension is: any non-authentication Extensions intended for the FA, followed by the MN-FA AE defined in Section 3.5.3 of [RFC5944].
通知メッセージは、MNからFAにある場合には、「MD」値は4に設定され、延長の順序は次のとおりです。MN-FA AE節で定義されているが続くFAのために意図任意の非認証の拡張、 [RFC5944]の3.5.3。
If the FA is initiating a notification to the MN using the GNM, it MAY also notify the HA.
FAはGNMを使用してMNへの通知を開始している場合、それはまた、HAに通知することができます。
In the message to the MN, the source address is the FA address, the destination address is the MN's address, the "MD" value is set to 4, and the ordering of the extension is: the notification extension, followed by any non-authentication extensions intended for the MN, followed by the MN-FA AE defined in Section 3.5.3 of [RFC5944]. Computing the Authentication Extension Values is done in the same manner as in Section 3.5.1 of [RFC5944] except the payload is the notification rather than the registration.
MNへのメッセージの送信元アドレスは、FAのアドレスであり、宛先アドレスはMNのアドレスであり、「MD」値は4に設定され、拡張の順序は次のとおり通知拡張、任意の非続いMN-FA AE [RFC5944]のセクション3.5.3で定義されているが続くMNのために意図認証の拡張機能、。認証拡張値を計算するペイロードを除い[RFC5944]のセクション3.5.1と同様に行われる通知ではなく登録です。
In the message to the HA, the source address is the FA's address, the destination address is the HA's address (the "MD" value is set to 5), and the ordering of the extension is: notification extension, followed by any non-authentication Extensions intended for the HA, followed by the FA-HA AE defined in Section 3.5.4 of [RFC5944]. Computing the Authentication Extension Value is done in the same manner as described in Section 3.5.1 of [RFC5944], except that the payload is the notification instead of the registration.
HAへのメッセージは、送信元アドレスがFAのアドレスであり、宛先アドレスは（「MD」の値は5に設定されている）HAのアドレスであり、拡張の順序は次のとおり、任意の非続い通知拡張、 [RFC5944]のセクション3.5.4で定義されたFA-HA AE続いHAを対象とした認証拡張機能、。ペイロードはなく、登録の通知であることを除いて、[RFC5944]のセクション3.5.1に記載したように認証拡張値を計算することは同様に行われます。
In the case of an FA-CoA, if the FA receives this message, and the "MD" value is set to 2, it means that the notification acknowledgement message is from the MN to the HA; if the "MD" value is set to 3, the message is from the MN to the FA; otherwise, it came from the HA.
FAは、このメッセージを受信し、「MD」の値が2に設定されている場合、FA-CoAの場合において、それは、通知確認メッセージをMNからHAであることを意味します。 「MD」の値が3に設定されている場合、メッセージは、MNからFAにあります。それ以外の場合は、HAから来ました。
If the "MD" value is set to 1, the FA-HA AE MUST be checked, and the FA MUST check the Authenticator value in the Extension. If no FA-HA AE is found, or if more than one FA-HA AE is found, or if the Authenticator is invalid, the FA MUST silently discard the Notification Acknowledgement message. If the FA accepted this message, the FA MAY also process it based on the notification event.
「MD」の値が1に設定されている場合は、FA-HA AEをチェックしなければなりません、そしてFAはExtensionでAuthenticator値をチェックしなければなりません。何のFA-HA AEが見つからない場合、または複数のFA-HA AEが発見された場合に認証が無効な場合、または、FAは静かに通知確認メッセージを捨てなければなりません。 FAは、このメッセージを受け入れた場合、FAはまた、通知イベントに基づいて処理することができます。
If the "MD" value is set to 3, and if the MN-FA AE is present, the AE MUST be checked, and the FA MUST check the Authenticator value in the extension. If no MN-FA AE is found, or if more than one MN-FA AE is found, or if the Authenticator is invalid, the FA MUST silently discard the GNAM. If the FA accepted this message, the FA MAY also process it based on the notification event.
「MD」の値が3に設定されている場合、およびMN-FA AEが存在する場合、AEをチェックしなければなりません、そしてFAはExtensionでAuthenticator値をチェックしなければなりません。何のMN-FA AEが見つからない場合、または場合は、複数のMN-FA AEが発見された、または認証が無効の場合、FAは黙っGNAMを捨てなければなりません。 FAは、このメッセージを受け入れた場合、FAはまた、通知イベントに基づいて処理することができます。
In the case of an FA-CoA and if the "MD" value is set to 2, if the FA received this message, and if the MN-FA AE is present, the MN-FA AE MUST be checked, and the FA MUST check the Authenticator value in the Extension. If no MN-FA AE is found, or if more than one MN-FA AE is found, or if the Authenticator is invalid, the FA MUST silently discard the GNAM. If the FA accepted the MN's GNAM, it MUST relay this message to the HA. The FA MUST NOT modify any of the fields beginning with the fixed portion of the GNAM up through and including the MN-HA AE or other authentication extension supplied by the HA as an authorization-enabling extension for the MN. Furthermore, the FA MUST process and remove any extensions following the MN-HA AE and MAY append any of its own non-authentication extensions of relevance to the HA, if applicable. Also, it MUST append the FA-HA AE, if the FA shares a mobility security association with the HA.
FA-CoAの場合に及びFAは、このメッセージを受信し、MN-FA AEが存在する場合、MN-FA AEをチェックしなければなりません、そしてFAがなければならない場合は「MD」値は、2に設定されている場合ExtensionでAuthenticator値をチェック。何のMN-FA AEが見つからない場合、または場合は、複数のMN-FA AEが発見された、または認証が無効の場合、FAは黙っGNAMを捨てなければなりません。 FAは、MNのGNAMを受け入れた場合、それはHAに、このメッセージをリレーしなければなりません。 FAはアップによるGNAMの固定部分で始まり、MN-HA AEまたはMNの認可有効化拡張機能としてHAが提供するその他の認証拡張を含むいずれかのフィールドを変更してはいけません。さらに、FA、プロセスおよびMN-HA AEを以下のいずれかの拡張子を削除し、該当する場合は、HAとの関連性の独自の非認証の拡張機能のいずれかを追加してもよい（MAY）しなければなりません。 FAは、HAとのモビリティセキュリティアソシエーションを共有する場合にも、それは、FA-HA AEを追加しなければなりません。
The HA MAY initiate a GNM to both the mobile node and FA, and it also MAY receive a GNAM from both the FA and MN. The HA also MAY receive a GNM from the FA, but only when there is a binding for an MN. If the HA receives a GNM from an FA and there is no corresponding MN registration, the HA SHOULD drop the GNM.
HAは、モバイルノードとFAの両方にGNMを開始することができる、そしてそれはまた、FAおよびMNの両方からGNAMを受信することができます。 HAはまた、FAからGNMを受けることができるが、MNのバインディングがある場合にのみ。 HAが、FAからGNMを受信し、該当するMNの登録がない場合は、HAはGNMをドロップすべきです。
In the case of an FA-CoA, the HA may either send a GNM to notify the FA, or have the FA relay the GNM to the MN if the MN needs to be notified.
FA-CoAの場合には、HAは、FAを通知するGNMを送ったり、MNに通知する必要がある場合FAがMNにGNMを中継有していてもよいいずれか。
If the message is from the HA to the FA, the source address is the HA's address, and the destination address is the FA's address
メッセージは、HAからFAにある場合には、送信元アドレスがHAのアドレスであり、宛先アドレスはFAのアドレスです
If the FA is working only as a relay agent, the "MD" value is set to 0, and the ordering of the extension is: the notification extension, followed by any non-authentication extension expected to be used by MN, followed by the MN-HA AE defined in Section 3.5.2 of [RFC5944], followed by any non-authentication extensions intended for the FA, followed by the FA-HA AE defined in Section 3.5.4 of [RFC5944]. Computing the Authentication Extension Value is done in the same manner as in Section 3.5.1 of [RFC5944].
FAはリレーエージェントとしてのみ機能している場合、「MD」の値が0に設定され、延長の順序は次のとおりです。続いMNによって使用されることが期待任意の非認証拡張に続いて、通知の拡張機能、 [RFC5944]のセクション3.5.4で定義されたFA-HA AE続いFAのために意図任意の非認証の拡張機能、続く[RFC5944]のセクション3.5.2で定義されたMN-HA AE、。認証拡張値を計算する[RFC5944]のセクション3.5.1と同様に行われます。
If the FA is the target of this notification message, then the "MD" value is set to 1, and the ordering of the extension is: the notification extension, followed by any non-authentication Extensions intended for the FA, followed by the FA-HA AE defined in Section 3.5.4 of [RFC5944]. Computing the Authentication Extension Values is done in the same manner as in Section 3.5.1 of [RFC5944].
FAは、この通知メッセージの対象である場合には、「MD」値が1に設定され、延長の順序は次のとおりです。FA続いFAのために意図任意の非認証の拡張に続いて、通知の拡張機能、 - HA AEは、[RFC5944]のセクション3.5.4で定義されています。認証拡張値を計算することは、[RFC5944]のセクション3.5.1と同様に行われます。
In the case of a co-located CoA, the HA MAY send a notification message directly to the MN if it needs to be notified. The "MD" value is set to 0, and the ordering of the extension is: the notification extension, followed by any non-authentication extension expected to be used by the MN, followed by the MN-HA AE defined in Section 3.5.2 of [RFC5944].
それが通知する必要がある場合は同じ場所に配置アシルCoAの場合には、HAは、MNに直接通知メッセージを送信することができます。 「MD」の値が0に設定され、延長の順序はあるさ：MN-HA AE続いMNによって使用されることが期待任意の非認証拡張に続いて、通知の拡張機能は、セクション3.5.2で定義されています[RFC5944]の。
In the case of an FA-CoA, if the HA receives this message, and the "MD" value is set to 2, it means that the GNAM came from the MN.
HAは、このメッセージを受信すると、「MD」の値が2に設定されている場合、FA-CoAの場合には、それはGNAMは、MNから来たことを意味します。
If the "MD" value is set to 5, and the HA accepted this message, the HA MAY also process it based on the notification event. The FA-HA AE MUST be checked, and the HA MUST check the Authenticator value in the extension. If no FA-HA AE is found, or if more than one FA-HA AE is found, or if the Authenticator is invalid, the HA MUST silently discard the GNAM.
「MD」の値が5に設定され、HAは、このメッセージを受け入れている場合は、HAはまた、通知イベントに基づいて処理することができます。 FA-HA AEをチェックしなければなりませんし、HAはExtensionでAuthenticator値をチェックしなければなりません。何のFA-HA AEが見つからない場合は、複数のFA-HA AEが発見された場合に認証が無効な場合、または、または、HAは黙っGNAMを捨てなければなりません。
If the "MD" value is set to 2, in the case of an FA-CoA, and if the FA-HA AE is present, the FA-HA AE MUST be checked, and the HA MUST check the Authenticator value in the Extension. If more than one FA-HA AE is found, or if the Authenticator is invalid, the HA MUST silently discard the GNAM. No matter what, the MN-HA AE MUST be checked, and the HA MUST check the Authenticator value in the Extension. If no MN-HA AE is found, or if more than one MN-HA AE is found, or if the Authenticator is invalid, the HA MUST silently discard the GNAM. If the HA accepted this message, the HA MAY also process it based on the notification event.
「MD」の値はFA-CoAの場合には、2に設定されている場合は、FA-HA AEが存在する場合、および、FA-HA AEをチェックしなければなりませんし、HAはExtensionでAuthenticator値をチェックしなければなりません。複数のFA-HA AEが検出された場合は認証が無効な場合、または、HAは黙っGNAMを捨てなければなりません。何があって、MN-HA AEをチェックしませんしなければならない、とHAはExtensionでAuthenticator値をチェックしなければなりません。何のMN-HA AEが検出されない、または、複数のMN-HA AEが発見された場合に認証が無効な場合、または、HAは黙っGNAMを捨てなければなりません場合。 HAは、このメッセージを受け入れた場合、HAはまた、通知イベントに基づいて処理することができます。
If the "MD" value is set to 2, in the case of a co-located CoA, the MN-HA AE MUST be checked, and the HA MUST check the Authenticator value in the Extension. If no MN-HA AE is found, or if more than one MN-HA AE is found, or if the Authenticator is invalid, the HA MUST silently discard the GNAM. If the HA accepted this message, the HA MAY also process it based on the notification event.
「MD」の値が2に設定されている場合は、同じ場所に配置アシルCoAの場合には、MN-HA AEをチェックしなければなりませんし、HAはExtensionでAuthenticator値をチェックしなければなりません。何のMN-HA AEが検出されない、または、複数のMN-HA AEが発見された場合に認証が無効な場合、または、HAは黙っGNAMを捨てなければなりません場合。 HAは、このメッセージを受け入れた場合、HAはまた、通知イベントに基づいて処理することができます。
The HA MAY receive a GNM sent from the FA. When the HA receives this message, if the "MD" value is set to 5, this message came from FA. The FA-HA AE MUST be checked, and the HA MUST check the Authenticator value in the extension. If no FA-HA AE is found, or if more than one FA-HA AE is found, or if the Authenticator is invalid, the HA MUST reject the GNM and MAY send a GNAM to the FA with Code 132, including an Identification field computed in accordance with the rules specified in Section 7.1. The HA MUST do no further processing with such a notification, though it SHOULD log the error as a security exception.
HAは、FAから送信されたGNMを受け取ることができます。 HAは、このメッセージを受信すると、「MD」の値が5に設定されている場合、このメッセージはFAから来ました。 FA-HA AEをチェックしなければなりませんし、HAはExtensionでAuthenticator値をチェックしなければなりません。何のFA-HA AEが見つからない場合、または複数のFA-HA AEが検出された、または認証が無効な場合、HAはGNM拒絶しなければなりませんし、識別フィールドを含む、コード132でFAにGNAMを送る可能性がある場合7.1節で指定されたルールに従って計算。それはセキュリティ例外としてエラーをログに記録すべきであるにもかかわらずHAは、このような通知とは、さらに処理してはいけません。
The HA MUST check that the Identification field is correct using the context selected by the SPI within a mandatory authentication extension like MN-HA AE or FA-HA AE. See Section 7.1 for a description of how this is performed. If incorrect, the HA MUST reject the GNM and MAY send a GNAM to the initiator with Code 133, including an Identification field computed in accordance with the rules specified in Section 7.1. The HA MUST do no further processing with such a notification, though it SHOULD log the error as a security exception. If the HA accepts the FA's GNM, it will process it based on the notification extension. Furthermore, the HA MAY reply to the FA with a GNAM with Code 0 based on the "A" flag in the GNM.
HAは、識別フィールドは、MN-HA AEまたはFA-HA AEのような必須の認証拡張内SPIによって選択されたコンテキストを使用して正しいことをチェックしなければなりません。これが実行される方法については、7.1項を参照してください。間違った場合、HAはGNMを拒絶しなければなりません、セクション7.1で指定された規則に従って計算識別フィールドを含む、コード133とイニシエータにGNAMを送信することができます。それはセキュリティ例外としてエラーをログに記録すべきであるにもかかわらずHAは、このような通知とは、さらに処理してはいけません。 HAは、FAのGNMを受け入れる場合、それは、通知の拡張子に基づいて処理します。さらに、HAはGNMの「A」フラグに基づいて、コード0でGNAMとFAに応答することができます。
If the "MD" value is set to 2, this message comes from the MN. In the case of FA-CoA, if FA-HA AE is present, it MUST be checked, and the HA MUST check the Authenticator value in the Extension. If more than one FA-HA AE Extension is found, or if the Authenticator is invalid, the HA MUST reject the GNM and MAY send a GNAM to the FA with Code 132, including an Identification field computed in accordance with the rules specified in Section 7.1. The HA MUST do no further processing with such a notification, though it SHOULD log the error as a security exception. Also, the MN-HA AE MUST be checked, and the HA MUST check the Authenticator value in the Extension. If no MN-HA AE is found, or if more than one MN-HA AE is found, or if the Authenticator is invalid, the HA MUST reject the GNM and MAY send a GNAM to the MN with Code 131, including an Identification field computed in accordance with the rules specified in Section 7.1. The HA MUST do no further processing with such a notification, though it SHOULD log the error as a security exception. If the HA accepts the MN's GNM, it will process it based on the notification extension. Furthermore, the HA MAY reply to the MN with a GNAM back with Code 0 based on the "A" flag in the GNM.
「MD」の値が2に設定されている場合は、このメッセージは、MNから来ています。 FA-HA AEが存在する場合、FA-CoAをする場合に、それをチェックしなければなりません、そしてHAはExtensionでAuthenticator値をチェックしなければなりません。複数のFA-HA AE拡張が発見された場合認証が無効な場合、または、HAはGNMを拒絶しなければなりませんし、セクションで指定されたルールに従って計算識別フィールドを含む、コード132でFAにGNAMを送るかもしれません7.1。それはセキュリティ例外としてエラーをログに記録すべきであるにもかかわらずHAは、このような通知とは、さらに処理してはいけません。また、MN-HA AEをチェックしなければなりませんし、HAはExtensionでAuthenticator値をチェックしなければなりません。何のMN-HA AEが見つからない場合、または複数のMN-HA AEが発見された場合、または認証が無効な場合、HAは、GNM拒絶しなければなりませんし、識別フィールドを含む、コード131でMNにGNAMを送るかもしれません7.1節で指定されたルールに従って計算。それはセキュリティ例外としてエラーをログに記録すべきであるにもかかわらずHAは、このような通知とは、さらに処理してはいけません。 HAは、MNのGNMを受け入れる場合、それは、通知の拡張子に基づいて処理します。さらに、HAはGNMの「A」フラグに基づいて、コード0で逆GNAMとMNに応答することができます。
If the "MD" value is set to 2, in the case of a co-located CoA, the MN-HA AE MUST be checked, and the HA MUST check the Authenticator value in the Extension. If no MN-HA AE is found, or if more than one MN-HA AE is found, or if the Authenticator is invalid, the HA MUST reject the GNM and MAY send a GNAM to the MN with Code 131, including an Identification field computed in accordance with the rules specified in Section 7.1. The HA MUST do no further processing with such a notification, though it SHOULD log the error as a security exception. If the HA accepts the MN's GNM, it will process it based on the notification extension. Furthermore, the HA MAY reply to the MN with a GNAM with Code 0 based on the "A" flag in the GNM.
「MD」の値が2に設定されている場合は、同じ場所に配置アシルCoAの場合には、MN-HA AEをチェックしなければなりませんし、HAはExtensionでAuthenticator値をチェックしなければなりません。何のMN-HA AEが見つからない場合、または複数のMN-HA AEが発見された場合、または認証が無効な場合、HAは、GNM拒絶しなければなりませんし、識別フィールドを含む、コード131でMNにGNAMを送るかもしれません7.1節で指定されたルールに従って計算。それはセキュリティ例外としてエラーをログに記録すべきであるにもかかわらずHAは、このような通知とは、さらに処理してはいけません。 HAは、MNのGNMを受け入れる場合、それは、通知の拡張子に基づいて処理します。さらに、HAはGNMの「A」フラグに基づいて、コード0でGNAMとMNに応答することができます。
The HA MUST also check that the extensions present in the Generic Notification Message are permitted for use with the GNM. If not, the HA MUST silently discard the message. It MUST NOT do any further processing with such a notification, though it SHOULD log the error.
HAはまた、一般的な通知メッセージに存在する拡張機能がGNMで使用するために許可されていることをチェックしなければなりません。ない場合は、HAは静かにメッセージを捨てなければなりません。それがエラーを記録すべきであるけれどもそれは、このような通知と任意の更なる処理を行うてはなりません。
If the GNM came from the FA only, and if the "A" flag is set in the GNM, then the HA MUST send a GNAM. The message is as follows: The source address is the HA's address, the destination address is the FA's address, and the "MD" value is set to 1. The ordering of the extension is: any non-authentication Extensions intended for the FA, followed by the Foreign-Home Authentication extension defined in Section 3.5.4 of [RFC5944].
GNMはFAから来た場合は、「A」フラグがGNMに設定されている場合にのみ、および、その後、HAはGNAMを送らなければなりません。次のようにメッセージは次のとおりです、FAのために意図任意の非認証拡張機能：送信元アドレスがHAのアドレスであり、宛先アドレスはFAのアドレスであり、「MD」の値が1に設定されている拡張機能の順序があります[RFC5944]のセクション3.5.4で定義された外国ホーム認証拡張が続きます。
The Code field of the GNAM is chosen in accordance with the rules specified in Section 4.2. When replying to an accepted GNM, an MN SHOULD respond with Code 0.
GNAMのコードフィールドは、セクション4.2で指定された規則に従って選択されます。受け入れGNMに返信すると、MNはコード0で応答する必要があります。
If the GNM came from the MN, and if the "A" flag is set in the GNM, then the HA MUST send a GNAM. The message is as follows: The source address is the HA's address, the destination address is the FA's address, and the "MD" value is set to 0. The ordering of the extension is: any non-authentication extensions intended for the MN, followed by the MN-HA AE defined in Section 3.5.2 of [RFC5944], optionally followed by any non-authentication extensions intended for the FA, optionally followed by the MN-FA AE defined in Section 3.5.3 of [RFC5944].
GNMは、MNから来た場合、および「A」フラグがGNMに設定されている場合、HAはGNAMを送らなければなりません。次のようにメッセージは次のとおりです、MNのために意図任意の非認証の拡張機能：送信元アドレスがHAのアドレスであり、宛先アドレスはFAのアドレスであり、「MD」の値が0に設定されている拡張機能の順序があります任意にMN-FA AE [RFC5944]のセクション3.5.3で定義され、続いてFAを意図する任意の非認証の拡張、続いて[RFC5944]のセクション3.5.2で定義されたMN-HA AE、続きます。
This document defines the Generic Notification Message used with the Message String Extension [RFC4917].
この文書では、メッセージ文字列の拡張[RFC4917]で使用される一般的な通知メッセージを定義します。
However, it is possible to define new notification-related extensions for use with the Generic Notification Message, for cases where the notification is intended to have a semantic content and is intended for the HA, FA, or MN, rather than for the user.
しかし、通知が意味内容を有することが意図されており、HA、FA、またはMNのためではなく、ユーザーのために意図された場合のために、一般的な通知メッセージで使用するために新たな通知関連の拡張を定義することが可能です。
One example of such usage, which would have been defined in this document if it hadn't already been defined as a separate message, is the Registration Revocation Message [RFC3543]. This is a message sent from the HA to the FA(s) or MN to notify the receiving node that a currently active registration is being revoked. The use case for this is clearly laid out in [RFC3543].
それは既に別のメッセージとして定義されていない場合は、この文書で定義されていたであろうこのような使用の一例は、登録失効メッセージ[RFC3543]です。これは、現在アクティブな登録が取り消されている受信ノードに通知するためにFA（S）またはMNのHAから送信されたメッセージです。このため、ユースケースを明確に[RFC3543]でレイアウトされています。
Another example would be managed maintenance switch-over between HA instances, where an HA due to go down for maintenance could direct the MNs registered with it to re-register with another specified HA.
別の例は、メンテナンスのためにダウンして行くによるHAは、別の指定されたHAに再登録することで登録するMNを指示できHAインスタンス間メンテナンススイッチオーバーを、管理されます。
Such a message could also be used for managed load balancing. There is currently no support for such forced switch-over in the Mobile IPv4 protocol.
このようなメッセージは、管理負荷分散のために使用することができます。モバイルIPv4プロトコルでは、このような強制的なスイッチオーバーのサポートは現在ありません。
Yet another example is when the prefix set handled by an MIPv4 NEMO [RFC5177] HA changes; to ensure proper routing, the mobile router needs to be notified about the change so that its internal routing rules may be updated.
プレフィックスセットがMIPv4のNEMO [RFC5177] HA変化によって処理するときさらに別の例です。適切なルーティングを確保するために、モバイルルータは、その内部のルーティングルールを更新することができるように、変更について通知する必要があります。
One final example is home network changes that require host configuration changes, for instance, a change of address for the DNS server or another network server. Again, this is a case where the HA would want to notify the MN of the change, so that service interruptions can be avoided.
最後にもう一つの例は、インスタンスのホストの設定を変更して、DNSサーバまたは別のネットワークサーバのアドレスの変更を必要とするホームネットワークの変更です。繰り返しますが、これは、HAは、サービスの中断を回避することができるように、変更のMNに通知したい場合です。
In order to avoid making the MIPv4 Generic Notification Message a generic protocol extension mechanism by which new protocol mechanisms could be implemented without appropriate discussion and approval, any new extensions that are to be used with the Generic Notification Message must be registered with IANA, where registration is limited by the 'RFC Required' policy defined in [RFC5226].
MIPv4の一般的な通知メッセージに新しいプロトコルメカニズムは、適切な議論と承認なしに実現することができたことにより、汎用的なプロトコル拡張メカニズムを避けるために、一般的な通知メッセージで使用されるすべての新しい拡張機能は、登録IANAに登録する必要があります[RFC5226]で定義された「RFC必須」ポリシーによって制限されています。
If additional extensions are specified for use with the Generic Notification Message, the practice exemplified in [RFC5944] and related specifications should be followed. Generally, it has not been necessary so far to provide versioning support within individual extensions; in a few cases, it has been necessary to define new extensions with new extension numbers where a generalization of a pre-existing extension has been needed. With the current rate of extension number consumption, that seems to be an acceptable approach.
追加の拡張機能は、一般的な通知メッセージで使用するように指定されている場合は、[RFC5944]で例示した実践と関連の仕様が従うべきです。一般的には、個々の拡張機能内のバージョン管理サポートを提供するために、これまで必要とされていません。いくつかのケースでは、既存の拡張子の一般化が必要とされた新しい内線番号を持つ新しい拡張を定義する必要がありました。内線番号の消費の現在のレートでは、それが許容可能なアプローチであると思われます。
If at some point extensions are specified for use with the Generic Notification Message that overlap with pre-existing notification messages, the authors of the specification should consider providing a method to flag which notification messages are supported, and which notification message usage is requested, in a manner similar to the way tunneling method capabilities and usage requests are flagged in the Mobile IPv4 base specification [RFC5944].
いくつかの点の拡張で既存の通知メッセージと重複汎用通知メッセージで使用するために指定されている場合、明細書の著者は、通知メッセージがサポートされているフラグに提供方法を検討する必要があり、どの通知メッセージ使用することで、要求され双方向トンネリング方式の機能と使用要求と同様に、モバイルIPv4ベース仕様[RFC5944]にフラグが設定されています。
Encoded in the extension number of Mobile IPv4 extensions is the notion of 'skippable' and 'not skippable' extensions; see Section 1.8 of [RFC5944]. This notion is also applicable when extensions are used with the Generic Notification Message: It is not required that a receiver understand a skippable extension, but a non-skippable extension needs to be handled according to Section 1.8 of [RFC5944]
モバイルIPv4拡張の内線番号で符号化された「スキップ可能」と「スキップ可能でない」拡張子の概念があります。 [RFC5944]のセクション1.8を参照してください。拡張機能は一般的な通知メッセージで使用されている場合は、この概念を適用することも可能である：受信機がスキップ可能な拡張を理解することが必要とされていないが、非スキップ可能な拡張子は[RFC5944]のセクション1.8に従って処理する必要があります
(i.e., the message must be silently discarded if the extension is not recognized). This document does not specify any change from the Mobile IPv4 base specification [RFC5944] in this respect.
（拡張子が認識されない場合、すなわち、メッセージは黙って廃棄しなければなりません）。この文書では、この点でモバイルIPv4ベース仕様[RFC5944]からの変更を指定していません。
This document defines two new messages, the Generic Notification Message described in Section 4.1, and the Generic Notification Acknowledgement Message described in Section 4.2. The message numbers for these two messages have been allocated from the same number space used by the Registration Request and Registration Reply messages in [RFC5944].
この文書では、2つの新しいメッセージ、4.1節で説明した一般的な通知メッセージ、および4.2節で説明した一般的な通知確認メッセージを定義します。これら二つのメッセージのメッセージ番号は登録要求と[RFC5944]で登録応答メッセージで使用されるのと同じ数の空間から割り当てられています。
The Generic Notification Message may only carry extensions that are explicitly permitted for use with this message. Section 4.1 of this document defines 4 extensions that are permitted. IANA has added a column to the registry of Mobile IPv4 extensions, which will indicate for each extension if it is permitted for use with the Generic Notification Message. Approval of new extensions that are permitted for use with the Generic Notification Message requires that they be defined in an RFC according to the 'RFC Required' policy described in [RFC5226].
一般的な通知メッセージは、明示的にのみ、このメッセージで使用するために許可されている拡張子を運ぶことができます。このドキュメントのセクション4.1は許可されている4つの拡張を定義します。 IANAは、それが一般的な通知メッセージで使用するために許可されている場合、各拡張のために示すことになるモバイルIPv4拡張機能のレジストリに列を追加しました。一般的な通知メッセージで使用するために許可されている新しい拡張機能の承認は、彼らが[RFC5226]で説明した「RFC必須」ポリシーに従って、RFCで定義されている必要があります。
The Generic Notification Acknowledgement Message, specified in Section 4.2, has a Code field. The number space for the Code field values is new and also specified in Section 4.2. The Code number space is structured according to whether the notification was successful, the HA denied the notification, the FA denied the notification, or the MN denied the notification, as follows:
4.2節で指定されたジェネリック通知確認メッセージは、Codeフィールドがあります。コードフィールド値の番号空間が新しいとも4.2節で指定されています。コード番号空間は、通知が成功したかどうかに応じて構成されているHAは、通知を否定し、FAは、通知を拒否された、または次のようにMNは、通知を拒否されました：
0 Success Code
64-69 Error Codes from the FA
128-133 Error Codes from the HA
192-197 Error Codes from the MN
Approval of new Code values requires expert review.
新しいコード値の承認は、専門家審査が必要です。
This specification operates with the security constraints and requirements of [RFC5944]. This means that when this message is transmitted between the MN and the HA, the MN-HA AE is REQUIRED; when this message is transmitted between the MN and the FA, the MN-FA AE is REQUIRED; when this message is transmitted between the FA and the HA, the FA-HA AE is REQUIRED. It extends the operations of the MN, HA, and FA defined in [RFC5944] to notify each other about some events. The GNM defined in this specification could carry information that modifies the mobility bindings. Therefore, the message MUST be integrity protected. Replay protection MUST also be guaranteed.
この仕様は、セキュリティ上の制約と[RFC5944]の要件で動作します。これは、このメッセージは、MNとHAとの間で送信される場合、MN-HA AEが必要であることを意味します。このメッセージは、MNとFAとの間で送信される場合、MN-FA AEが必要です。このメッセージは、FAとHAとの間で送信される場合、FA-HA AEが必要です。これは、いくつかのイベントについてお互いに通知するために、[RFC5944]で定義されたMN、HA、およびFAの動作を拡張します。この仕様で定義されたGNMは、モビリティバインディングを変更する情報を運ぶことができます。そのため、メッセージが完全性保護されなければなりません。リプレイ保護も保証されなければなりません。
RFC 5944 provides replay protection only for Registration Requests sent by the MN. There is no mechanism for replay protection for messages initiated by an FA or HA. The 64-bit Identification field specified in this document (Sections 4.1 and 4.2) for the GNM is used to provide replay protection for the notification messages initiated by the FA or HA.
RFC 5944はMNによって送られた登録要求のためのリプレイ保護を提供します。 FAまたはHAによって開始されたメッセージのリプレイ保護のためのメカニズムはありません。 GNMは、このドキュメント（セクション4.1および4.2）に指定された64ビットの識別フィールドがFA又はHAによって開始された通知メッセージのリプレイ保護を提供するために使用されます。
The Identification field is used to let the receiving node verify that a GNM has been freshly generated by the sending node, not replayed by an attacker from some previous notification. Two methods are described in this section: timestamps (REQUIRED) and "nonces" (OPTIONAL). All senders and receivers MUST implement timestamp-based replay protection. These nodes MAY also implement nonce-based replay protection
識別フィールドは、受信ノードがGNMが新たにいくつかの以前の通知からの攻撃者によって再生しない送信ノードによって生成されたことを確認させるために使用されます。タイムスタンプ（REQUIRED）と「ナンス」（オプション）：二つの方法は、このセクションに記載されています。すべての送信者と受信者は、タイムスタンプベースのリプレイ保護を実装しなければなりません。これらのノードはまた、ナンスベースのリプレイ保護を実装してもよい（MAY）
The style of replay protection in effect between any two peer nodes among the MN, FA, and HA is part of the mobile security association. A sending node and its receiving node MUST agree on which method of replay protection will be used. The interpretation of the Identification field depends on the method of replay protection as described in the subsequent subsections.
MNの間で任意の2つのピア・ノード間の効果で再生保護のスタイル、FA、およびHAは、モバイルセキュリティアソシエーションの一部です。送信ノードとその受信ノードはリプレイ保護の方法が使用されるに同意しなければなりません。後続のサブセクションで説明したように識別フィールドの解釈はリプレイ保護の方法に依存します。
Whatever method is used, the low-order 32 bits of the Identification field MUST be copied unchanged from the GNM to the GNAM. The receiver uses those bits (and the sender's source address) to match the GNAM with corresponding replies. The receiver MUST verify that the low-order 32 bits of any GNAM Identification field are identical to the bits it sent in the GNM.
どのような方法で使用され、識別フィールドの下位32ビットはGNAMにGNMから不変コピーしなければなりません。受信機は、対応する応答とGNAMに一致するようにこれらのビット（及び送信者のソースアドレス）を使用します。受信機は、任意のGNAM識別フィールドの下位32ビットは、それがGNMで送られたビットと同一であることを確かめなければなりません。
The Identification in a new GNM MUST NOT be the same as in an immediately preceding GNM, and SHOULD NOT repeat while the same security context is being used between the MN and the HA.
新しいGNMにおける識別は、直前GNMと同じであってはなりませんと同じセキュリティコンテキストはMNとHAの間で使用されている間繰り返すべきではありません。
The basic principle of timestamp replay protection is that the node generating a message inserts the current time of day, and the node receiving the message checks that this timestamp is sufficiently close to its own time of day. Unless specified differently in the security association between the nodes, a default value of 7 seconds MAY be used to limit the time difference. This value SHOULD be greater than 3 seconds. Obviously, the two nodes must have adequately synchronized time-of-day clocks. As with any messages, time synchronization messages may be protected against tampering by an authentication mechanism determined by the security context between the two nodes.
タイムスタンプリプレイ保護の基本的な原理は、メッセージを生成するノードは、現在の時刻を挿入し、メッセージを受信したノードがこのタイムスタンプがその日の独自の時間に十分に近いかどうかをチェックすることです。ノード間のセキュリティアソシエーションで異なる指定がない限り、7秒のデフォルト値は、時間差を制限するために使用されるかもしれません。この値は、3秒以上でなければなりません。明らかに、2つのノードが適切に時刻クロックを同期している必要があります。任意のメッセージと同様に、時刻同期メッセージは、2つのノード間のセキュリティコンテキストによって決定される認証機構による改ざんから保護することができます。
In this document, the timestamps are used, and the sender MUST set the Identification field to a 64-bit value formatted as specified by the Network Time Protocol (NTP) [RFC5905]. The low-order 32 bits of the NTP format represent fractional seconds. Note, however, that when using timestamps, the 64-bit Identification used in a GNM from the sender MUST be greater than that used in any previous GNM, as the receiver uses this field also as a sequence number. Without such a sequence number, it would be possible for a delayed duplicate of an earlier GNM to arrive at the receiver (within the clock synchronization required by the receiver), and thus be applied out of order, mistakenly altering the sender's current status.
この文書では、タイムスタンプが使用され、送信者がネットワークタイムプロトコル（NTP）[RFC5905]によって指定されるようにフォーマットされた64ビット値を識別フィールドを設定しなければなりません。 NTPフォーマットの下位32ビットは小数秒を表します。タイムスタンプを使用した場合、受信機は、シーケンス番号としても、このフィールドを使用するように、送信者からGNMに使用される64ビットの識別が、以前GNMに使用されるものよりも大きくなければならないこと、しかし、注意してください。このようなシーケンス番号なしで、それは（受信機で必要なクロック同期内で）受信機に到達する以前GNMの遅延重複可能となり、したがって誤って送信者の現在の状態を変化させる、順不同で適用されます。
Upon receipt of a GNM with an authorization-enabling extension, the receiver MUST check the Identification field for validity. In order to be valid, the timestamp contained in the Identification field MUST be close enough to the receiver's time-of-day clock and the timestamp MUST be greater than all previously accepted timestamps for the requesting sender. Time tolerances and re-synchronization details are specific to a particular mobility security association.
認可可能拡張子を持つGNMを受信すると、受信機は、有効性の識別フィールドをチェックしなければなりません。有効であるためには、識別フィールドに含まれるタイムスタンプは、受信機の時刻クロックに十分に近くなければならないとタイムスタンプは、要求の送信者のすべての以前に受け入れられたタイムスタンプよりも大きくなければなりません。時間の許容範囲と再同期の詳細は、特定のモビリティセキュリティアソシエーションに固有のものです。
If the timestamp is valid, the receiver copies the entire Identification field into the GNAM, and it returns the GNAM to the sender. If the timestamp is not valid, the receiver copies only the low-order 32 bits into the GNAM, and supplies the high-order 32 bits from its own time of day. In this latter case, the receiver MUST reject the notification by returning Code 69, 133, or 197 (notification Identification mismatch) in the GNAM.
タイムスタンプはGNAMに、受信機の全体をコピー識別フィールド有効であり、そしてそれは、送信者にGNAMを返す場合。タイムスタンプが有効でない場合、受信機コピーGNAMにのみ、下位32ビットを、そしてその日の独自の時間から上位32ビットを供給する。後者の場合、受信機はGNAMにコード69、133、または197（通知識別ミスマッチ）を返すことによって通知を拒絶しなければなりません。
Furthermore, the receiver MUST verify that the low-order 32 bits of the Identification in the GNAM are identical to those in the rejected GNM attempt, before using the high-order bits for clock re-synchronization.
さらに、受信機はGNAMにおける識別の下位32ビットは、クロック再同期のための上位ビットを使用する前に、拒否GNM試行におけるものと同一であることを確かめなければなりません。
The basic principle of nonce replay protection is that node A includes a new random number in every message to node B, and checks that node B returns that same number in its next message to node A. Both messages use an authentication code to protect against alteration by an attacker. At the same time, node B can send its own nonces in all messages to node A (to be echoed by node A), so that it too can verify that it is receiving fresh messages.
ノンスリプレイ保護の基本原理は、ノードAがノードBが両方のメッセージ認証コードを使用してノードAへの次のメッセージに同じ番号が改ざんから保護することに戻り、新たなランダムなノードBへのすべてのメッセージに数、及びチェックを含みます攻撃者による。これと同時に、ノードBは、それがあまりにも、それは新鮮なメッセージを受信していることを確認できるように、A（ノードAによってエコーされる）をノードAにすべてのメッセージに独自のナンスを送信することができます。
The receiver may be expected to have resources for computing pseudo-random numbers useful as nonces, according to [RFC4086]. It inserts a new nonce as the high-order 32 bits of the Identification field of every GNAM. The receiver copies the low-order 32 bits of the Identification field from the GNM into the low-order 32 bits of the Identification field in the GNAM. When the sender receives an authenticated GNAM from the receiver, it saves the high-order 32 bits of the Identification field for use as the high-order 32 bits of its next GNM.
受信機は、[RFC4086]によれば、ナンスとして有用な擬似乱数を計算するためのリソースを有することが期待されてもよいです。これは、すべてのGNAMの識別フィールドの上位32ビットとして新たなnonceを挿入します。レシーバコピーGNAMにおける識別フィールドの下位32ビットにGNMから識別フィールドの下位32ビットです。送信者が受信機から認証GNAMを受信すると、その次GNMの上位32ビットとして使用するための識別フィールドの上位32ビットを保存します。
The sender is responsible for generating the low-order 32 bits of the Identification field in each GNM. Ideally, it should generate its own random nonces. However, it may use any expedient method, including duplication of the random value sent by the receiver. The method chosen is of concern only to the sender because it is the node that checks for valid values in the GNAM. The high-order and low-order 32 bits of the Identification chosen SHOULD both differ from their previous values. For each notification message, the receiver uses a new high-order value and the sender uses a new low-order value.
送信者は、各GNMにおける識別フィールドの下位32ビットを生成する責任があります。理想的には、それはそれ自身のランダムなナンスを生成する必要があります。しかし、受信機によって送信されたランダム値の重複を含む、任意の好都合な方法を使用することができます。それはGNAMで有効な値をチェックするノードであるため、選択した方法は、送信者のみに関心があります。識別の32ビットは選択された上位及び下位の両方がそれらの以前の値とは異なるべきです。各通知メッセージのために、受信機は新たな高次の値を使用し、送信側は、新しい下位値を使用します。
If a GNM is rejected because of an invalid nonce, the GNAM always provides the sender with a new nonce to be used in the next message. Thus, the nonce protocol is self-synchronizing.
GNMが無効なためナンスを拒否された場合、GNAMは、常に次のメッセージで使用される新しいナンスを送信者に提供します。したがって、ノンスプロトコルは、自己同期です。
When the FA is relaying a GNM between the MN and the HA, and if the FA does not share a mobility security association with the MN or HA, all non-authentication extensions between the MN and FA, or FA and HA, are not protected. In this case, all non-authentication extensions should be silently discarded.
FAは、MNとHAの間GNMを中継した場合、およびFAはMNまたはHAとのモビリティセキュリティアソシエーションを共有しない場合は、MNとFA、またはFAとHAの間のすべての非認証の拡張機能は、保護されていません。この場合、すべての非認証の拡張機能は、静かに捨てられるべきです。
The authors appreciate the efforts of Ahmad Muhanna for his detailed review of and his many contributions to the text of this document. The author also wants to thank Kent Leung, Peng Yang, Peter McCann, et al., for their helping developing this document. Thanks to Alexey Melnikov, Sean Turner, Ralph Droms, Charles E. Perkins, Russ Housley, Magnus Westerlund, Lars Eggert, Dan Romascanu, Tim Polk, Amanda Baber, Sebastian Thalanany, and Joseph Salowey for their discussion and comments. Thanks to Jari Arkko for help at each step of this document's development.
著者は、彼の詳細なレビューと、この文書のテキストへの彼の多くの貢献のためのアフマドMuhannaの努力を高く評価しています。著者はまた、彼らは、このドキュメントの開発を支援するために、ケントレオン、鵬ヤン、ピーター・マッキャンを、ら。感謝したいです。アレクセイ・メルニコフ、ショーン・ターナー、ラルフDroms、チャールズE.パーキンス、ラスHousley、マグヌスウェスター、ラースEggertの、ダンRomascanu、ティムポーク、アマンダBaber、セバスチャンThalanany、そしてジョセフSaloweyのおかげで彼らの議論とコメント。このドキュメントの開発の各段階で、助けのためのヤリArkkoに感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3543] Glass, S. and M. Chandra, "Registration Revocation in Mobile IPv4", RFC 3543, August 2003.
[RFC3543]ガラス、S.とM.チャンドラ、 "モバイルIPv4における登録失効"、RFC 3543、2003年8月。
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086]イーストレーク、D.、シラー、J.、およびS.クロッカー、 "セキュリティのためのランダム要件"、BCP 106、RFC 4086、2005年6月。
[RFC4917] Sastry, V., Leung, K., and A. Patel, "Mobile IPv4 Message String Extension", RFC 4917, June 2007.
[RFC4917] Sastry、V.、レオン、K.、およびA.パテル、 "モバイルIPv4メッセージ文字列の拡張"、RFC 4917、2007年6月。
[RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010.
[RFC5905]ミルズ、D.、マーティン、J.、バーバンク、J.、およびW. Kasch、 "ネットワークタイムプロトコルバージョン4：プロトコルとアルゴリズムの仕様"、RFC 5905、2010年6月。
[RFC5944] Perkins, C., "IP Mobility Support for IPv4, Revised", RFC 5944, November 2010.
[RFC5944]パーキンス、C.、 "IPv4のIPモビリティのサポート、改訂"、RFC 5944、2010年11月。
[RFC5177] Leung, K., Dommety, G., Narayanan, V., and A. Petrescu, "Network Mobility (NEMO) Extensions for Mobile IPv4", RFC 5177, April 2008.
[RFC5177]レオン、K.、Dommety、G.、ナラヤナン、V.、およびA.ペトレスク、 "モバイルIPv4のためのネットワークモビリティ（NEMO）の拡張"、RFC 5177、2008年4月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 5226、2008年5月。
Authors' Addresses
著者のアドレス
Hui Deng China Mobile 53A, Xibianmennei Ave., Xuanwu District, Beijing 100053 China
ホイ鄧小平中国移動53A、ξサイドドアAVE。、X UA Nノー地区、北京100053中国
EMail: denghui02@gmail.com
メールアドレス：denghui02@gmail.com
Henrik Levkowetz Netnod Franzengatan 5 S-104 25, Stockholm SWEDEN
ヘンリックLevkowetz Netnod Franzengatan 5つのS-104 25、スウェーデンストックホルム
EMail: henrik@levkowetz.com
メールアドレス：henrik@levkowetz.com
Vijay Devarapalli Vasona Networks 2900 Lakeside Drive Santa Clara, CA 95054 USA
サンタクララの湖畔のドライブネットワークによるビジェイのdevarapalli 2900、K.は、95054を見ました
EMail: dvijay@gmail.com
メールアドレス：dvijay@gmail.com
Sri Gundavelli Cisco 170 W.Tasman Drive San Jose, CA 95134 USA
スリGundavelliシスコ170 W.Tasmanドライブサンノゼ、CA 95134 USA
EMail: sgundave@cisco.com
メールアドレス：sgundave@cisco.com
Brian Haley Hewlett-Packard Company 165 Dascomb Road Andover, MA 01810 USA
ブライアン・ヘイリー、米国Hewlett-Packard Company 165 Dascombロードアンドーバー、MA 01810 USA
EMail: brian.haley@hp.com
メールアドレス：brian.haley@hp.com