RFC 5845 - Generic Routing Encapsulation (GRE) Key Option for Proxy Mobile IPv6 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc5845
タイトル : RFC 5845 - プロキシモバイルIPv6の汎用ルーティングカプセル化（GRE）キーオプション
翻訳編集 : 自動生成

[要約] RFC 5845は、Proxy Mobile IPv6におけるGeneric Routing Encapsulation（GRE）キーオプションに関する仕様です。このRFCの目的は、GREキーオプションを使用してProxy Mobile IPv6のトンネルエンドポイント間でセキュアな通信を確立することです。

Internet Engineering Task Force (IETF)                        A. Muhanna
Request for Comments: 5845                                     M. Khalil
Category: Standards Track                                       Ericsson
ISSN: 2070-1721                                            S. Gundavelli
                                                                K. Leung
                                                                   Cisco
                                                               June 2010

Generic Routing Encapsulation (GRE) Key Option for Proxy Mobile IPv6

プロキシモバイルIPv6の汎用ルーティングカプセル化（GRE）キーオプション

Abstract

概要

This specification defines a new mobility option for allowing the mobile access gateway and the local mobility anchor to negotiate Generic Routing Encapsulation (GRE) encapsulation mode and exchange the downlink and uplink GRE keys that are used for marking the downlink and uplink traffic that belong to a specific mobility session. In addition, the same mobility option can be used to negotiate the GRE encapsulation mode without exchanging the GRE keys.

この仕様では、モバイルアクセスゲートウェイとローカルモビリティアンカーがGeneric Routing Encapsulation（GRE）カプセル化モードをネゴシエートし、ダウンリンクとアップリンクのGREキーを交換して、特定のモビリティセッション。さらに、同じモビリティオプションを使用して、GREキーを交換せずにGREカプセル化モードをネゴシエートできます。

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/rfc5845.

このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc5845で入手できます。

著作権表示

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  . . . . . . . . . . . . . . . . .  3
     2.1.  Conventions  . . . . . . . . . . . . . . . . . . . . . . .  3
     2.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  GRE Encapsulation and Key Exchange . . . . . . . . . . . . . .  4
     3.1.  GRE Encapsulation Overview . . . . . . . . . . . . . . . .  4
     3.2.  GRE Encapsulation Mode Only  . . . . . . . . . . . . . . .  6
     3.3.  GRE Encapsulation and Key Exchange . . . . . . . . . . . .  6
       3.3.1.  Initial GRE Key Exchange . . . . . . . . . . . . . . .  6
       3.3.2.  GRE Key Exchange during Binding Re-Registration  . . .  7
   4.  Mobile Access Gateway Considerations . . . . . . . . . . . . .  8
     4.1.  Extensions to the Conceptual Data Structure  . . . . . . .  8
     4.2.  Operational Summary  . . . . . . . . . . . . . . . . . . .  9
   5.  Local Mobility Anchor Considerations . . . . . . . . . . . . . 10
     5.1.  Extensions to the Binding Cache Entry  . . . . . . . . . . 10
     5.2.  Operational Summary  . . . . . . . . . . . . . . . . . . . 11
   6.  Message Formats  . . . . . . . . . . . . . . . . . . . . . . . 12
     6.1.  GRE Key Option . . . . . . . . . . . . . . . . . . . . . . 12
     6.2.  Proxy Binding Update Message Extension . . . . . . . . . . 13
     6.3.  Proxy Binding Acknowledgement Message Extension  . . . . . 14
     6.4.  Status Codes . . . . . . . . . . . . . . . . . . . . . . . 14
   7.  Data Packets Processing Considerations . . . . . . . . . . . . 15
     7.1.  Tunneling Format . . . . . . . . . . . . . . . . . . . . . 15
     7.2.  TLV-Header Tunneling Negotiation . . . . . . . . . . . . . 16
     7.3.  Mobile Access Gateway Operation  . . . . . . . . . . . . . 18
       7.3.1.  Sending and Receiving Data Packets . . . . . . . . . . 18
     7.4.  Local Mobility Anchor Operation  . . . . . . . . . . . . . 19
       7.4.1.  Sending and Receiving Data Packets . . . . . . . . . . 20
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 21
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 21
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 22
     11.2. Informative References . . . . . . . . . . . . . . . . . . 22

1. Introduction

1. はじめに

The Proxy Mobile IPv6 specification [RFC5213] and IPv4 Support for Proxy Mobile IPv6 [RFC5844] allow the use of IPv6 and IPv4 encapsulation modes as specified in [RFC2473] and [RFC2003] for the tunneled traffic between the local mobility anchor (LMA) and the mobile access gateway (MAG). There are scenarios where these encapsulation modes are not sufficient to uniquely identify the destination of packets of a specific mobility session. Thus, there is a need for an encapsulation mode with richer semantics. The Generic Routing Encapsulation (GRE) [RFC2784], and the Key extension as defined in [RFC2890], has the required semantics to allow such a distinction for use in Proxy Mobile IPv6.

プロキシモバイルIPv6仕様[RFC5213]およびプロキシモバイルIPv6のIPv4サポート[RFC5844]では、ローカルモビリティアンカー（LMA）との間のトンネルトラフィックに対して[RFC2473]および[RFC2003]で指定されているIPv6およびIPv4カプセル化モードを使用できます。モバイルアクセスゲートウェイ（MAG）。特定のモビリティセッションのパケットの宛先を一意に識別するには、これらのカプセル化モードでは不十分なシナリオがあります。したがって、より豊富なセマンティクスを持つカプセル化モードが必要です。 Generic Routing Encapsulation（GRE）[RFC2784]、および[RFC2890]で定義されているキー拡張には、プロキシモバイルIPv6で使用するためにそのような区別を可能にするために必要なセマンティクスがあります。

This specification defines the GRE Key option to be used for the negotiation of GRE encapsulation mode and exchange of the uplink and downlink GRE keys. The negotiated downlink and uplink GRE keys can be used for marking the downlink and uplink traffic for a specific mobility session. In addition, this specification enables the mobile access gateway and the local mobility anchor to negotiate the use of GRE encapsulation mode without exchanging the GRE keys.

この仕様は、GREカプセル化モードのネゴシエーションと、アップリンクおよびダウンリンクGREキーの交換に使用されるGREキーオプションを定義します。ネゴシエートされたダウンリンクおよびアップリンクGREキーは、特定のモビリティセッションのダウンリンクおよびアップリンクトラフィックをマーキングするために使用できます。さらに、この仕様により、モバイルアクセスゲートウェイとローカルモビリティアンカーは、GREキーを交換せずにGREカプセル化モードの使用をネゴシエートできます。

This specification has no impact on IPv4 or IPv6 mobile nodes.

この仕様は、IPv4またはIPv6モバイルノードに影響を与えません。

2. Conventions and Terminology

2. 表記法と用語

2.1. Conventions

2.1. 規約

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this specification 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]で説明されているように解釈されます。

2.2. Terminology

2.2. 用語

All the general mobility-related terminology and abbreviations are to be interpreted as defined in the Mobile IPv6 [RFC3775], Proxy Mobile IPv6 [RFC5213], and IPv4 Support for Proxy Mobile IPv6 [RFC5844] specifications. The following terms are used in this specification.

すべての一般的なモビリティ関連の用語と略語は、モバイルIPv6 [RFC3775]、プロキシモバイルIPv6 [RFC5213]、およびプロキシモバイルIPv6のIPv4サポート[RFC5844]仕様で定義されているとおりに解釈されます。この仕様では、次の用語が使用されます。

Downlink Traffic

ダウンリンクトラフィック

The traffic in the tunnel between the local mobility anchor and the mobile access gateway, heading towards the mobile access gateway and tunneled at the local mobility anchor. This traffic is also called forward direction traffic.

ローカルモビリティアンカーとモバイルアクセスゲートウェイの間のトンネル内のトラフィック。モバイルアクセスゲートウェイに向かい、ローカルモビリティアンカーでトンネリングされます。このトラフィックは、順方向トラフィックとも呼ばれます。

Uplink Traffic

アップリンクトラフィック

The traffic in the tunnel between the mobile access gateway and the local mobility anchor, heading towards the local mobility anchor and tunneled at the mobile access gateway. This traffic is also called reverse direction traffic.

モバイルアクセスゲートウェイとローカルモビリティアンカー間のトンネル内のトラフィックは、ローカルモビリティアンカーに向かい、モバイルアクセスゲートウェイでトンネリングされます。このトラフィックは、逆方向トラフィックとも呼ばれます。

Downlink GRE Key

ダウンリンクGREキー

The GRE key is assigned by the mobile access gateway and used by the local mobility anchor to mark the downlink traffic that belongs to a specific mobility session as described in this specification.

GREキーはモバイルアクセスゲートウェイによって割り当てられ、この仕様で説明されているように、特定のモビリティセッションに属するダウンリンクトラフィックをマークするためにローカルモビリティアンカーによって使用されます。

Uplink GRE Key

アップリンクGREキー

The GRE key is assigned by the local mobility anchor and used by the mobile access gateway to mark the uplink traffic that belongs to a specific mobility session as described in this specification.

この仕様で説明されているように、GREキーはローカルモビリティアンカーによって割り当てられ、モバイルアクセスゲートウェイによって使用され、特定のモビリティセッションに属するアップリンクトラフィックをマークします。

A Policy Check

ポリシーチェック

When a local mobility anchor receives an initial, handoff-triggered Binding Lifetime Extension, or Binding Lifetime Extension Proxy Binding Update for a mobility session, the local mobility anchor determines if the GRE encapsulation mode only or GRE encapsulation and GRE keys are required based on a policy check. This policy could be a per-MAG-LMA pair, a per-LMA local policy, a per-MN policy, or the combination of any of them.

ローカルモビリティアンカーが、モビリティセッションの初期のハンドオフトリガーバインディングライフタイムエクステンション、またはバインディングライフタイムエクステンションプロキシバインディングアップデートを受信すると、ローカルモビリティアンカーは、GREカプセル化モードのみ、またはGREカプセル化とGREキーが必要かどうかを決定します。ポリシーチェック。このポリシーは、MAG-LMAごとのペア、LMAごとのローカルポリシー、MNごとのポリシー、またはそれらのいずれかの組み合わせです。

3. GRE Encapsulation and Key Exchange

3. GREカプセル化とキー交換

This section describes how GRE encapsulation mode is negotiated and the GRE keys are dynamically exchanged using Proxy Mobile IPv6 protocol [RFC5213] signaling.

このセクションでは、GREカプセル化モードがネゴシエートされ、GREキーがプロキシモバイルIPv6プロトコル[RFC5213]シグナリングを使用して動的に交換される方法について説明します。

3.1. GRE Encapsulation Overview

3.1. GREカプセル化の概要

Using the GRE Key option defined in this specification, the mobile access gateway and the local mobility anchor can negotiate GRE encapsulation mode only or GRE encapsulation mode and exchange the GRE keys for marking the downlink and uplink traffic. In the case when GRE encapsulation mode only is negotiated between the mobile access gateway and the local mobility anchor, then no GRE keys are used.

この仕様で定義されているGREキーオプションを使用して、モバイルアクセスゲートウェイとローカルモビリティアンカーは、GREカプセル化モードのみまたはGREカプセル化モードをネゴシエートし、GREキーを交換して、ダウンリンクおよびアップリンクトラフィックをマーキングできます。 GREカプセル化モードのみがモバイルアクセスゲートウェイとローカルモビリティアンカーの間でネゴシエートされる場合、GREキーは使用されません。

However, once the GRE keys have been exchanged between the mobile access gateway and the local mobility anchor as per this specification, the mobile access gateway will use the uplink GRE key that is assigned by the local mobility anchor in the GRE header of the uplink payload packet. Similarly, the local mobility anchor will use the downlink GRE key as negotiated with the mobile access gateway in the GRE header of the downlink payload packet.

ただし、GREキーがこの仕様に従ってモバイルアクセスゲートウェイとローカルモビリティアンカーの間で交換されると、モバイルアクセスゲートウェイは、アップリンクペイロードのGREヘッダー内のローカルモビリティアンカーによって割り当てられたアップリンクGREキーを使用しますパケット。同様に、ローカルモビリティアンカーは、ダウンリンクペイロードパケットのGREヘッダーでモバイルアクセスゲートウェイとネゴシエートされたダウンリンクGREキーを使用します。

The following illustration explains the use of GRE encapsulation mode and the GRE keys for supporting the usecase where overlapping IPv4 private address [RFC1918] allocation is in use.

次の図は、重複するIPv4プライベートアドレス[RFC1918]割り当てが使用されているユースケースをサポートするためのGREカプセル化モードとGREキーの使用について説明しています。

                                                          +------------+
                                                          | Operator-A |
                                                          |            |
                                                          | 10.x.0.0/16|
                                                          +------------+
                                                                   /
        +------+                                      +------+    /
        |      |      ==========================      |      |   /
 MN-1---|      |    /                            \    |      |  / Key-1
        |  M   |   / ---Flows with GRE Key-1 ---- \   |  L   | / Traffic
 MN-2---|  A   |--|                                |--|  M   |-
        |  G   |   \ ---Flows with GRE Key-2 ---- /   |  A   | \ Key-2
 MN-3---|      |    \                            /    |      |  \Traffic
        |      |      ==========================      |      |   \
 MN-4---|      |       Proxy Mobile IPv6 Tunnel       |      |    \
        +------+                                      +------+     \
                                                                    \
                   Operator-C: Access Network             +------------+
                                                          | Operator-B |
                                                          |            |
                                                          | 10.x.0.0/16|
                                                          +------------+

Figure 1: GRE Tunneling for IPv4 Private Address Space Overlapping

図1：IPv4プライベートアドレススペースの重複のためのGREトンネリング

Figure 1 illustrates a local mobility anchor providing mobility service to mobile nodes that are from different operators and are assigned IPv4 addresses from overlapping private address space. In this scenario, the mobile access gateway and the local mobility anchor must be able to distinguish flows belonging to different operators.

図1は、さまざまな事業者のモバイルノードにモビリティサービスを提供し、重複するプライベートアドレススペースからIPv4アドレスが割り当てられたローカルモビリティアンカーを示しています。このシナリオでは、モバイルアクセスゲートウェイとローカルモビリティアンカーは、異なる事業者に属するフローを区別できる必要があります。

The mobile nodes MN-1 and MN-2 are visiting from Operator-A, and the mobile nodes MN-3 and MN-4 are visiting from Operator-B. The mobile access gateway and the local mobility anchor exchange a specific pair of downlink and uplink GRE keys and save them as part of the mobile node's binding to be used for identifying the flows belonging to each mobile node.

モバイルノードMN-1およびMN-2はオペレーターAからアクセスしており、モバイルノードMN-3およびMN-4はオペレーターBからアクセスしています。モバイルアクセスゲートウェイとローカルモビリティアンカーは、ダウンリンクとアップリンクのGREキーの特定のペアを交換し、各モバイルノードに属するフローを識別するために使用されるモバイルノードのバインディングの一部としてそれらを保存します。

The LMA and the MAG will be able to distinguish each mobile node flow(s) based on the GRE key present in the GRE header of the tunneled payload packet, and route them accordingly. However, the GRE keys, as in this specification, apply to the individual mobility binding updated by the Proxy Binding Update but not to all bindings that the mobile may have registered following procedures described in [RFC5648].

LMAとMAGは、トンネリングされたペイロードパケットのGREヘッダーにあるGREキーに基づいて各モバイルノードフローを区別し、それに応じてルーティングできます。ただし、この仕様のように、GREキーはProxy Binding Updateによって更新される個々のモビリティバインディングに適用されますが、[RFC5648]で説明されている手順に従ってモバイルが登録したすべてのバインディングには適用されません。

3.2. GRE Encapsulation Mode Only

3.2. GREカプセル化モードのみ

In order for the mobile access gateway to request GRE encapsulation mode only without exchanging the GRE keys, the mobile access gateway MUST include the GRE Key option but omit the GRE Key Identifier field in the Proxy Binding Update.

モバイルアクセスゲートウェイがGREキーを交換せずにGREカプセル化モードを要求するためには、モバイルアクセスゲートウェイはGREキーオプションを含める必要がありますが、プロキシバインディング更新のGREキー識別子フィールドを省略しなければなりません。

If the local mobility anchor supports GRE encapsulation and the received Proxy Binding Update contains the GRE Key option but the GRE Key Identifier field is omitted, the mobile access gateway is requesting GRE encapsulation without exchanging the GRE keys dynamically. If the Proxy Binding Update processing is successful, the local mobility anchor sends a successful Proxy Binding Acknowledgement message with the GRE Key option but the GRE Key Identifier field is omitted.

ローカルモビリティアンカーがGREカプセル化をサポートし、受信したプロキシバインディング更新にGREキーオプションが含まれているが、GREキー識別子フィールドが省略されている場合、モバイルアクセスゲートウェイはGREキーを動的に交換せずにGREカプセル化を要求しています。プロキシバインディング更新処理が成功した場合、ローカルモビリティアンカーは、GREキーオプションを使用して成功したプロキシバインディング確認メッセージを送信しますが、GREキー識別子フィールドは省略されています。

When the mobile access gateway and the local mobility anchor successfully negotiate the GRE encapsulation mode only, then no GRE keys are used.

モバイルアクセスゲートウェイとローカルモビリティアンカーがGREカプセル化モードのみを正常にネゴシエートする場合、GREキーは使用されません。

3.3. GRE Encapsulation and Key Exchange

3.3. GREカプセル化とキー交換

The following subsections describe how the mobile access gateway and the local mobility anchor negotiate GRE encapsulation and exchange downlink and uplink GRE keys using the Proxy Mobile IPv6 registration procedure.

次のサブセクションでは、モバイルアクセスゲートウェイとローカルモビリティアンカーがGREカプセル化をネゴシエートし、プロキシモバイルIPv6登録手順を使用してダウンリンクおよびアップリンクGREキーを交換する方法について説明します。

3.3.1. Initial GRE Key Exchange

3.3.1. 初期GREキー交換

When the mobile access gateway determines, based on, e.g., private IPv4 address support [RFC1918], the mobile access gateway local policy, or the MAG-LMA peer agreement, that GRE encapsulation is needed and GRE keys are required, the mobile access gateway MUST include the GRE Key option in the initial Proxy Binding Update message sent to the local mobility anchor. The mobile access gateway MUST include the downlink GRE key in the GRE Key Identifier field of the GRE Key option.

モバイルアクセスゲートウェイが、たとえばプライベートIPv4アドレスサポート[RFC1918]、モバイルアクセスゲートウェイのローカルポリシー、またはMAG-LMAピア合意に基づいて、GREカプセル化が必要であり、GREキーが必要であると判断した場合、モバイルアクセスゲートウェイローカルモビリティアンカーに送信される最初のプロキシバインディング更新メッセージにGREキーオプションを含める必要があります。モバイルアクセスゲートウェイは、GREキーオプションのGREキー識別子フィールドにダウンリンクGREキーを含める必要があります。

After the local mobility anchor successfully processes the initial Proxy Binding Update and accepts the GRE encapsulation request and the downlink GRE key based on a policy check, the local mobility anchor MUST include the GRE Key option with the uplink GRE key in the GRE Key Identifier field in a successful Proxy Binding Acknowledgement and send it to the mobile access gateway.

ローカルモビリティアンカーが初期プロキシバインディング更新を正常に処理し、ポリシーチェックに基づいてGREカプセル化要求とダウンリンクGREキーを受け入れた後、ローカルモビリティアンカーは、GREキー識別子フィールドにアップリンクGREキーを含むGREキーオプションを含める必要があります成功したプロキシバインディング確認で、それをモバイルアクセスゲートウェイに送信します。

3.3.2. GRE Key Exchange during Binding Re-Registration

3.3.2. バインド再登録中のGREキー交換

If the local mobility anchor has successfully negotiated and exchanged the initial GRE keys with the mobile access gateway for a specific mobile node's mobility session, the local mobility anchor MUST maintain the same negotiated uplink GRE key for the lifetime of that mobility session. However, for administrative reasons, e.g., local mobility anchor reboot, the local mobility anchor MAY change the uplink GRE key for the mobility session. In that case, some packet loss may be experienced.

ローカルモビリティアンカーが特定のモバイルノードのモビリティセッションのモバイルアクセスゲートウェイと初期GREキーを正常にネゴシエートおよび交換した場合、ローカルモビリティアンカーは、そのモビリティセッションの存続期間中、同じネゴシエートされたアップリンクGREキーを維持する必要があります。ただし、ローカルモビリティアンカーの再起動などの管理上の理由により、ローカルモビリティアンカーはモビリティセッションのアップリンクGREキーを変更できます（MAY）。その場合、一部のパケット損失が発生する可能性があります。

If the mobile access gateway has successfully negotiated and exchanged the initial GRE keys with the local mobility anchor for a specific mobile node's mobility session, the mobile access gateway MUST include the GRE Key option with the downlink GRE key in the Proxy Binding Update that is used to request a Binding Lifetime Extension. In this case, if the local mobility anchor successfully processes the Proxy Binding Update message, the local mobility anchor MUST return the same uplink GRE key that was exchanged with the mobile access gateway in the last successful Proxy Binding Update for the same mobility session in the GRE Key option in a successful Proxy Binding Acknowledgement message.

モバイルアクセスゲートウェイが特定のモバイルノードのモビリティセッションのローカルモビリティアンカーと初期GREキーを正常にネゴシエートおよび交換した場合、モバイルアクセスゲートウェイは、使用されるプロキシバインディングアップデートにダウンリンクGREキーを含むGREキーオプションを含める必要がありますBinding Lifetime Extensionをリクエストします。この場合、ローカルモビリティアンカーがプロキシバインディング更新メッセージを正常に処理した場合、ローカルモビリティアンカーは、同じモビリティセッションで最後に成功したプロキシバインディング更新でモバイルアクセスゲートウェイと交換された同じアップリンクGREキーを返す必要があります。成功したプロキシバインディング確認メッセージのGREキーオプション。

However, during inter-MAG handoff and if the new mobile access gateway determines, based on, e.g., private IPv4 address support, the mobile access gateway local policy, the MAG-LMA peer agreement, or an indication during the handoff process, that GRE encapsulation and GRE keys exchange are required, the new mobile access gateway MUST include the GRE Key option with the downlink GRE key in the Proxy Binding Update that is used to request an after-handoff Binding Lifetime Extension. In this case, the new mobile access gateway may either pick a new downlink GRE key or use the downlink GRE key that was used by the previous mobile access gateway for the same binding. For the new mobile access gateway to know the downlink GRE key used by the previous mobile access gateway, it may require transfer of context from the previous mobile access gateway to the new mobile access gateway during a handoff. Such mechanisms are out of scope for this specification.

ただし、MAG間のハンドオフ中、および新しいモバイルアクセスゲートウェイが、たとえばプライベートIPv4アドレスのサポート、モバイルアクセスゲートウェイのローカルポリシー、MAG-LMAピア合意、またはハンドオフプロセス中の指示に基づいて決定した場合、そのGREカプセル化とGREキー交換が必要です。新しいモバイルアクセスゲートウェイは、ハンドオフ後のバインディングライフタイム拡張を要求するために使用されるプロキシバインディングアップデートにダウンリンクGREキーとGREキーオプションを含める必要があります。この場合、新しいモバイルアクセスゲートウェイは、新しいダウンリンクGREキーを選択するか、以前のモバイルアクセスゲートウェイが同じバインディングに使用していたダウンリンクGREキーを使用します。新しいモバイルアクセスゲートウェイが以前のモバイルアクセスゲートウェイで使用されていたダウンリンクGREキーを知るには、ハンドオフ中に以前のモバイルアクセスゲートウェイから新しいモバイルアクセスゲートウェイにコンテキストを転送する必要がある場合があります。このようなメカニズムは、この仕様の範囲外です。

If the local mobility anchor successfully processes a handoff-triggered Binding Lifetime Extension Proxy Binding Update message that contains a GRE Key option with a downlink GRE key included, the local mobility anchor MUST return the same uplink GRE key that was exchanged with the previous mobile access gateway for the same mobility session in the GRE Key option in a successful Proxy Binding Acknowledgement.

ローカルモビリティアンカーが、ダウンリンクGREキーを含むGREキーオプションを含むハンドオフトリガーバインディングライフタイムエクステンションプロキシバインディングアップデートメッセージを正常に処理する場合、ローカルモビリティアンカーは、以前のモバイルアクセスと交換された同じアップリンクGREキーを返さなければなりません（MUST）。正常なプロキシバインディング確認のGREキーオプションで同じモビリティセッションのゲートウェイ。

If the local mobility anchor receives a handoff-triggered Binding Lifetime Extension Proxy Binding Update message without the GRE Key option for a Binding Cache entry (BCE) that is using GRE keys and GRE encapsulation, the local mobility anchor makes a policy check regarding GRE encapsulation and GRE key exchange. If, according to the policy check, GRE encapsulation and GRE key exchange are required, the local mobility anchor MUST reject the Proxy Binding Update by sending a Proxy Binding Acknowledgement message with the Status field set to GRE_KEY_OPTION_REQUIRED as defined in Section 6.4. Otherwise, the local mobility anchor SHOULD accept the Proxy Binding Update, and if it is processed successfully, the local mobility anchor MUST return a successful Proxy Binding Acknowledgement without including the GRE Key option.

ローカルモビリティアンカーが、GREキーとGREカプセル化を使用しているバインディングキャッシュエントリ（BCE）のGREキーオプションなしでハンドオフトリガーのバインディングライフタイム拡張プロキシバインディング更新メッセージを受信した場合、ローカルモビリティアンカーはGREカプセル化に関するポリシーチェックを行いますおよびGREキー交換。ポリシーチェックに従って、GREカプセル化およびGREキー交換が必要な場合、ローカルモビリティアンカーは、セクション6.4で定義されているように、ステータスフィールドがGRE_KEY_OPTION_REQUIREDに設定されたプロキシバインディング確認メッセージを送信して、プロキシバインディング更新を拒否する必要があります。それ以外の場合、ローカルモビリティアンカーはプロキシバインディング更新を受け入れる必要があり（SHOULD）、それが正常に処理された場合、ローカルモビリティアンカーは、GREキーオプションを含めずに、正常なプロキシバインディング確認を返さなければなりません。

4. Mobile Access Gateway Considerations

4. モバイルアクセスゲートウェイの考慮事項

4.1. Extensions to the Conceptual Data Structure

4.1. 概念的なデータ構造の拡張

Every mobile access gateway maintains a Binding Update List (BUL) entry for each currently attached mobile node, as explained in Section 6.1 of the Proxy Mobile IPv6 specification [RFC5213]. To support this specification, the conceptual Binding Update List entry data structure must be extended with the following four new additional fields.

プロキシモバイルIPv6仕様[RFC5213]のセクション6.1で説明されているように、すべてのモバイルアクセスゲートウェイは、現在接続されている各モバイルノードのバインディングアップデートリスト（BUL）エントリを維持します。この仕様をサポートするには、概念的なバインディング更新リストエントリのデータ構造を、次の4つの新しい追加フィールドで拡張する必要があります。

o A flag (GRE-encapsulation-enabled) is used for indicating whether GRE encapsulation is enabled for the mobile node's traffic.

o フラグ（GREカプセル化が有効）は、モバイルノードのトラフィックに対してGREカプセル化が有効かどうかを示すために使用されます。

o The downlink GRE key used in the GRE encapsulation header of the tunneled payload packet from the local mobility anchor to the mobile access gateway that is destined to the mobile node. This GRE key is generated by the mobile access gateway and communicated to the local mobility anchor in the GRE Key option in the Proxy Binding Update message.

o ローカルモビリティアンカーからモバイルノード宛のモバイルアクセスゲートウェイへのトンネルペイロードパケットのGREカプセル化ヘッダーで使用されるダウンリンクGREキー。このGREキーは、モバイルアクセスゲートウェイによって生成され、プロキシバインディング更新メッセージのGREキーオプションでローカルモビリティアンカーに通知されます。

o The uplink GRE key used in the GRE encapsulation header of the tunneled payload packet from the mobile access gateway to the local mobility anchor that is originating from the mobile node. This GRE key is obtained from the GRE Key Identifier field of the GRE Key option present in the received Proxy Binding Acknowledgement message sent by the local mobility anchor as specified in this document.

o モバイルアクセスゲートウェイからモバイルノードから発信されているローカルモビリティアンカーへのトンネルペイロードパケットのGREカプセル化ヘッダーで使用されるアップリンクGREキー。このGREキーは、このドキュメントで指定されているように、ローカルモビリティアンカーによって送信された受信プロキシバインディング確認メッセージに存在するGREキーオプションのGREキー識別子フィールドから取得されます。

o A flag indicating whether UDP-based TLV-header format (Section 7.2) is enabled for the mobile node's traffic. This flag is TRUE only when UDP tunneling as in [RFC5844] and GRE encapsulation as in this specification are both enabled for this mobility session.

o UDPベースのTLVヘッダー形式（セクション7.2）がモバイルノードのトラフィックに対して有効かどうかを示すフラグ。このフラグは、[RFC5844]のようなUDPトンネリングと、この仕様のようなGREカプセル化の両方がこのモビリティセッションで有効になっている場合にのみTRUEになります。

4.2. Operational Summary

4.2. 運用の概要

o If the mobile access gateway determines that GRE encapsulation mode only is required, the mobile access gateway MUST include the GRE Key option but omit the GRE Key Identifier field in the Proxy Binding Update message that is sent to the local mobility anchor.

o モバイルアクセスゲートウェイがGREカプセル化モードのみが必要であると判断した場合、モバイルアクセスゲートウェイはGREキーオプションを含める必要がありますが、ローカルモビリティアンカーに送信されるプロキシバインディングアップデートメッセージのGREキーIDフィールドを省略します。

o If the mobile access gateway determines that GRE encapsulation and GRE keys are required, the mobile access gateway MUST include the GRE Key option with the downlink GRE key in the GRE Key Identifier field in the Proxy Binding Update message that is sent to the local mobility anchor.

o モバイルアクセスゲートウェイがGREカプセル化とGREキーが必要であると判断した場合、モバイルアクセスゲートウェイは、ローカルモビリティアンカーに送信されるProxy Binding UpdateメッセージのGRE Key Identifierフィールドに、ダウンリンクGREキーとともにGREキーオプションを含める必要があります。

o After receiving a successful Proxy Binding Acknowledgement message with the GRE Key option with the GRE Key Identifier field omitted, the mobile access gateway MUST update the mobile node's Binding Update List entry described in Section 4.1 by only setting the GRE-encapsulation-enabled flag.

o モバイルアクセスゲートウェイは、GREキー識別子フィールドを省略したGREキーオプションを含む正常なプロキシバインディング確認メッセージを受信した後、GREカプセル化有効フラグを設定するだけで、セクション4.1で説明したモバイルノードのバインディングアップデートリストエントリを更新する必要があります。

o After receiving a successful Proxy Binding Acknowledgement message with the GRE Key option and the uplink GRE key included in the GRE Key Identifier field, the mobile access gateway MUST update the related fields in the mobile node's Binding Update List entry described in Section 4.1. Additionally, the mobile access gateway MUST use the assigned uplink GRE Key for tunneling all the traffic that belongs to this mobile node BUL entry and that originated from the mobile node before forwarding the tunneled traffic to the local mobility anchor.

o GRE Key Identifierフィールドに含まれるGRE KeyオプションとアップリンクGREキーを含む正常なProxy Binding Acknowledgementメッセージを受信した後、モバイルアクセスゲートウェイは、セクション4.1で説明されているモバイルノードのBinding Update Listエントリの関連フィールドを更新する必要があります。さらに、モバイルアクセスゲートウェイは、割り当てられたアップリンクGREキーを使用して、このモバイルノードのBULエントリに属し、トンネルされたトラフィックをローカルモビリティアンカーに転送する前にモバイルノードから発信されたすべてのトラフィックをトンネリングする必要があります。

o If the mobile access gateway includes the GRE Key option in the Proxy Binding Update for a specific mobile node and the local mobility anchor accepts the Proxy Binding Update by sending a Proxy Binding Acknowledgement with a success status code (less than 128) other than GRE_KEY_OPTION_NOT_REQUIRED, but without the GRE Key option, then the mobile access gateway MUST consider that the local mobility anchor does not support the GRE Key option as per this specification. The mobile access gateway SHOULD NOT include the GRE Key option in any subsequent Proxy Binding Update message that is sent to that local mobility anchor.

oモバイルアクセスゲートウェイが特定のモバイルノードのプロキシバインディング更新にGREキーオプションを含み、ローカルモビリティアンカーがプロキシバインディング更新を受け入れる場合、GRE_KEY_OPTION_NOT_REQUIRED以外の成功ステータスコード（128未満）を含むプロキシバインディング確認を送信します。、ただしGREキーオプションがない場合、モバイルアクセスゲートウェイは、ローカルモビリティアンカーがこの仕様に従ってGREキーオプションをサポートしていないことを考慮する必要があります。モバイルアクセスゲートウェイは、そのローカルモビリティアンカーに送信される後続のプロキシバインディングアップデートメッセージにGREキーオプションを含めないでください。

o If the mobile access gateway sent a Proxy Binding Update message without the GRE Key option, but the received Proxy Binding Acknowledgement has the status code GRE_KEY_OPTION_REQUIRED, indicating that GRE encapsulation and GRE keys are required, the mobile access gateway SHOULD resend the Proxy Binding Update message with the GRE Key option. If the mobile access gateway does not support the GRE Key option, it MAY log the event and possibly raise an alarm to indicate a possible misconfiguration.

o モバイルアクセスゲートウェイがGREキーオプションなしでプロキシバインディング更新メッセージを送信したが、受信したプロキシバインディング確認にステータスコードGRE_KEY_OPTION_REQUIREDがあり、GREカプセル化とGREキーが必要であることを示している場合、モバイルアクセスゲートウェイはプロキシバインディング更新メッセージを再送信する必要があります（SHOULD）。 GRE Keyオプション付き。モバイルアクセスゲートウェイがGREキーオプションをサポートしていない場合は、イベントをログに記録し、場合によっては、誤設定の可能性を示すアラームを発生させることがあります。

o If the mobile access gateway sent a Proxy Binding Update message with the GRE Key option and the downlink GRE key included and received a successful Proxy Binding Acknowledgement message with the status code GRE_KEY_OPTION_NOT_REQUIRED, the mobile access gateway MUST consider that GRE encapsulation and GRE keys are not required for this specific mobility session. The mobile access gateway follows procedures in the Proxy Mobile IPv6 specification [RFC5213] for the handling of uplink and downlink traffic and MUST NOT include the GRE Key option in any subsequent Proxy Binding Update message that is sent to the local mobility anchor for this mobility session.

o モバイルアクセスゲートウェイがGREキーオプションとダウンリンクGREキーを含むProxy Binding Updateメッセージを送信し、ステータスコードGRE_KEY_OPTION_NOT_REQUIREDを含む成功したProxy Binding Acknowledgementメッセージを受信した場合、モバイルアクセスゲートウェイはGREカプセル化とGREキーが存在しないことを考慮しなければなりません（MUST）。この特定のモビリティセッションに必要です。モバイルアクセスゲートウェイは、アップリンクおよびダウンリンクトラフィックを処理するためのプロキシモバイルIPv6仕様[RFC5213]の手順に従い、このモビリティセッションのローカルモビリティアンカーに送信される後続のプロキシバインディング更新メッセージにGREキーオプションを含めないでください。。

o If the mobile access gateway has successfully negotiated GRE encapsulation and exchanged the GRE keys with the local mobility anchor for a specific mobility session, the mobile access gateway SHOULD NOT include the GRE Key option in the de-registration Proxy Binding Update.

o モバイルアクセスゲートウェイがGREカプセル化を正常にネゴシエートし、特定のモビリティセッションのローカルモビリティアンカーとGREキーを交換した場合、モバイルアクセスゲートウェイは、登録解除プロキシバインディングアップデートにGREキーオプションを含めないでください。

o On receiving a packet from the tunnel with the GRE header, the mobile access gateway MUST use the GRE key present in the GRE extension header as an additional identifier to determine to which mobility session this packet belongs. The GRE header is removed before further processing takes place.

o GREヘッダーを含むトンネルからパケットを受信すると、モバイルアクセスゲートウェイは、GRE拡張ヘッダーにあるGREキーを追加識別子として使用して、このパケットがどのモビリティセッションに属するかを決定する必要があります。 GREヘッダーは、さらに処理が行われる前に削除されます。

5. Local Mobility Anchor Considerations

5. ローカルモビリティアンカーの考慮事項

5.1. Extensions to the Binding Cache Entry

5.1. バインディングキャッシュエントリの拡張

When the local mobility anchor and the mobile access gateway successfully negotiate GRE encapsulation and exchange downlink and uplink GRE keys, the local mobility anchor MUST maintain the downlink and uplink GRE keys as part of the mobile node's BCE. This requires the BCE described in Section 5.1 of the Proxy Mobile IPv6

ローカルモビリティアンカーとモバイルアクセスゲートウェイがGREカプセル化のネゴシエーションに成功し、ダウンリンクおよびアップリンクGREキーを交換する場合、ローカルモビリティアンカーは、モバイルノードのBCEの一部としてダウンリンクおよびアップリンクGREキーを維持する必要があります。これには、プロキシモバイルIPv6のセクション5.1で説明されているBCEが必要です。

specification [RFC5213] to be extended. To support this specification, the BCE must be extended with the following four additional fields.

拡張される仕様[RFC5213]。この仕様をサポートするには、BCEを次の4つの追加フィールドで拡張する必要があります。

o A flag indicating whether GRE encapsulation is enabled for the mobile node's traffic flows.

o モバイルノードのトラフィックフローに対してGREカプセル化が有効かどうかを示すフラグ。

o The downlink GRE key, assigned by the mobile access gateway and used in the GRE encapsulation header of the tunneled payload packet from the local mobility anchor to the mobile access gateway.

o モバイルアクセスゲートウェイによって割り当てられ、ローカルモビリティアンカーからモバイルアクセスゲートウェイへのトンネルペイロードパケットのGREカプセル化ヘッダーで使用されるダウンリンクGREキー。

o The uplink GRE key, assigned by the local mobility anchor and used in the GRE encapsulation header of the tunneled payload packet from the mobile access gateway to the local mobility anchor.

o ローカルモビリティアンカーによって割り当てられ、モバイルアクセスゲートウェイからローカルモビリティアンカーへのトンネルペイロードパケットのGREカプセル化ヘッダーで使用されるアップリンクGREキー。

5.2. Operational Summary

5.2. 運用の概要

o If the local mobility anchor successfully processes a Proxy Binding Update message with the GRE Key option, but the GRE Key Identifier field is omitted for initial GRE key exchange, the local mobility anchor MUST include the GRE Key option but omit the GRE Key Identifier field when responding with a successful Proxy Binding Acknowledgement message.

o ローカルモビリティアンカーがGREキーオプションを使用してプロキシバインディング更新メッセージを正常に処理したが、GREキー識別子フィールドが最初のGREキー交換で省略されている場合、ローカルモビリティアンカーはGREキーオプションを含める必要がありますが、次の場合はGREキー識別子フィールドを省略します。正常なProxy Binding Acknowledgmentメッセージで応答します。

o If the local mobility anchor successfully processes a Proxy Binding Update message with the GRE Key option and the downlink GRE key included in the GRE Key Identifier field for initial GRE key exchange as in Section 3.3.1, the local mobility anchor MUST include the GRE Key option with the uplink GRE key included in the GRE Key Identifier field when responding with a successful Proxy Binding Acknowledgement message.

o ローカルモビリティアンカーが、セクション3.3.1のように、GREキーオプションと初期GREキー交換用のGREキー識別子フィールドに含まれるダウンリンクGREキーを含むプロキシバインディング更新メッセージを正常に処理する場合、ローカルモビリティアンカーはGREキーを含める必要があります正常なプロキシバインディング確認メッセージで応答するときに、GREキー識別子フィールドにアップリンクGREキーが含まれるオプション。

o If the GRE tunneling is negotiated and the downlink and uplink GRE keys have been exchanged between the mobile access gateway and the local mobility anchor for a specific mobility session, the local mobility anchor MUST use the negotiated downlink GRE key in the GRE header of every packet that is destined to the mobile node of this specific mobility session over the GRE tunnel to the mobile access gateway.

o GREトンネリングがネゴシエートされ、特定のモビリティセッションのモバイルアクセスゲートウェイとローカルモビリティアンカーの間でダウンリンクおよびアップリンクGREキーが交換されている場合、ローカルモビリティアンカーは、すべてのパケットのGREヘッダーでネゴシエートされたダウンリンクGREキーを使用する必要がありますこれは、モバイルアクセスゲートウェイへのGREトンネルを介して、この特定のモビリティセッションのモバイルノードに送信されます。

o If the received Proxy Binding Update message does not contain the GRE Key option, and if the local mobility anchor based on a policy check determines that GRE encapsulation and GRE keys are required, e.g., overlapping IPv4 private addressing is in use, a local mobility anchor local policy, or LMA-MAG peer agreement, the local mobility anchor MUST reject the request and send a Proxy Binding Acknowledgement message to the mobile access gateway with the status code GRE_KEY_OPTION_REQUIRED as defined in Section 6.4. This indicates that GRE encapsulation and GRE keys are required.

o 受信したプロキシバインディング更新メッセージにGREキーオプションが含まれておらず、ポリシーチェックに基づくローカルモビリティアンカーがGREカプセル化とGREキーが必要であると判断した場合、たとえば、重複するIPv4プライベートアドレスが使用されている場合、ローカルモビリティアンカーローカルポリシー、またはLMA-MAGピア合意、ローカルモビリティアンカーは、リクエストを拒否し、セクション6.4で定義されているステータスコードGRE_KEY_OPTION_REQUIREDを使用して、プロキシバインディング確認メッセージをモバイルアクセスゲートウェイに送信する必要があります。これは、GREカプセル化とGREキーが必要であることを示しています。

o If, after receiving and successfully processing a Proxy Binding Update message with the GRE Key option, the local mobility anchor determines, based on a policy check, that GRE encapsulation and GRE keys are not required for this specific binding, e.g., private IPv4 addressing is not in use, the local mobility anchor SHOULD send a successful Proxy Binding Acknowledgement message to the mobile access gateway with the status code GRE_KEY_OPTION_NOT_REQUIRED. In this case, the local mobility anchor MUST NOT include the GRE Key option in the Proxy Binding Acknowledgement.

o GREキーオプションを使用してプロキシバインディング更新メッセージを受信して正常に処理した後、ローカルモビリティアンカーは、ポリシーチェックに基づいて、この特定のバインディングにGREカプセル化とGREキーが不要であると判断します。たとえば、プライベートIPv4アドレス指定は使用されていない場合、ローカルモビリティアンカーは、ステータスコードGRE_KEY_OPTION_NOT_REQUIREDを使用して、モバイルアクセスゲートウェイに正常なプロキシバインディング確認メッセージを送信する必要があります（SHOULD）。この場合、ローカルモビリティアンカーは、プロキシバインディング確認にGREキーオプションを含めてはなりません（MUST NOT）。

o If the local mobility anchor successfully processes a de-registration Proxy Binding Update message, the local mobility anchor follows the same de-registration process as described in the Proxy Mobile IPv6 specification [RFC5213] to clean the Binding Cache entry and all associated resources including the downlink and uplink GRE keys.

o ローカルモビリティアンカーが登録解除プロキシバインディング更新メッセージを正常に処理した場合、ローカルモビリティアンカーは、プロキシモバイルIPv6仕様[RFC5213]で説明されているのと同じ登録解除プロセスに従って、バインディングキャッシュエントリと、ダウンリンクおよびアップリンクGREキー。

o On receiving a packet from the tunnel with the GRE header, the local mobility anchor MUST use the GRE key in the GRE extension header as an additional identifier to determine to which mobility session this packet belongs. The GRE header is removed before further processing takes place.

o GREヘッダーのあるトンネルからパケットを受信すると、ローカルモビリティアンカーは、GRE拡張ヘッダーのGREキーを追加識別子として使用して、このパケットがどのモビリティセッションに属するかを決定する必要があります。 GREヘッダーは、さらに処理が行われる前に削除されます。

6. Message Formats

6. メッセージ形式

This section defines an extension to the Mobile IPv6 protocol [RFC3775] messages. The use of the GRE Key option for supporting GRE tunneling and GRE key exchange for Proxy Mobile IPv6 is defined in this specification.

このセクションでは、モバイルIPv6プロトコル[RFC3775]メッセージの拡張機能を定義します。プロキシモバイルIPv6のGREトンネリングおよびGREキー交換をサポートするためのGREキーオプションの使用は、この仕様で定義されています。

6.1. GRE Key Option

6.1. 灰色のキーオプション

A new mobility option, the GRE Key option, is defined for use in the Proxy Binding Update and Proxy Binding Acknowledgement messages exchanged between the mobile access gateway and the local mobility anchor. This option can be used for negotiating GRE encapsulation mode only or GRE encapsulation and exchanging the downlink and uplink GRE keys. These GRE keys can be used by the peers in all GRE encapsulated payload packets for marking that specific mobile node's data traffic.

新しいモビリティオプションであるGREキーオプションは、モバイルアクセスゲートウェイとローカルモビリティアンカーの間で交換されるプロキシバインディング更新メッセージとプロキシバインディング確認メッセージで使用するために定義されています。このオプションは、GREカプセル化モードのみまたはGREカプセル化をネゴシエートし、ダウンリンクおよびアップリンクGREキーを交換するために使用できます。これらのGREキーは、特定のモバイルノードのデータトラフィックをマーキングするために、すべてのGREカプセル化ペイロードパケットのピアで使用できます。

The alignment requirement for this option is 4n.

このオプションのアライメント要件は4nです。

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Type     |   Length      |           Reserved            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      GRE Key Identifier                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 2: GRE Key Option

図2：GREキーオプション

Type

タイプ

３３

Length

長さ

An 8-bit unsigned integer indicating the length in octets of the option, excluding the Type and Length fields. If the Length field is set to 2, it indicates that the GRE Key Identifier field is not being carried in the option. If the Length field is set to a value of 6, it means that either the downlink or the uplink GRE key is carried.

TypeおよびLengthフィールドを除く、オプションのオクテットの長さを示す8ビットの符号なし整数。長さフィールドが2に設定されている場合、GREキー識別子フィールドがオプションに含まれていないことを示します。長さフィールドが値6に設定されている場合、ダウンリンクまたはアップリンクGREキーのいずれかが伝送されることを意味します。

Reserved

予約済み

These fields are unused. They MUST be initialized to zero by the sender and MUST be ignored by the receiver.

これらのフィールドは未使用です。それらは送信者によってゼロに初期化されなければならず、受信者によって無視されなければなりません。

GRE Key Identifier

GREキー識別子

A 32-bit field containing the downlink or the uplink GRE key. This field is present in the GRE Key option only if the GRE keys are being exchanged using the Proxy Binding Update and Proxy Binding Acknowledgement messages.

ダウンリンクまたはアップリンクGREキーを含む32ビットのフィールド。このフィールドは、GREキーがProxy Binding UpdateおよびProxy Binding Acknowledgmentメッセージを使用して交換されている場合にのみ、GRE Keyオプションに存在します。

6.2. Proxy Binding Update Message Extension

6.2. プロキシバインディング更新メッセージ拡張

This specification extends the Proxy Binding Update message as defined in [RFC5213] with the new TLV-header format (T) flag. The new (T) flag is described below and shown as part of the Proxy Binding Update message as in Figure 3.

この仕様は、[RFC5213]で定義されているように、新しいTLVヘッダー形式（T）フラグを使用してProxy Binding Updateメッセージを拡張します。新しい（T）フラグを以下に説明し、図3のようにプロキシバインディング更新メッセージの一部として示します。

       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 #           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |A|H|L|K|M|R|P|F|T|  Reserved   |           Lifetime            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 3: Proxy Binding Update Message

図3：プロキシバインディング更新メッセージ

TLV-header format (T)

TLVヘッダー形式（T）

When set, this flag indicates that the mobile access gateway requests the use of the TLV header for encapsulating IPv6 or IPv4 packets in IPv4. The TLV-header format is described in Section 7.2. None of the other fields or flags in the Proxy Binding Update are modified by this specification.

設定されている場合、このフラグは、モバイルアクセスゲートウェイがIPv4でIPv6またはIPv4パケットをカプセル化するためにTLVヘッダーの使用を要求することを示します。 TLVヘッダー形式については、セクション7.2で説明しています。プロキシバインディングアップデートの他のフィールドやフラグは、この仕様によって変更されることはありません。

6.3. Proxy Binding Acknowledgement Message Extension

6.3. プロキシバインディング確認メッセージ拡張

This specification extends the Proxy Binding Acknowledgement message as defined in [RFC5213] with the new TLV-header format (T) flag. The new (T) flag is described below and shown as part of the Proxy Binding Acknowledgement message as in Figure 4.

この仕様は、[RFC5213]で定義されているように、Proxy Binding Acknowledgementメッセージを新しいTLVヘッダーフォーマット（T）フラグで拡張します。新しい（T）フラグについては、以下で説明し、図4のように、Proxy Binding Acknowledgmentメッセージの一部として示しています。

       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
                                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                      |    Status     |K|R|P|T|   Res |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Sequence #          |           Lifetime            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 4: Proxy Binding Acknowledgement Message

図4：プロキシバインディング確認メッセージ

TLV-header format (T)

TLVヘッダー形式（T）

When set, this flag indicates that the sender of the Proxy Binding Acknowledgement, the LMA, supports tunneling IPv6-or-IPv4 in IPv4 using TLV-header format. None of the other fields or flags in the Proxy Binding Acknowledgement are modified by this specification.

設定されている場合、このフラグは、プロキシバインディング確認の送信者であるLMAが、TLVヘッダー形式を使用したIPv4でのIPv6-or-IPv4のトンネリングをサポートしていることを示します。プロキシバインディング確認のその他のフィールドまたはフラグは、この仕様によって変更されません。

6.4. Status Codes

6.4. ステータスコード

The following status code values are defined for use in the Binding Acknowledgement message when using Proxy Mobile IPv6.

次のステータスコード値は、Proxy Mobile IPv6を使用する場合のバインディング確認メッセージで使用するために定義されています。

GRE_KEY_OPTION_NOT_REQUIRED (2)

GRE_KEY_OPTION_NOT_REQUIRED（2）

When the local mobility anchor receives a Proxy Binding Update with the GRE Key option, and based on a policy check it determines that GRE encapsulation is not required for this specific mobility session, it uses this code to indicate to the mobile access gateway that the Proxy Binding Update has been processed successfully but GRE encapsulation and GRE keys are not required.

ローカルモビリティアンカーは、GREキーオプションを使用したプロキシバインディングアップデートを受信し、ポリシーチェックに基づいて、この特定のモビリティセッションにGREカプセル化が不要であると判断した場合、このコードを使用して、モバイルアクセスゲートウェイにプロキシバインディングアップデートは正常に処理されましたが、GREカプセル化とGREキーは必要ありません。

GRE_TUNNELING_BUT_TLV_HEADER_NOT_SUPPORTED (3)

GRE_TUNNELING_BUT_TLV_HEADER_NOT_SUPPORTED（3）

If the local mobility anchor receives a Proxy Binding Update with the GRE Key option and TLV-header format (T) flag set, the local mobility anchor uses this code to indicate to the mobile access gateway that GRE encapsulation has been successfully negotiated but TLV-header format is NOT supported.

ローカルモビリティアンカーがGREキーオプションとTLVヘッダーフォーマット（T）フラグセットを使用してProxy Binding Updateを受信した場合、ローカルモビリティアンカーはこのコードを使用して、GREカプセル化が正常にネゴシエートされたがTLV-ヘッダー形式はサポートされていません。

GRE_KEY_OPTION_REQUIRED (163)

GRE_KEY_OPTION_REQUIRED（163）

When the local mobility anchor receives a Proxy Binding Update without the GRE Key option while based on a policy check, the local mobility anchor determines that GRE encapsulation is required for this specific mobility session and uses this code to reject the Proxy Binding Update and indicate to the mobile access gateway that GRE encapsulation and GRE keys are required.

ローカルモビリティアンカーは、ポリシーチェックに基づいてGREキーオプションなしでプロキシバインディングアップデートを受信すると、この特定のモビリティセッションにGREカプセル化が必要であると判断し、このコードを使用してプロキシバインディングアップデートを拒否し、 GREカプセル化とGREキーが必要なモバイルアクセスゲートウェイ。

7. Data Packets Processing Considerations

7. データパケットの処理に関する考慮事項

This section describes how the local mobility anchor and mobile access gateway encapsulate and decapsulate data packets when GRE encapsulation and GRE keys are used for tunneling the mobile node's data traffic between these two mobile nodes.

このセクションでは、GREカプセル化とGREキーを使用して、これら2つのモバイルノード間のモバイルノードのデータトラフィックをトンネリングするときに、ローカルモビリティアンカーとモバイルアクセスゲートウェイがデータパケットをカプセル化およびカプセル化解除する方法について説明します。

7.1. Tunneling Format

7.1. トンネリング形式

When GRE encapsulation is used, the mobile access gateway is allowed to use various tunneling formats depending on the mobile access gateway location and the network capabilities between the mobile access gateway and the local mobility anchor. Using GRE encapsulation, as described in [RFC2784] and [RFC2890], the mobile access gateway can tunnel the IPv6-or-IPv4 payload packet in IPv6 or in IPv4 following the rules in [RFC5213] and [RFC5844].

GREカプセル化が使用されている場合、モバイルアクセスゲートウェイは、モバイルアクセスゲートウェイの場所と、モバイルアクセスゲートウェイとローカルモビリティアンカー間のネットワーク機能に応じて、さまざまなトンネリング形式を使用できます。 [RFC2784]と[RFC2890]で説明されているように、GREカプセル化を使用して、モバイルアクセスゲートウェイは[RFC5213]と[RFC5844]のルールに従ってIPv6またはIPv4でIPv6-or-IPv4ペイロードパケットをトンネリングできます。

If UDP-based tunneling is used in conjunction with GRE encapsulation between the mobile access gateway and the local mobility anchor, the TLV-header UDP tunneling format as shown in Figure 5 MUST be used.

UDPベースのトンネリングをモバイルアクセスゲートウェイとローカルモビリティアンカー間のGREカプセル化と組み合わせて使用する場合は、図5に示すTLVヘッダーUDPトンネリング形式を使用する必要があります。

[IPv4 Header]

[IPv4ヘッダー]

[UDP Header]

[UDPヘッダー]

[TLV Header]

[TLVヘッダー]

[GRE Header]

[GREヘッダー]

[Payload - IPv6 or IPv4 Header]

[ペイロード-IPv6またはIPv4ヘッダー]

Upper Layer protocols

上位層プロトコル

Figure 5: TLV-Header UDP-Based Encapsulation Header Order

図5：TLVヘッダーUDPベースのカプセル化ヘッダーの順序

When a UDP-based tunneling format is used between the mobile access gateway and the local mobility anchor, the use of the TLV header is negotiated during the Proxy Binding Update/Acknowledgement exchange as described in Sections 7.3 and 7.4. If the TLV-header format is agreed upon between the mobile access gateway and local mobility anchor, the local mobility anchor expects the TLV header to follow the UDP header as shown in Figure 5. The TLV header contains the Type field, the following payload packet header type, and its length. The Type field in the TLV header is always set to a value of 0 to enhance the processing of the received packet by ensuring that the receiver can differentiate whether what came after the UDP header is a TLV-header Type field or an IP version field of an IP header. Hence, the TLV header can carry traffic other than IP as indicated in the Next Header field. The distinction between IP and TLV encapsulation is needed, because the Proxy Binding Update (IP packet) and the data packets (GRE packets) can be sent over the same UDP tunnel.

モバイルアクセスゲートウェイとローカルモビリティアンカーの間でUDPベースのトンネリング形式が使用される場合、セクション7.3および7.4で説明されているように、プロキシバインディングの更新/確認の交換中にTLVヘッダーの使用がネゴシエートされます。モバイルアクセスゲートウェイとローカルモビリティアンカーの間でTLVヘッダー形式が合意されている場合、ローカルモビリティアンカーは、図5に示すように、TLVヘッダーがUDPヘッダーの後に続くことを期待します。TLVヘッダーには、タイプフィールド、次のペイロードパケットが含まれますヘッダータイプとその長さ。 TLVヘッダーのTypeフィールドは常に値0に設定され、UDPヘッダーの後に来たものがTLVヘッダーのTypeフィールドまたはIPバージョンフィールドのどちらであるかをレシーバーが区別できるようにすることで、受信パケットの処理を強化します。 IPヘッダー。したがって、TLVヘッダーは、次のヘッダーフィールドに示されているIP以外のトラフィックを伝送できます。プロキシバインディングアップデート（IPパケット）とデータパケット（GREパケット）は同じUDPトンネルを介して送信できるため、IPカプセル化とTLVカプセル化の区別が必要です。

When processing a UDP packet with the TLV-header format, if the receiving node found that the payload packet length as calculated from the UDP header length field is different than its length as calculated from the TLV-header length field, the receiving node MUST discard the received IP packet.

TLVヘッダー形式でUDPパケットを処理するとき、UDPヘッダー長フィールドから計算されたペイロードパケット長がTLVヘッダー長フィールドから計算された長さと異なることが受信ノードで検出された場合、受信ノードは破棄する必要があります受信したIPパケット。

7.2. TLV-Header Tunneling Negotiation

7.2. TLVヘッダートンネリングネゴシエーション

The mobile access gateway negotiates the format for tunneling payload traffic during the Proxy Mobile IPv6 registration procedure. If the mobile access gateway is required to use the TLV-header UDP encapsulation format, the mobile access gateway MUST set the TLV-header format (T) flag in the Proxy Binding Update message sent to the local mobility anchor. If the local mobility anchor supports the TLV-header UDP tunneling format, the local mobility anchor SHOULD set the TLV-header format (T) flag in the Proxy Binding Acknowledgement.

モバイルアクセスゲートウェイは、プロキシモバイルIPv6登録手順中にペイロードトラフィックのトンネリングの形式をネゴシエートします。モバイルアクセスゲートウェイがTLVヘッダーUDPカプセル化形式を使用する必要がある場合、モバイルアクセスゲートウェイは、ローカルモビリティアンカーに送信されるプロキシバインディング更新メッセージにTLVヘッダー形式（T）フラグを設定する必要があります。ローカルモビリティアンカーがTLVヘッダーUDPトンネリング形式をサポートする場合、ローカルモビリティアンカーは、プロキシバインディング確認でTLVヘッダー形式（T）フラグを設定する必要があります（SHOULD）。

Otherwise, the TLV-header format (T) flag is cleared. The setting of the TLV-header Format (T) flag in the Proxy Binding Acknowledgement indicates to the mobile access gateway that it MUST use the TLV-header UDP encapsulation format for all packets tunneled to the local mobility anchor for the entire duration the mobile node is attached to the mobile access gateway. The TLV-header UDP tunneling format SHOULD NOT change during a Binding Lifetime Extension Proxy Binding Update (re-registration) from the same mobile access gateway.

それ以外の場合、TLVヘッダーフォーマット（T）フラグはクリアされます。プロキシバインディング確認のTLVヘッダーフォーマット（T）フラグの設定は、モバイルアクセスゲートウェイに対して、モバイルノード全体の期間中、ローカルモビリティアンカーにトンネリングされるすべてのパケットにTLVヘッダーUDPカプセル化フォーマットを使用する必要があることを示します。モバイルアクセスゲートウェイに接続されています。 TLVヘッダーのUDPトンネリング形式は、同じモバイルアクセスゲートウェイからのバインディングライフタイム拡張プロキシバインディングアップデート（再登録）中に変更してはなりません（SHOULD NOT）。

Any Proxy Binding Update message triggered by a handoff (Section 5.3.4 of [RFC5213]) may renegotiate the tunneling format. Therefore, in order to avoid interoperability issues, the local mobility anchor MUST NOT set the TLV-header format (T) flag unless it was set in the Proxy Binding Update received from the mobile access gateway.

ハンドオフ（[RFC5213]のセクション5.3.4）によってトリガーされたProxy Binding Updateメッセージは、トンネリング形式を再ネゴシエートする可能性があります。したがって、相互運用性の問題を回避するために、モバイルアクセスゲートウェイから受信したProxy Binding Updateで設定されていない限り、ローカルモビリティアンカーはTLVヘッダーフォーマット（T）フラグを設定してはなりません（MUST NOT）。

The TLV-header format is as shown below in Figure 6.

TLVヘッダーのフォーマットは、図6に示すとおりです。

       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  |  Res. |  Next Header  |            Length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 6: TLV-Header Format

図6：TLVヘッダーの形式

Type

タイプ

This field is always 0 (zero) and distinguishes the TLV header from the IPv4 and IPv6 headers.

このフィールドは常に0（ゼロ）であり、TLVヘッダーとIPv4およびIPv6ヘッダーを区別します。

Res.

解像度

These fields are Reserved and unused. They MUST be initialized to zero by the sender and MUST be ignored by the receiver.

これらのフィールドは予約済みであり、未使用です。それらは送信者によってゼロに初期化されなければならず、受信者によって無視されなければなりません。

Next Header

次のヘッダー

An 8-bit unsigned integer that indicates the protocol number of the payload header following this TLV header. It is set to the protocol number as assigned by IANA in the "Assigned Internet Protocol Numbers" registry. For example, if an IPv6 header follows, it should be '41'; if a GRE header follows, it should be '47'.

このTLVヘッダーに続くペイロードヘッダーのプロトコル番号を示す8ビットの符号なし整数。「割り当てられたインターネットプロトコル番号」レジストリでIANAによって割り当てられたプロトコル番号に設定されます。たとえば、IPv6ヘッダーが続く場合、それは「41」でなければなりません。 GREヘッダーが続く場合、「47」である必要があります。

Length

長さ

A 16-bit unsigned integer indicating the length in octets of the payload following this header, excluding the TLV header itself.

TLVヘッダー自体を除く、このヘッダーに続くペイロードの長さをオクテットで示す16ビットの符号なし整数。

7.3. Mobile Access Gateway Operation

7.3. モバイルアクセスゲートウェイの操作

When sending a Proxy Binding Update message over an IPv4 transport network, the mobile access gateway follows the procedures specified in [RFC5844] for using IPv4-UDP encapsulation mode. However, when using GRE header in conjunction with IPv4-UDP encapsulation mode is required, the mobile access gateway MUST set the TLV-header format (T) flag in the Proxy Binding Update and follow this specification for GRE encapsulation negotiation. If the received Proxy Binding Acknowledgement is successful and the TLV-header format (T) flag is set and the GRE Key option included, the mobile access gateway MUST update the mobile node's Binding Update List entry described in Section 4.1 by setting the UDP-based TLV-header format (T) flag. In this case, the mobile access gateway MUST use the TLV-header UDP-based encapsulation format as shown in Figure 5.

IPv4トランスポートネットワークを介してProxy Binding Updateメッセージを送信する場合、モバイルアクセスゲートウェイは、[RFC5844]で指定されている手順に従って、IPv4-UDPカプセル化モードを使用します。ただし、GREヘッダーをIPv4-UDPカプセル化モードと組み合わせて使用する必要がある場合、モバイルアクセスゲートウェイはプロキシバインディングアップデートでTLVヘッダーフォーマット（T）フラグを設定し、このGREカプセル化ネゴシエーションの仕様に従う必要があります。受信したプロキシバインディング確認が成功し、TLVヘッダーフォーマット（T）フラグが設定されており、GREキーオプションが含まれている場合、モバイルアクセスゲートウェイは、UDPベースのTLVヘッダーフォーマット（T）フラグ。この場合、モバイルアクセスゲートウェイは、図5に示すように、TLVヘッダーのUDPベースのカプセル化形式を使用する必要があります。

If the mobile access gateway receives a Proxy Binding Acknowledgement with the status GRE_TUNNELING_BUT_TLV_HEADER_NOT_SUPPORTED in response to a Proxy Binding Update with the GRE Key option and the (T) flag set, the mobile access gateway MUST use GRE encapsulation without UDP encapsulation. If the mobile access gateway is allowed to use GRE encapsulation without UDP tunneling, the mobile access gateway MUST update the mobile node's Binding Update List entry described in Section 4.1 by setting the GRE-encapsulation-enabled flag and the uplink and downlink GRE key fields. In this case, the mobile access gateway MUST set the UDP-based TLV-header format (T) flag to FALSE. A Proxy Binding Acknowledgement message with the status code GRE_TUNNELING_BUT_TLV_HEADER_NOT_SUPPORTED has the (T) flag cleared. Alternatively, the mobile access gateway may resend the Proxy Binding Update to negotiate different tunneling options, e.g., using UDP-based tunneling without GRE encapsulation if possible or de-register the mobile node mobility session.

モバイルアクセスゲートウェイが、GREキーオプションと（T）フラグが設定されたプロキシバインディング更新に応答して、ステータスGRE_TUNNELING_BUT_TLV_HEADER_NOT_SUPPORTEDのプロキシバインディング確認を受信した場合、モバイルアクセスゲートウェイは、UDPカプセル化なしのGREカプセル化を使用する必要があります。モバイルアクセスゲートウェイがUDPトンネリングなしでGREカプセル化の使用を許可されている場合、モバイルアクセスゲートウェイは、GREカプセル化有効フラグとアップリンクおよびダウンリンクGREキーフィールドを設定して、セクション4.1で説明されているモバイルノードのバインディングアップデートリストエントリを更新する必要があります。この場合、モバイルアクセスゲートウェイは、UDPベースのTLVヘッダーフォーマット（T）フラグをFALSEに設定する必要があります。ステータスコードがGRE_TUNNELING_BUT_TLV_HEADER_NOT_SUPPORTEDのプロキシバインディング確認メッセージでは、（T）フラグがクリアされています。または、モバイルアクセスゲートウェイは、プロキシバインディングアップデートを再送信して、たとえば可能であればGREカプセル化なしのUDPベースのトンネリングを使用したり、モバイルノードモビリティセッションの登録を解除したりして、さまざまなトンネリングオプションをネゴシエートします。

7.3.1. Sending and Receiving Data Packets

7.3.1. データパケットの送受信

When the mobile access gateway is located in an IPv6-enabled or IPv4- enabled network, it may be required to use GRE encapsulation for tunneling IPv6 or IPv4 data packets to the local mobility anchor. In this case, and if the mobile access gateway has successfully negotiated GRE encapsulation mode only or GRE encapsulation and GRE keys as described in this specification, the mobile access gateway encapsulates or decapsulates IPv6-or-IPv4 payload packets following the rules described in [RFC5213] and [RFC5844] while ensuring that the GRE header is present as shown in Figure 7.

モバイルアクセスゲートウェイがIPv6対応またはIPv4対応のネットワークにある場合、ローカルモビリティアンカーへのIPv6またはIPv4データパケットのトンネリングにGREカプセル化を使用する必要がある場合があります。この場合、モバイルアクセスゲートウェイは、この仕様で説明されているように、GREカプセル化モードのみ、またはGREカプセル化とGREキーのネゴシエーションに成功した場合、[RFC5213 ]と[RFC5844]で、GREヘッダーが存在することを確認します（図7を参照）。

[IPv6 or IPv4 Header]

[IPv6またはIPv4ヘッダー]

[GRE Header]

[GREヘッダー]

[Payload - IPv6 or IPv4 Header]

[ペイロード-IPv6またはIPv4ヘッダー]

Upper Layer protocols

上位層プロトコル

Figure 7: IPv6-or-IPv4 over IPv4 Using GRE Encapsulation

図7：GREカプセル化を使用したIPv6またはIPv4 over IPv4

On the other hand, if the mobile access gateway is located in an IPv4-only network where NAT has been detected on the path between the mobile access gateway and the local mobility anchor and successfully negotiated GRE encapsulation and the TLV-header format, the mobile access gateway MUST use UDP TLV-header tunneling format when sending an IPv6-or-IPv4 payload packet to the local mobility anchor according to the format described in Figure 5. The source and the destination of the IPv4 outer header are mobile node IPv4 Proxy Care-of Address, IPv4-Proxy-CoA, and the IPv4 local mobility anchor address, IPv4- LMAA, respectively. In addition, the source and the destination IP addresses of the IPv6-or-IPv4 payload data packet are the mobile node's IPv6-or-IPv4 home address, IPv6/IPv4-MN-HoA, and the IPv6-or-IPv4 corresponding node's address, IPv6/IPv4-CN-Addr, respectively.

一方、モバイルアクセスゲートウェイがIPv4のみのネットワークにあり、モバイルアクセスゲートウェイとローカルモビリティアンカーの間のパスでNATが検出され、GREカプセル化とTLVヘッダー形式が正常にネゴシエートされた場合、モバイルアクセスゲートウェイは、図5で説明されている形式に従ってローカルのモビリティアンカーにIPv6-or-IPv4ペイロードパケットを送信するときに、UDP TLVヘッダートンネリング形式を使用する必要があります。IPv4外部ヘッダーの送信元と宛先はモバイルノードIPv4プロキシケアです。 -ofアドレス、IPv4-Proxy-CoA、およびIPv4ローカルモビリティアンカーアドレス、IPv4- LMAA。さらに、IPv6-or-IPv4ペイロードデータパケットの送信元および宛先IPアドレスは、モバイルノードのIPv6-or-IPv4ホームアドレス、IPv6 / IPv4-MN-HoA、およびIPv6-or-IPv4対応ノードのアドレスです。、IPv6 / IPv4-CN-Addr、それぞれ。

7.4. Local Mobility Anchor Operation

7.4. ローカルモビリティアンカーオペレーション

When the local mobility anchor receives a Proxy Binding Update encapsulated in UDP and containing the IPv4 Home Address Request option ([RFC5844]), it needs to follow all the steps in [RFC5213] and [RFC5844]. In addition, if the TLV-header format (T) flag is set in the Proxy Binding Update, the local mobility anchor needs to determine whether it can accept the TLV-header UDP-based encapsulation format. If it does, it SHOULD set the TLV-header format (T) flag in the Proxy Binding Acknowledgement. Otherwise, the local mobility anchor MUST NOT set the TLV-header format (T) flag in the Proxy Binding Acknowledgement.

ローカルモビリティアンカーがUDPにカプセル化され、IPv4ホームアドレス要求オプション（[RFC5844]）を含むプロキシバインディング更新を受信した場合、[RFC5213]および[RFC5844]のすべての手順に従う必要があります。さらに、TLVヘッダー形式（T）フラグがプロキシバインディング更新で設定されている場合、ローカルモビリティアンカーは、TLVヘッダーのUDPベースのカプセル化形式を受け入れることができるかどうかを判断する必要があります。含まれている場合は、プロキシバインディング確認でTLVヘッダーフォーマット（T）フラグを設定する必要があります（SHOULD）。それ以外の場合、ローカルモビリティアンカーは、プロキシバインディング確認でTLVヘッダーフォーマット（T）フラグを設定してはなりません（MUST NOT）。

If the local mobility anchor (LMA) receives a Proxy Binding Update with the GRE Key option and TLV-header format (T) flag set and, based on a policy check, the LMA determines that GRE encapsulation is required and the LMA supports TLV-header tunneling and the LMA sent a successful Proxy Binding Acknowledgement with the TLV-header format (T) flag set, the LMA MUST update the mobile node's Binding Cache entry described in Section 5.1 by setting the GRE-encapsulation-enabled flag and update the uplink and downlink GRE key fields. In addition, the LMA MUST set the UDP-based TLV-header format flag.

ローカルモビリティアンカー（LMA）がGREキーオプションとTLVヘッダーフォーマット（T）フラグセットを含むProxy Binding Updateを受信し、ポリシーチェックに基づいて、LMAがGREカプセル化が必要であり、LMAがTLV-ヘッダートンネリングとLMAがTLVヘッダーフォーマット（T）フラグセットを使用して正常なプロキシバインディング確認を送信した場合、LMAは、セクション5.1で説明したモバイルノードのバインディングキャッシュエントリをGREカプセル化有効フラグを設定して更新し、アップリンクを更新する必要があります。およびダウンリンクGREキーフィールド。さらに、LMAはUDPベースのTLVヘッダーフォーマットフラグを設定する必要があります。

If the LMA receives a Proxy Binding Update with the GRE Key option and TLV-header format (T) flag set and, based on a policy check, the LMA determines that GRE encapsulation is required BUT the LMA does NOT support TLV-header tunneling and if the Proxy Binding Update has been successfully processed, the LMA MUST send a successful Proxy Binding Acknowledgement with the status code GRE_TUNNELING_BUT_TLV_HEADER_NOT_SUPPORTED. This way, the LMA indicates to the mobile access gateway that GRE encapsulation has been successfully negotiated BUT TLV-header UDP-based tunneling format is not supported. In this case, the LMA MUST update the mobile node's BCE described in Section 5.1 by setting the GRE encapsulation enabled flag and update the uplink and downlink GRE key fields. In this case, the LMA MUST set the UDP-based TLV-header format flag to FALSE.

LMAがGREキーオプションとTLVヘッダーフォーマット（T）フラグが設定されたプロキシバインディング更新を受信し、ポリシーチェックに基づいてLMAがGREカプセル化が必要であると判断したが、LMAがTLVヘッダートンネリングをサポートしていない場合プロキシバインディングの更新が正常に処理された場合、LMAはステータスコードGRE_TUNNELING_BUT_TLV_HEADER_NOT_SUPPORTEDを含む正常なプロキシバインディング確認を送信する必要があります。このように、LMAはモバイルアクセスゲートウェイに対して、GREカプセル化が正常にネゴシエートされたことを示しますが、TLVヘッダーのUDPベースのトンネリング形式はサポートされていません。この場合、LMAは、セクション5.1で説明されているモバイルノードのBCEをGREカプセル化有効フラグを設定して更新し、アップリンクおよびダウンリンクのGREキーフィールドを更新する必要があります。この場合、LMAはUDPベースのTLVヘッダー形式フラグをFALSEに設定する必要があります。

If the local mobility anchor and the mobile access gateway have successfully negotiated the TLV-header UDP-based tunneling format and GRE encapsulation for a specific mobility session, the local mobility anchor processes data packets as described in the following subsection.

ローカルモビリティアンカーとモバイルアクセスゲートウェイが、特定のモビリティセッションのTLVヘッダーUDPベースのトンネリング形式とGREカプセル化を正常にネゴシエートした場合、ローカルモビリティアンカーは、次のサブセクションで説明するようにデータパケットを処理します。

7.4.1. Sending and Receiving Data Packets

7.4.1. データパケットの送受信

The local mobility anchor may use GRE encapsulation for tunneling an IPv6 or IPv4 data packet to the mobile access gateway. If the local mobility anchor has successfully negotiated GRE encapsulation with the mobile access gateway for a specific mobility session, the local mobility anchor encapsulates and decapsulates IPv6-or-IPv4 payload data packets following the rules described in [RFC5213] and [RFC5844] while ensuring that the GRE header is present as shown in Figure 7.

ローカルモビリティアンカーは、IPv6またはIPv4データパケットをモバイルアクセスゲートウェイにトンネリングするためにGREカプセル化を使用できます。ローカルモビリティアンカーが特定のモビリティセッションのモバイルアクセスゲートウェイとGREカプセル化を正常にネゴシエートした場合、ローカルモビリティアンカーは、[RFC5213]と[RFC5844]で説明されているルールに従って、IPv6-or-IPv4ペイロードデータパケットをカプセル化およびカプセル化解除します。図7に示すように、GREヘッダーが存在することを確認します。

In the case when TLV-tunneling format and GRE encapsulation for a specific mobility session have been successfully negotiated between the local mobility anchor and the mobile access gateway, the local mobility anchor follows the TLV-header UDP-based tunneling format and header order as shown in Figure 5 to encapsulate IPv4 or IPv6 payload packets in IPv4 before sending the IPv4 packet to the mobile access gateway. In this case, the source and the destination of the IPv4 outer header are IPv4-LMAA and IPv4-Proxy-CoA, respectively. In addition, the source and the destination IP addresses of the IPv6-or-IPv4 payload data packet are IPv6/IPv4-CN-Addr and IPv6/IPv4-MN-HoA, respectively. On the other hand, the local mobility anchor ensures the same TLV-header UDP-based tunneling format and header order when it decapsulates received IPv4 packets from the mobile access gateway for the same mobility session.

特定のモビリティセッションのTLVトンネリング形式とGREカプセル化がローカルモビリティアンカーとモバイルアクセスゲートウェイ間で正常にネゴシエートされた場合、ローカルモビリティアンカーは、TLVヘッダーのUDPベースのトンネリング形式とヘッダーの順序に従います。図5では、IPv4パケットをモバイルアクセスゲートウェイに送信する前に、IPv4またはIPv6ペイロードパケットをIPv4にカプセル化しています。この場合、IPv4外部ヘッダーの送信元と宛先は、それぞれIPv4-LMAAとIPv4-Proxy-CoAです。さらに、IPv6-or-IPv4ペイロードデータパケットの送信元および宛先IPアドレスは、それぞれIPv6 / IPv4-CN-AddrおよびIPv6 / IPv4-MN-HoAです。一方、ローカルモビリティアンカーは、同じモビリティセッションのモバイルアクセスゲートウェイから受信したIPv4パケットをカプセル化解除するときに、同じTLVヘッダーUDPベースのトンネリング形式とヘッダーの順序を保証します。

8. IANA Considerations

8. IANAに関する考慮事項

This specification defines a new mobility option, the GRE Key option, described in Section 6.1. This option is carried in the Mobility Header. The type value for this option has been assigned from the same numbering space as allocated for the other mobility options defined in the Mobile IPv6 specification [RFC3775].

この仕様は、セクション6.1で説明されている新しいモビリティオプションであるGREキーオプションを定義しています。このオプションは、モビリティヘッダーに含まれています。このオプションのタイプ値は、モバイルIPv6仕様[RFC3775]で定義されている他のモビリティオプションに割り当てられているのと同じ番号付けスペースから割り当てられています。

This specification also defines three new Binding Acknowledgement status codes as described in Section 6.4 and IANA has allocated the numeric values as specified in Section 6.4 from the "Status Codes" registry of the Mobility IPv6 Parameters.

この仕様は、セクション6.4で説明されている3つの新しいバインディング確認ステータスコードも定義し、IANAはモビリティIPv6パラメータの「ステータスコード」レジストリからセクション6.4で指定されている数値を割り当てました。

9. Security Considerations

9. セキュリティに関する考慮事項

The GRE Key option, defined in this specification, when carried in Proxy Binding Update and Proxy Binding Acknowledgement messages, reveals the group affiliation of a mobile node identified by its Network Access Identifier (NAI) or an IP address. It may help an attacker in targeting flows belonging to a specific group. This vulnerability can be prevented, by enabling confidentiality protection on the Proxy Binding Update and Proxy Binding Acknowledgement messages where the presence of the NAI and GRE Key options establish a mobile node's relation to a specific group. This vulnerability can also be avoided by enabling confidentiality protection on all the tunneled data packets between the mobile access gateway and the local mobility anchor, for hiding all the markings.

この仕様で定義されているGREキーオプションは、Proxy Binding UpdateおよびProxy Binding Acknowledgmentメッセージで送信されると、ネットワークアクセス識別子（NAI）またはIPアドレスで識別されるモバイルノードのグループ所属を明らかにします。攻撃者が特定のグループに属するフローを標的にするのを助ける可能性があります。この脆弱性は、NAIおよびGREキーオプションの存在が特定のグループとのモバイルノードの関係を確立するプロキシバインディングアップデートおよびプロキシバインディング確認メッセージで機密保護を有効にすることで防止できます。この脆弱性は、モバイルアクセスゲートウェイとローカルモビリティアンカー間のすべてのトンネリングされたデータパケットの機密保護を有効にし、すべてのマーキングを非表示にすることによっても回避できます。

In Proxy Mobile IPv6 [RFC5213], the use of IPsec [RFC4301] for protecting a mobile node's data traffic is optional. Additionally, Proxy Mobile IPv6 recommends the use of Encapsulating Security Payload (ESP) [RFC4303] in tunnel mode when using ESP for protecting the mobile node's data traffic. However, when GRE encapsulation is used, both IPsec tunnel mode and transport mode can be used to protect the GRE header. The IPsec traffic selectors will contain the protocol number for GRE, and there is currently no mechanism to use the GRE key as a traffic selector.

プロキシモバイルIPv6 [RFC5213]では、モバイルノードのデータトラフィックを保護するためのIPsec [RFC4301]の使用はオプションです。さらに、プロキシモバイルIPv6では、ESPを使用してモバイルノードのデータトラフィックを保護する場合、トンネルモードでカプセル化セキュリティペイロード（ESP）[RFC4303]を使用することを推奨しています。ただし、GREカプセル化が使用されている場合、IPsecトンネルモードとトランスポートモードの両方を使用してGREヘッダーを保護できます。 IPsecトラフィックセレクターにはGREのプロトコル番号が含まれます。現在、GREキーをトラフィックセレクターとして使用するメカニズムはありません。

10. Acknowledgements

10. 謝辞

The authors would like to thank Alessio Casati, Barney Barnowski, Mark Grayson, and Parviz Yegani for their input on the need for this option. The authors would like to thank Charlie Perkins, Curtis Provost, Irfan Ali, Jouni Korhonen, Julien Laganier, Kuntal Chowdhury, Suresh Krishnan, and Vijay Devarapalli for their review and comments.

著者は、このオプションの必要性についての意見を提供してくれたAlessio Casati、Barney Barnowski、Mark Grayson、およびParviz Yeganiに感謝します。著者は、レビューとコメントを提供してくれたCharlie Perkins、Curtis Provost、Irfan Ali、Jouni Korhonen、Julien Laganier、Kuntal Chowdhury、Suresh Krishnan、Vijay Devarapalliに感謝します。

11. References

11. 参考文献

11.1. Normative References

11.1. 引用文献

[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.

[RFC1918] Rekhter、Y.、Moskowitz、R.、Karrenberg、D.、Groot、G。、およびE. Lear、「プライベートインターネットのアドレス割り当て」、BCP 5、RFC 1918、1996年2月。

[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.

[RFC2003]パーキンス、C。、「IP内のIPカプセル化」、RFC 2003、1996年10月。

[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月。

[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998.

[RFC2473] Conta、A。およびS. Deering、「Generic Packet Tunneling in IPv6 Specification」、RFC 2473、1998年12月。

[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.

[RFC2784] Farinacci、D.、Li、T.、Hanks、S.、Meyer、D。、およびP. Traina、「Generic Routing Encapsulation（GRE）」、RFC 2784、2000年3月。

[RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", RFC 2890, September 2000.

[RFC2890] Dommety、G。、「GREのキーとシーケンス番号の拡張」、RFC 2890、2000年9月。

[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.

[RFC3775]ジョンソンD.、パーキンスC.、およびJ.アーコ、「IPv6でのモビリティサポート」、RFC 3775、2004年6月。

[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。ガンダベリ、「プロキシモバイルIPv6のIPv4サポート」、RFC 5844、2010年5月。

11.2. Informative References

11.2. 参考引用

[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月。

[RFC5648] Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., and K. Nagami, "Multiple Care-of Addresses Registration", RFC 5648, October 2009.

[RFC5648]脇川R.、Devarapalli、V.、Tsirtsis、G.、Ernst、T。、およびK. Nagami、「Multiple Care-of Addresses Registration」、RFC 5648、2009年10月。

Authors' Addresses

著者のアドレス

Ahmad Muhanna Ericsson, Inc. 2201 Lakeside Blvd. Richardson, TX 75082 USA

Ahmad Muhanna Ericsson、Inc. 2201 Lakeside Blvd.リチャードソン、テキサス州75082米国

   EMail: ahmad.muhanna@ericsson.com

Mohamed Khalil Ericsson, Inc. 6300 Legacy Dr. Plano, TX 75024 USA

Mohamed Khalil Ericsson、Inc. 6300 Legacy Dr. Plano、TX 75024 USA

   EMail: Mohamed.khalil@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

Kent Leung Cisco 170 West Tasman Drive San Jose, CA 95134 USA

Kent Leung Cisco 170 West Tasman Drive San Jose、CA 95134 USA

   EMail: kleung@cisco.com