[要約] RFC 6098は、モバイルIPv4における汎用通知メッセージに関する規格であり、モバイルノードの状態変更やネットワークの変更を通知するためのメッセージ形式を定義しています。目的は、モバイルノードの移動やネットワークの変更に関する情報を効率的に伝達することです。
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
モバイル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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2012 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。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）、外国エージェント（FA）、モバイルノード（MN）などのモバイルIPv4エンティティが必要です。この文脈では、「非同期メッセージ」は、ベースモバイル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の詳細を参照してください）。このような使用法の例は、請求またはサービス関連のイベントに関するオペレーターからユーザーへのメッセージです（「プリペイドクォータのほぼすべてを使用しました。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.
拡張ジェネリック通知メッセージの適用の1つの例は、CDMA 2000 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がオフラインになることを決定する前に、MNSに別の候補者に登録するように通知したい）、
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プレフィックスの変更とサービス関連のイベントについて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).
ここで指定されている通知メカニズムは、FAを介した登録を伴う共同配置されたケアオブアドレス（COA）モードの場合をサポートしていません（FAの広告メッセージに「R」ビットが設定されているため）。
+----+ 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に通知メッセージを送信する場合があります。1つはメッセージを中継している場合、もう1つは別のネットワークエンティティからのメッセージによってトリガーされる場合、認証、承認、会計（認証、会計など）がトリガーされる場合があります。AAA）ノード。（AAAエンティティとFAの間の通知メッセージは半径または直径に基づいている可能性がありますが、これはこのドキュメントの範囲外です。）通知が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にFAまたはFAに通知するHAに通知
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.
送信ノードは、[RFC5944]のセクション3.3と同じ登録要求を送信するための同じ手順に従って常にGNMを送信し、受信ノードはGNAMを送信する際の[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 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:
GNMは、モビリティエージェントによって送信され、メッセージ文字列拡張子[RFC4917]の形式のMIP関連情報を別のモビリティエージェントまたはMNに通知します。これらのメッセージは、同じエンティティへの以前の登録要求（RRQ）または返信（RRP）メッセージと同じIPおよびUDPヘッダーを使用する必要があります。これにより、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.
Agentが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-HAからMNに送信されたメッセージ
1 -- Message sent by the HA to the FA
1-HAからFAに送信されたメッセージ
2 -- Message sent by the MN to the HA
2- MNからHAに送信されたメッセージ
3 -- Message sent by the MN to the FA
3- MNからFAに送信されたメッセージ
4 -- Message sent by the FA to the MN
4- FAからMNに送信されたメッセージ
5 -- Message sent by the FA to the HA
5- FAからHAに送信されたメッセージ
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.
このビットは、通知メッセージが受信者によって確認されなければならないかどうかを示します。メッセージ中に「A」ビットが設定されているが、送信者が確認メッセージを受け取らない場合、送信者は通知メッセージを再度送信する必要があります。
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ビット番号は、GNMとGNAMを一致させ、通知メッセージのリプレイ攻撃から保護するために使用されます。この分野でのタイムスタンプとノンセスの使用の詳細については、セクション7.1.1および7.1.2を参照してください。タイムスタンプの使用のサポートが必要であり、Noncesのサポートはオプションです。
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].
GNMの固定部分の後に、このメッセージで使用できる1つ以上の拡張機能が続き、[RFC5944]のセクション3.5で定義されている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]で定義されたメッセージ文字列拡張子で使用できるように、このドキュメントで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とFAの間にこのメッセージが送信される場合、MN-FA AEの使用も必要です。このドキュメントでは、このメッセージがFAとHAの間に送信されると、FA-HA AEの使用が最終的に必要であり、Mn-Ha AEとMn-Fa AEは必要ありません。これは、「MD」値に基づいて決定できます。モバイルIPv4 RRQおよびRRPメッセージに表示されるこれらの拡張機能のルールについては、[RFC5944]のセクション3.6.1.3および3.8.3.3を参照してください。同じルールがGNMとGNAMに適用されます。
A GNAM is sent by mobility agents or MNs to indicate the successful receipt of a GNM.
GNMのGNAが送信され、GNMの受領が成功することを示すために、MNSが送信されます。
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
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-HAからMNに送信されたメッセージ
1 -- Message sent by the HA to the FA
1-HAからFAに送信されたメッセージ
2 -- Message sent by the MN to the HA
2- MNからHAに送信されたメッセージ
3 -- Message sent by the MN to the FA
3- MNからFAに送信されたメッセージ
4 -- Message sent by the FA to the MN
4- FAからMNに送信されたメッセージ
5 -- Message sent by the FA to the HA
5- FAからHAに送信されたメッセージ
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 67 -- mobile node failed authentication
66-リソース不足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).
GNMとGNAMを一致させ、通知メッセージのリプレイ攻撃から保護するために使用される64ビット番号。この分野でのタイムスタンプとノンセスの使用の詳細については、セクション7.1.1および7.1.2を参照してください。タイムスタンプの使用のサポートが必要であり、Noncesのサポートはオプションです。値は、送信者からのGNMからの識別フィールドと、送信者とその受信機の間のセキュリティコンテキストで使用されるリプレイ保護のスタイルに基づいています（それらの間のモビリティセキュリティアソシエーションとセキュリティパラメーターインデックス（SPI））承認を有する拡張機能の値）。
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].
GNAMの固定部分の後に、このメッセージで使用できる1つ以上の拡張機能が続き、[RFC5944]のセクション3.5で定義されている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とFAの間にこのメッセージが送信される場合、MN-FA AEの使用も必要です。このドキュメントでは、このメッセージがFAとHAの間に送信されると、FA-HA AEの使用が最終的に必要であり、Mn-Ha AEとMn-Fa AEは必要ありません。これは、「MD」値に基づいて決定できます。モバイルIPv4 RRQおよびRRPメッセージに表示されるこれらの拡張機能のルールについては、[RFC5944]のセクション3.6.1.3および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.
GNM中に「A」フラグが設定されているが、送信者が合理的な時間内にGNAMを受け取らない場合、GNMを再送信する必要があります。タイムスタンプを使用すると、再送信ごとに新しい通知識別が選択されます。したがって、それは新しいGNMとしてカウントされます。NONCESを使用すると、未回答のGNMは変更されずに再送信されます。したがって、再送信は新しいGNMとしてカウントされません（セクション7.1）。このようにして、再送信は、ネットワークによって失われた元の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の要求された寿命よりも大きくなければなりません。最小値は、メッセージのサイズを考慮するのに十分な大きさでなければなりません。レシーバーへの送信の往復時間の2倍、および応答する前にメッセージを処理できるように少なくとも100ミリ秒を追加する必要があります。受信機への送信の往復時間は、少なくとも送信者の現在の添付ファイルのリンク速度でメッセージを送信するのに必要な時間と同じくらい大きくなります。一部の回路では、レシーバーへの合計往復時間にさらに200ミリ秒の衛星遅延が追加されます。GNM間の最小時間は1秒以上でなければなりません。連続する各再送信タイムアウト期間は、上記の最大値よりも少ない限り、少なくとも前の期間の少なくとも2倍である必要があります。
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とCo-Located 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」値は0になり、通知メッセージがHAから来たことを示します。
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には、正確に1つの承認を有する拡張機能が存在する必要があります。
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を拒否し、識別を含むCode 195でGNAMをFAに送信する必要があります。セクション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.
この通知メッセージがFAによって中継されたHAから来た場合、またはMNが共同配置COAを使用している場合、MN-HA AEをチェックし、MNは拡張機能の認証因子値をチェックする必要があります。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で指定されたルールに従って計算された識別フィールドを含むコード19で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:
Co-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がFAからMN（ "MD"値が4に設定されている）に開始された場合、セクション3.5.3で定義されている他のすべての非認証拡張機能を保護するために、MN-FA AEは最後の拡張でなければなりません。[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).
MNが通知を拒否する理由はいくつかあります。たとえば、通知を受け取ることが許可されていないなど、多くの理由である可能性があり、コード値193（管理上禁止）でGNAMの返還を引き起こします。または、通知に基づいて行動または表示できない場合、またはリソースが制約されているため、コード値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がHAからMN（ "MD"値が0に設定されている）および共同配置COAの場合に開始された場合、他のすべての非非非非拡張機能が最後の延長でなければなりません。 - [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].
HAからFA-COAを持つMNにGNMに返信する場合、ソースアドレスはMNのホームアドレスであり、宛先アドレスはFAのアドレスです（「MD」値は2に設定されています）。拡張の順序は次のとおりです。HA専用の非認証拡張機能、続いて[RFC5944]のセクション3.5.2で定義されたMN-HA AEが続き、FAを意図した非認証拡張機能が続き、その後に続いて続きます。[RFC5944]のセクション3.5.3で定義されているMN-FA AE。
The MN may send a GNM to notify either the FA or HA.
MNはGNMを送信してFAまたはHAのいずれかに通知する場合があります。
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に設定され、拡張機能の順序は通知拡張です。[RFC5944]のセクション3.5.2で定義されているMN-HA AE、続いてFAを対象とした非認証拡張機能が続き、[RFC5944]のセクション3.5.3で定義されたMN-FA 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に設定されており、拡張の順序は次のとおりです。通知拡張、続いてHAが使用すると予想される非認証拡張、続いて、セクション3.5.2で定義されているMN-HA AEが続きます。[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で使用するリプレイ保護のスタイルに従って識別フィールドを選択します。これは、MNがHAと共有するモビリティセキュリティ協会の一部です。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.
FA-COAの場合、MNがこのメッセージを受信し、「MD」値が0に設定されている場合、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は拡張子の認証因子値を確認する必要があります。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は拡張子の認証因子値をチェックする必要があります。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.
CO-COAの場合、MNがこのメッセージを受け取った場合、MN-HA AEをチェックする必要があり、MNは拡張機能の認証因子値を確認する必要があります。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の間でGNMとGNMSを中継します。
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はFAにメッセージをMNに中継するように求めていることを意味します。「MD」値が1に設定されている場合、通知のターゲットがFAであることを意味します。「MD」値が2に設定されている場合、MNがFAにメッセージをHAに中継するように求めていることを意味します。「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が無効である場合、HA-MN AEとHA-FA AEの間のすべての拡張機能を削除する必要があります。FAは、GNMのホームアドレスフィールドで指定されているように、GNMをMNのホームアドレスに中継する必要があります。また、MNは最終的にMN-HA AEを検証して、MNに送信されるすべての情報が整合性保護されていることを確認します。FA-HA AEが有効な場合、FAはGNMのホームアドレスフィールドで指定されているように、GNMをMNのホームアドレスに中継する必要があります。FAは、MN-HA AEを介してGNMの固定部分から始まるフィールドを変更してはならない、またはMNの認証可能な拡張拡張としてHAが提供する他の認証拡張拡張機能を変更してはなりません。
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は拡張子の認証因子値を確認する必要があります。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の「A」フラグに基づいて、コード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の場合、「MD」値が2に設定されている場合、FAがこのメッセージを受け取った場合、MN-FA AEが存在する場合、MN-FA AEを確認する必要があり、FAは確認する必要があります。拡張機能の認証値を確認してください。MN-FA AEが見つからない場合、または複数のMN-FA AEが見つかった場合、または認証器が無効である場合、FAはGNMを静かに廃棄する必要があります。MN-FAが有効な場合、FAはGNMのホームエージェントアドレスフィールドで指定されているように、GNMをHAのアドレスに中継する必要があります。HAは最終的にMN-HA AEを検証して、HAに送信されるすべての情報が整合性保護されていることを確認します。FAは、HAの承認を有する拡張としてMNが提供するMN-HA AEまたはその他の認証拡張を介して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に関連する独自の非認証拡張のいずれかを追加する必要があります。また、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をチェックする必要があり、FAは[RFC5944]のセクション3.7.2.1で説明されているように、拡張子の認証因子値をチェックする必要があります。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の「A」フラグに基づいて、コード0のGNAMを使用してMNに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への応答としてそれを送信する必要がある場合があります。どちらの場合も、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はGNAMの固定部分から始まり、MN-HA AEまたはMNが提供するMNによって提供されたその他の認証拡張を許可として含めて、フィールドを変更してはなりません。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に設定され、拡張機能の順序は次のとおりです。[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に設定され、拡張機能の順序は次のとおりです。[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専用の認証拡張機能、続いて[RFC5944]のセクション3.5.3で定義されているMN-FA AEが続きます。認証拡張値の計算は、ペイロードが登録ではなく通知であることを除いて、[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のアドレスであり、宛先アドレスはHAのアドレス（「MD」値は5に設定されています）、拡張機能の順序付けは通知拡張です。HA専用の認証拡張機能に続いて、[RFC5944]のセクション3.5.4で定義されているFA-HA AEが続きます。認証拡張値の計算は、ペイロードが登録の代わりに通知であることを除いて、[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-COAの場合、FAがこのメッセージを受信し、「MD」値が2に設定されている場合、通知の確認メッセージは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は拡張子の認証因子値を確認する必要があります。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は拡張機能の認証因子値を確認する必要があります。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の場合、「MD」値が2に設定されている場合、FAがこのメッセージを受け取った場合、MN-FA AEが存在する場合、MN-FA AEを確認する必要があり、FAは確認する必要があります。拡張機能の認証値を確認してください。MN-FA AEが見つからない場合、または複数のMN-FA AEが見つかった場合、または認証器が無効である場合、FAはGNAMを静かに捨てなければなりません。FAがMNのGNAMを受け入れた場合、このメッセージをHAに中継する必要があります。FAは、GNAMの固定部分から始まり、MN-HA AEまたはMNの認可を有する拡張機能としてHAが提供するその他の認証拡張拡張を介して開始することから始まるフィールドのいずれかを変更してはなりません。さらに、FAは、MN-HA AEに続く拡張機能を処理および削除し、該当する場合はHAに関連する独自の非認証拡張のいずれかを追加する必要があります。また、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はGNMを送信してFAに通知するか、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に設定され、拡張の順序は次のとおりです。[RFC5944]のセクション3.5.2で定義されているMN-HA AE、続いてFAを対象とした非認証拡張機能が続き、[RFC5944]のセクション3.5.4で定義されているFA-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に設定され、拡張機能の順序は次のとおりです。[RFC5944]のセクション3.5.4で定義されている-HA AE。認証拡張値の計算は、[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が使用すると予想される非認証拡張、続いてセクション3.5.2で定義されたMN-HA AEが続きます。[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.
FA-COAの場合、HAがこのメッセージを受信し、「MD」値が2に設定されている場合、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は拡張機能の認証因子値を確認する必要があります。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.
FA-COAの場合、「MD」値が2に設定されている場合、FA-HA AEが存在する場合、FA-HA AEをチェックする必要があり、HAは拡張機能の認証因子値をチェックする必要があります。。複数のFA-HA AEが見つかった場合、または認証器が無効である場合、HAはGNAMを静かに捨てなければなりません。何があっても、MN-HA AEをチェックする必要があり、HAは拡張機能の認証因子値をチェックする必要があります。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は拡張機能の認証因子値を確認する必要があります。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は拡張機能の認証因子値を確認する必要があります。FA-HA AEが見つからない場合、または複数のFA-HA AEが見つかった場合、または認証器が無効である場合、HAはGNMを拒否し、識別フィールドを含むコード132でGNAMをFAに送信する必要があります。セクション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-COAの場合、FA-HA AEが存在する場合、チェックする必要があり、HAは拡張機能の認証因子値を確認する必要があります。複数のFA-HA AE拡張機能が見つかった場合、または認証器が無効である場合、HAはGNMを拒否し、セクションで指定されたルールに従って計算された識別フィールドを含むコード132でGNAMをFAに送信することができます。7.1。HAは、このような通知でさらに処理する必要はありませんが、セキュリティ例外としてエラーを記録する必要があります。また、MN-HA AEをチェックする必要があり、HAは拡張機能の認証因子値をチェックする必要があります。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は拡張機能の認証因子値を確認する必要があります。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はまた、GENERIC通知メッセージに存在する拡張機能が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を送信する必要があります。メッセージは次のとおりです。ソースアドレスは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を送信する必要があります。メッセージは次のとおりです。ソースアドレスはHAのアドレス、宛先アドレスはFAのアドレス、「MD」値は0に設定されています。[RFC5944]のセクション3.5.2で定義されたMN-HA AEが続き、オプションでFA用に意図された非認証拡張機能が続き、オプションで[RFC5944]のセクション3.5.3で定義されたMN-FA 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].
このドキュメントでは別のメッセージとしてまだ定義されていなかった場合、このドキュメントで定義されていたこのような使用の1つの例は、登録撤回メッセージ[RFC3543]です。これは、HAからFA（S）またはMNに送信されたメッセージであり、現在アクティブな登録が取り消されていることを受信ノードに通知します。これのユースケースは、[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.
もう1つの例は、メンテナンスのスイッチオーバーを管理することです。HAインスタンスの間で、メンテナンスのために下降するHAは、登録されたMNSに別の指定された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.
最後の例の1つは、ホスト構成の変更を必要とするホームネットワークの変更です。たとえば、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] (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]のセクション1.8を参照してください。この概念は、拡張機能が汎用通知メッセージで使用される場合にも適用されます。受信者がスキップ可能な拡張機能を理解する必要はありませんが、[RFC5944]のセクション1.8（すなわち、メッセージ）に従ってスキップできない拡張機能を処理する必要があります。拡張機能が認識されない場合は、静かに廃棄する必要があります）。このドキュメントでは、この点でモバイル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].
このドキュメントでは、セクション4.1で説明されている一般的な通知メッセージと、セクション4.2で説明されている汎用通知確認メッセージを定義します。これら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で指定されている一般的な通知確認メッセージには、コードフィールドがあります。コードフィールド値の数値スペースは新しく、セクション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
0サクセスコード64-69 FAからのエラーコード128-133 HAからのエラーコード192-197 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が生成されたことを確認するために使用されます。このセクションでは、2つの方法について説明します。タイムスタンプ（必須）と「nonces」（オプション）。すべての送信者と受信者は、タイムスタンプベースのリプレイ保護を実装する必要があります。これらのノードは、NonCeベースのリプレイ保護を実装する場合もあります
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、FA、およびHAの間の任意の2つのピアノード間の有効なリプレイ保護のスタイルは、モバイルセキュリティ協会の一部です。送信ノードとその受信ノードは、どのリプレイ保護方法が使用されるかに同意する必要があります。識別フィールドの解釈は、後続のサブセクションで説明されているように、リプレイ保護の方法に依存します。
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ビットをGNMからGNAMに変更せずにコピーする必要があります。受信者は、これらのビット（および送信者のソースアドレス）を使用して、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.
NonCe Replay Protectionの基本原則は、ノードAにノードBへのすべてのメッセージに新しい乱数が含まれ、ノードBが次のメッセージでその次のメッセージをノードAに返すことをチェックすることです。両方のメッセージは、変更から保護するために認証コードを使用します攻撃者によって。同時に、ノードBはすべてのメッセージで独自のノンセを送信して、ノード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]によると、受信機は、Noncesとして役立つ擬似ランダム数を計算するためのリソースがあると予想される場合があります。すべてのGNAMの識別フィールドの高次の32ビットとして、新しいNonceを挿入します。受信機は、GNMからGNAMの識別フィールドの低次の32ビットの識別フィールドの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.
無効なNonCEのためにGNMが拒否された場合、GNAMは常に次のメッセージで使用される新しいNonCEを送信者に提供します。したがって、NonCeプロトコルは自己同期です。
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.
著者は、この文書のテキストに対する彼の詳細なレビューと彼の多くの貢献に対するアフマド・ムハンナの努力に感謝しています。著者はまた、ケント・レオン、ペン・ヤン、ピーター・マッキャンなどに感謝したいと考えています。Alexey Melnikov、Sean Turner、Ralph Droms、Charles E. Perkins、Russ Housley、Magnus Westerlund、Lars Eggert、Dan Romascanu、Tim Polk、Amanda Baber、Sebastian Thalanany、およびJoseph Saloweyの議論とコメントに感謝します。このドキュメントの開発の各ステップで助けてくれたJari Arkkoに感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3543] Glass, S. and M. Chandra, "Registration Revocation in Mobile IPv4", RFC 3543, August 2003.
[RFC3543] Glass、S。およびM. Chandra、「モバイルIPv4の登録取り消し」、RFC 3543、2003年8月。
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086] Eastlake、D.、Schiller、J。、およびS. Crocker、「セキュリティのランダム性要件」、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.、Leung、K。、およびA. Patel、「モバイル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] Mills、D.、Martin、J.、Burbank、J。、およびW. Kasch、「ネットワーク時間プロトコルバージョン4：プロトコルとアルゴリズムの仕様」、RFC 5905、2010年6月。
[RFC5944] Perkins, C., "IP Mobility Support for IPv4, Revised", RFC 5944, November 2010.
[RFC5944] Perkins、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] Leung、K.、Dommety、G.、Narayanan、V.、およびA. Petrescu、「Mobile 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
Hui Deng China Mobile 53a、Xibianmennei Ave.、Xuanwu District、Beijing 100053 China
EMail: denghui02@gmail.com
Henrik Levkowetz Netnod Franzengatan 5 S-104 25, Stockholm SWEDEN
Henrik Levkowetz Netnod Franzengatan 5 S-104 25、ストックホルムスウェーデン
EMail: henrik@levkowetz.com
Vijay Devarapalli Vasona Networks 2900 Lakeside Drive Santa Clara, CA 95054 USA
Vijay Devarapalli Vasona Networks 2900 Lakeside Drive Santa Clara、CA 95054 USA
EMail: dvijay@gmail.com
Sri Gundavelli Cisco 170 W.Tasman Drive San Jose, CA 95134 USA
Sri Gundavelli Cisco 170 W.Tasman Drive San Jose、CA 95134 USA
EMail: sgundave@cisco.com
Brian Haley Hewlett-Packard Company 165 Dascomb Road Andover, MA 01810 USA
ブライアンヘイリーヒューレットパッカードカンパニー165ダスコムロードアンドーバー、マサチューセッツ州01810 USA
EMail: brian.haley@hp.com