[要約] RFC 7077は、Proxy Mobile IPv6（PMIPv6）の更新通知に関する仕様であり、モバイルノードのIPアドレスの変更を通知するためのメカニズムを提供します。このRFCの目的は、モバイルノードのIPアドレスの変更を効率的に通知し、ネットワークのパフォーマンスを向上させることです。
Internet Engineering Task Force (IETF) S. Krishnan
Request for Comments: 7077 Ericsson
Category: Standards Track S. Gundavelli
ISSN: 2070-1721 Cisco
M. Liebsch
NEC
H. Yokota
KDDI
J. Korhonen
Broadcom
November 2013
Update Notifications for Proxy Mobile IPv6
プロキシモバイルIPv6の更新通知
Abstract
概要
This document specifies protocol enhancements for allowing the local mobility anchor in a Proxy Mobile IPv6 domain to asynchronously notify the mobile access gateway about changes related to a mobility session. These Update Notification messages are exchanged using a new Mobility Header message type specifically designed for this purpose.
このドキュメントでは、プロキシモバイルIPv6ドメインのローカルモビリティアンカーがモビリティセッションに関連する変更についてモバイルアクセスゲートウェイに非同期に通知できるようにするためのプロトコル拡張を指定します。これらの更新通知メッセージは、この目的のために特別に設計された新しいモビリティヘッダーメッセージタイプを使用して交換されます。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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/rfc7077.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7077で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 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文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
2. Conventions and Terminology .....................................4
2.1. Conventions ................................................4
2.2. Terminology ................................................4
3. Notification Message - Usage Examples ...........................4
4. Message Formats .................................................5
4.1. Update Notification (UPN) ..................................5
4.2. Update Notification Acknowledgement (UPA) ..................7
5. LMA Considerations ..............................................9
5.1. Constructing the Update Notification Message ..............10
5.2. Receiving the Update Notification Acknowledgement
Message ...................................................11
6. MAG Considerations .............................................12
6.1. Receiving the Update Notification Message .................12
6.2. Constructing the Update Notification Acknowledgement
Message ...................................................15
7. Protocol Configuration Variables ...............................16
8. Security Considerations ........................................16
9. Acknowledgements ...............................................17
10. IANA Considerations ...........................................17
11. References ....................................................19
11.1. Normative References .....................................19
11.2. Informative References ...................................19
In some situations, there is a need for the local mobility anchor (LMA) to send asynchronous notification messages to the mobile access gateway (MAG) in the course of a mobility session. These situations include changes to mobility session parameters and policy parameters. In this context, "Asynchronous messages" is used to mean messages that are not synchronous with the Proxy Binding Update and Proxy Binding Acknowledgement messages of the base Proxy Mobile IPv6 specification [RFC5213]. The base Proxy Mobile IPv6 specification does not have a provision for sending unsolicited Update Notification messages from the local mobility anchor to the mobile access gateway.
状況によっては、ローカルモビリティアンカー（LMA）がモビリティセッションの途中でモバイルアクセスゲートウェイ（MAG）に非同期通知メッセージを送信する必要があります。これらの状況には、モビリティセッションパラメータとポリシーパラメータの変更が含まれます。この文脈では、「非同期メッセージ」は、基本のProxy Mobile IPv6仕様[RFC5213]のProxy Binding UpdateおよびProxy Binding Acknowledgementメッセージと同期していないメッセージを意味するために使用されます。ベースプロキシモバイルIPv6仕様には、ローカルモビリティアンカーからモバイルアクセスゲートウェイに非送信請求更新通知メッセージを送信するための規定がありません。
Proxy Mobile IPv6 [RFC5213] is a network-based mobility management protocol. It is designed to provide IP mobility management support to a mobile node without requiring the participation of the mobile node in any IP mobility-related signaling. The protocol defines two mobility management entities: the LMA and the MAG. These entities are responsible for managing IP mobility management support for a mobile node in a Proxy Mobile IPv6 domain. The setup of the mobility session is initiated by the mobile access gateway by sending a Proxy Binding Update message and acknowledged by the local mobility anchor in the Proxy Binding Acknowledgement message. Once the mobility session is set up, currently there is no mechanism for the local mobility anchor to inform the mobile access gateway about changes to the mobility session or any parameters related to the mobility session. However, there are mechanisms in the Proxy Mobile IPv6 protocol that allow a local mobility anchor to send signaling messages to the mobile access gateway asynchronously, as defined in the Proxy Mobile IPv6 Heartbeat message [RFC5847] or in the Binding Revocation message [RFC5846], but these signaling messages are designed for a very specific purpose and are not sufficient for supporting a notification framework.
プロキシモバイルIPv6 [RFC5213]は、ネットワークベースのモビリティ管理プロトコルです。 IPモビリティ関連のシグナリングへのモバイルノードの参加を必要とせずに、モバイルノードにIPモビリティ管理サポートを提供するように設計されています。プロトコルは、LMAとMAGの2つのモビリティ管理エンティティを定義します。これらのエンティティは、プロキシモバイルIPv6ドメイン内のモバイルノードのIPモビリティ管理サポートの管理を担当します。モビリティセッションのセットアップは、モバイルアクセスゲートウェイによってプロキシバインディング更新メッセージを送信することによって開始され、ローカルモビリティアンカーによってプロキシバインディング確認メッセージで確認されます。モビリティセッションがセットアップされると、現在、ローカルモビリティアンカーがモビリティセッションへの変更またはモビリティセッションに関連するパラメータについてモバイルアクセスゲートウェイに通知するメカニズムはありません。ただし、プロキシモバイルIPv6プロトコルには、プロキシモバイルIPv6ハートビートメッセージ[RFC5847]またはバインディング失効メッセージ[RFC5846]で定義されているように、ローカルモビリティアンカーがモバイルアクセスゲートウェイに非同期でシグナリングメッセージを送信できるメカニズムがあります。しかし、これらのシグナリングメッセージは非常に特定の目的のために設計されており、通知フレームワークをサポートするには不十分です。
One such scenario where such a mechanism is needed is when the local mobility anchor wants to inform the mobile access gateway that it needs to re-register the mobility session for a mobile node. It is possible to achieve a similar effect by using a short lifetime for the mobility sessions, but in several networks this results in an unacceptable, and mostly unnecessary, increase in the signaling load and overhead. A more suitable scenario would be to enable demand-based signaling from the local mobility anchor to one or more mobile access gateways. Another example is when there is a change in a QoS policy [PMIPv6-QoS], an IP flow mobility policy [PMIPv6-FLOW-MOB], or an IPv4 traffic offload policy [RFC6909] for a mobility session. In this case, the local mobility anchor wants to request that the mobile access gateway perform re-registration of the mobility session in order to update the policies associated with the mobility session of a mobile node.
このようなメカニズムが必要なシナリオの1つは、ローカルモビリティアンカーがモバイルアクセスゲートウェイにモバイルノードのモビリティセッションを再登録する必要があることを通知する場合です。モビリティセッションに短いライフタイムを使用することで同様の効果を達成することは可能ですが、いくつかのネットワークでは、これにより信号負荷とオーバーヘッドが許容できないほど増加し、ほとんど不要になります。より適切なシナリオは、ローカルモビリティアンカーから1つ以上のモバイルアクセスゲートウェイへのデマンドベースのシグナリングを有効にすることです。別の例は、モビリティセッションのQoSポリシー[PMIPv6-QoS]、IPフローモビリティポリシー[PMIPv6-FLOW-MOB]、またはIPv4トラフィックオフロードポリシー[RFC6909]に変更がある場合です。この場合、ローカルモビリティアンカーは、モバイルノードのモビリティセッションに関連付けられているポリシーを更新するために、モバイルアクセスゲートウェイがモビリティセッションの再登録を実行することを要求します。
This document defines a new Mobility Header message for allowing the local mobility anchor to send notification messages to the mobile access gateway and a corresponding Mobility Header message for the mobile access gateway to acknowledge the notification message. The purpose of the notification message is twofold: (1) to enable the local mobility anchor to notify the mobile access gateway about the updated session parameters and (2) to enable the local mobility anchor to request that the mobile access gateway renegotiate the session parameters.
このドキュメントでは、ローカルモビリティアンカーがモバイルアクセスゲートウェイに通知メッセージを送信できるようにする新しいモビリティヘッダーメッセージと、モバイルアクセスゲートウェイが通知メッセージを確認するための対応するモビリティヘッダーメッセージを定義します。通知メッセージの目的は2つあります。（1）ローカルモビリティアンカーが更新されたセッションパラメータについてモバイルアクセスゲートウェイに通知できるようにすること、および（2）ローカルモビリティアンカーがモバイルアクセスゲートウェイにセッションパラメータの再ネゴシエーションを要求できるようにすることです。 。
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]で説明されているように解釈されます。
All the mobility-related terms used in this document are to be interpreted as defined in the base Proxy Mobile IPv6 specifications [RFC5213] and [RFC5844].
このドキュメントで使用されているすべてのモビリティ関連の用語は、ベースプロキシモバイルIPv6仕様[RFC5213]および[RFC5844]で定義されているとおりに解釈されます。
Use Case 1: Consider a use case where the local mobility anchor wants the mobile access gateway to re-register a specific mobility session.
ユースケース1：ローカルモビリティアンカーがモバイルアクセスゲートウェイに特定のモビリティセッションの再登録を要求するユースケースを検討してください。
MN MAG LMA
|------>| | 1. Mobile Node Attach
| |------->| 2. Proxy Binding Update
| |<-------| 3. Proxy Binding Acknowledgement
| |========| 4. Tunnel/Route Setup
| | |
| |<-------| 5. Update Notification (FORCE-REREGISTRATION)
| |------->| 6. Update Notification Acknowledgement
| | |
| |------->| 7. Proxy Binding Update
| |<-------| 8. Proxy Binding Acknowledgement
| | |
Figure 1: Update Notification: FORCE-REREGISTRATION
図1：更新の通知：FORCE-REREGISTRATION
Use Case 2: Consider a use case where the local mobility anchor wants to notify the mobile access gateway of the updated session parameters, for example, an updated QoS profile or an updated IPv4 offload policy.
ユースケース2：ローカルモビリティアンカーが、モバイルアクセスゲートウェイに更新されたセッションパラメーター（たとえば、更新されたQoSプロファイルや更新されたIPv4オフロードポリシー）を通知することを望むユースケースを検討してください。
MN MAG LMA
|------>| | 1. Mobile Node Attach
| |------->| 2. Proxy Binding Update
| |<-------| 3. Proxy Binding Acknowledgement
| |========| 4. Tunnel/Route Setup
| | |
| |<-------| 5. Update Notification
| | | (UPDATE-SESSION-PARAMETERS)
| |------->| 6. Update Notification Acknowledgement
| + | 7. MAG applies the new policy option
| | |
Figure 2: Update Notification: UPDATE-SESSION-PARAMETERS
図2：更新通知：UPDATE-SESSION-PARAMETERS
The Update Notification is a Mobility Header message that has an MH Type value of 19. It is used by the local mobility anchor to notify the mobile access gateway that some parameters related to the mobility session have changed.
更新通知は、MHタイプ値が19のモビリティヘッダーメッセージです。これは、ローカルモビリティアンカーによって、モビリティセッションに関連する一部のパラメーターが変更されたことをモバイルアクセスゲートウェイに通知するために使用されます。
The format of the Update Notification message is as follows:
更新通知メッセージの形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Notification Reason |A|D| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Update Notification Message
図3：更新通知メッセージ
Sequence Number This 16-bit unsigned integer is used by the local mobility anchor to match the received Update Notification Acknowledgement message with this Update Notification message. This Sequence Number could be a random number and can be managed under the same variable used in Proxy Mobile IPv6 signaling messages [RFC5213]. Implementations MUST ensure that there is no collision between the Sequence Numbers of all outstanding Update Notification messages at any time.
シーケンス番号この16ビットの符号なし整数は、ローカルのモビリティアンカーによって使用され、受信した更新通知確認メッセージをこの更新通知メッセージと照合します。このシーケンス番号は乱数である可能性があり、プロキシモバイルIPv6シグナリングメッセージ[RFC5213]で使用されているのと同じ変数で管理できます。実装は、未処理のすべての更新通知メッセージのシーケンス番号が常に衝突しないようにする必要があります。
Notification Reason This 16-bit unsigned integer indicates the Notification Reason code. This code corresponds to the reason that the local mobility anchor sent the Update Notification to the mobile access gateway. This field does not contain any structure and MUST be treated as an enumeration. The reason code can indicate a vendor-specific reason if the semantics of the Update Notification message are to be based on the attached vendor-specific options, not solely from the reason code. These attached options can be deployment specific and are not specified in this document. The following Notification Reason values are currently defined:
通知理由この16ビットの符号なし整数は、通知理由コードを示します。このコードは、ローカルモビリティアンカーがモバイルアクセスゲートウェイに更新通知を送信した理由に対応しています。このフィールドには構造が含まれておらず、列挙型として扱う必要があります。理由コードは、更新通知メッセージのセマンティクスが理由コードだけからではなく、添付されたベンダー固有のオプションに基づく場合、ベンダー固有の理由を示すことができます。これらの添付オプションは展開固有であり、このドキュメントでは指定されていません。現在、次の通知理由値が定義されています。
(0) - Reserved This value is currently reserved and cannot be used.
（0）-予約済みこの値は現在予約されており、使用できません。
(1) - FORCE-REREGISTRATION Request to re-register the session by sending a Proxy Binding Update for the mobility session.
（1）-FORCE-REREGISTRATIONモビリティセッションのプロキシバインディングアップデートを送信することにより、セッションを再登録する要求。
(2) - UPDATE-SESSION-PARAMETERS Request to apply the updated session parameters obtained from the message on the mobility session.
（2）-UPDATE-SESSION-PARAMETERSメッセージから取得した更新されたセッションパラメータをモビリティセッションに適用する要求。
(3) - VENDOR-SPECIFIC-REASON This Notification Reason is for vendor-specific use. The processing rules are to be based on the Vendor-Specific Mobility option(s) [RFC5094] present in the message.
（3）-ベンダー固有の理由この通知理由はベンダー固有の使用のためのものです。処理ルールは、メッセージに含まれるベンダー固有のモビリティオプション[RFC5094]に基づいています。
(4) - ANI-PARAMS-REQUESTED Request to send currently known Access Network Identifier (ANI) [RFC6757] parameters for the mobility session.
（4）-ANI-PARAMS-REQUESTEDモビリティセッションの現在既知のAccess Network Identifier（ANI）[RFC6757]パラメータを送信するための要求。
(255) - Reserved This value is currently reserved and cannot be used.
（255）-予約済みこの値は現在予約されており、使用できません。
Acknowledgement Requested Flag ((A) Flag) When this flag is set to a value of (1), it is an indication that the local mobility anchor is requesting that the mobile access gateway send an Update Notification Acknowledgement message. When this flag is set to a value of (0), it is an indication that the local mobility anchor is not requesting any Update Notification Acknowledgement messages.
確認要求フラグ（（A）フラグ）このフラグが（1）の値に設定されている場合、ローカルモビリティアンカーがモバイルアクセスゲートウェイが更新通知確認メッセージを送信することを要求していることを示します。このフラグが値（0）に設定されている場合、ローカルモビリティアンカーが更新通知確認メッセージを要求していないことを示しています。
Retransmit Flag ((D) Flag) When this flag is set to a value of (1), it is an indication that the message is a retransmitted message and has the same Sequence Number and other message contents as in the previously sent message. The (D) flag is set for retransmitted request messages, to aid the reliable detection of duplicate requests at the receiver of the request message. It is set when originating requests that have not yet been acknowledged, as an indication of a possible duplicate due to a retransmission. This flag MUST be cleared when sending a request for the first time for a given Sequence Number; otherwise, the sender MUST set this flag.
再送信フラグ（（D）フラグ）このフラグが（1）の値に設定されている場合、メッセージが再送信されたメッセージであり、以前に送信されたメッセージと同じシーケンス番号とその他のメッセージの内容を持っていることを示します。 （D）フラグは、再送された要求メッセージに対して設定され、要求メッセージの受信側で重複要求を確実に検出できるようにします。これは、まだ確認されていない要求を発信するときに、再送信による重複の可能性を示すために設定されます。このフラグは、所定のシーケンス番号で初めてリクエストを送信するときにクリアする必要があります。それ以外の場合、送信者はこのフラグを設定する必要があります。
Reserved This field is unused for now. The value MUST be initialized to 0 by the sender and MUST be ignored by the receiver.
予約済みこのフィールドは現在使用されていません。値は送信者によって0に初期化されなければならず（MUST）、受信者によって無視されなければなりません（MUST）。
Mobility Options This variable-length field is of such length that the complete Mobility Header is an integer multiple of 8 octets long; the Pad1 and PadN options [RFC6275] can be used for padding. This field contains zero or more TLV-encoded mobility options. Any of the Mobility Header options, including Vendor-Specific Mobility options [RFC5094], can be included here. The receiver MUST ignore and skip any options that it does not understand. These mobility options are used by the mobile access gateway to identify the specific binding for which the Update Notification message is sent.
モビリティオプションこの可変長フィールドは、完全なモビリティヘッダーが8オクテットの整数倍になるような長さです。 Pad1およびPadNオプション[RFC6275]をパディングに使用できます。このフィールドには、ゼロ個以上のTLVエンコードモビリティオプションが含まれます。ベンダー固有のモビリティオプション[RFC5094]を含む、任意のモビリティヘッダーオプションをここに含めることができます。レシーバーは、理解できないオプションを無視してスキップする必要があります。モバイルアクセスゲートウェイはこれらのモビリティオプションを使用して、更新通知メッセージが送信される特定のバインディングを識別します。
The Update Notification Acknowledgement is a Mobility Header message that has an MH Type value of 20. The mobile access gateway sends this message in order to acknowledge that it has received an Update Notification message with the (A) flag set and to indicate the status after processing the message.
更新通知の確認応答は、20のMHタイプ値を持つモビリティヘッダーメッセージです。モバイルアクセスゲートウェイは、（A）フラグが設定された更新通知メッセージを受信したことを確認し、その後のステータスを示すために、このメッセージを送信します。メッセージを処理します。
The format of the Update Notification Acknowledgement message is as follows:
更新通知の確認メッセージの形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Code | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Update Notification Acknowledgement Message
図4：更新通知の確認メッセージ
Sequence Number This 16-bit unsigned integer is copied from the Update Notification message and is used for matching the Update Notification Acknowledgement message with the Update Notification message.
シーケンス番号この16ビットの符号なし整数は、更新通知メッセージからコピーされ、更新通知確認メッセージと更新通知メッセージを照合するために使用されます。
Status Code This 8-bit unsigned integer indicates the status code and specifies the result of the processing of the Update Notification message. Status codes between 0 and 127 signify successful processing of the Update Notification message, and codes between 128 and 255 signify that an error occurred during processing of the Update Notification message. The following status code values are currently defined:
ステータスコードこの8ビットの符号なし整数は、ステータスコードを示し、更新通知メッセージの処理結果を示します。 0〜127のステータスコードは、更新通知メッセージの処理が成功したことを示し、128〜255のコードは、更新通知メッセージの処理中にエラーが発生したことを示します。現在、次のステータスコード値が定義されています。
(0) - SUCCESS The mobile access gateway successfully processed the received Update Notification message.
（0）-SUCCESSモバイルアクセスゲートウェイは、受信した更新通知メッセージを正常に処理しました。
(128) - FAILED-TO-UPDATE-SESSION-PARAMETERS The mobile access gateway was not able to apply the session parameters sent by the local mobility anchor in the Update Notification message.
（128）-FAILED-TO-UPDATE-SESSION-PARAMETERSモバイルアクセスゲートウェイは、ローカルモビリティアンカーによって送信されたセッションパラメータを更新通知メッセージに適用できませんでした。
(129) - MISSING-VENDOR-SPECIFIC-OPTION The received Update Notification message does not have the required Vendor-Specific Mobility option(s) needed for handling the message.
（129）-MISSING-VENDOR-SPECIFIC-OPTION受信した更新通知メッセージには、メッセージの処理に必要なベンダー固有のモビリティオプションがありません。
Reserved This field is unused for now. The value MUST be initialized to 0 by the sender and MUST be ignored by the receiver.
予約済みこのフィールドは現在使用されていません。値は送信者によって0に初期化されなければならず（MUST）、受信者によって無視されなければなりません（MUST）。
Mobility Options This variable-length field is of such length that the complete Mobility Header is an integer multiple of 8 octets long; the Pad1 and PadN options [RFC6275] can be used for padding. This field contains zero or more TLV-encoded mobility options. Any of the Mobility Header options, including Vendor-Specific Mobility options [RFC5094], can be included here. The receiver MUST ignore and skip any options that it does not understand. These mobility options are used by the mobile access gateway to identify the specific binding for which the Update Notification Acknowledgement message is sent.
モビリティオプションこの可変長フィールドは、完全なモビリティヘッダーが8オクテットの整数倍になるような長さです。 Pad1およびPadNオプション[RFC6275]をパディングに使用できます。このフィールドには、ゼロ個以上のTLVエンコードモビリティオプションが含まれます。ベンダー固有のモビリティオプション[RFC5094]を含む、任意のモビリティヘッダーオプションをここに含めることができます。レシーバーは、理解できないオプションを無視してスキップする必要があります。これらのモビリティオプションは、モバイルアクセスゲートウェイによって使用され、更新通知確認メッセージが送信される特定のバインディングを識別します。
o The local mobility anchor sends the Update Notification message in response to a condition that is specified in the Notification Reason field. The Notification Reason field in the Update Notification message MUST be set to a specific value that identifies the reason for which the Update Notification message is being sent. The Notification Reason, based on the chosen value, may require a specific action that the mobile access gateway needs to perform (for example, requiring re-registration of a mobility session).
o ローカルモビリティアンカーは、[通知理由]フィールドで指定された条件に応答して、更新通知メッセージを送信します。更新通知メッセージの通知理由フィールドは、更新通知メッセージが送信されている理由を識別する特定の値に設定する必要があります。選択した値に基づく通知理由には、モバイルアクセスゲートウェイが実行する必要がある特定のアクションが必要な場合があります（たとえば、モビリティセッションの再登録が必要です）。
o The Update Notification message MUST include either the Mobile Node Identifier option [RFC4283] or the Mobile Node Group Identifier option [RFC6602].
o 更新通知メッセージには、モバイルノード識別子オプション[RFC4283]またはモバイルノードグループ識別子オプション[RFC6602]のいずれかを含める必要があります。
* If the Mobile Node Identifier option is present, it indicates that the Update Notification message is sent for that specific mobility session.
* モバイルノード識別子オプションが存在する場合、その特定のモビリティセッションに対して更新通知メッセージが送信されていることを示します。
* If the Mobile Node Group Identifier option is present, it indicates that the Update Notification message is sent for the set of mobility sessions identified by the Group Identifier. The Group Identifier is negotiated as part of the initial Proxy Mobile IPv6 signaling. If the Group Identifier is not negotiated in the initial Proxy Mobile IPv6 signaling, a value of (1) for the Group Identifier can always be used. The Group Identifier value of (1) identifies all the mobility sessions established between that local mobility anchor and the mobile access gateway.
* モバイルノードグループ識別子オプションが存在する場合、それは、グループ識別子によって識別されるモビリティセッションのセットに対して更新通知メッセージが送信されることを示します。グループ識別子は、初期のプロキシモバイルIPv6シグナリングの一部としてネゴシエートされます。最初のプロキシモバイルIPv6シグナリングでグループ識別子がネゴシエートされない場合、グループ識別子の値（1）は常に使用できます。グループ識別子の値（1）は、そのローカルモビリティアンカーとモバイルアクセスゲートウェイの間に確立されたすべてのモビリティセッションを識別します。
o The Update Notification message MAY contain a modified session parameter in the form of a mobility option (e.g., an IPv4 traffic offload option or a QoS option), so the mobile access gateway can apply them on the identified mobility session.
o 更新通知メッセージには、モビリティオプション（IPv4トラフィックオフロードオプションやQoSオプションなど）の形式で変更されたセッションパラメータが含まれている場合があります。そのため、モバイルアクセスゲートウェイは、識別されたモビリティセッションにそれらを適用できます。
The local mobility anchor, when sending the Update Notification message to the mobile access gateway, has to construct the message as specified below:
ローカルモビリティアンカーは、更新通知メッセージをモバイルアクセスゲートウェイに送信するときに、次のようにメッセージを作成する必要があります。
o For requesting an Acknowledgement message and an indication about the result of processing the message from the mobile access gateway for the Update Notification message, the (A) flag in the Update Notification message MUST be set to a value of (1); otherwise, it MUST be set to a value of (0). However, if the Notification Reason is set to a value of (1) "FORCE-REREGISTRATION" or (4) "ANI-PARAMS-REQUESTED", then it is RECOMMENDED that the (A) flag be set to a value of (0). For certain general notifications that are informational in nature, the local mobility anchor may choose not to request acknowledgement for the Update Notification message.
o 承認メッセージと、モバイルアクセスゲートウェイからのメッセージを更新通知メッセージに対して処理した結果に関する指示を要求するには、更新通知メッセージの（A）フラグを（1）の値に設定する必要があります。それ以外の場合は、値（0）に設定する必要があります。ただし、通知理由が（1） "FORCE-REREGISTRATION"または（4） "ANI-PARAMS-REQUESTED"の値に設定されている場合は、（A）フラグに（0）の値を設定することをお勧めします。 ）。本質的に情報である特定の一般的な通知の場合、ローカルモビリティアンカーは、更新通知メッセージの確認応答を要求しないことを選択できます。
o The Sequence Number field of the message MUST be initialized to a random number and increased monotonically for subsequent messages. Once the Sequence Number hits the maximum value, it should be wrapped around to 0. Furthermore, if the message is a retransmission of a previously sent message, then the Sequence Number value is not changed.
o メッセージのシーケンス番号フィールドは、乱数に初期化され、その後のメッセージのために単調に増加しなければなりません（MUST）。シーケンス番号が最大値に達すると、0にラップされるはずです。さらに、メッセージが以前に送信されたメッセージの再送信である場合、シーケンス番号の値は変更されません。
o When using IPv4 transport, the source address in the IPv4 header MUST be set to the local mobility anchor's IPv4 address (IPv4-LMAA), and the destination address in the IPv4 header MUST be set to the IPv4-Proxy-CoA (Care-of Address) of the mobile access gateway. The Mobility Header (without the IPv6 header) containing the Update Notification message is encapsulated in a UDP header with the destination port of 5436 [RFC5844]. If IPsec Encapsulating Security Payload (ESP) [RFC4303] is used to protect signaling, the packet is processed using transport mode ESP.
o IPv4トランスポートを使用する場合、IPv4ヘッダーのソースアドレスはローカルモビリティアンカーのIPv4アドレス（IPv4-LMAA）に設定する必要があり、IPv4ヘッダーの宛先アドレスはIPv4-Proxy-CoA（Care-of）に設定する必要がありますアドレス）モバイルアクセスゲートウェイの。更新通知メッセージを含むモビリティヘッダー（IPv6ヘッダーなし）は、宛先ポートが5436 [RFC5844]のUDPヘッダーにカプセル化されます。 IPsecカプセル化セキュリティペイロード（ESP）[RFC4303]を使用してシグナリングを保護する場合、パケットはトランスポートモードESPを使用して処理されます。
o The format of the Update Notification message sent over IPv4 and protected using ESP is shown below:
o IPv4を介して送信され、ESPを使用して保護された更新通知メッセージの形式を以下に示します。
IPv4 header (src=IPv4-LMAA, dst=IPv4-Proxy-CoA) ESP header (in transport mode) UDP header (sport=5436, dport=5436) Mobility Header (Update Notification) (one or more Mobility Header options)
IPv4ヘッダー（src = IPv4-LMAA、dst = IPv4-Proxy-CoA）ESPヘッダー（トランスポートモード）UDPヘッダー（sport = 5436、dport = 5436）モビリティヘッダー（更新通知）（1つ以上のモビリティヘッダーオプション）
o When using IPv6 transport, the source address in the IPv6 header MUST be set to the local mobility anchor's IPv6 address (LMAA). The destination address in the IPv6 header MUST be set to the Proxy-CoA of the mobile access gateway. The Mobility Header is part of the IPv6 headers.
o IPv6トランスポートを使用する場合、IPv6ヘッダーのソースアドレスをローカルモビリティアンカーのIPv6アドレス（LMAA）に設定する必要があります。 IPv6ヘッダーの宛先アドレスは、モバイルアクセスゲートウェイのProxy-CoAに設定する必要があります。モビリティヘッダーは、IPv6ヘッダーの一部です。
o The format of the Update Notification message sent over IPv6 and protected using ESP is shown below:
o IPv6を介して送信され、ESPを使用して保護された更新通知メッセージの形式を以下に示します。
IPv6 header (src=LMAA, dst=Proxy-CoA) Mobility Header (Update Notification) ESP header (in transport mode) (one or more Mobility Header options)
IPv6ヘッダー（src = LMAA、dst = Proxy-CoA）モビリティヘッダー（更新通知）ESPヘッダー（トランスポートモード）（1つ以上のモビリティヘッダーオプション）
o If the local mobility anchor does not receive an Update Notification Acknowledgement message from the mobile access gateway for the Update Notification message with the (A) flag set, then the local mobility anchor MUST retransmit the message. The related considerations are as follows:
o ローカルモビリティアンカーが（A）フラグが設定された更新通知メッセージのモバイルアクセスゲートウェイから更新通知確認メッセージを受信しない場合、ローカルモビリティアンカーはメッセージを再送信する必要があります。関連する考慮事項は次のとおりです。
* When retransmitting an Update Notification message, the Sequence Number value and other message contents MUST be the same as in the original message. The (D) flag in the message MUST be set to a value of (1).
* 更新通知メッセージを再送信する場合、シーケンス番号の値と他のメッセージの内容は、元のメッセージと同じである必要があります。メッセージの（D）フラグは、（1）の値に設定する必要があります。
* There MUST be a minimum delay of MIN_DELAY_BETWEEN_UPDATE_NOTIFICATION_REPLAY (Section 7), with a default value of 1000 milliseconds, between two retransmit messages.
* 2つの再送信メッセージ間には、MIN_DELAY_BETWEEN_UPDATE_NOTIFICATION_REPLAY（セクション7）の最小遅延があり、デフォルト値は1000ミリ秒です。
* The message MUST be retransmitted up to the number of times defined by the configuration variable MAX_UPDATE_NOTIFICATION_RETRANSMIT_COUNT (Section 7), with a default value of (1). If there is no Update Notification Acknowledgement message after the retransmission count reaches the value defined by the configuration variable MAX_UPDATE_NOTIFICATION_RETRANSMIT_COUNT, then the message MUST be discarded, and the event SHOULD be logged.
* メッセージは、構成変数MAX_UPDATE_NOTIFICATION_RETRANSMIT_COUNT（セクション7）で定義された回数まで、デフォルト値（1）で再送信する必要があります。再送信カウントが構成変数MAX_UPDATE_NOTIFICATION_RETRANSMIT_COUNTで定義された値に達した後、更新通知確認メッセージがない場合、メッセージを破棄する必要があり、イベントを記録する必要があります（SHOULD）。
o If the local mobility anchor receives a Binding Error message with the Status field set to 2 as described in [RFC6275], this indicates that the mobile access gateway does not support the Update Notification message, and hence the local mobility anchor MUST NOT send any further Update Notification messages to that mobile access gateway unless an administrative action is taken.
o [RFC6275]で説明されているように、ローカルモビリティアンカーがステータスフィールドが2に設定されたバインディングエラーメッセージを受信した場合、モバイルアクセスゲートウェイが更新通知メッセージをサポートしていないため、ローカルモビリティアンカーはこれ以上送信してはならない管理アクションが実行されない限り、そのモバイルアクセスゲートウェイへの通知メッセージを更新します。
o When receiving an Update Notification Acknowledgement message, the local mobility anchor MUST verify the Mobility Header as described in Section 9.2 of [RFC6275]. If the packet is dropped due to failure of any of the Mobility Header test checks, the local mobility anchor MUST follow the processing rules as described in Section 9.2 of [RFC6275].
o [RFC6275]のセクション9.2で説明されているように、ローカルモビリティアンカーは、更新通知確認メッセージを受信すると、モビリティヘッダーを検証する必要があります。モビリティヘッダーテストチェックのいずれかが失敗したためにパケットがドロップされた場合、ローカルモビリティアンカーは、[RFC6275]のセクション9.2で説明されている処理ルールに従う必要があります。
o Upon receiving the Update Notification Acknowledgement message, the local mobility anchor MUST verify that the received message is protected by the security association that is being used to protect the other signaling messages between those two peers. For example, if the Proxy Binding Update and Proxy Binding Acknowledgement messages are protected using an IPsec security association [RFC4301], then the Update Notification Acknowledgement message MUST have the IPsec protection with the currently established IPsec security association that is being used for protecting the other Proxy Mobile IPv6 signaling messages.
o 更新通知確認メッセージを受信すると、ローカルモビリティアンカーは、受信したメッセージが、これら2つのピア間の他のシグナリングメッセージを保護するために使用されているセキュリティアソシエーションによって保護されていることを確認する必要があります。たとえば、Proxy Binding UpdateおよびProxy Binding AcknowledgmentメッセージがIPsecセキュリティアソシエーション[RFC4301]を使用して保護されている場合、Update Notification Acknowledgmentメッセージには、他の保護に使用されている現在確立されているIPsecセキュリティアソシエーションによるIPsec保護が必要です。プロキシモバイルIPv6シグナリングメッセージ。
o If the local mobility anchor receives an Update Notification Acknowledgement message with a failure status and a value of 128 or greater, then it SHOULD log an error.
o ローカルモビリティアンカーが、障害ステータスと128以上の値を持つ更新通知確認メッセージを受信した場合、エラーをログに記録する必要があります（SHOULD）。
o If the Sequence Number in the received Update Notification Acknowledgement message does not match any of the Update Notification messages that the local mobility anchor sent, then the message MUST be discarded, and the message should be logged.
o 受信した更新通知確認メッセージのシーケンス番号が、ローカルモビリティアンカーが送信した更新通知メッセージのいずれとも一致しない場合は、メッセージを破棄する必要があり、メッセージをログに記録する必要があります。
o If the local mobility anchor receives an Update Notification Acknowledgement message from the mobile access gateway for an Update Notification message that did not have the (A) flag set, the local mobility anchor MUST process the received message in the same way as a response to an Update Notification message with the (A) flag set.
o ローカルモビリティアンカーが、（A）フラグが設定されていない更新通知メッセージのモバイルアクセスゲートウェイから更新通知確認メッセージを受信した場合、ローカルモビリティアンカーは、受信したメッセージを、 （A）フラグが設定された更新通知メッセージ。
o When receiving an Update Notification message, the mobile access gateway MUST verify the Mobility Header as described in Section 9.2. of [RFC6275]. If the packet is dropped due to failure of any of the Mobility Header test checks, the mobile access gateway MUST follow the processing rules as described in Section 9.2 of [RFC6275].
o 更新通知メッセージを受信すると、モバイルアクセスゲートウェイはセクション9.2で説明されているようにモビリティヘッダーを確認する必要があります。 [RFC6275]の。モビリティヘッダーテストチェックのいずれかが失敗したためにパケットがドロップされた場合、モバイルアクセスゲートウェイは、[RFC6275]のセクション9.2で説明されている処理ルールに従う必要があります。
o Upon receiving the Update Notification message, the mobile access gateway MUST verify that the received packet is protected by the security association that is being used to protect the other signaling messages between those two peers. For example, if the Proxy Binding Update and Proxy Binding Acknowledgement messages are protected using an IPsec security association, then the Update Notification message MUST have the IPsec protection with the currently established IPsec security association that is being used for protecting the other Proxy Mobile IPv6 signaling messages.
o 更新通知メッセージを受信すると、モバイルアクセスゲートウェイは、受信したパケットが、これら2つのピア間の他のシグナリングメッセージを保護するために使用されているセキュリティアソシエーションによって保護されていることを確認する必要があります。たとえば、Proxy Binding UpdateおよびProxy Binding AcknowledgmentメッセージがIPsecセキュリティアソシエーションを使用して保護されている場合、更新通知メッセージには、他のプロキシモバイルIPv6シグナリングの保護に使用されている現在確立されているIPsecセキュリティアソシエーションによるIPsec保護が必要です。メッセージ。
o If the received Update Notification message is a retransmission of a previously received message, as identified by the Sequence Number, then the mobile access gateway MUST NOT handle the message as a new request. The (D) flag is used as an indication of a retransmitted request, e.g., due to lost messages or the local mobility anchor not seeing the requested update actions. If the mobile access gateway has not seen the (potentially lost) initial request message, it MUST treat the received Update Notification message (with the (D) flag set) as an initial request and continue processing based on that. If the mobile access gateway detects that the request is a retransmission based on the (D) flag and the Sequence Number, then it SHOULD redo the requested update action, e.g., when the Acknowledgement Requested ((A)) flag is not set. The mobile access gateway MUST always respond to the retransmitted request if the (A) flag is set.
o シーケンス番号で識別されるように、受信した更新通知メッセージが以前に受信したメッセージの再送信である場合、モバイルアクセスゲートウェイはメッセージを新しい要求として処理してはなりません（MUST NOT）。 （Ｄ）フラグは、例えば、失われたメッセージまたはローカルモビリティアンカーが要求された更新アクションを見ないために、再送信された要求の指標として使用される。モバイルアクセスゲートウェイが（潜在的に失われた）初期要求メッセージを確認していない場合、受信した更新通知メッセージ（（D）フラグが設定されている）を初期要求として処理し、それに基づいて処理を続行する必要があります。モバイルアクセスゲートウェイが、リクエストが（D）フラグとシーケンス番号に基づいて再送信であることを検出した場合、たとえば、承認リクエスト（（A））フラグが設定されていない場合など、リクエストされた更新アクションを再実行する必要があります。 （A）フラグが設定されている場合、モバイルアクセスゲートウェイは常に再送信された要求に応答する必要があります。
o Upon accepting the Update Notification message, the mobile access gateway MUST process the message and perform the actions based on the Notification Reason.
o 更新通知メッセージを受け入れると、モバイルアクセスゲートウェイはメッセージを処理し、通知理由に基づいてアクションを実行する必要があります。
* If the (A) flag in the message is set to a value of (1), the mobile access gateway MUST send an Update Notification Acknowledgement message with the status code field set based on the result of processing the Update Notification message.
* メッセージの（A）フラグが（1）の値に設定されている場合、モバイルアクセスゲートウェイは、更新通知メッセージの処理結果に基づいてステータスコードフィールドを設定した更新通知確認メッセージを送信する必要があります。
* If the Notification Reason is set to a value of (1) "FORCE-REREGISTRATION", then the mobile access gateway MUST send a Proxy Binding Update message to the local mobility anchor and obtain the updated session parameters for that mobility session.
* 通知理由が（1） "FORCE-REREGISTRATION"の値に設定されている場合、モバイルアクセスゲートウェイはプロキシバインディング更新メッセージをローカルモビリティアンカーに送信し、そのモビリティセッションの更新されたセッションパラメータを取得する必要があります。
* If the Notification Reason is set to a value of (2) "UPDATE-SESSION-PARAMETERS", then the mobile access gateway MUST apply the session parameters that are obtained from the Update Notification message in the form of mobility options.
* 通知理由が（2） "UPDATE-SESSION-PARAMETERS"の値に設定されている場合、モバイルアクセスゲートウェイは、モビリティオプションの形式で更新通知メッセージから取得されたセッションパラメータを適用する必要があります。
However, if the mobile access gateway is unable to apply the received session parameters, then the mobile access gateway MUST apply the following considerations:
ただし、モバイルアクセスゲートウェイが受信したセッションパラメータを適用できない場合、モバイルアクセスゲートウェイは次の考慮事項を適用する必要があります。
+ If the received Update Notification message has the (A) flag in the message set to a value of (0), then the mobile access gateway MUST drop the received Update Notification message and log the error.
+ 受信した更新通知メッセージのメッセージの（A）フラグの値が（0）に設定されている場合、モバイルアクセスゲートウェイは受信した更新通知メッセージをドロップし、エラーをログに記録する必要があります。
+ If the received Update Notification message has the (A) flag in the message set to a value of (1), then the mobile access gateway MUST send an Update Notification Acknowledgement message with a status code value of 128 (FAILED-TO-UPDATE-SESSION-PARAMETERS).
+ 受信した更新通知メッセージのメッセージの（A）フラグの値が（1）に設定されている場合、モバイルアクセスゲートウェイは、ステータスコード値128（FAILED-TO-UPDATE-を含む更新通知確認メッセージを送信する必要があります。 SESSION-PARAMETERS）。
* If the Notification Reason is set to a value of (3) "VENDOR-SPECIFIC-REASON", then the mobile access gateway MUST apply the considerations related to handling of the Vendor-Specific Mobility option [RFC5094] that is carried in the Update Notification message. However, if there is no Vendor-Specific Mobility option present in the message, the mobile access gateway MUST apply the following considerations:
* 通知理由が（3）「ベンダー固有の理由」の値に設定されている場合、モバイルアクセスゲートウェイは、更新通知で実行されるベンダー固有のモビリティオプション[RFC5094]の処理に関する考慮事項を適用する必要があります。メッセージ。ただし、メッセージにベンダー固有のモビリティオプションがない場合、モバイルアクセスゲートウェイは次の考慮事項を適用する必要があります。
+ If the received Update Notification message has the (A) flag in the message set to a value of (0), then the mobile access gateway MUST drop the received Update Notification message and log the error.
+ 受信した更新通知メッセージのメッセージの（A）フラグの値が（0）に設定されている場合、モバイルアクセスゲートウェイは受信した更新通知メッセージをドロップし、エラーをログに記録する必要があります。
+ If the received Update Notification message has the (A) flag in the message set to a value of (1), then the mobile access gateway MUST send an Update Notification Acknowledgement message with a status code value of 129 (MISSING-VENDOR-SPECIFIC-OPTION).
+ 受信した更新通知メッセージのメッセージの（A）フラグの値が（1）に設定されている場合、モバイルアクセスゲートウェイは、ステータスコード値129（MISSING-VENDOR-SPECIFIC-を含む更新通知確認メッセージを送信する必要があります。オプション）。
* If the Notification Reason is set to a value of (4) "ANI-PARAMS-REQUESTED", then the mobile access gateway MUST send a Proxy Binding Update message to the local mobility anchor with the Access Network Identifier option [RFC6757]. The Access Network Identifier option MUST reflect the current access network parameters for that mobility session as known to the mobile access gateway at the time of sending the Proxy Binding Update message.
* 通知理由が（4） "ANI-PARAMS-REQUESTED"の値に設定されている場合、モバイルアクセスゲートウェイは、アクセスネットワーク識別子オプション[RFC6757]を使用して、プロキシバインディング更新メッセージをローカルモビリティアンカーに送信する必要があります。 Access Network Identifierオプションは、Proxy Binding Updateメッセージの送信時にモバイルアクセスゲートウェイに認識されている、そのモビリティセッションの現在のアクセスネットワークパラメータを反映する必要があります。
* For other Notification Reason values not reserved by this document, the processing required on the mobile access gateway is out of scope for this document and will be specified for each Notification Reason defined by other documents.
* このドキュメントで予約されていない他の通知理由値の場合、モバイルアクセスゲートウェイで必要な処理はこのドキュメントの範囲外であり、他のドキュメントで定義されている通知理由ごとに指定されます。
The mobile access gateway, when sending the Update Notification Acknowledgement message to the local mobility anchor, has to construct the message as specified below:
モバイルアクセスゲートウェイは、Update Notification Acknowledgmentメッセージをローカルモビリティアンカーに送信するときに、次のようにメッセージを作成する必要があります。
o The Sequence Number MUST be the same as the Sequence Number from the received Update Notification message.
o シーケンス番号は、受信した更新通知メッセージのシーケンス番号と同じである必要があります。
o The Status field of the Update Notification message MUST be set to a value that reflects the status of the processing of the Update Notification request. A value of 0 (SUCCESS) indicates that the handling of the Update Notification message was successful.
o 更新通知メッセージのステータスフィールドは、更新通知リクエストの処理のステータスを反映する値に設定する必要があります。値0（成功）は、更新通知メッセージの処理が成功したことを示します。
o The Update Notification Acknowledgement message MUST contain either the Mobile Node Identifier option or the Mobile Node Group Identifier option, copied from the Update Notification message. Furthermore, the mobile access gateway MAY include other Mobility Header options.
o 更新通知確認メッセージには、更新通知メッセージからコピーされたモバイルノード識別子オプションまたはモバイルノードグループ識別子オプションのいずれかが含まれている必要があります。さらに、モバイルアクセスゲートウェイには他のモビリティヘッダーオプションが含まれる場合があります。
o The source address in the IP header of the Update Notification Acknowledgement message MUST be set to the destination IP address of the received Update Notification message.
o 更新通知確認メッセージのIPヘッダーの送信元アドレスは、受信した更新通知メッセージの宛先IPアドレスに設定する必要があります。
o The destination address in the IP header of the Update Notification Acknowledgement message MUST be set to the source address of the received Update Notification message.
o 更新通知肯定応答メッセージのIPヘッダーの宛先アドレスは、受信した更新通知メッセージの送信元アドレスに設定する必要があります。
o If IPsec ESP is used to protect signaling, the packet is processed using transport mode ESP.
o シグナリングの保護にIPsec ESPが使用されている場合、パケットはトランスポートモードESPを使用して処理されます。
o The format of the Update Notification Acknowledgement message sent over IPv4 and protected using ESP is shown below:
o IPv4を介して送信され、ESPを使用して保護された更新通知確認メッセージの形式を以下に示します。
IPv4 header (src=IPv4-Proxy-CoA, dst=IPv4-LMAA) ESP header (in transport mode) UDP header (sport=5436, dport=5436) Mobility Header (Update Notification Acknowledgement) (one or more Mobility Header options)
IPv4ヘッダー（src = IPv4-Proxy-CoA、dst = IPv4-LMAA）ESPヘッダー（トランスポートモード）UDPヘッダー（sport = 5436、dport = 5436）モビリティヘッダー（更新通知確認）（1つ以上のモビリティヘッダーオプション）
o The format of the Update Notification Acknowledgement message sent over IPv6 and protected using ESP is shown below:
o IPv6を介して送信され、ESPを使用して保護された更新通知確認メッセージの形式を以下に示します。
IPv6 header (src=Proxy-CoA, dst=LMAA) Mobility Header (Update Notification Acknowledgement) ESP header (in transport mode) (one or more Mobility Header options)
IPv6ヘッダー（src = Proxy-CoA、dst = LMAA）Mobilityヘッダー（Update Notification Acknowledgement）ESPヘッダー（トランスポートモード）（1つ以上のMobilityヘッダーオプション）
This specification defines the following configuration variables that control the Update Notification feature.
この仕様は、更新通知機能を制御する次の構成変数を定義します。
The mobility entities, the local mobility anchor, and the mobile access gateway have to allow these variables to be configured by the system management. The configured values for these protocol variables have to survive server reboots and service restarts.
モビリティエンティティ、ローカルモビリティアンカー、およびモバイルアクセスゲートウェイでは、これらの変数をシステム管理で設定できるようにする必要があります。これらのプロトコル変数に設定された値は、サーバーの再起動とサービスの再起動に耐える必要があります。
MAX_UPDATE_NOTIFICATION_RETRANSMIT_COUNT
MAX_UPDATE_NOTIFICATION_RETRANSMIT_COUNT
This variable specifies the maximum number of times a local mobility anchor can retransmit an Update Notification message before it receives an Update Notification Acknowledgement message. The default value for this parameter is 1. The suggested range of configured values for this variable is between 0 and 5.
この変数は、ローカルモビリティアンカーがUpdate Notification Acknowledgementメッセージを受信する前に、Update Notificationメッセージを再送信できる最大回数を指定します。このパラメーターのデフォルト値は1です。この変数の構成値の推奨範囲は0〜5です。
MIN_DELAY_BETWEEN_UPDATE_NOTIFICATION_REPLAY
MIN_DELAY_BETWEEN_UPDATE_NOTIFICATION_REPLAY
This variable specifies the minimum delay in seconds before an Update Notification message is retransmitted. The default value for this parameter is 1000 milliseconds. The suggested range of configured values for this variable is between 500 and 5000 milliseconds.
この変数は、更新通知メッセージが再送信されるまでの最小遅延を秒単位で指定します。このパラメーターのデフォルト値は1000ミリ秒です。この変数の構成値の推奨範囲は500〜5000ミリ秒です。
The Update Notification protocol described in this specification is for use between a local mobility anchor and a mobile access gateway. This specification defines two new Mobility Header messages: Update Notification messages and Update Notification Acknowledgement messages. These Mobility Header messages are to be protected using the same security mechanism that is used for protecting the Proxy Mobile IPv6 signaling messages exchanged between a given local mobility anchor and mobile access gateway.
この仕様で説明されている更新通知プロトコルは、ローカルモビリティアンカーとモバイルアクセスゲートウェイの間で使用するためのものです。この仕様は、2つの新しいモビリティヘッダーメッセージを定義します。更新通知メッセージと更新通知確認メッセージです。これらのモビリティヘッダーメッセージは、特定のローカルモビリティアンカーとモバイルアクセスゲートウェイの間で交換されるプロキシモバイルIPv6シグナリングメッセージを保護するために使用されるのと同じセキュリティメカニズムを使用して保護されます。
If IPsec is used, the IPsec security association that is used for protecting the Proxy Binding Update and Proxy Binding Acknowledgement also needs to be used for protecting Update Notification and Update Notification Acknowledgement messages. A Proxy Mobile IPv6 implementation and the IPsec layer are typically able to communicate with each other through an implementation-specific interface, for example, to exchange configuration and notification information.
IPsecを使用する場合、プロキシバインディングの更新とプロキシバインディングの確認の保護に使用されるIPsecセキュリティアソシエーションも、更新通知と更新通知の確認メッセージの保護に使用する必要があります。プロキシモバイルIPv6実装とIPsec層は、通常、実装固有のインターフェイスを介して相互に通信できます。たとえば、構成と通知情報を交換できます。
The traffic selectors associated with the Security Policy Database (SPD) entry for protecting Proxy Binding Update and Proxy Binding Acknowledgement messages (Section 4.2 of [RFC5213]) have to be extended to include the Mobility Header Type values 19 and 20, which have been allocated for Update Notification and Update Notification Acknowledgement messages, respectively. Furthermore, any time there is rekeying of the IPsec security association between the mobile access gateway and the local mobility anchor, the newly established IPsec security association will be used for protecting the Update Notification and Update Notification Acknowledgement messages.
プロキシバインディングアップデートおよびプロキシバインディング確認メッセージ（[RFC5213]のセクション4.2）を保護するためのセキュリティポリシーデータベース（SPD）エントリに関連付けられたトラフィックセレクタは、割り当てられたモビリティヘッダータイプ値19および20を含むように拡張する必要があります。更新通知と更新通知確認メッセージのそれぞれ。さらに、モバイルアクセスゲートウェイとローカルモビリティアンカーの間にIPsecセキュリティアソシエーションのキー更新がある場合は常に、新しく確立されたIPsecセキュリティアソシエーションを使用して、更新通知および更新通知確認メッセージが保護されます。
The authors would like to thank Basavaraj Patil, Rajeev Koodli, Lionel Morand, Itsuma Tanaka, Rajesh Pazhyannur, Carlos Jesus Bernardos Cano, John Kaippallimalil, Brian Haberman, and other members of the NETEXT working group for all the comments and discussions on the document.
この文書に関するすべてのコメントと議論について、著者はバサバラジパティル、ラジーブクードリ、ライオネルモランド、田中逸馬、ラジェシュパジヤヌール、カルロスジーザスベルナルドスカノ、ジョンカイパリマリル、ブライアンハーバーマン、およびNETEXTワーキンググループの他のメンバーに感謝します。
The authors would like to thank Barry Leiba, Robert Sparks, Carlos Pignataro, Benoit Claise, Stephen Farrell, and Jari Arkko for their inputs to the document as part of the IESG review process.
著者は、IESGレビュープロセスの一部としてのドキュメントへの入力について、バリーレイバ、ロバートスパークス、カルロスピニャタロ、ブノワクレイズ、スティーブンファレル、およびヤリアルコに感謝します。
IANA has taken the following actions.
IANAは次の行動をとった。
o This specification defines a new Mobility Header Type message, Update Notification. This Mobility Header message is described in Section 4.1. The type value 19 for this message has been allocated from the "Mobility Header Types - for the MH Type field in the Mobility Header" registry at <http://www.iana.org/assignments/mobility-parameters>.
o この仕様では、新しいモビリティヘッダータイプメッセージである更新通知を定義しています。このモビリティヘッダーメッセージについては、セクション4.1で説明します。このメッセージのタイプ値19は、<http://www.iana.org/assignments/mobility-parameters>の「モビリティヘッダータイプ-モビリティヘッダーのMHタイプフィールド」レジストリから割り当てられています。
o This specification defines a new Mobility Header Type message, Update Notification Acknowledgement. This Mobility Header message is described in Section 4.2. The type value 20 for this message has been allocated from the "Mobility Header Types - for the MH Type field in the Mobility Header" registry at <http://www.iana.org/assignments/mobility-parameters>.
o この仕様は、新しいモビリティヘッダータイプメッセージであるUpdate Notification Acknowledgementを定義しています。このモビリティヘッダーメッセージについては、セクション4.2で説明します。このメッセージのタイプ値20は、<http://www.iana.org/assignments/mobility-parameters>の「モビリティヘッダータイプ-モビリティヘッダーのMHタイプフィールド用」レジストリから割り当てられています。
o This specification defines a new registry for Notification Reasons. It is called the "Update Notification Reasons Registry". This registry has been created under the "Mobile IPv6 Parameters" registry at <http://www.iana.org/assignments/mobility-parameters>. The Notification Reason is a field in the Update Notification message (Section 4.1). The number space for the Notification Reason field needs to be managed by IANA, under the "Update Notification Reason Registry". This specification reserves the following type values. The allocation policy for this field is "Specification Required" [RFC5226].
o この仕様は、通知理由の新しいレジストリを定義します。 「更新通知理由レジストリ」と呼ばれます。このレジストリは、<http://www.iana.org/assignments/mobility-parameters>の「Mobile IPv6 Parameters」レジストリの下に作成されています。通知理由は、更新通知メッセージ（セクション4.1）のフィールドです。 [Notification Reason]フィールドの番号スペースは、[Update Notification Reason Registry]でIANAが管理する必要があります。この仕様では、次のタイプの値が予約されています。このフィールドの割り当てポリシーは「Specification Required」[RFC5226]です。
+=====+===========================+====================+
|Value| Description | Reference |
+=====+===========================+====================+
| 0 | Reserved | [RFC7077] |
+=====+================================================+
| 1 | FORCE-REREGISTRATION | [RFC7077] |
+=====+================================================+
| 2 | UPDATE-SESSION-PARAMETERS | [RFC7077] |
+=====+================================================+
| 3 | VENDOR-SPECIFIC-REASON | [RFC7077] |
+=====+================================================+
| 4 | ANI-PARAMS-REQUESTED | [RFC7077] |
+=====+================================================+
|255 | Reserved | [RFC7077] |
+=====+================================================+
o This specification defines a new registry for Status. It is called the "Update Notification Acknowledgement Status Registry". This registry has been created under the "Mobile IPv6 Parameters" registry at <http://www.iana.org/assignments/mobility-parameters>. The status is a field in the Update Notification Acknowledgement message (Section 4.2). The number space for the Status field needs to be managed by IANA, under the "Update Notification Acknowledgement Status Registry". This specification reserves the following type values. The allocation policy for this field is "Specification Required". Status codes between 0 and 127 signify successful processing of the Update Notification message, and codes between 128 and 255 signify that an error occurred during processing of the Update Notification message.
o この仕様は、ステータスの新しいレジストリを定義します。 「更新通知確認ステータスレジストリ」と呼ばれます。このレジストリは、<http://www.iana.org/assignments/mobility-parameters>の「Mobile IPv6 Parameters」レジストリの下に作成されています。ステータスは、Update Notification Acknowledgmentメッセージ（セクション4.2）のフィールドです。 Statusフィールドの番号スペースは、「Update Notification Acknowledgement Status Registry」の下でIANAが管理する必要があります。この仕様では、次のタイプの値が予約されています。このフィールドの割り当てポリシーは「指定が必要」です。 0〜127のステータスコードは、更新通知メッセージの処理が成功したことを示し、128〜255のコードは、更新通知メッセージの処理中にエラーが発生したことを示します。
+=====+=====================================+=============+
|Value| Description | Reference |
+=====+=====================================+=============+
| 0 | SUCCESS | [RFC7077] |
+=====+=====================================+=============+
|128 | FAILED-TO-UPDATE-SESSION-PARAMETERS | [RFC7077] |
+=====+=====================================+=============+
|129 | MISSING-VENDOR-SPECIFIC-OPTION | [RFC7077] |
+=====+=====================================+=============+
[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月。
[RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury, "Mobile Node Identifier Option for Mobile IPv6 (MIPv6)", RFC 4283, November 2005.
[RFC4283] Patel、A.、Leung、K.、Khalil、M.、Akhtar、H。、およびK. Chowdhury、「Mobile IPv6（MIPv6）のMobile Node Identifier Option」、RFC 4283、2005年11月。
[RFC5094] Devarapalli, V., Patel, A., and K. Leung, "Mobile IPv6 Vendor Specific Option", RFC 5094, December 2007.
[Raffsey 108] Devarapalli、V.、Patel、A。、およびK. Leungi、「Mobile ipp9 Vendor Specific Option」、rfk 108、2006年12月。
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[Rufsey1] Gundavelli、S.、Leunji、K.、Devarapalli、V.、Chowdhury、K。、およびB. Patil、「Proxy Mobile Ipp 1」、Rfak 2、2009年8月。
[RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile IPv6", RFC 5844, May 2010.
[RFC5844]脇川R.およびS. Gundavelli、「プロキシモバイルIPv6のIPv4サポート」、RFC 5844、2010年5月。
[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, July 2011.
[RFC6275] Perkins、C.、Johnson、D。、およびJ. Arkko、「IPv6でのモビリティサポート」、RFC 6275、2011年7月。
[RFC6602] Abinader, F., Gundavelli, S., Leung, K., Krishnan, S., and D. Premec, "Bulk Binding Update Support for Proxy Mobile IPv6", RFC 6602, May 2012.
[RFC6602] Abinader、F.、Gundavelli、S.、Leung、K.、Krishnan、S。、およびD. Premec、「Bulk Binding Update Support for Proxy Mobile IPv6」、RFC 6602、2012年5月。
[PMIPv6-FLOW-MOB] Bernardos, CJ., Ed., "Proxy Mobile IPv6 Extensions to Support Flow Mobility", Work in Progress, October 2013.
[PMIPv6-FLOW-MOB]バーナードス、CJ。、編、「フローモビリティをサポートするためのプロキシモバイルIPv6拡張機能」、2013年10月、作業中。
[PMIPv6-QoS] Liebsch, M., Seite, P., Yokota, H., Korhonen, J., and S. Gundavelli, "Quality of Service Option for Proxy Mobile IPv6", Work in Progress, November 2013.
[PMIPv6-QoS] Liebsch、M.、Seite、P.、Yokota、H.、Korhonen、J.、and S. Gundavelli、 "Quality of Service Option for Proxy Mobile IPv6"、Work in Progress、2013年11月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent、S。およびK. Seo、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]ケント、S。、「IPカプセル化セキュリティペイロード（ESP）」、RFC 4303、2005年12月。
[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、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC5846] Muhanna, A., Khalil, M., Gundavelli, S., Chowdhury, K., and P. Yegani, "Binding Revocation for IPv6 Mobility", RFC 5846, June 2010.
[RFC5846] Muhanna、A.、Khalil、M.、Gundavelli、S.、Chowdhury、K。、およびP. Yegani、「IPv6モビリティのバインディング失効」、RFC 5846、2010年6月。
[RFC5847] Devarapalli, V., Koodli, R., Lim, H., Kant, N., Krishnan, S., and J. Laganier, "Heartbeat Mechanism for Proxy Mobile IPv6", RFC 5847, June 2010.
[RFC5847] Devarapalli、V.、Koodli、R.、Lim、H.、Kant、N.、Krishnan、S.、J。Laganier、「Heartbeat Mechanism for Proxy Mobile IPv6」、RFC 5847、2010年6月。
[RFC6757] Gundavelli, S., Korhonen, J., Grayson, M., Leung, K., and R. Pazhyannur, "Access Network Identifier (ANI) Option for Proxy Mobile IPv6", RFC 6757, October 2012.
[RFC6757] Gundavelli、S.、Korhonen、J.、Grayson、M.、Leung、K。、およびR. Pazhyannur、「Access Mobile Identifier（ANI）Option for Proxy Mobile IPv6」、RFC 6757、2012年10月。
[RFC6909] Gundavelli, S., Zhou, X., Korhonen, J., Feige, G., and R. Koodli, "IPv4 Traffic Offload Selector Option for Proxy Mobile IPv6", RFC 6909, April 2013.
[RFC6909] Gundavelli、S.、Zhou、X.、Korhonen、J.、Feige、G。、およびR. Koodli、「プロキシモバイルIPv6のIPv4トラフィックオフロードセレクタオプション」、RFC 6909、2013年4月。
Authors' Addresses
著者のアドレス
Suresh Krishnan Ericsson 8400 Blvd Decarie Town of Mount Royal, Quebec Canada
Suresh Krishnan Ericsson 8400 Blvd Decarie Town of Mount Royal、Quebec Canada
Phone: +1 514 345 7900 x42871
EMail: suresh.krishnan@ericsson.com
Sri Gundavelli Cisco 170 West Tasman Drive San Jose, CA 95134 USA
Sri Gundavelli Cisco 170 West Tasman Drive San Jose、CA 95134 USA
EMail: sgundave@cisco.com
Marco Liebsch NEC Kurfuersten-Anlage 36 D-69115 Heidelberg Germany
Marco Liebsch NEC Kurfuersten-Anlage 36 D-69115ハイデルベルクドイツ
EMail: marco.liebsch@neclab.eu
Hidetoshi Yokota KDDI
ひでとし よこた Ｋっぢ
EMail: yokota@kddilabs.jp
Jouni Korhonen Broadcom Porkkalankatu 24 Helsinki FIN-00180 Finland
Jouni Korhonen Broadcom Porkkalankatu 24ヘルシンキFIN-00180フィンランド
EMail: jouni.nospam@gmail.com