[要約] RFC 6706は、Asymmetric Extended Route Optimization（AERO）プロトコルに関するものであり、IPv6ネットワークでのエンドツーエンドの通信を最適化するための手法を提供します。AEROの目的は、モバイルノードの移動やネットワークの変更に対応しながら、効率的な通信経路を確立することです。
Internet Engineering Task Force (IETF) F. Templin, Ed.
Request for Comments: 6706 Boeing Research & Technology
Category: Experimental August 2012
ISSN: 2070-1721
Asymmetric Extended Route Optimization (AERO)
非対称拡張ルート最適化（AERO）
Abstract
概要
Nodes attached to common multi-access link types (e.g., multicast-capable, shared media, non-broadcast multiple access (NBMA), etc.) can exchange packets as neighbors on the link, but they may not always be provisioned with sufficient routing information for optimal neighbor selection. Such nodes should therefore be able to discover a trusted intermediate router on the link that provides both forwarding services to reach off-link destinations and redirection services to inform the node of an on-link neighbor that is closer to the final destination. This redirection can provide a useful route optimization, since the triangular path from the ingress link neighbor, to the intermediate router, and finally to the egress link neighbor may be considerably longer than the direct path from ingress to egress. However, ordinary redirection may lead to operational issues on certain link types and/or in certain deployment scenarios. This document therefore introduces an Asymmetric Extended Route Optimization (AERO) capability that addresses the issues.
一般的なマルチアクセスリンクタイプ（たとえば、マルチキャスト対応、共有メディア、非ブロードキャストマルチアクセス（NBMA）など）に接続されたノードは、リンク上のネイバーとしてパケットを交換できますが、常に十分なルーティングでプロビジョニングされているとは限りません最適なネイバー選択のための情報。したがって、そのようなノードは、オフリンク宛先に到達するための転送サービスと、最終宛先により近いオンリンクネイバーをノードに通知するためのリダイレクトサービスの両方を提供するリンク上の信頼できる中間ルーターを検出できる必要があります。入力リダイレクトネイバーから中間ルータ、そして最終的に出力リンクネイバーへの三角形のパスは、入力から出力への直接パスよりもかなり長くなる可能性があるため、このリダイレクトは便利なルート最適化を提供できます。ただし、通常のリダイレクトでは、特定のリンクタイプや特定の展開シナリオで運用上の問題が発生する可能性があります。したがって、このドキュメントでは、問題に対処する非対称拡張ルート最適化（AERO）機能を紹介します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはInternet Standards Trackの仕様ではありません。試験、実験、評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. 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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントでは、インターネットコミュニティの実験プロトコルを定義します。このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 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/rfc6706.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6706で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 IETF Trustおよびドキュメントの作成者として特定された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................4
2. Terminology .....................................................6
3. Motivation ......................................................7
4. Example Use Cases ...............................................8
5. Requirements ....................................................9
6. Asymmetric Extended Route Optimization (AERO) ..................10
6.1. AERO Link Dynamic Routing .................................10
6.2. AERO Node Behavior ........................................11
6.2.1. AERO Node Types ....................................11
6.2.2. AERO Host Behavior .................................11
6.2.3. Edge AERO Router Behavior ..........................11
6.2.4. Intermediate AERO Router Behavior ..................12
6.3. AERO Reference Operational Scenario .......................12
6.4. AERO Specification ........................................14
6.4.1. Traditional Redirection Approaches .................14
6.4.2. AERO Concept of Operations .........................15
6.4.3. Conceptual Data Structures and Protocol Constants ..16
6.4.4. Data Origin Authentication .........................17
6.4.5. AERO Redirection Message Format ....................18
6.4.6. Sending Predirects .................................20
6.4.7. Processing Predirects and Sending Redirects ........21
6.4.8. Forwarding Redirects ...............................22
6.4.9. Processing Redirects ...............................23
6.4.10. Sending Periodic Predirect Keepalives .............24
6.4.11. Neighbor Reachability Considerations ..............26
6.4.12. Mobility Considerations ...........................26
6.4.13. Link-Layer Address Change Considerations ..........27
6.4.14. Prefix Re-provisioning Considerations .............28
6.4.15. Backward Compatibility ............................29
7. IANA Considerations ............................................29
8. Security Considerations ........................................29
9. Acknowledgements ...............................................29
10. References ....................................................30
10.1. Normative References .....................................30
10.2. Informative References ...................................30
Appendix A. Intermediate Router Interworking ......................32
Nodes attached to common multi-access link types (e.g., multicast-capable, shared media, non-broadcast multiple access (NBMA), etc.) can exchange packets as neighbors on the link, but they may not always be provisioned with sufficient routing information for optimal neighbor selection. Such nodes should therefore be able to discover a trusted intermediate router on the link that provides both default forwarding services to reach off-link destinations and redirection services to inform the node of an on-link neighbor that is closer to the final destination.
一般的なマルチアクセスリンクタイプ（たとえば、マルチキャスト対応、共有メディア、非ブロードキャストマルチアクセス（NBMA）など）に接続されたノードは、リンク上のネイバーとしてパケットを交換できますが、常に十分なルーティングでプロビジョニングされているとは限りません最適なネイバー選択のための情報。したがって、このようなノードは、リンク上の信頼できる中間ルーターを検出して、オフリンク宛先に到達するデフォルトの転送サービスと、最終宛先に近いオンリンクネイバーをノードに通知するリダイレクトサービスの両方を提供できる必要があります。
+--------------+
| Router A |
| (D->C) |
+--------------+
|
X--------+--------+--------+------X
| |
+----------+---+ +---+----------+
| Node B | | Router C |
| (default->A) | +-------+------+
+--------------+ .-.
,-( _)-.
.-(_ IPv6 )-.
(__ EUN )
`-(______)-'
+-------+------+
| Node D |
+--------------+
Figure 1: Traditional Multi-Access Link Redirection
図1：従来のマルチアクセスリンクのリダイレクト
Figure 1 shows a traditional multi-access link redirection scenario. In this figure, node ('B') is provisioned with only a default route with router ('A') as the next hop. Router ('A'), in turn, has a more specific route that lists router ('C') as the next-hop neighbor on the link for the End User Network (EUN) attached to node ('D').
図1は、従来のマルチアクセスリンクリダイレクションシナリオを示しています。この図では、ノード（ 'B'）は、次のホップとしてルーター（ 'A'）を使用したデフォルトルートのみでプロビジョニングされています。次に、ルーター（ 'A'）には、ルーター（ 'C'）を、ノード（ 'D'）に接続されたエンドユーザーネットワーク（EUN）のリンク上のネクストホップネイバーとしてリストするより具体的なルートがあります。
If node ('B') has a packet to send to node ('D'), node ('B') is obliged to send its initial packets via router ('A'). Router ('A') then forwards the packet to router ('C') and also returns a redirection control message to inform ('B') that ('C') is, in fact, an on-link neighbor that is closer to the final destination ('D'). After receiving the redirection control message, node ('B') can place a more specific route in its forwarding table so that future packets destined to node ('D') can be sent directly via router ('C'), as shown in Figure 2.
ノード（ 'B'）にノード（ 'D'）に送信するパケットがある場合、ノード（ 'B'）はルーター（ 'A'）を介して最初のパケットを送信する必要があります。次に、ルーター（ 'A'）はパケットをルーター（ 'C'）に転送し、リダイレクト制御メッセージを返して（ 'B'）に（ 'C'）が実際にはより近いリンク上のネイバーであることを通知します最終目的地（ 'D'）へ。リダイレクション制御メッセージを受信した後、ノード（ 'B'）は、より具体的なルートを転送テーブルに配置できるため、次に示すように、ノード（ 'D'）宛の将来のパケットをルーター（ 'C'）経由で直接送信できます。図2。
+--------------+
| Router A |
| (D->C) |
+--------------+
|
X--------+--------+--------+------X
| |
+----------+---+ +---+----------+
| Node B | | Router C |
| (default->A) | +-------+------+
| (D->C) | .-.
+--------------+ ,-( _)-.
.-(_ IPv6 )-.
(__ EUN )
`-(______)-'
+-------+------+
| Node D |
+--------------+
Figure 2: More Specific Route Following Redirection
図2：リダイレクト後のより具体的なルート
This traditional redirection can provide a useful route optimization, since the triangular path from the ingress link neighbor, to the intermediate router, and finally to the egress link neighbor may be considerably longer than the direct path from ingress to egress. However, ordinary redirection may lead to operational issues on certain link types and/or in certain deployment scenarios.
この従来のリダイレクションは、入口リンクネイバーから中間ルーター、最終的に出口リンクネイバーへの三角形のパスが、入口から出口への直接パスよりもかなり長くなる可能性があるため、便利なルート最適化を提供できます。ただし、通常のリダイレクトでは、特定のリンクタイプや特定の展開シナリオで運用上の問題が発生する可能性があります。
For example, when an ingress link neighbor accepts an ordinary redirection control message, it has no way of knowing whether the egress link neighbor is ready and willing to accept packets directly without forwarding through an intermediate router. Likewise, the egress has no way of knowing that the ingress is authorized to forward packets from the claimed network-layer source address. (This is especially important for very large links, since any node on the link can spoof the network-layer source address with low probability of detection even if the link-layer source address cannot be spoofed.) Additionally, the ingress would have no way of knowing whether the direct path to the egress has failed, nor whether the final destination has moved away from the egress to some other network attachment point.
たとえば、入力リンクネイバーが通常のリダイレクト制御メッセージを受け入れる場合、出力ルーターネイバーが準備ができており、中間ルーターを介して転送せずに直接パケットを受け入れる用意があるかどうかを知る方法はありません。同様に、出力には、要求されたネットワーク層の送信元アドレスからのパケットの転送が許可されていることを知る方法がありません。 （リンク層の送信元アドレスを偽装できない場合でも、リンク上のどのノードもネットワーク層の送信元アドレスを偽装して検出する可能性が低いため、これは非常に重要です。）さらに、入力には方法がありません。出力への直接パスが失敗したかどうか、または最終宛先が出力から他のネットワーク接続ポイントに移動したかどうかを知ることができます。
Therefore, a new approach is required that can enable redirection signaling from the egress to the ingress link node under the mediation of a trusted intermediate router. The mechanism is asymmetric (since only the forward direction from the ingress to the egress is optimized) and extended (since the redirection extends forward to the egress before reaching back to the ingress). This document therefore introduces an Asymmetric Extended Route Optimization (AERO) capability that addresses the issues.
したがって、信頼できる中間ルーターの仲介により、出口から入口リンクノードへのリダイレクトシグナリングを可能にする新しいアプローチが必要です。メカニズムは非対称であり（入力から出力への順方向のみが最適化されているため）、拡張されています（リダイレクトは入力に戻る前に出力まで順方向に拡張されるため）。したがって、このドキュメントでは、問題に対処する非対称拡張ルート最適化（AERO）機能を紹介します。
While the AERO mechanisms were initially designed for the specific
purpose of NBMA tunnel virtual interfaces (e.g., see [RFC2529],
[RFC5214], [RFC5569], and [VET]), they can also be applied to any
multiple access link types that support redirection. The AERO
techniques are discussed herein with reference to IPv6
[RFC2460][RFC4861][RFC4862][RFC3315]; however, they can also be
applied to any other network-layer protocol (e.g., IPv4
[RFC0791][RFC0792][RFC2131], etc.) that provides a redirection
service (details of operation for other network-layer protocols are
out of scope).
This document is an Experimental RFC; therefore, it does not seek to define a new standard for the Internet. Experimental status instead of Standards Track has been used since the document proposes a new and different dynamic routing mechanism. Experimentation will focus on candidate multi-access link types that can connect large numbers of neighboring nodes where the use of existing dynamic routing protocols may be impractical. Examples include NBMA tunnel virtual links, large bridged campus LANs, etc.
このドキュメントは試験的なRFCです。したがって、インターネットの新しい標準を定義しようとするものではありません。ドキュメントが新しい異なる動的ルーティングメカニズムを提案しているため、Standards Trackの代わりに実験的なステータスが使用されています。実験では、既存の動的ルーティングプロトコルの使用が実用的でない可能性がある多数の隣接ノードを接続できるマルチアクセスリンクタイプの候補に焦点を当てます。例には、NBMAトンネル仮想リンク、大規模なブリッジキャンパスLANなどが含まれます。
The terminology in the normative references applies; the following terms are defined within the scope of this document:
規範的な参考文献の用語が適用されます。次の用語は、このドキュメントの範囲内で定義されています。
AERO link any link (either physical or virtual) over which the AERO mechanisms can be applied. (For example, a virtual overlay of tunnels can serve as an AERO link.)
AEROリンクは、AEROメカニズムを適用できるリンク（物理リンクまたは仮想リンク）です。 （たとえば、トンネルの仮想オーバーレイはAEROリンクとして機能します。）
AERO interface a node's attachment to an AERO link.
AEROは、ノードのAEROリンクへの接続をインターフェースします。
AERO node a router or host that is connected to an AERO link and that participates in the AERO protocol on that link.
AEROノードAEROリンクに接続され、そのリンク上のAEROプロトコルに参加するルーターまたはホスト。
intermediate AERO router ("intermediate router") a router that configures an advertising router interface on an AERO link over which it can provide default forwarding and redirection services for other AERO nodes.
中間AEROルーター（「中間ルーター」）他のAEROノードにデフォルトの転送およびリダイレクトサービスを提供できるAEROリンク上にアドバタイズルーターインターフェイスを構成するルーター。
edge AERO router ("edge router") a router that configures a non-advertising router interface on an AERO link over which it can connect End User Networks (EUNs) to the AERO link.
エッジAEROルーター（「エッジルーター」）AEROリンクにエンドユーザーネットワーク（EUN）を接続できるAEROリンク上に非広告ルーターインターフェイスを構成するルーター。
AERO host a simple host on an AERO link.
AEROホストは、AEROリンク上の単純なホストです。
ingress AERO node ("ingress node") a node that injects packets into an AERO link.
入力AEROノード（「入力ノード」）AEROリンクにパケットを注入するノード。
egress AERO node ("egress node") a node that receives packets from an AERO link.
出力AEROノード（「出力ノード」）AEROリンクからパケットを受信するノード。
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 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
AERO was designed to operate as an on-demand route optimization function for nodes attached to a single multi-access link, i.e., similar to the standard IPv6 redirection mechanism based on ICMPv6 messaging [RFC4443][RFC4861]. However, AERO differs in that the target of the redirection first receives a pre-authorization notification, after which it returns route optimization information to the source of the original packet. This scenario calls into question whether a standard dynamic routing protocol could be used instead of AERO, but a number of considerations indicate that standard routing protocols may be poorly suited for the use cases AERO was designed to address.
AEROは、単一のマルチアクセスリンクに接続されたノードのオンデマンドルート最適化機能として動作するように設計されています。つまり、ICMPv6メッセージングに基づく標準IPv6リダイレクションメカニズム[RFC4443] [RFC4861]と同様です。ただし、AEROは、リダイレクトのターゲットが最初に事前承認通知を受信し、その後、ルート最適化情報を元のパケットのソースに返すという点で異なります。このシナリオでは、AEROの代わりに標準の動的ルーティングプロトコルを使用できるかどうかを疑問視していますが、多くの考慮事項により、AEROが対処するように設計されたユースケースには標準のルーティングプロトコルがあまり適していない可能性があります。
First, AERO is designed to work on very large multiple access links that may connect a mix of many thousands of routers and hosts. Traditional proactive dynamic routing protocols such as OSPF, IS-IS, RIP, OLSR (Optimized Link State Routing), and TBRPF (Topology Dissemination Based on Reverse-Path Forwarding) may be inefficient in such environments due to the control message overhead scaling when large numbers of routers are present and/or when link capacity is low.
まず、AEROは、何千ものルーターとホストの組み合わせを接続する可能性がある非常に大規模な複数のアクセスリンクで機能するように設計されています。 OSPF、IS-IS、RIP、OLSR（最適化リンクステートルーティング）、およびTBRPF（Reverse-Path Forwardingに基づくトポロジー配布）などの従来のプロアクティブダイナミックルーティングプロトコルは、制御メッセージのオーバーヘッドスケーリングが大規模なため、このような環境では非効率的です。ルーターの数が存在するか、リンク容量が少ない場合。
Second, AERO is designed to work on-demand of data packet arrival, but it only seeks to discover neighbors on the same link and not distant nodes that may be located many link hops away. Reactive dynamic routing protocols such as Ad hoc On-Demand Distance Vector (AODV) and Dynamic Source Routing (DSR) also operate on-demand; however, they flood specialized route discovery messages that reach all nodes on the link and may further traverse multiple link hops before a route reply is received. This requires a multicast-capable network and does not ensure delivery of the original data packet, which may be dropped or delayed during route discovery.
第2に、AEROはデータパケット到着のオンデマンドで機能するように設計されていますが、同じリンク上の近隣を発見することだけを目的としており、多くのリンクホップ離れている可能性のある遠方のノードは発見しません。 Ad Hoc On-Demand Distance Vector（AODV）やDynamic Source Routing（DSR）などのリアクティブな動的ルーティングプロトコルもオンデマンドで動作します。ただし、それらはリンク上のすべてのノードに到達し、ルート応答が受信される前に複数のリンクホップをさらに通過する特殊なルート検出メッセージをフラッディングします。これには、マルチキャスト対応ネットワークが必要であり、元のデータパケットの配信は保証されません。元のデータパケットは、ルート検出中にドロップまたは遅延される可能性があります。
Additionally, AERO is designed to override an existing route to a destination if the existing route directs traffic along a sub-optimal path via an extraneous router on the shared link. AERO nodes send data packets over a preexisting working route, and they may subsequently receive notification of a better route based on route optimization feedback from a trusted on-link neighbor. This stands in contrast to on-demand routing protocols that were designed to operate when no preexisting working routes are present and that multicast explicit route request messages to receive a route reply rather than simply unicast forwarding the data packet via a preexisting route.
さらに、AEROは、既存のルートが共有リンク上の無関係なルーターを介して準最適パスに沿ってトラフィックを誘導する場合、宛先への既存のルートを上書きするように設計されています。 AEROノードは既存の現用ルートを介してデータパケットを送信し、その後、信頼できるオンリンクネイバーからのルート最適化フィードバックに基づいて、より適切なルートの通知を受信します。これは、既存の作業ルートが存在しない場合に動作するように設計され、既存のルートを介してデータパケットをユニキャスト転送するだけでなく、ルート応答を受信するために明示的なルート要求メッセージをマルチキャストするオンデマンドルーティングプロトコルとは対照的です。
Finally, AERO requires less control message and/or processing overhead than standard dynamic routing protocols on links for which the number of routes that must be maintained by each router is far smaller than the total number of routers on the link, and the routes maintained by each router may be changing over time. For example, on a link that connects N nodes, it will often be the case that each node will only communicate with a small number of link neighbors, and the set of neighbors may change dynamically over time. Therefore, the number of active neighbor pairs on the link is V*N (where V is a small variable number) instead of N**2. This is especially important on very large links, e.g., for values of N such as 1,000 or more.
最後に、AEROは、各ルーターが維持する必要のあるルートの数がリンク上のルーターの総数よりもはるかに少ないリンク上の標準の動的ルーティングプロトコルよりも制御メッセージや処理のオーバーヘッドが少なくて済み、ルートは各ルーターは時間とともに変化する可能性があります。たとえば、N個のノードを接続するリンクでは、各ノードが少数のリンクネイバーとのみ通信し、ネイバーのセットが時間とともに動的に変化する場合がよくあります。したがって、リンク上のアクティブなネイバーペアの数は、N ** 2ではなくV * N（Vは小さな変数番号）です。これは、非常に大きなリンク（たとえば、1,000以上などのNの値）で特に重要です。
AERO was designed to satisfy numerous operational use cases. As a first example, a hypothetical major airline has deployed an overlay network on top of the global Internet to track the aircraft in its fleet. The global Internet therefore acts as the "link" over which the overlay network is configured. Each aircraft acts as a mobile router that fronts for an internal network that includes various devices controlled and monitored by the airline. However, it would be impractical for each aircraft to track the changing locations of all other aircraft in the fleet due to control message overhead on limited capacity communication links.
AEROは、数多くの運用上のユースケースを満たすように設計されています。最初の例として、架空の大手航空会社が全世界のインターネット上にオーバーレイネットワークを展開し、航空機を追跡しています。したがって、グローバルインターネットは、オーバーレイネットワークが設定される「リンク」として機能します。各航空機は、航空会社によって制御および監視されるさまざまなデバイスを含む内部ネットワークに向かうモバイルルーターとして機能します。しかしながら、限られた容量の通信リンク上の制御メッセージのオーバーヘッドのために、各航空機が艦隊内の他のすべての航空機の変化する位置を追跡することは実際的ではありません。
In this example, an aircraft ('A') en route to its destination needs to report its ETA and communicate passenger itineraries to other en route aircraft that will be servicing passenger connections. ('A') knows the overlay network addresses of the other aircraft, but does not know the current underlay address mappings. ('A') sends its initial messages targeted to the other aircraft via an airline central dispatch router ('D'), which may be located in a far away location. ('D') forwards the messages, but also initiates the AERO redirection procedure to step out of the triangular path and allow direct aircraft-to-aircraft communications.
この例では、目的地に向かう途中の航空機（「A」）は、ETAを報告し、旅客の旅程を旅客接続を提供する他の途中の航空機に通知する必要があります。 （ 'A'）は他の航空機のオーバーレイネットワークアドレスを知っていますが、現在のアンダーレイアドレスマッピングを知りません。 （「A」）は、離れた場所にある航空会社の中央ディスパッチルーター（「D」）を介して、他の航空機をターゲットとする初期メッセージを送信します。 （ 'D'）はメッセージを転送しますが、AEROリダイレクション手順を開始して、三角形のパスから抜け出し、航空機間の直接通信を可能にします。
In a second example, Mobile Ad hoc Networks (MANETs) are often deployed in environments with a high degree of mobility, attrition, and very limited wireless communications link bandwidth. Such environments typically also require the use of network-layer security mechanisms that view the MANET as a "link" over which encrypted messages are forwarded in an overlay network. In such environments, a dynamic routing protocol running in the overlay network may serve to add unacceptable additional congestion to the already overtaxed wireless links. In that case, the AERO route optimization mechanism can eliminate costly extraneous routing hops without imparting additional control message overhead.
2番目の例では、モバイルアドホックネットワーク（MANET）は、高度な移動性、消耗、および非常に限られたワイヤレス通信リンク帯域幅の環境に展開されることがよくあります。このような環境では、通常、暗号化されたメッセージがオーバーレイネットワークで転送される「リンク」としてMANETを表示するネットワーク層セキュリティメカニズムの使用も必要です。このような環境では、オーバーレイネットワークで実行されている動的ルーティングプロトコルが、すでに過負荷になっているワイヤレスリンクに許容できない追加の輻輳を追加するのに役立つ場合があります。その場合、AEROルート最適化メカニズムは、追加の制御メッセージのオーバーヘッドを与えることなく、コストのかかる無関係なルーティングホップを排除できます。
In a further example, a large campus LAN that is joined by Layer 2 (L2) bridges may connect many thousands of routers and hosts that appear to share a single common multi-access link. In that case, the AERO mechanisms can be applied to satisfy the necessary intra-link route optimization functions without employing an adjunct dynamic routing protocol that may be inefficient for reasons mentioned above.
さらなる例では、レイヤー2（L2）ブリッジによって結合された大規模なキャンパスLANは、単一の共通マルチアクセスリンクを共有しているように見える何千ものルーターとホストを接続する場合があります。その場合、AEROメカニズムを適用して、上記の理由で非効率的な補助動的ルーティングプロトコルを使用せずに、必要なリンク内ルート最適化機能を満たすことができます。
The route optimization mechanism must satisfy the following requirements:
ルート最適化メカニズムは、次の要件を満たす必要があります。
Req 1: Off-load traffic from performance-critical gateways. The mechanism must offload sustained transit though an intermediate AERO router that would otherwise become a traffic concentrator.
要件1：パフォーマンスが重要なゲートウェイからトラフィックをオフロードします。このメカニズムは、中間のAEROルーターを介して持続的なトランジットをオフロードする必要があります。そうしないと、トラフィックコンセントレーターになります。
Req 2: Support route optimization. The ingress AERO node should be able to send packets directly to the egress node without forwarding through an intermediate router for route optimization purposes.
要件2：ルートの最適化をサポートします。入力AEROノードは、ルート最適化の目的で、中間ルーターを介して転送することなく、出力ノードに直接パケットを送信できる必要があります。
Req 3: Support scaling. For scaling purposes, support interworking and control message forwarding between multiple intermediate routers (see Appendix A).
要件3：スケーリングをサポートする。スケーリングの目的で、インターワーキングをサポートし、複数の中間ルーター間のメッセージ転送を制御します（付録Aを参照）。
Req 4: Do not circumvent ingress filtering. The mechanism must not open an attack vector where network-layer source address spoofing is enabled even when link-layer source address spoofing is disabled.
Req 4：入力フィルタリングを回避しないでください。メカニズムは、リンク層の送信元アドレスのスプーフィングが無効になっている場合でも、ネットワーク層の送信元アドレスのスプーフィングが有効になっている攻撃ベクトルを開かないようにする必要があります。
Req 5: Do not expose packets to loss due to filtering. The ingress AERO node must have a way of knowing that the egress AERO node will accept its forwarded packets.
要件5：フィルタリングによりパケットを損失にさらさないでください。入力AEROノードは、出力AEROノードが転送されたパケットを受け入れることを知る方法が必要です。
Req 6: Do not expose packets to loss due to path failure. The ingress AERO node must have a way of discovering whether the AERO egress node has gone unreachable on the route optimized path.
Req 6：パス障害による損失にパケットをさらさないでください。入力AEROノードには、ルート最適化パスでAERO出力ノードが到達不能になったかどうかを検出する方法が必要です。
Req 7: Do not introduce routing loops. Intermediate routers must not invoke a route optimization that would cause a routing loop to form.
Req 7：ルーティングループを導入しないでください。中間ルーターは、ルーティングループを形成する原因となるルート最適化を呼び出してはなりません。
Req 8: Support mobility. The mechanism must continue to work even if the final destination node/network moves from a first egress node and re-associates with a second egress node.
Req 8：モビリティをサポートします。このメカニズムは、最終的な宛先ノード/ネットワークが最初の出力ノードから移動し、2番目の出力ノードに再度関連付けられた場合でも機能し続ける必要があります。
Req 9: Support link layer address changes. The mechanism must continue to work even if the Layer 2 addresses of ingress and/or egress AERO nodes change.
Req 9：サポートリンクレイヤーアドレスの変更。このメカニズムは、入力または出力AEROノードのレイヤー2アドレスが変更されても機能し続ける必要があります。
Req 10: Support network renumbering. The mechanism must provide graceful transition when an AERO node's attached EUN is renumbered.
要件10：ネットワークの再番号付けをサポートします。このメカニズムは、AEROノードの接続されたEUNの番号が付け直されたときに、適切な移行を提供する必要があります。
The following sections specify an Asymmetric Extended Route Optimization (AERO) capability that fulfills the requirements specified in Section 5.
以下のセクションでは、セクション5で指定された要件を満たす非対称拡張ルート最適化（AERO）機能を指定します。
In many AERO link use case scenarios (e.g., small enterprise networks, small and stable MANETs, etc.), routers can engage in a traditional dynamic routing protocol so that routing/forwarding tables can be populated and standard forwarding between routers can be used. In other scenarios (e.g., large enterprise/ISP networks, cellular service provider networks, dynamic MANETs, etc.), this might be impractical due to routing protocol control message scaling issues.
多くのAEROリンクのユースケースシナリオ（小規模なエンタープライズネットワーク、小規模で安定したMANETなど）では、ルーターは従来の動的ルーティングプロトコルに関与できるため、ルーティング/転送テーブルにデータを入力し、ルーター間の標準の転送を使用できます。他のシナリオ（大企業/ ISPネットワーク、セルラーサービスプロバイダーネットワーク、動的MANETなど）では、ルーティングプロトコル制御メッセージのスケーリングの問題により、これは実用的でない場合があります。
When a traditional dynamic routing protocol cannot be used, the mechanisms specified in this section can provide a useful on-demand route discovery capability. When both traditional dynamic routing protocols and the AERO mechanism are active on the same link, routes discovered by the dynamic routing protocol should take precedence over those discovered by AERO.
従来の動的ルーティングプロトコルを使用できない場合、このセクションで指定されたメカニズムは、便利なオンデマンドルート検出機能を提供できます。従来の動的ルーティングプロトコルとAEROメカニズムの両方が同じリンクでアクティブな場合、動的ルーティングプロトコルによって検出されたルートは、AEROによって検出されたルートよりも優先されます。
The following sections discuss characteristics of nodes attached to links over which AERO can be used.
次のセクションでは、AEROを使用できるリンクに接続されたノードの特性について説明します。
Intermediate AERO routers configure their AERO link interfaces as advertising router interfaces (see [RFC4861], Section 6.2.2); therefore, they may send Router Advertisement (RA) messages that include non-zero Router Lifetimes.
中間のAEROルーターは、AEROリンクインターフェースをアドバタイズルーターインターフェースとして構成します（[RFC4861]、セクション6.2.2を参照）。したがって、ゼロ以外のルーターライフタイムを含むルーターアドバタイズ（RA）メッセージを送信する可能性があります。
Edge AERO routers configure their AERO link interfaces as non-advertising router interfaces.
エッジAEROルーターは、AEROリンクインターフェイスを非広告ルーターインターフェイスとして構成します。
AERO hosts configure their AERO link interfaces as simple host interfaces.
AEROホストは、AEROリンクインターフェイスを単純なホストインターフェイスとして構成します。
AERO hosts observe the IPv6 host requirements defined in [RFC6434], except that AERO hosts also engage in the AERO route optimization procedure as specified in Section 6.4.
AEROホストは、[RFC6434]で定義されているIPv6ホスト要件を順守します。ただし、AEROホストは、セクション6.4で指定されているAEROルート最適化手順にも関与します。
Edge AERO routers observe the IPv6 router requirements defined in [RFC6434] except that they act as "hosts" on their non-advertising AERO link router interfaces in the same fashion as for IPv6 Customer Premises Equipment (CPE) routers [RFC6204]. Edge routers can then acquire managed prefix delegations aggregated by an intermediate router through the use of, e.g., DHCPv6 Prefix Delegation [RFC3633], administrative configuration, etc.
エッジAEROルーターは、[RFC6434]で定義されているIPv6ルーター要件を順守しますが、IPv6顧客宅内機器（CPE）ルーター[RFC6204]と同じように、非広告AEROリンクルーターインターフェイスで「ホスト」として機能します。次に、エッジルーターは、DHCPv6プレフィックス委任[RFC3633]、管理構成などを使用して、中間ルーターによって集約された管理されたプレフィックス委任を取得できます。
After the edge router acquires prefixes, it can sub-delegate them to nodes and links within its attached EUNs, then it can forward any outbound packets coming from its EUNs via the intermediate router. The edge router also engages in the AERO route optimization procedure as specified in Section 6.4.
エッジルーターは、プレフィックスを取得した後、接続されたEUN内のノードとリンクにサブプレデリゲートできます。次に、中間ルーターを介して、そのEUNからの送信パケットを転送できます。エッジルータは、セクション6.4で指定されているAEROルート最適化手順にも関与しています。
Intermediate AERO routers observe the IPv6 router requirements defined in [RFC6434] and respond to Router Solicitation (RS) messages from AERO hosts and edge routers on their advertising AERO link router interfaces by returning an RA message. Intermediate routers further configure a DHCP relay/server function on their AERO links and/or provide an administrative interface for delegation of network-layer addresses and prefixes.
中間のAEROルーターは、[RFC6434]で定義されているIPv6ルーターの要件を遵守し、RAメッセージを返すことで、広告用AEROリンクルーターインターフェイス上のAEROホストとエッジルーターからのルーター要請（RS）メッセージに応答します。中間ルーターは、AEROリンクでDHCPリレー/サーバー機能をさらに構成したり、ネットワークレイヤーアドレスとプレフィックスを委任するための管理インターフェイスを提供したりします。
When the intermediate router completes a stateful network-layer address or prefix delegation transaction (e.g., as a DHCPv6 relay/ server, etc.), it establishes forwarding table entries that list the link-layer address of the client AERO node as the link-layer address of the next hop toward the delegated network-layer addresses/ prefixes.
中間ルーターがステートフルネットワーク層アドレスまたはプレフィックス委任トランザクションを完了すると（DHCPv6リレー/サーバーなどとして）、クライアントAEROノードのリンク層アドレスをリンクとしてリストする転送テーブルエントリを確立します。委任されたネットワーク層アドレス/プレフィックスへのネクストホップの層アドレス。
When the intermediate router forwards a packet out the same AERO interface on which it arrived, it initiates an AERO route optimization procedure as specified in Section 6.4.
中間ルーターがパケットを、それが到着したのと同じAEROインターフェースから転送すると、セクション6.4で指定されているAEROルート最適化手順が開始されます。
Figure 3 depicts the AERO reference operational scenario. The figure shows an intermediate AERO router ('A'), two edge AERO routers ('B', 'D'), an AERO host ('F'), and three ordinary IPv6 hosts ('C', 'E', 'G'):
図3は、AEROリファレンスの運用シナリオを示しています。この図は、中間AEROルーター（「A」）、2つのエッジAEROルーター（「B」、「D」）、AEROホスト（「F」）、および3つの通常のIPv6ホスト（「C」、「E」、 'G'）：
.-(::::::::)
.-(::: IPv6 :::)-. +-------------+
(:::: Internet ::::)--| Host G |
`-(::::::::::::)-' +-------------+
`-(::::::)-' 2001:db8:3::1
|
+--------------+ +--------------+
| Intermediate | | AERO Host F |
| AERO Router A| | (default->A) |
| (C->B; E->D) | +--------------+
+--------------+ 2001:db8:2:1
L3(A) L3(F)
L3(A) L2(F)
| |
X-----+-----------+-----------+-----------+---X
| AERO Link |
L2(B) L2(D)
L3(B) L3(D)
+--------------+ +--------------+ .-.
| AERO Edge | | AERO Edge | ,-( _)-.
| Router B | | Router D | .-(_ IPv6 )-.
| (default->A) | | (default->A) |--(__ EUN )
+--------------+ +--------------+ `-(______)-'
2001:db8:0::/48 2001:db8:1::/48 |
| 2001:db8:1::1
.-. +-------------+
,-( _)-. 2001:db8:0::1 | Host E |
.-(_ IPv6 )-. +-------------+ +-------------+
(__ EUN )--| Host C |
`-(______)-' +-------------+
Figure 3: AERO Reference Operational Scenario
図3：AEROリファレンスの運用シナリオ
In Figure 3, the intermediate AERO router ('A') connects to the AERO link and connects to the IPv6 Internet, either directly or via other IPv6 routers (not shown). Intermediate router ('A') configures an AERO link interface with a link-local network-layer address L3(A) and with link-layer address L2(A). The intermediate router ('A') next arranges to add L2(A) to a published list of valid intermediate routers for the link.
図3では、中間AEROルーター（ 'A'）がAEROリンクに接続し、直接または他のIPv6ルーター（図示せず）を介してIPv6インターネットに接続しています。中間ルーター（ 'A'）は、リンクローカルネットワーク層アドレスL3（A）とリンク層アドレスL2（A）でAEROリンクインターフェイスを構成します。次に、中間ルーター（ 'A'）は、リンクの有効な中間ルーターの公開リストにL2（A）を追加するように調整します。
AERO node ('B') is an AERO edge router that connects to the AERO link via an interface with link-local network-layer address L3(B) and with link-layer address L2(B). Node ('B') configures a default route with next-hop network-layer address L3(A) via the AERO interface, and it assigns the network-layer prefix 2001:db8:0::/48 to its attached EUN link. IPv6 host ('C') attaches to the EUN, and it configures the network-layer address 2001:db8:0::1.
AEROノード（ 'B'）は、リンクローカルネットワーク層アドレスL3（B）およびリンク層アドレスL2（B）のインターフェイスを介してAEROリンクに接続するAEROエッジルーターです。ノード（ 'B'）は、AEROインターフェイスを介してネクストホップネットワークレイヤーアドレスL3（A）でデフォルトルートを構成し、接続されたEUNリンクにネットワークレイヤープレフィックス2001：db8：0 :: / 48を割り当てます。 IPv6ホスト（ 'C'）はEUNに接続し、ネットワーク層アドレス2001：db8：0 :: 1を構成します。
AERO node ('D') is an AERO edge router that connects to the AERO link via an interface with link-local network-layer address L3(D) and with link-layer address L2(D). Node ('D') configures a default route with next-hop network-layer address L3(A) via the AERO interface, and it assigns the network-layer prefix 2001:db8:1::/48 to its attached EUN link. IPv6 host ('E') attaches to the EUN, and it configures the network-layer address 2001:db8:1::1.
AEROノード（ 'D'）は、リンクローカルネットワーク層アドレスL3（D）およびリンク層アドレスL2（D）のインターフェイスを介してAEROリンクに接続するAEROエッジルーターです。ノード（ 'D'）は、AEROインターフェイスを介してネクストホップネットワーク層アドレスL3（A）でデフォルトルートを構成し、接続されているEUNリンクにネットワーク層プレフィックス2001：db8：1 :: / 48を割り当てます。 IPv6ホスト（ 'E'）はEUNに接続し、ネットワーク層アドレス2001：db8：1 :: 1を構成します。
AERO host ('F') connects to the AERO link via an interface with link-local network-layer address L3(F) and with link-layer address L2(F). Host ('F') configures a default route with next-hop network-layer address L3(A) via the AERO interface, and it assigns the network-layer address 2001:db8:2::1 to the AERO interface.
AEROホスト（ 'F'）は、リンクローカルネットワークレイヤーアドレスL3（F）およびリンクレイヤーアドレスL2（F）のインターフェイスを介してAEROリンクに接続します。ホスト（ 'F'）は、AEROインターフェイスを介してネクストホップネットワーク層アドレスL3（A）でデフォルトルートを構成し、ネットワーク層アドレス2001：db8：2 :: 1をAEROインターフェイスに割り当てます。
Finally, IPv6 host ('G') connects to an IPv6 network outside of the AERO link domain. Host ('G') configures its IPv6 interface in a manner specific to its attached IPv6 link, and it assigns the network-layer address 2001:db8:3::1 to its IPv6 link interface.
最後に、IPv6ホスト（ 'G'）は、AEROリンクドメイン外のIPv6ネットワークに接続します。ホスト（ 'G'）は、接続されているIPv6リンクに固有の方法でIPv6インターフェースを構成し、ネットワーク層アドレス2001：db8：3 :: 1をそのIPv6リンクインターフェースに割り当てます。
In these arrangements, intermediate router ('A') must maintain state that associates the delegated network-layer addresses/prefixes with the link-local network-layer addresses of the correct edge routers and/or hosts on the AERO link. The nodes must, in turn, maintain at least a default route that points to intermediate router ('A'), and they can discover more-specific routes either via a proactive dynamic routing protocol or via the AERO mechanisms specified in Section 6.4.
これらの配置では、中間ルーター（ 'A'）は、委任されたネットワークレイヤーアドレス/プレフィックスを、AEROリンク上の正しいエッジルーターやホストのリンクローカルネットワークレイヤーアドレスに関連付ける状態を維持する必要があります。次に、ノードは少なくとも中間ルーター（ 'A'）を指すデフォルトルートを維持する必要があり、プロアクティブダイナミックルーティングプロトコルまたはセクション6.4で指定されたAEROメカニズムを介して、より具体的なルートを検出できます。
Section 6.3 describes the AERO reference operational scenario. We now discuss the operation and protocol details of AERO with respect to this reference scenario.
セクション6.3では、AEROリファレンスの運用シナリオについて説明します。次に、この参照シナリオに関して、AEROの操作とプロトコルの詳細について説明します。
With reference to Figure 3, when the IPv6 source host ('C') sends a packet to an IPv6 destination host ('E'), the packet is first forwarded via the EUN to ingress AERO node ('B'). The ingress node ('B') then forwards the packet over its AERO interface to intermediate router ('A'), which then forwards the packet to egress AERO node ('D'), where the packet is finally forwarded to the IPv6 destination host ('E'). When intermediate router ('A') forwards the packet back out on its advertising AERO interface, it must arrange to redirect ingress node ('B') toward egress node ('D') as a better next-hop node on the AERO link that is closer to the final destination. However, this redirection process should only occur if there is assurance that both the ingress and egress nodes are willing participants.
図3を参照すると、IPv6ソースホスト（ 'C'）がIPv6宛先ホスト（ 'E'）にパケットを送信すると、パケットは最初にEUNを介して入力AEROノード（ 'B'）に転送されます。次に、入口ノード（「B」）は、AEROインターフェースを介して中間ルーター（「A」）にパケットを転送します。中間ルーター（「A」）は、パケットを出口AEROノード（「D」）に転送し、最終的にパケットはIPv6宛先に転送されます。ホスト（ 'E'）。中間ルーター（ 'A'）がアドバタイズAEROインターフェイスでパケットを転送する場合、AEROリンクのより良い次のホップノードとして、入口ノード（ 'B'）を出口ノード（ 'D'）にリダイレクトするように調整する必要があります。それは最終目的地に近いです。ただし、このリダイレクトプロセスが発生するのは、入力ノードと出力ノードの両方が参加を希望していることが保証されている場合のみです。
Consider a first alternative in which intermediate router ('A') informs ingress node ('B') only and does not inform egress node ('D') (i.e., "traditional redirection"). In that case, the egress node has no way of knowing that the ingress is authorized to forward packets from their claimed source network-layer addresses, and it may simply elect to drop the packets. Also, the ingress node has no way of knowing whether the egress is performing some form of source address filtering that would reject packets arriving from a node other than a trusted default router, nor whether the egress is even reachable via a direct path that does not involve the intermediate router. Finally, the ingress node has no way of knowing whether the final destination has moved away from the egress node.
中間ルーター（ 'A'）が入口ノード（ 'B'）にのみ通知し、出口ノード（ 'D'）には通知しない（つまり、「従来のリダイレクト」）最初の代替案を検討してください。その場合、出力ノードは、要求された送信元ネットワーク層アドレスからのパケットの転送が入力に許可されていることを知る方法がなく、単にパケットをドロップすることを選択できます。また、入口ノードは、出口が信頼できるデフォルトルーター以外のノードから到着するパケットを拒否する何らかの形の送信元アドレスフィルタリングを実行しているかどうか、または出口が直接経路を介して到達できないかどうかを知る方法がありません。中間ルーターが含まれます。最後に、入口ノードは、最終宛先が出口ノードから移動したかどうかを知る方法がありません。
Consider a second alternative in which intermediate router ('A') informs both ingress node ('B') and egress node ('D') separately, via independent redirection control messages (i.e., "augmented redirection"). In that case, several conditions can occur that could result in communication failures. First, if the ingress receives the redirection control message but the egress does not, subsequent packets sent by the ingress could be dropped due to filtering since the egress would not have neighbor state to verify their source network-layer addresses. Second, if the egress receives the redirection control message but the ingress does not, subsequent packets sent in the reverse direction by the egress would be lost. Finally, timing issues surrounding the establishment and garbage collection of neighbor state at the ingress and egress nodes could yield unpredictable behavior. For example, unless the timing were carefully coordinated through some form of synchronization loop, there would invariably be instances in which one node has the correct neighbor state and the other node does not resulting in non-deterministic packet loss.
中間ルーター（ 'A'）が独立したリダイレクト制御メッセージ（つまり、「拡張リダイレクト」）を介して入口ノード（ 'B'）と出口ノード（ 'D'）の両方に別々に通知する2番目の代替案を検討してください。その場合、通信障害を引き起こす可能性のあるいくつかの条件が発生する可能性があります。第1に、入力がリダイレクト制御メッセージを受信しても出力を受信しない場合、出力は送信元ネットワーク層アドレスを確認するためのネイバー状態を持たないため、入力が送信した後続のパケットはフィルタリングによりドロップされる可能性があります。第2に、出力がリダイレクト制御メッセージを受信しても、入力が受信しない場合、出力によって逆方向に送信された後続のパケットは失われます。最後に、入力ノードと出力ノードでのネイバー状態の確立とガベージコレクションを取り巻くタイミングの問題により、予測できない動作が発生する可能性があります。たとえば、何らかの形の同期ループを介してタイミングを注意深く調整しない限り、一方のノードのネイバー状態が正しく、もう一方のノードが非決定的なパケット損失を引き起こさない場合があります。
Since neither of these alternatives can satisfy the requirements listed in Section 5, a new redirection technique (i.e., "AERO redirection") is needed.
これらの選択肢はいずれもセクション5に記載されている要件を満たすことができないため、新しいリダイレクト手法（「AEROリダイレクト」）が必要です。
AERO redirection is used on links for which the traditional redirection approaches described in Section 6.4.1 are insufficient to satisfy all requirements. We now discuss the concept of operations for this new approach.
AEROリダイレクションは、セクション6.4.1で説明されている従来のリダイレクションアプローチではすべての要件を満たすには不十分なリンクで使用されます。次に、この新しいアプローチの操作の概念について説明します。
Again, with reference to Figure 3, when source host ('C') sends a packet to destination host ('E'), the packet is first forwarded over the source host's attached EUN to ingress node ('B'), which then forwards the packet via its AERO interface to intermediate router ('A').
ここでも、図3を参照して、送信元ホスト（ 'C'）が宛先ホスト（ 'E'）にパケットを送信すると、パケットは最初に送信元ホストの接続されたEUNを介して入力ノード（ 'B'）に転送されます。 AEROインターフェース経由でパケットを中間ルーター（ 'A'）に転送します。
Using AERO redirection, intermediate router ('A') then forwards the packet out the same AERO interface toward egress node ('D') and also sends an AERO "Predirect" message forward to the egress node as specified in Section 6.4.6. The AERO Predirect message includes the identity of ingress node ('B') as well as information that egress node ('D') can use to determine the longest-match prefixes that cover the source and destination network-layer addresses of the packet that triggered the predirection event. After egress node ('D') receives the AERO Predirect message, it process the message and returns an AERO Redirect message to the intermediate router ('A') as specified in Section 6.4.7. (During the process, it also creates or updates neighbor state for ingress node ('B'), and retains this (src, dst) "prefix pair" as ingress filtering information to accept future packets using addresses matched by the prefixes from ingress node ('B').)
AEROリダイレクションを使用して、中間ルーター（ 'A'）はパケットを同じAEROインターフェイスから出力ノード（ 'D'）に転送し、セクション6.4.6で指定されているようにAERO "Predirect"メッセージを出力ノードに転送します。 AERO Predirectメッセージには、入力ノード（ 'B'）のIDと、出力ノード（ 'D'）がパケットの送信元および宛先ネットワーク層アドレスをカバーする最長一致プレフィックスを決定するために使用できる情報が含まれます。 predirectionイベントをトリガーしました。出口ノード（ 'D'）がAERO Predirectメッセージを受信すると、メッセージを処理し、セクション6.4.7で指定されているようにAERO Redirectメッセージを中間ルーター（ 'A'）に返します。 （プロセス中に、入力ノード（ 'B'）のネイバー状態も作成または更新し、この（src、dst）「プレフィックスペア」を入力フィルタリング情報として保持して、入力ノードからのプレフィックスと一致するアドレスを使用して将来のパケットを受け入れる（ 'B'）。）
When the intermediate router ('A') receives the AERO Redirect message, it processes the message and forwards it on to ingress node ('B') as specified in Section 6.4.8. The message includes the identity of egress node ('D') as well as information that ingress node ('B') can use to determine the longest-match prefixes that cover the source and destination network-layer addresses of the packet that triggered the redirection event. After ingress node ('B') receives the AERO Redirect message, it processes the message as specified in Section 6.4.9. (During the process, it also creates or updates neighbor state for egress node ('D'), and retains this prefix pair as forwarding information to forward future packets using addresses matched by the prefixes to the egress node ('D').)
中間ルーター（ 'A'）がAEROリダイレクトメッセージを受信すると、メッセージを処理し、セクション6.4.8で指定されているように、それを入口ノード（ 'B'）に転送します。メッセージには、出力ノードの識別情報（「D」）と、入力ノード（「B」）が、パケットの送信元と宛先のネットワーク層アドレスをカバーする最長一致プレフィックスを決定するために使用できる情報が含まれています。リダイレクトイベント。入力ノード（ 'B'）はAEROリダイレクトメッセージを受信した後、セクション6.4.9で指定されているようにメッセージを処理します。 （プロセス中に、出力ノード（ 'D'）のネイバー状態も作成または更新し、このプレフィックスペアを転送情報として保持して、プレフィックスと一致するアドレスを使用して将来のパケットを出力ノード（ 'D'）に転送します。）
Following the above AERO Predirect/Redirect message exchange, forwarding of packets with source and destination network-layer addresses covered by the longest-match prefix pair is enabled in the forward direction from ingress node ('B') to egress node ('D'). The mechanisms that enable this exchange are specified in the following sections.
上記のAERO Predirect / Redirectメッセージ交換に続いて、最長一致プレフィックスペアでカバーされる送信元および宛先ネットワーク層アドレスを持つパケットの転送が、入力ノード（ 'B'）から出力ノード（ 'D'）への順方向で有効になります）。この交換を可能にするメカニズムについては、次のセクションで説明します。
Each AERO node maintains a per-AERO interface conceptual neighbor cache that includes an entry for each neighbor it communicates with on the AERO link, the same as for any IPv6 interface (see [RFC4861]).
各AEROノードは、AEROリンク上で通信する各ネイバーのエントリを含む、AEROインターフェイスごとの概念的なネイバーキャッシュを維持します。これは、IPv6インターフェイスの場合と同じです（[RFC4861]を参照）。
Each AERO interface neighbor cache entry further maintains two lists of (src, dst) prefix pairs. The AERO node adds a prefix pair to the ACCEPT list if it has been informed by a trusted intermediate router that it is safe to accept packets from the neighbor using network-layer source and destination addresses covered by the prefix pair. The AERO node adds a prefix pair to the FORWARD list if it has been informed by a trusted intermediate router that it is permitted to forward packets to the neighbor using network-layer addresses covered by the prefix pair.
各AEROインターフェイスネイバーキャッシュエントリは、さらに（src、dst）プレフィックスペアの2つのリストを維持します。 AEROノードは、プレフィックスペアがカバーするネットワーク層の送信元アドレスと宛先アドレスを使用してネイバーからのパケットを安全に受け入れることが信頼できる中間ルーターから通知された場合、プレフィックスペアをACCEPTリストに追加します。 AEROノードは、信頼できる中間ルーターからプレフィックスペアの対象となるネットワーク層アドレスを使用してネイバーにパケットを転送することが許可されていることが通知された場合、プレフィックスペアをFORWARDリストに追加します。
When the node adds a prefix pair to a neighbor cache entry ACCEPT list, it also sets an expiration timer for the prefix pair to ACCEPT_TIME seconds. When the node adds a prefix pair to a neighbor cache entry FORWARD list, it also sets an expiration timer for the prefix pair to FORWARD_TIME seconds. The node further maintains a keepalive interval KEEPALIVE_TIME used to limit the number of keepalive control messages. Finally, the node maintains a constant value MAX_RETRY to limit the number of keepalives sent when a neighbor has gone unreachable.
ノードがプレフィックスペアをネイバーキャッシュエントリのACCEPTリストに追加すると、プレフィックスペアの有効期限タイマーもACCEPT_TIME秒に設定されます。ノードが隣接キャッシュエントリのFORWARDリストにプレフィックスペアを追加すると、プレフィックスペアの有効期限タイマーもFORWARD_TIME秒に設定されます。ノードはさらに、キープアライブ制御メッセージの数を制限するために使用されるキープアライブ間隔KEEPALIVE_TIMEを維持します。最後に、ノードは定数MAX_RETRYを維持して、ネイバーが到達不能になったときに送信されるキープアライブの数を制限します。
It is RECOMMENDED that FORWARD_TIME be set to the default constant value 30 seconds to match the default REACHABLE_TIME value specified for IPv6 neighbor discovery [RFC4861].
IPv6ネイバー探索[RFC4861]に指定されたデフォルトのREACHABLE_TIME値と一致するように、FORWARD_TIMEをデフォルトの定数値30秒に設定することをお勧めします。
It is RECOMMENDED that ACCEPT_TIME be set to the default constant value 40 seconds to allow a 10 second window so that the AERO redirection procedure can converge before the ACCEPT_TIME timer decrements below FORWARD_TIME.
ACCEPT_TIMEタイマーがFORWARD_TIMEを下回る前にAEROリダイレクション手順が収束できるように、10秒のウィンドウを許可するためにACCEPT_TIMEをデフォルトの定数値40秒に設定することをお勧めします。
It is RECOMMENDED that KEEPALIVE_TIME be set to the default constant value 5 seconds to providing timely reachability verification without causing excessive control message overhead.
KEEPALIVE_TIMEをデフォルトの定数値5秒に設定して、過度の制御メッセージのオーバーヘッドを引き起こさずにタイムリーな到達可能性検証を提供することをお勧めします。
It is RECOMMENDED that MAX_RETRY be set to 3 the same as described for IPv6 neighbor discovery address resolution in Section 7.3.3 of [RFC4861].
[RFC4861]のセクション7.3.3でIPv6ネイバー探索アドレス解決について説明したのと同じように、MAX_RETRYを3に設定することをお勧めします。
Different values for FORWARD_TIME, ACCEPT_TIME, KEEPALIVE_TIME, and MAX_RETRY MAY be administratively set, if necessary, to better match the AERO link's performance characteristics; however, if different values are chosen, all nodes on the link MUST consistently configure the same values. ACCEPT_TIME SHOULD further be set to a value that is sufficiently longer than FORWARD time to allow the AERO redirection procedure to converge.
FORWARD_TIME、ACCEPT_TIME、KEEPALIVE_TIME、およびMAX_RETRYの異なる値は、AEROリンクのパフォーマンス特性によりよく一致するように、必要に応じて管理上設定できます。ただし、異なる値が選択された場合、リンク上のすべてのノードは常に同じ値を構成する必要があります。 ACCEPT_TIMEはさらに、AEROリダイレクト手順が収束できるように、FORWARD時間よりも十分に長い値に設定する必要があります（SHOULD）。
AERO nodes MUST employ a data origin authentication check for the packets they receive on an AERO interface. In particular, the node considers the network-layer source address correct for the link-layer source address if at least one of the following is true: o the network-layer source address is an on-link address that embeds the link-layer source address, or
AEROノードは、AEROインターフェースで受信するパケットに対してデータ発信元認証チェックを使用する必要があります。特に、ノードは、次の少なくとも1つが当てはまる場合に、ネットワーク層の送信元アドレスがリンク層の送信元アドレスに対して正しいと見なします。oネットワーク層の送信元アドレスが、リンク層の送信元を組み込んだオンリンクアドレスである住所、または
o the network-layer source address is explicitly linked to the link-layer source address through per-neighbor state, or
o ネットワーク層の送信元アドレスが、ネイバーごとの状態を介してリンク層の送信元アドレスに明示的にリンクされている、または
o the link-layer source address is the address of a trusted intermediate AERO router.
o リンク層の送信元アドレスは、信頼できる中間AEROルーターのアドレスです。
When the AERO node receives a packet on an AERO interface, it processes the packet further if it satisfies one of these data origin authentication conditions; otherwise, it drops the packet.
AEROノードは、AEROインターフェースでパケットを受信すると、これらのデータ発信元認証条件のいずれかを満たしている場合、パケットをさらに処理します。それ以外の場合は、パケットをドロップします。
Note that on links in which link-layer address spoofing is possible, AERO nodes may require additional securing mechanisms. To address this, future work will define a strong data origin authentication scheme such as the use of digital signatures.
リンク層アドレスのスプーフィングが可能なリンクでは、AEROノードが追加のセキュリティメカニズムを必要とする場合があることに注意してください。これに対処するために、将来の作業では、デジタル署名の使用などの強力なデータ発信元認証方式を定義します。
AERO Redirect/Predirect messages use the same format as for ICMPv6 Redirect messages depicted in Section 4.5 of [RFC4861]; however, the messages are encapsulated in a UDP header [RFC0768] to distinguish them from ordinary ICMPv6 Redirect messages. AERO Redirect messages therefore require a new UDP service port number 'AERO_PORT'.
AEROリダイレクト/プレリダイレクトメッセージは、[RFC4861]のセクション4.5に示されているICMPv6リダイレクトメッセージと同じ形式を使用します。ただし、メッセージは通常のICMPv6リダイレクトメッセージと区別するために、UDPヘッダー[RFC0768]にカプセル化されます。したがって、AEROリダイレクトメッセージには、新しいUDPサービスポート番号「AERO_PORT」が必要です。
AERO Redirect/Predirect messages are formatted as shown in Figure 4:
AERO Redirect / Predirectメッセージは、図4に示すようにフォーマットされます。
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 (=0) | Code (=0) | Checksum (=0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Target Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Destination Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
Figure 4: AERO Redirect/Predirect Message Format
図4：AEROリダイレクト/プレダイレクトメッセージ形式
The AERO Redirect/Predirect message sender sets the 'Type' field to 0 (since this is not an actual ICMPv6 message), and it also sets the 'Checksum' field to 0 (since the UDP checksum will provide protection for the entire packet). The sender further sets the 'P' bit to 1 if this is a 'Predirect' message and sets the 'P' bit to 0 if this is a 'Redirect' message (as described below).
AERO Redirect / Predirectメッセージ送信者は「タイプ」フィールドを0に設定し（これは実際のICMPv6メッセージではないため）、「チェックサム」フィールドも0に設定します（UDPチェックサムはパケット全体を保護するため） 。送信者はさらに、「Predirect」メッセージの場合は「P」ビットを1に設定し、「Redirect」メッセージの場合は「P」ビットを0に設定します（以下で説明します）。
The sender then encapsulates the AERO Redirect message in IP/UDP headers as shown in Figure 5:
次に送信者は、図5に示すように、AERO RedirectメッセージをIP / UDPヘッダーにカプセル化します。
+--------------------+
~ IP header ~
+--------------------+
~ UDP header ~
+--------------------+
| |
~ AERO Redirect ~
~ Message ~
| |
+--------------------+
Figure 5: AERO Message UDP Encapsulation Format
図5：AEROメッセージのUDPカプセル化形式
The AERO Redirect/Predirect message sender sets the UDP destination port number to 'AERO_PORT' and sets the UDP source port number to a (pseudo-)random value. The sender next sets the UDP length field to the length of the UDP message, then calculates the checksum across the message and writes the value into the UDP checksum field. Next, the sender sets the IP TTL/Hop-limit field to a small integer value chosen to provide a quick exit from any temporal routing loops. It is RECOMMENDED that the sender set IP TTL/Hop-limit to the value 8 unless it has better knowledge of the AERO link characteristics.
AERO Redirect / Predirectメッセージ送信者は、UDP宛先ポート番号を「AERO_PORT」に設定し、UDP送信元ポート番号を（疑似）ランダム値に設定します。送信者は次に、UDP長さフィールドをUDPメッセージの長さに設定し、メッセージ全体のチェックサムを計算し、その値をUDPチェックサムフィールドに書き込みます。次に、送信者は、IP TTL /ホップ制限フィールドを、一時的なルーティングループからすばやく抜けるために選択された小さな整数値に設定します。 AEROリンクの特性をよく理解していない限り、送信者はIP TTL /ホップ制限を値8に設定することをお勧めします。
When an intermediate AERO router forwards a packet out the same AERO interface that it arrived on, the router sends an AERO Predirect message forward toward the egress AERO node instead of sending an ICMPv6 Redirect message back to the ingress AERO node.
中間AEROルーターが到着したのと同じAEROインターフェイスからパケットを転送すると、ルーターは、ICMPv6リダイレクトメッセージを入力AEROノードに送信する代わりに、AERO Predirectメッセージを出力AEROノードに転送します。
In the reference operational scenario, when the intermediate router ('A') forwards a packet sent by the ingress node ('B') toward the egress node ('D'), it also sends an AERO Predirect message forward toward the egress, subject to rate limiting (see Section 8.2 of [RFC4861]). The intermediate router ('A') prepares the AERO Predirect message as follows:
参照運用シナリオでは、中間ルーター（ 'A'）が入口ノード（ 'B'）から送信されたパケットを出口ノード（ 'D'）に転送するときに、AERO Predirectメッセージを出口に向けて転送します。レート制限の対象となります（[RFC4861]のセクション8.2を参照）。中間ルーター（ 'A'）は、AERO Predirectメッセージを次のように準備します。
o the link-layer source address is set to 'L2(A)' (i.e., the link-layer address of the intermediate router).
o リンク層ソースアドレスは「L2（A）」に設定されます（つまり、中間ルーターのリンク層アドレス）。
o the link-layer destination address is set to 'L2(D)' (i.e., the link-layer address of the egress node).
o リンク層宛先アドレスは「L2（D）」に設定されます（つまり、出口ノードのリンク層アドレス）。
o the network-layer source address is set to 'L3(A)' (i.e., the link-local network-layer address of the intermediate router).
o ネットワーク層の送信元アドレスは「L3（A）」に設定されます（つまり、中間ルーターのリンクローカルネットワーク層アドレス）。
o the network-layer destination address is set to 'L3(D)' (i.e., the link-local network-layer address of the egress node).
o ネットワーク層宛先アドレスは「L3（D）」に設定されます（つまり、出口ノードのリンクローカルネットワーク層アドレス）。
o the UDP destination port is set to 'AERO_PORT'.
o UDP宛先ポートは「AERO_PORT」に設定されています。
o the Target and Destination Addresses are both set to 'L3(B)' (i.e., the link-local network-layer address of the ingress node).
o ターゲットアドレスと宛先アドレスは両方とも「L3（B）」に設定されます（つまり、入力ノードのリンクローカルネットワーク層アドレス）。
o on links that require stateful address mapping, the message includes a Target Link Layer Address Option (TLLAO) set to 'L2(B)' (i.e., the link-layer address of the ingress node).
o ステートフルアドレスマッピングを必要とするリンクでは、メッセージに「L2（B）」に設定されたターゲットリンクレイヤーアドレスオプション（TLLAO）が含まれます（つまり、入力ノードのリンクレイヤーアドレス）。
o the message includes a Route Information Option (RIO) [RFC4191] that encodes the ingress node's network-layer address/prefix delegation that covers the network-layer source address of the originating packet.
o メッセージには、送信元パケットのネットワーク層の送信元アドレスをカバーする入口ノードのネットワーク層アドレス/プレフィックス委任をエンコードするルート情報オプション（RIO）[RFC4191]が含まれています。
o the message includes a Redirected Header Option (RHO) that contains the originating packet truncated to ensure that at least the network-layer header is included but the size of the message does not exceed 1280 bytes.
o メッセージには、少なくともネットワークレイヤーヘッダーが含まれていることを確認するために切り捨てられた元のパケットを含むRedirected Header Option（RHO）が含まれていますが、メッセージのサイズは1280バイトを超えません。
o the 'P' bit is set to P=1.
o 「P」ビットはP = 1に設定されます。
The intermediate router ('A') then sends the message forward to the egress node ('D').
次に、中間ルーター（ 'A'）がメッセージを出力ノード（ 'D'）に転送します。
When the egress node ('D') receives an AERO Predirect message, it accepts the message only if it satisfies the data origin authentication requirements specified in Section 6.4.4. The egress further accepts the message only if it is willing to serve as a redirection target.
出口ノード（ 'D'）がAERO Predirectメッセージを受信すると、セクション6.4.4で指定されたデータ発信元認証要件を満たしている場合にのみ、メッセージを受け入れます。出力は、リダイレクトターゲットとして機能する用意がある場合にのみ、メッセージをさらに受け入れます。
Next, the egress node ('D') validates the message according to the ICMPv6 Redirect message validation rules in Section 8.1 of [RFC4861] with the exception that the message includes a Type value of 0, a Checksum value of 0 and a link-local address in the ICMP destination field that differs from the destination address of the packet header encapsulated in the RHO.
次に、出力ノード（「D」）は、[RFC4861]のセクション8.1のICMPv6リダイレクトメッセージ検証ルールに従ってメッセージを検証します。ただし、メッセージにはタイプ値0、チェックサム値0およびリンクが含まれます。 RHOにカプセル化されたパケットヘッダーの宛先アドレスとは異なるICMP宛先フィールドのローカルアドレス。
In the reference operational scenario, when the egress node ('D') receives a valid AERO Predirect message, it either creates or updates a neighbor cache entry that stores the Target address of the message (i.e., the link-local network-layer address of the ingress node ('B')). The egress node ('D') then records the prefix found in the RIO along with its own prefix that matches the network-layer destination address in the packet header found in the RHO with the neighbor cache entry as an acceptable (src, dst) prefix pair. The egress node ('D') then adds the prefix pair to the neighbor cache entry ACCEPT list, and sets/resets an expiration timer for the prefix pair to ACCEPT_TIME seconds. If the timer later expires, the egress node ('D') deletes the prefix pair.
参照運用シナリオでは、出口ノード（ 'D'）が有効なAERO Predirectメッセージを受信すると、メッセージのターゲットアドレス（つまり、リンクローカルネットワーク層アドレス）を格納するネイバーキャッシュエントリを作成または更新します入力ノードの（ 'B'））。次に、出口ノード（ 'D'）は、RIOで見つかったプレフィックスと、ネットワークレイヤーの宛先アドレスと一致する独自のプレフィックスを、RHOで見つかったパケットヘッダー内のパケットヘッダーに記録し、ネイバーキャッシュエントリを受け入れ可能（src、dst）として記録します。プレフィックスのペア。次に、出口ノード（ 'D'）は、プレフィックスペアをネイバーキャッシュエントリのACCEPTリストに追加し、プレフィックスペアの有効期限タイマーをACCEPT_TIME秒に設定/リセットします。タイマーが後で期限切れになると、出口ノード（ 'D'）はプレフィックスペアを削除します。
After processing the message, the egress node ('D') prepares an AERO Redirect message response as follows:
メッセージを処理した後、出口ノード（ 'D'）は次のようにAEROリダイレクトメッセージ応答を準備します。
o the link-layer source address is set to 'L2(D)' (i.e., the link-layer address of the egress node).
o リンク層の送信元アドレスは「L2（D）」に設定されます（つまり、出口ノードのリンク層アドレス）。
o the link-layer destination address is set to 'L2(A)' (i.e., the link-layer address of the intermediate router).
o リンク層宛先アドレスは「L2（A）」に設定されます（つまり、中間ルーターのリンク層アドレス）。
o the network-layer source address is set to 'L3(D)' (i.e., the link-local network-layer address of the egress node).
o ネットワーク層の送信元アドレスは「L3（D）」に設定されます（つまり、出口ノードのリンクローカルネットワーク層アドレス）。
o the network-layer destination address is set to 'L3(B)' (i.e., the link-local network-layer address of the ingress node).
o ネットワーク層の宛先アドレスは「L3（B）」に設定されます（つまり、入口ノードのリンクローカルネットワーク層アドレス）。
o the UDP destination port is set to 'AERO_PORT'.
o UDP宛先ポートは「AERO_PORT」に設定されています。
o the Target and the Destination Addresses are both set to 'L3(D)' (i.e., the link-local network-layer address of the egress node).
o ターゲットおよび宛先アドレスは両方とも「L3（D）」に設定されます（つまり、出口ノードのリンクローカルネットワーク層アドレス）。
o on links that require stateful address mapping, the message includes a Target Link Layer Address Option (TLLAO) set to 'L2(D)'.
o ステートフルアドレスマッピングが必要なリンクでは、メッセージに「L2（D）」に設定されたターゲットリンクレイヤーアドレスオプション（TLLAO）が含まれます。
o the message includes an RIO that encodes the egress node's network-layer address/prefix delegation that covers the network-layer destination address of the originating packet.
o メッセージには、発信ノードのネットワーク層アドレス/プレフィックス委任をエンコードするRIOが含まれており、発信元パケットのネットワーク層宛先アドレスをカバーしています。
o the message includes as much of the RHO copied from the corresponding AERO Predirect message as possible such that at least the network-layer header is included but the size of the message does not exceed 1280 bytes.
o メッセージには、対応するAERO PredirectメッセージからコピーされたRHOができるだけ多く含まれるため、少なくともネットワーク層ヘッダーは含まれますが、メッセージのサイズは1280バイトを超えません。
o the 'P' bit is set to P=0.
o 「P」ビットはP = 0に設定されます。
After the egress node ('D') prepares the AERO Redirect message, it sends the message to the intermediate router ('A').
出力ノード（ 'D'）はAEROリダイレクトメッセージを準備した後、メッセージを中間ルーター（ 'A'）に送信します。
When the intermediate router ('A') receives an AERO Redirect message, it accepts the message only if it satisfies the data origin authentication requirements specified in Section 6.4.4. Next, the intermediate router ('A') validates the message the same as described in Section 6.4.7. Following validation, the intermediate router ('A') processes the Redirect, and then forwards a corresponding Redirect on to the ingress node ('B') as follows.
中間ルーター（ 'A'）がAEROリダイレクトメッセージを受信すると、セクション6.4.4で指定されたデータ発信元認証要件を満たしている場合にのみ、メッセージを受け入れます。次に、中間ルーター（ 'A'）は、セクション6.4.7で説明したのと同じ方法でメッセージを検証します。検証後、中間ルーター（ 'A'）はリダイレクトを処理し、次のように対応するリダイレクトを入口ノード（ 'B'）に転送します。
In the reference operational scenario, the intermediate router ('A') receives the AERO Redirect message from the egress node ('D') and prepares to forward a corresponding AERO Redirect message to the ingress node ('B'). The intermediate router ('A') then verifies that the RIO encodes a network-layer address/prefix that the egress node ('D') is authorized to use, and it discards the message if verification fails. Otherwise, the intermediate router ('A') changes the link-layer source address of the message to 'L2(A)', changes the network-layer source address of the message to the link-local network-layer address 'L3(A)', and changes the link-layer destination address to 'L2(B)' . The intermediate router ('A') finally decrements the IP TTL/Hop-limit and forwards the message to the ingress node ('B').
参照運用シナリオでは、中間ルーター（ 'A'）が出口ノード（ 'D'）からAEROリダイレクトメッセージを受信し、対応するAEROリダイレクトメッセージを入口ノード（ 'B'）に転送する準備をします。次に中間ルーター（ 'A'）は、RIOが出口ノード（ 'D'）が使用を許可するネットワーク層アドレス/プレフィックスをエンコードしていることを確認し、確認に失敗した場合はメッセージを破棄します。それ以外の場合、中間ルーター（ 'A'）はメッセージのリンク層ソースアドレスを 'L2（A）'に変更し、メッセージのネットワーク層ソースアドレスをリンクローカルネットワーク層アドレス 'L3（ A） '、リンク層の宛先アドレスを' L2（B） 'に変更します。中間ルーター（ 'A'）は最終的にIP TTL /ホップ制限をデクリメントし、メッセージを入口ノード（ 'B'）に転送します。
When the ingress node ('B') receives an AERO Redirect message (i.e., one with P=0), it accepts the message only if it satisfies the data origin authentication requirements specified in Section 6.4.4. Next, the ingress node ('B') validates the message the same as described in Section 6.4.6. Following validation, the ingress node ('B') then processes the message as follows.
入力ノード（ 'B'）がAEROリダイレクトメッセージ（つまり、P = 0のメッセージ）を受信すると、セクション6.4.4で指定されたデータ発信元認証要件を満たしている場合にのみ、メッセージを受け入れます。次に、入力ノード（ 'B'）は、セクション6.4.6で説明されているのと同じ方法でメッセージを検証します。検証に続いて、入力ノード（ 'B'）はメッセージを次のように処理します。
In the reference operational scenario, when the ingress node ('B') receives the AERO Redirect message, it either creates or updates a neighbor cache entry that stores the Target address of the message (i.e., the link-local network-layer address of the egress node 'L3(D)'). The ingress node ('B') then records the (src, dst) prefix pair associated with the triggering packet in the neighbor cache entry FORWARD list, i.e., it records its prefix that matches the redirected packet's network-layer source address and the prefix listed in the RIO as the prefix pair. The ingress node ('B') then sets/resets an expiration timer for the prefix pair to FORWARD_TIME seconds. If the timer later expires, the ingress node ('B') deletes the entry.
参照運用シナリオでは、入口ノード（ 'B'）がAEROリダイレクトメッセージを受信すると、メッセージのターゲットアドレス（つまり、リンクローカルネットワーク層のアドレス）を格納するネイバーキャッシュエントリを作成または更新します。出力ノード 'L3（D）'）。次に、入口ノード（ 'B'）は、トリガーパケットに関連付けられた（src、dst）プレフィックスペアをネイバーキャッシュエントリのFORWARDリストに記録します。つまり、リダイレクトされたパケットのネットワークレイヤーの送信元アドレスとプレフィックスに一致するプレフィックスを記録します。 RIOにプレフィックスペアとしてリストされます。次に、入力ノード（ 'B'）は、プレフィックスペアの有効期限タイマーをFORWARD_TIME秒に設定/リセットします。タイマーが後で期限切れになると、入口ノード（「B」）がエントリーを削除します。
Now, the ingress node ('B') has a neighbor cache FORWARD list entry for the prefix pair, and the egress node ('D') has a neighbor cache ACCEPT list entry for the prefix pair. Therefore, the ingress node ('B') may forward ordinary network-layer data packets with network-layer source and destination addresses that match the prefix pair directly to the egress node ('D') without forwarding through the intermediate router ('A'). Note that the ingress node must have a way of informing the network layer of a route that associates the destination prefix with this neighbor cache entry. The manner of establishing such a route (and deleting it when it is no longer necessary) is left to the implementation.
これで、入力ノード（ 'B'）にはプレフィックスペアの隣接キャッシュFORWARDリストエントリがあり、出力ノード（ 'D'）にはプレフィックスペアの隣接キャッシュACCEPTリストエントリがあります。したがって、入力ノード（「B」）は、プレフィックスペアと一致するネットワーク層の送信元アドレスと宛先アドレスを持つ通常のネットワーク層データパケットを、中間ルーター（「A」 '）。入力ノードには、宛先プレフィックスをこのネイバーキャッシュエントリに関連付けるルートをネットワーク層に通知する方法が必要であることに注意してください。このようなルートを確立する方法（および不要になった場合は削除する方法）は、実装に委ねられています。
To enable packet forwarding in the reverse direction, a separate AERO redirection operation is required that is the mirror-image of the forward operation described above but the link segments traversed in the forward and reverse directions may be different, i.e., the operations are asymmetric.
逆方向のパケット転送を有効にするには、上記の順方向操作の鏡像である個別のAEROリダイレクション操作が必要ですが、順方向と逆方向に渡されるリンクセグメントは異なる場合があります。つまり、操作は非対称です。
In order to prevent prefix pairs from expiring while data packets are actively flowing, the ingress node ('B') can send AERO Predirect messages directly to the egress node ('D') as a "keepalive" to solicit AERO Redirect messages. The node should send such keepalive messages only when a data packet covered by the prefix pair has been sent recently, and should wait for at least KEEPALIVE_TIME seconds before sending each successive keepalive message in order to limit control message overhead.
データパケットがアクティブに流れている間にプレフィックスペアが期限切れになるのを防ぐために、入口ノード（ 'B'）はAEROリダイレクトメッセージを「キープアライブ」として直接出口ノード（ 'D'）に送信し、AEROリダイレクトメッセージを要求します。ノードは、プレフィックスペアでカバーされるデータパケットが最近送信された場合にのみこのようなキープアライブメッセージを送信し、制御メッセージのオーバーヘッドを制限するために、連続する各キープアライブメッセージを送信する前に少なくともKEEPALIVE_TIME秒待機する必要があります。
In the reference operational scenario, when the ingress node ('B') needs to refresh the FORWARD timer for a specific prefix pair, it can send an AERO Predirect message directly to the egress node ('D') prepared as follows:
参照運用シナリオでは、入力ノード（ 'B'）が特定のプレフィックスペアのFORWARDタイマーを更新する必要がある場合、次のように準備された出力ノード（ 'D'）に直接AERO Predirectメッセージを送信できます。
o the link-layer source address is set to 'L2(B)' (i.e., the link-layer address of the ingress node).
o リンク層ソースアドレスは「L2（B）」に設定されます（つまり、入力ノードのリンク層アドレス）。
o the link-layer destination address is set to 'L2(D)' (i.e., the link-layer address of the egress node).
o リンク層宛先アドレスは「L2（D）」に設定されます（つまり、出口ノードのリンク層アドレス）。
o the network-layer source address is set to 'L3(B)' (i.e., the link-local network-layer address of the ingress node).
o ネットワーク層の送信元アドレスは「L3（B）」に設定されます（つまり、入力ノードのリンクローカルネットワーク層アドレス）。
o the network-layer destination address is set to 'L3(D)' (i.e., the link-local network-layer address of the egress node).
o ネットワーク層宛先アドレスは「L3（D）」に設定されます（つまり、出口ノードのリンクローカルネットワーク層アドレス）。
o the UDP destination port is set to 'AERO_PORT'.
o UDP宛先ポートは「AERO_PORT」に設定されています。
o the Predirect Target and Destination Addresses are both set to 'L3(B)' (i.e., the link-local network-layer address of the ingress node).
o Predirect TargetとDestination Addressesはどちらも「L3（B）」に設定されています（つまり、入力ノードのリンクローカルネットワーク層アドレス）。
o the message includes an RHO that contains the originating packet truncated to ensure that at least the network-layer header is included but the size of the message does not exceed 1280 bytes.
o メッセージには、少なくともネットワーク層ヘッダーが含まれていることを確認するために切り捨てられた元のパケットを含むRHOが含まれていますが、メッセージのサイズは1280バイトを超えません。
o the 'P' bit is set to P=1.
o 「P」ビットはP = 1に設定されます。
When the egress node ('D') receives the AERO Predirect message, it validates the message the same as described in Section 6.4.6. Following validation, the egress node ('D') then resets its ACCEPT timer for the prefix pair that matches the originating packet's network-layer source and destination addresses to ACCEPT_TIME seconds, and it sends an AERO Redirect message directly to the ingress node ('B') prepared as follows:
出力ノード（ 'D'）は、AERO Predirectメッセージを受信すると、セクション6.4.6で説明されているのと同じ方法でメッセージを検証します。検証に続いて、出力ノード（ 'D'）は、元のパケットのネットワークレイヤーの送信元アドレスと宛先アドレスに一致するプレフィックスペアのACCEPTタイマーをACCEPT_TIME秒にリセットし、AEROリダイレクトメッセージを直接入力ノード（ ' B '）以下のように準備されます：
o the link-layer source address is set to 'L2(D)' (i.e., the link-layer address of the egress node).
o リンク層の送信元アドレスは「L2（D）」に設定されます（つまり、出口ノードのリンク層アドレス）。
o the link-layer destination address is set to 'L2(B)' (i.e., the link-layer address of the ingress node).
o リンク層宛先アドレスは「L2（B）」に設定されます（つまり、入力ノードのリンク層アドレス）。
o the network-layer source address is set to 'L3(D)' (i.e., the link-local network-layer address of the egress node).
o ネットワーク層の送信元アドレスは「L3（D）」に設定されます（つまり、出口ノードのリンクローカルネットワーク層アドレス）。
o the network-layer destination address is set to 'L3(B)' (i.e., the link-local network-layer address of the ingress node).
o ネットワーク層の宛先アドレスは「L3（B）」に設定されます（つまり、入口ノードのリンクローカルネットワーク層アドレス）。
o the UDP destination port is set to 'AERO_PORT'.
o UDP宛先ポートは「AERO_PORT」に設定されています。
o the Redirect Target and Destination Addresses are both set to 'L3(D)' (i.e., the link-local network-layer address of the egress node).
o リダイレクトターゲットと宛先アドレスの両方が「L3（D）」に設定されている（つまり、出口ノードのリンクローカルネットワーク層アドレス）。
o the message includes as much of the RHO copied from the corresponding AERO Predirect message as possible such that at least the network-layer header is included but the size of the message does not exceed 1280 bytes.
o メッセージには、対応するAERO PredirectメッセージからコピーされたRHOができるだけ多く含まれるため、少なくともネットワーク層ヘッダーは含まれますが、メッセージのサイズは1280バイトを超えません。
o the 'P' bit is set to P=0.
o 「P」ビットはP = 0に設定されます。
When the ingress node ('B') receives the AERO Redirect message, it validates the message the same as described in Section 6.4.6. Following validation, the ingress node ('B') then resets its FORWARD timer for the prefix pair that matches the originating packet's network-layer source and destination addresses to FORWARD_TIME seconds.
入力ノード（ 'B'）がAEROリダイレクトメッセージを受信すると、セクション6.4.6で説明されているのと同じ方法でメッセージを検証します。検証後、入力ノード（ 'B'）は、元のパケットのネットワーク層の送信元アドレスと宛先アドレスに一致するプレフィックスペアのFORWARDタイマーをFORWARD_TIME秒にリセットします。
In this process, if the ingress node sends MAX_RETRY AERO Predirect messages as keepalives without receiving an AERO Redirect message reply, it can either declare the prefix pair unreachable immediately or allow the pair to expire after FORWARD_TIME seconds.
このプロセスでは、イングレスノードがAEROリダイレクトメッセージの応答を受信せずにキープアライブとしてMAX_RETRY AEROプレダイレクトメッセージを送信する場合、プレフィックスペアが到達不能であるとすぐに宣言するか、FORWARD_TIME秒後にペアを期限切れにすることができます。
When the ingress node ('B') receives an AERO Redirect message informing it of a direct path to a new egress node ('D'), there is a question in point as to whether the new egress node ('D') can be reached directly without forwarding through an intermediate router ('A'). On some AERO links, it may be reasonable for the ingress node ('B') to (optimistically) assume that reachability is transitive, and to immediately begin forwarding data packets to the egress node ('D') without testing reachability.
入力ノード（ 'B'）が新しい出力ノード（ 'D'）への直接パスを通知するAEROリダイレクトメッセージを受信すると、新しい出力ノード（ 'D'）が中間ルーター（ 'A'）を介して転送せずに直接到達する。一部のAEROリンクでは、到達可能性が推移的であると（楽観的に）入力ノード（ 'B'）が想定し、到達可能性をテストせずに出力ノード（ 'D'）へのデータパケットの転送をすぐに開始するのが妥当です。
On AERO links in which an optimistic assumption of transitive reachability may be unreasonable, however, the ingress node ('B') can defer the redirection until it tests the direct path to the egress node ('D'), e.g., by sending an IPv6 Neighbor Solicitation to elicit an IPv6 Neighbor Advertisement response. If the ingress node ('B') is unable to elicit a response after MAX_RETRY attempts, it should consider the direct path to the egress node ('D') to be unusable.
推移的な到達可能性の楽観的な仮定が不合理である可能性があるAEROリンクでは、入力ノード（ 'B'）は、たとえば、 IPv6ネイバーアドバタイズメント応答を引き出すためのIPv6ネイバー要請。入力ノード（ 'B'）がMAX_RETRYの試行後に応答を引き出すことができない場合は、出力ノード（ 'D'）への直接パスが使用できないと見なす必要があります。
In either case, the ingress node ('B') can process any link errors corresponding to the data packets sent directly to the egress node ('D') as a hint that the direct path has either failed or has become intermittent. Conversely, the ingress node ('B') can further process any AERO Redirect messages received as evidence of neighbor reachability.
どちらの場合も、入力ノード（ 'B'）は、直接パスに障害が発生したか、または断続的になったかのヒントとして、出力ノード（ 'D'）に直接送信されたデータパケットに対応するリンクエラーを処理できます。逆に、入口ノード（ 'B'）は、ネイバーの到達可能性の証拠として受信したAEROリダイレクトメッセージをさらに処理できます。
Again, with reference to Figure 3, egress node ('D') can configure both a non-advertising router interface on a provider AERO link and advertising router interfaces on its connected EUN links. When an EUN node ('E') in one of the egress node's connected EUNs moves to a different network point of attachment, however, it can release its network-layer address/prefix delegations that were registered with egress node ('D' ) and re-establish them via a different router.
再び、図3を参照すると、出口ノード（「D」）は、プロバイダーのAEROリンク上の非アドバタイズルーターインターフェイスと、接続されたEUNリンク上のアドバタイズルーターインターフェイスの両方を構成できます。ただし、出口ノードの接続されたEUNの1つにあるEUNノード（ 'E'）が別のネットワーク接続点に移動すると、出口ノード（ 'D'）に登録されていたネットワーク層アドレス/プレフィックス委任を解放できます。別のルーターを介してそれらを再確立します。
When the EUN node ('E') releases its network-layer address/prefix delegations, the egress node ('D') marks its forwarding table entries corresponding to the network-layer addresses/prefixes as "departed" and no longer responds to AERO Predirect messages for the departed addresses/prefixes. When egress node ('D') receives packets from an ingress node ('B') with network-layer source and destination addresses that match a prefix pair on the ACCEPT list, it forwards them to the last-known link-layer address of EUN node ('E') as a means for avoiding mobility-related packet loss during routing changes. Egress node ('D') also returns a NULL AERO Redirect message to inform the ingress node ('B') of the departure. The message is prepared as follows: o the link-layer source address is set to 'L2(D)'.
EUNノード（ 'E'）がネットワークレイヤーアドレス/プレフィックスの委任を解放すると、出力ノード（ 'D'）はネットワークレイヤーアドレス/プレフィックスに対応する転送テーブルエントリを「出発」としてマークし、応答しなくなります。出発したアドレス/プレフィックスのAERO Predirectメッセージ。出口ノード（「D」）は、ACCEPTリストのプレフィックスペアと一致するネットワークレイヤーの送信元アドレスと宛先アドレスを持つ入口ノード（「B」）からパケットを受信すると、それらを最後に認識されたリンクレイヤーアドレスに転送します。ルーティングの変更中にモビリティ関連のパケット損失を回避するための手段としてのEUNノード（ 'E'）。出口ノード（ 'D'）もNULL AERO Redirectメッセージを返し、入口ノード（ 'B'）に出発を通知します。メッセージは次のように準備されます。oリンク層の送信元アドレスが「L2（D）」に設定されます。
o the link-layer destination address is set to 'L2(B)'.
o リンク層の宛先アドレスは「L2（B）」に設定されます。
o the network-layer source address is set to the link-local address 'L3(D)'.
o ネットワーク層の送信元アドレスは、リンクローカルアドレス「L3（D）」に設定されます。
o the network-layer destination address is set to the link-local address 'L3(B)'.
o ネットワーク層の宛先アドレスは、リンクローカルアドレス「L3（B）」に設定されます。
o the UDP destination port is set to 'AERO_PORT'.
o UDP宛先ポートは「AERO_PORT」に設定されています。
o the Redirect Target and Destination Addresses are both set to NULL.
o リダイレクトターゲットと宛先アドレスはどちらもNULLに設定されます。
o the message includes an RHO that contains as much of the original packet as possible such that at least the network-layer header is included but the size of the message does not exceed 1280 bytes.
o メッセージには、元のパケットをできるだけ多く含むRHOが含まれているため、少なくともネットワークレイヤーヘッダーは含まれますが、メッセージのサイズは1280バイトを超えません。
o the 'P' bit is set to P=0.
o 「P」ビットはP = 0に設定されます。
When ingress node ('B') receives the NULL AERO Redirect message, it deletes the prefix pair associated with the packet in the RHO from its list of forwarding entries corresponding to egress node ('D'). When egress node ('D')s ACCEPT_TIME timer for the prefix pair corresponding to the departed prefix expires, it deletes the prefix pairs from its list of ingress filtering entries corresponding to ingress node ('B').
入力ノード（ 'B'）がNULL AERO Redirectメッセージを受信すると、RHOのパケットに関連付けられたプレフィックスペアを、出力ノード（ 'D'）に対応する転送エントリのリストから削除します。出発したプレフィックスに対応するプレフィックスペアの出口ノード（ 'D'）のACCEPT_TIMEタイマーが期限切れになると、入口ノード（ 'B'）に対応する入口フィルタリングエントリのリストからプレフィックスペアを削除します。
Eventually, any such correspondent AERO nodes will receive a NULL AERO Redirect message and will cease to use the egress node ('D') as a next hop. They will then revert to sending packets destined to the EUN node ('E') via a trusted intermediate router and may subsequently receive new AERO Redirect messages to discover that the EUN node ('E') is now associated with a new AERO edge router.
最終的に、対応するAEROノードはNULL AEROリダイレクトメッセージを受信し、出力ノード（ 'D'）をネクストホップとして使用しなくなります。次に、信頼できる中間ルーター経由でEUNノード（ 'E'）宛のパケットを送信するように戻り、その後、新しいAEROリダイレクトメッセージを受信して、EUNノード（ 'E'）が新しいAEROエッジルーターに関連付けられていることを検出します。 。
Note that any packets forwarded by the egress node ('D') via a departed forwarding table entry may be lost if the (mobile) EUN node ('E') moves off-link with respect to its previous EUN point of attachment. This should not be a problem for large links (e.g., large cellular network deployments, large ISP networks, etc.) in which all/most mobility events are intra-link.
（モバイル）EUNノード（ 'E'）が以前のEUNアタッチメントポイントからリンク外に移動した場合、出発ノード（ 'D'）が出発した転送テーブルエントリを介して転送したパケットは失われる可能性があることに注意してください。これは、すべて/ほとんどのモビリティイベントがイントラリンクである大規模なリンク（大規模なセルラーネットワークの展開、大規模なISPネットワークなど）では問題になりません。
When an ingress node needs to change its link-layer address, it deletes each FORWARD list entry that was established under the old link layer address, changes the link layer address, then allows packets to again flow through an intermediate router. Any egress node that receives the packets will also receive new AERO Predirect messages from the intermediate router. The egress node then deletes the ACCEPT entry that included the ingress node's old link-layer address and installs a new ACCEPT entry that includes the ingress node's new link-layer address. The egress then returns a new AERO Redirect message to the ingress node via the intermediate router, which the ingress node uses to establish a new FORWARD list entry.
入力ノードは、リンク層アドレスを変更する必要がある場合、古いリンク層アドレスの下で確立された各FORWARDリストエントリを削除し、リンク層アドレスを変更してから、パケットが再び中間ルーターを通過できるようにします。パケットを受信するすべての出口ノードは、中間ルーターから新しいAERO Predirectメッセージも受信します。次に、出口ノードは、入口ノードの古いリンク層アドレスを含むACCEPTエントリを削除し、入口ノードの新しいリンク層アドレスを含む新しいACCEPTエントリをインストールします。次に、出口は、中間ルーターを介して新しいAEROリダイレクトメッセージを入口ノードに返します。これは、入口ノードが新しいFORWARDリストエントリを確立するために使用します。
When an egress node needs to change its link-layer address, it deletes each entry in the ACCEPT list and SHOULD also send NULL AERO Redirect messages to the corresponding ingress node (i.e., the same as described for mobility operations in Section 6.4.12) before changing the link-layer address. Any ingress node that receives the NULL AERO Redirect messages will delete any corresponding FORWARD list entries and again allow packets to flow through an intermediate router. The egress then changes the link-layer address, and it sends new AERO Redirect messages in response to any AERO Predirect messages it receives from the intermediate router while using the new link-layer address.
出力ノードがリンク層アドレスを変更する必要がある場合、ACCEPTリストの各エントリを削除し、対応する入力ノードにNULL AERO Redirectメッセージを送信する必要があります（つまり、セクション6.4.12のモビリティ操作で説明したものと同じ）。リンク層アドレスを変更する前。 NULL AERO Redirectメッセージを受信するすべての入力ノードは、対応するFORWARDリストエントリを削除し、パケットが中間ルーターを通過できるようにします。次に、出力はリンク層アドレスを変更し、新しいリンク層アドレスを使用している間に中間ルーターから受信したAERO Predirectメッセージに応答して、新しいAERO Redirectメッセージを送信します。
When an AERO node configures one or more FORWARD/ACCEPT list prefix pair entries, and the prefixes associated with the pair are somehow reconfigured or renumbered, the stale FORWARD/ACCEPT list information must be deleted.
AEROノードが1つ以上のFORWARD / ACCEPTリストプレフィックスペアエントリを構成し、ペアに関連付けられたプレフィックスが何らかの方法で再構成または再番号付けされた場合、古いFORWARD / ACCEPTリスト情報を削除する必要があります。
When an ingress node ('B') reconfigures its network-layer source prefix in such a way that the ACCEPT list entry in the egress node ('D') would no longer be valid (e.g., the prefix length of the source prefix changes), the ingress node ('B') simply deletes the prefix pair form its FORWARD list and allows subsequent packets to again flow through an intermediate router ('A').
入力ノード（「B」）がネットワーク層のソースプレフィックスを再構成して、出力ノード（「D」）のACCEPTリストエントリが有効でなくなったとき（たとえば、ソースプレフィックスのプレフィックス長が変更されたとき） ）、入力ノード（ 'B'）は、そのFORWARDリストからプレフィックスペアを削除するだけで、後続のパケットが再び中間ルーター（ 'A'）を通過できるようにします。
When the egress node ('D') reconfigures its network-layer destination prefix in such a way that the FORWARD list entry in the ingress node ('B') would no longer be valid, the egress node ('D') sends a NULL AERO Redirect message to the ingress node ('B') the same as described for mobility and link-layer address change considerations when it receives either an AERO Predirect message or a data packet (subject to rate limiting) from the ingress node ('B').
出力ノード（ 'D'）は、ネットワークノードの宛先プレフィックスを再構成して、入力ノード（ 'B'）のFORWARDリストエントリが無効になると、出力ノード（ 'D'）が入口ノード（ 'B'）へのNULL AEROリダイレクトメッセージは、入口ノードからのAERO Predirectメッセージまたはデータパケット（レート制限の対象）のいずれかを受信したときのモビリティおよびリンク層アドレス変更の考慮事項について説明したのと同じB '）。
There are no backward compatibility considerations since AERO Redirect/Predirect messages use a new UDP port number that distinguishes them from other kinds of control messages. Therefore, legacy nodes will simply discard any AERO Redirect/Predirect messages they may accidentally receive.
AERO Redirect / Predirectメッセージは、他の種類の制御メッセージと区別する新しいUDPポート番号を使用するため、下位互換性に関する考慮事項はありません。したがって、レガシーノードは、誤って受信する可能性のあるAERO Redirect / Predirectメッセージを単に破棄します。
Note however that AERO redirection requires that all three (the ingress, intermediate router, and egress) participate in the protocol. Additionally, the intermediate router SHOULD disable ordinary ICMPv6 Redirects when AERO redirection is enabled.
ただし、AEROリダイレクションでは、3つすべて（入力、中間ルーター、および出力）がプロトコルに参加する必要があることに注意してください。さらに、中間ルーターは、AEROリダイレクションが有効な場合、通常のICMPv6リダイレクトを無効にする必要があります（SHOULD）。
IANA has assigned UDP user port number 8060 for this protocol via the expert review process [RFC5226].
IANAは、エキスパートレビュープロセス[RFC5226]を介して、このプロトコルにUDPユーザーポート番号8060を割り当てました。
AERO link security considerations are the same as for standard IPv6 Neighbor Discovery [RFC4861] except that AERO improves on some aspects. In particular, AERO is dependent on a trust basis between AERO edge nodes and intermediate routers, where the edge nodes must only engage in the AERO mechanism when it is facilitated by a trusted intermediate router.
AEROリンクのセキュリティに関する考慮事項は、標準のIPv6近隣探索[RFC4861]の場合と同じですが、AEROはいくつかの点で改善されています。特に、AEROは、AEROエッジノードと中間ルーター間の信頼関係に依存しています。エッジノードがAEROメカニズムに関与する必要があるのは、信頼された中間ルーターによって促進される場合のみです。
AERO links must be protected against link-layer address spoofing attacks in which an attacker on the link pretends to be a trusted neighbor. Links that provide link-layer securing mechanisms (e.g., WiFi networks) and links that provide physical security (e.g., enterprise network LANs) provide a first line of defense that is often sufficient. In other instances, sufficient assurances against link-layer address spoofing attacks are possible if the source can digitally sign its messages through means outside the scope of this document.
AEROリンクは、リンク上の攻撃者が信頼できる近隣者になりすますリンク層アドレススプーフィング攻撃から保護する必要があります。リンク層のセキュリティ保護メカニズムを提供するリンク（WiFiネットワークなど）と物理的なセキュリティを提供するリンク（エンタープライズネットワークLANなど）は、多くの場合十分な防御の第一線を提供します。他の例では、ソースがこのドキュメントの範囲外の手段でメッセージにデジタル署名できる場合、リンク層アドレススプーフィング攻撃に対する十分な保証が可能です。
Discussions both on the v6ops list and in private exchanges helped shape some of the concepts in this work. Individuals who contributed insights include Mikael Abrahamsson, Fred Baker, Stewart Bryant, Brian Carpenter, Brian Haberman, Joel Halpern, and Lee Howard. Members of the IESG also provided valuable input during their review process that greatly improved the document. Special thanks go to Stewart Bryant, Joel Halpern, and Brian Haberman for their shepherding guidance.
v6opsリストとプライベートエクスチェンジの両方での議論は、この作業のいくつかの概念の形成に役立ちました。洞察に貢献した個人には、ミカエルアブラハムソン、フレッドベイカー、スチュワートブライアント、ブライアンカーペンター、ブライアンハーバーマン、ジョエルハルパーン、リーハワードなどがあります。 IESGのメンバーは、レビュープロセス中にドキュメントを大幅に改善する貴重な情報も提供しました。シェパーディングのガイダンスを提供してくれたスチュワートブライアント、ジョエルハルパーン、ブライアンハーバーマンに特に感謝します。
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC0768] Postel、J。、「User Datagram Protocol」、STD 6、RFC 768、1980年8月。
[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月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、1998年12月。
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191, November 2005.
[RFC4191] Draves、R。およびD. Thaler、「デフォルトのルーター設定とより具体的なルート」、RFC 4191、2005年11月。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861] Narten、T.、Nordmark、E.、Simpson、W。、およびH. Soliman、「Neighbor Discovery for IP version 6（IPv6）」、RFC 4861、2007年9月。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
[RFC4862] Thomson、S.、Narten、T。、およびT. Jinmei、「IPv6 Stateless Address Autoconfiguration」、RFC 4862、2007年9月。
[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月。
[RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node Requirements", RFC 6434, December 2011.
[RFC6434] Jankiewicz、E.、Loughney、J。、およびT. Narten、「IPv6ノードの要件」、RFC 6434、2011年12月。
[IRON] Templin, F., "The Internet Routing Overlay Network (IRON)", Work in Progress, June 2012.
[IRON] Templin、F。、「The Internet Routing Overlay Network（IRON）」、Work in Progress、2012年6月。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[RFC0792] Postel、J。、「インターネット制御メッセージプロトコル」、STD 5、RFC 792、1981年9月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131] Droms、R。、「Dynamic Host Configuration Protocol」、RFC 2131、1997年3月。
[RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 Domains without Explicit Tunnels", RFC 2529, March 1999.
[RFC2529] Carpenter、B。およびC. Jung、「明示的なトンネルのないIPv4ドメインを介したIPv6の転送」、RFC 2529、1999年3月。
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315] Droms、R.、Bound、J.、Volz、B.、Lemon、T.、Perkins、C.、and M. Carney、 "Dynamic Host Configuration Protocol for IPv6（DHCPv6）"、RFC 3315、July 2003 。
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003.
[RFC3633] Troan、O。およびR. Droms、「動的ホスト構成プロトコル（DHCP）バージョン6のIPv6プレフィックスオプション」、RFC 3633、2003年12月。
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4443]コンタ、A。、ディアリング、S。、およびM.グプタ、「インターネットプロトコルバージョン6（IPv6）仕様のインターネットコントロールメッセージプロトコル（ICMPv6）」、RFC 4443、2006年3月。
[RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, March 2008.
[RFC5214] Templin、F.、Gleeson、T。、およびD. Thaler、「Intra-Site Automatic Tunnel Addressing Protocol（ISATAP）」、RFC 5214、2008年3月。
[RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)", RFC 5569, January 2010.
[RFC5569] Despres、R。、「IPv4 Infrastructures on IPv4 Infrastructures（6rd）」、RFC 5569、2010年1月。
[RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O. Troan, "Basic Requirements for IPv6 Customer Edge Routers", RFC 6204, April 2011.
[RFC6204] Singh、H.、Beebee、W.、Donley、C.、Stark、B。、およびO. Troan、「IPv6カスタマーエッジルーターの基本要件」、RFC 6204、2011年4月。
[VET] Templin, F., "Virtual Enterprise Traversal (VET)", Work in Progress, June 2012.
[VET] Templin、F。、「Virtual Enterprise Traversal（VET）」、Work in Progress、2012年6月。
Figure 3 depicts a reference AERO operational scenario with a single intermediate router on the AERO link. In order to support scaling to larger numbers of nodes, the AERO link can deploy multiple intermediate routers, e.g., as shown in Figure 6.
図3は、AEROリンク上に単一の中間ルーターがある場合の基準AERO運用シナリオを示しています。より多くのノードへのスケーリングをサポートするために、AEROリンクは、たとえば図6に示すように、複数の中間ルーターを展開できます。
+--------------+ +--------------+
| Intermediate | +--------------+ | Intermediate |
| Router C | | Core Router D| | Router E |
| (default->D) | | (A->C; G->E) | | (default->D) |
| (A->B) | +--------------+ | (G->F) |
+-------+------+ +------+-------+
| |
X---+---+--------------------------------------+---+---X
| AERO Link |
+-----+--------+ +--------+-----+
| Edge Router B| | Edge Router F|
| (default->C) | | (default->E) |
+--------------+ +--------------+
.-. .-.
,-( _)-. ,-( _)-.
.-(_ IPv6 )-. .-(_ IPv6 )-.
(__ EUN ) (__ EUN )
`-(______)-' `-(______)-'
| |
+--------+ +--------+
| Host A | | Host G |
+--------+ +--------+
Figure 6: Multiple Intermediate Routers
図6：複数の中間ルーター
In this example, the ingress AERO node ('B') (in this case an edge router, but could also be a host) associates with intermediate AERO router ('C'), while the egress AERO node ('F') (in this case an edge router, but could also be a host) associates with intermediate AERO router ('E'). Furthermore, intermediate routers ('C') and ('E') do not associate with each other directly, but rather have an association with a "core" router ('D') (i.e., a router that has full topology information concerning its associated intermediate routers). Core router ('D') may connect to either the AERO link or to other physical or virtual links (not shown) to which intermediate routers ('C') and ('E') also connect.
この例では、入力AEROノード（ 'B'）（この場合はエッジルーターですが、ホストにすることもできます）は中間AEROルーター（ 'C'）に関連付けられ、出力AEROノード（ 'F'）（この場合、エッジルーター（ただし、ホストの場合もあります）は中間AEROルーター（ 'E'）に関連付けられます。さらに、中間ルーター（ 'C'）と（ 'E'）は互いに直接関連付けられておらず、「コア」ルーター（ 'D'）（つまり、関連する中間ルーター）。コアルーター（ 'D'）は、AEROリンク、または中間ルーター（ 'C'）と（ 'E'）も接続する他の物理リンクまたは仮想リンク（図示せず）に接続できます。
When host ('A') sends a packet toward destination host ('G'), IPv6 forwarding directs the packet through the EUN to edge router ('B'), which forwards the packet to intermediate router ('C') in absence of more-specific forwarding information. Intermediate router ('C') forwards the packet, and it also generates an AERO Predirect message that is then forwarded through core router ('D') to intermediate router ('E'). When intermediate router ('E') receives the message, it forwards the message to egress router ('F').
ホスト（ 'A'）が宛先ホスト（ 'G'）にパケットを送信すると、IPv6転送はパケットをEUN経由でエッジルーター（ 'B'）に転送し、エッジルーターはパケットがない場合に中間ルーター（ 'C'）に転送します。より具体的な転送情報。中間ルーター（ 'C'）はパケットを転送し、さらにAERO Predirectメッセージを生成して、コアルーター（ 'D'）を介して中間ルーター（ 'E'）に転送されます。中間ルーター（ 'E'）がメッセージを受信すると、メッセージを出力ルーター（ 'F'）に転送します。
After processing the AERO Predirect message, egress router ('F') sends an AERO Redirect message to intermediate router ('E').
AERO Predirectメッセージを処理した後、出力ルーター（ 'F'）はAERO Redirectメッセージを中間ルーター（ 'E'）に送信します。
Intermediate router ('E'), in turn, forwards the message through core router ('D') to intermediate router ('C'). When intermediate router ('C') receives the message, it forwards the message to ingress edge router ('B') informing it that host 'G's EUN can be reached via egress router ('F'), thus completing the AERO redirection.
次に、中間ルーター（ 'E'）は、メッセージをコアルーター（ 'D'）を介して中間ルーター（ 'C'）に転送します。中間ルーター（ 'C'）がメッセージを受信すると、メッセージを入力エッジルーター（ 'B'）に転送して、ホスト 'G'のEUNに出力ルーター（ 'F'）経由で到達できることを通知し、AEROリダイレクトを完了します。
The interworkings between intermediate and core routers (including the conveyance of pseudo Predirects and Redirects) must be carefully coordinated in a manner outside the scope of this document. In particular, the intermediate and core routers must ensure that any routing loops that may be formed are temporal in nature. See [IRON] for an architectural discussion of coordination between intermediate and core routers.
中間ルータとコアルータ間のインターワーキング（疑似PredirectとRedirectの伝達を含む）は、このドキュメントの範囲外の方法で慎重に調整する必要があります。特に、中間ルーターとコアルーターは、形成されるルーティングループが一時的なものであることを確認する必要があります。中間ルーターとコアルーターの間の調整に関するアーキテクチャの説明については、[IRON]を参照してください。
Author's Address
著者のアドレス
Fred L. Templin (editor) Boeing Research & Technology P.O. Box 3707 MC 7L-49 Seattle, WA 98124 USA
フレッドL.テンプリン（編集者）ボーイングリサーチ＆テクノロジーP.O.ボックス3707 MC 7L-49シアトル、ワシントン州98124米国
EMail: fltemplin@acm.org