RFC 7949 - OSPFv3 over IPv4 for IPv6 Transition 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc7949
タイトル : RFC 7949 - IPv6移行のためのIPv4上のOSPFv3
翻訳編集 : 自動生成

[要約] RFC 7949は、IPv6への移行におけるIPv4上でのOSPFv3の使用に関するガイドラインです。その目的は、IPv6への移行を容易にするために、既存のIPv4ネットワーク上でOSPFv3を使用する方法を提供することです。

Internet Engineering Task Force (IETF)                           I. Chen
Request for Comments: 7949                                      Ericsson
Updates: 5838                                                  A. Lindem
Category: Standards Track                                          Cisco
ISSN: 2070-1721                                              R. Atkinson
                                                              Consultant
                                                             August 2016

OSPFv3 over IPv4 for IPv6 Transition

IPv6移行のためのIPv4上のOSPFv3

Abstract

概要

This document defines a mechanism to use IPv4 to transport OSPFv3 packets. Using OSPFv3 over IPv4 with the existing OSPFv3 Address Family extension can simplify transition from an OSPFv2 IPv4-only routing domain to an OSPFv3 dual-stack routing domain. This document updates RFC 5838 to support virtual links in the IPv4 unicast address family when using OSPFv3 over IPv4.

このドキュメントでは、IPv4を使用してOSPFv3パケットを転送するメカニズムを定義しています。既存のOSPFv3アドレスファミリ拡張でOSPFv3 over IPv4を使用すると、OSPFv2 IPv4のみのルーティングドメインからOSPFv3デュアルスタックルーティングドメインへの移行を簡素化できます。このドキュメントは、IPv4 over OSPFv3を使用するときにIPv4ユニキャストアドレスファミリの仮想リンクをサポートするようにRFC 5838を更新します。

Status of This Memo

本文書の状態

This is an Internet Standards Track document.

これはInternet Standards Trackドキュメントです。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.

このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション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/rfc7949.

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

著作権表示

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 ....................................................2
      1.1. IPv4-Only Use Case .........................................3
   2. Requirements Language ...........................................4
   3. Encapsulation in IPv4 ...........................................4
      3.1. Source Address .............................................6
      3.2. Destination Address ........................................6
      3.3. OSPFv3 Header Checksum .....................................6
      3.4. Operation over Virtual Links ...............................7
   4. Management Considerations .......................................7
      4.1. Coexistence with OSPFv2 ....................................7
   5. Security Considerations .........................................8
   6. References ......................................................8
      6.1. Normative References .......................................8
      6.2. Informative References .....................................9
   Acknowledgments ...................................................10
   Authors' Addresses ................................................11

1. Introduction

1. はじめに

Using OSPFv3 [RFC5340] over IPv4 [RFC791] with the existing OSPFv3 address family extension can simplify transition from an IPv4-only routing domain to an IPv6 [RFC2460] or dual-stack routing domain. Dual-stack routing protocols, such as the Border Gateway Protocol [RFC4271], have an advantage during the transition, because both IPv4 and IPv6 address families can be advertised using either IPv4 or IPv6 transport. Some IPv4-specific and IPv6-specific routing protocols share enough similarities in their protocol packet formats and protocol signaling that it is trivial to deploy an initial IPv6 routing domain by transporting the routing protocol over IPv4, thereby allowing IPv6 routing domains to be deployed and tested before decommissioning IPv4 and moving to an IPv6-only network.

OSPFv3 [RFC5340]とIPv4 [RFC791]を既存のOSPFv3アドレスファミリ拡張で使用すると、IPv4のみのルーティングドメインからIPv6 [RFC2460]またはデュアルスタックルーティングドメインへの移行が簡単になります。ボーダーゲートウェイプロトコル[RFC4271]などのデュアルスタックルーティングプロトコルは、IPv4とIPv6の両方のアドレスファミリをIPv4またはIPv6トランスポートを使用してアドバタイズできるため、移行中に利点があります。一部のIPv4固有およびIPv6固有のルーティングプロトコルは、プロトコルパケット形式とプロトコルシグナリングの十分な類似性を共有しているため、IPv4を介してルーティングプロトコルを転送することで初期IPv6ルーティングドメインを展開することは簡単であり、それによってIPv6ルーティングドメインを展開およびテストできます。 IPv4を廃止してIPv6のみのネットワークに移行する前。

In the case of the Open Shortest Path First (OSPF) interior gateway routing protocol (IGP), OSPFv2 [RFC2328] is the IGP deployed over IPv4, while OSPFv3 [RFC5340] is the IGP deployed over IPv6. OSPFv3 further supports multiple address families [RFC5838], including both the IPv6 unicast address family and the IPv4 unicast address family. Consequently, it is possible to deploy OSPFv3 over IPv4 without any changes to either OSPFv3 or IPv4. During the transition to IPv6, future OSPF extensions can focus on OSPFv3, and OSPFv2 can move to maintenance mode.

OSPF（Open Shortest Path First）（OSPF）内部ゲートウェイルーティングプロトコル（IGP）の場合、OSPFv2 [RFC2328]はIPv4で展開されるIGPであり、OSPFv3 [RFC5340]はIPv6で展開されるIGPです。 OSPFv3はさらに、IPv6ユニキャストアドレスファミリとIPv4ユニキャストアドレスファミリの両方を含む複数のアドレスファミリ[RFC5838]をサポートしています。したがって、OSPFv3またはIPv4に変更を加えることなく、IPv4を介してOSPFv3を展開できます。 IPv6への移行中、将来のOSPF拡張はOSPFv3に集中でき、OSPFv2はメンテナンスモードに移行できます。

This document specifies how to use IPv4 to transport OSPFv3 packets. The mechanism takes advantage of the fact that OSPFv2 and OSPFv3 share the same IP protocol number, 89. Additionally, the OSPF packet header for both OSPFv2 and OSPFv3 includes the OSPF header version (i.e., the field that distinguishes an OSPFv2 packet from an OSPFv3 packet) in the same location (i.e., the same offset from the start of the header).

このドキュメントでは、IPv4を使用してOSPFv3パケットを転送する方法について説明します。このメカニズムは、OSPFv2とOSPFv3が同じIPプロトコル番号89を共有するという事実を利用しています。さらに、OSPFv2とOSPFv3の両方のOSPFパケットヘッダーには、OSPFヘッダーバージョン（つまり、OSPFv2パケットとOSPFv3パケットを区別するフィールド）が含まれています）同じ場所（つまり、ヘッダーの先頭からの同じオフセット）。

If the IPv4 topology and IPv6 topology are not identical, the most likely cause is that some parts of the network deployment have not yet been upgraded to support both IPv4 and IPv6. In situations where the IPv4 deployment is a superset of the IPv6 deployment, it is expected that OSPFv3 packets would be transported over IPv4, until the rest of the network deployment is upgraded to support IPv6 in addition to IPv4. In situations where the IPv6 deployment is a superset of the IPv4 deployment, it is expected that OSPFv3 would be transported over IPv6.

IPv4トポロジとIPv6トポロジが同一でない場合、最も可能性の高い原因は、ネットワーク展開の一部がまだIPv4とIPv6の両方をサポートするようにアップグレードされていないことです。 IPv4展開がIPv6展開のスーパーセットである状況では、ネットワーク展開の残りの部分がIPv4に加えてIPv6をサポートするようにアップグレードされるまで、OSPFv3パケットがIPv4を介して転送されることが期待されます。 IPv6展開がIPv4展開のスーパーセットである状況では、OSPFv3がIPv6を介して転送されることが予想されます。

Throughout this document, "OSPF" is used when the text applies to both OSPFv2 and OSPFv3. "OSPFv2" or "OSPFv3" is used when the text is specific to one version of the OSPF protocol. Similarly, "IP" is used when the text describes either version of the Internet Protocol. "IPv4" or "IPv6" is used when the text is specific to a single version of the Internet Protocol.

このドキュメント全体を通して、「OSPF」は、テキストがOSPFv2とOSPFv3の両方に適用される場合に使用されます。「OSPFv2」または「OSPFv3」は、テキストがOSPFプロトコルの1つのバージョンに固有である場合に使用されます。同様に、テキストがインターネットプロトコルのいずれかのバージョンを説明している場合は、「IP」が使用されます。「IPv4」または「IPv6」は、テキストがインターネットプロトコルの単一バージョンに固有である場合に使用されます。

1.1. IPv4-Only Use Case

1.1. IPv4のみの使用例

OSPFv3 only requires IPv6 link-local addresses to form adjacencies, and does not require IPv6 global-scope addresses to establish an IPv6 routing domain. However, IPv6 over Ethernet [RFC2464] uses a different EtherType (0x86dd) from IPv4 (0x0800) and the Address Resolution Protocol (ARP) (0x0806) [RFC826] used with IPv4.

OSPFv3は、隣接関係を形成するためにIPv6リンクローカルアドレスのみを必要とし、IPv6ルーティングドメインを確立するためにIPv6グローバルスコープアドレスを必要としません。ただし、IPv6 over Ethernet [RFC2464]は、IPv4（0x0800）とは異なるEtherType（0x86dd）と、IPv4で使用されるアドレス解決プロトコル（ARP）（0x0806）[RFC826]を使用します。

Some existing deployed link-layer equipment only supports IPv4 and ARP. Such equipment contains hardware filters keyed on the EtherType field of the Ethernet frame to filter which frames will be accepted by that link-layer equipment. Because IPv6 uses a different EtherType, IPv6 framing for OSPFv3 will not work with that equipment. In other cases, Point-to-Point Protocol (PPP) might be used over a serial interface, but again only IPv4 over PPP might be supported over such an interface. It is hoped that equipment with such limitations will be eventually upgraded or replaced.

一部の既存の展開されたリンク層機器は、IPv4およびARPのみをサポートしています。そのような機器には、イーサネットフレームのEtherTypeフィールドをキーとするハードウェアフィルターが含まれており、そのリンク層機器がどのフレームを受け入れるかをフィルタリングします。 IPv6は異なるEtherTypeを使用するため、OSPFv3のIPv6フレーミングはその機器では機能しません。その他の場合、シリアルインターフェイス経由でポイントツーポイントプロトコル（PPP）を使用できますが、そのようなインターフェイス経由ではIPv4 over PPPのみがサポートされる可能性があります。このような制限のある機器は、最終的にアップグレードまたは交換されることが望まれます。

In some locations, especially locations with less communications infrastructure, satellite communications (SATCOM) are used to reduce deployment costs for data networking. SATCOM often has lower cost to deploy than running new copper or optical cables over long distances to connect remote areas. Also, in a wide range of locations including places with good communications infrastructure, Very Small Aperture Terminals (VSATs) often are used by banks and retailers to connect their branches and stores to a central location.

一部の場所、特に通信インフラストラクチャの少ない場所では、衛星通信（SATCOM）を使用してデータネットワーキングの導入コストを削減しています。多くの場合、SATCOMは、遠隔地を接続するために新しい銅線または光ケーブルを長距離にわたって実行するよりも導入コストが低くなります。また、通信インフラの整った場所を含むさまざまな場所で、銀行や小売業者が支店や店舗を中央の場所に接続するために、非常に小さなアパーチャターミナル（VSAT）がよく使用されています。

Some widely deployed VSAT equipment has either (A) Ethernet interfaces that only support the Ethernet Address Resolution Protocol (ARP) and IPv4, or (B) serial interfaces that only support IPv4 and PPP packets. Such deployments and equipment still can deploy and use OSPFv3 over IPv4 today, and then later migrate to OSPFv3 over IPv6 after equipment is upgraded or replaced. This can have lower operational costs than running OSPFv2 and then trying to make a flag-day switch to OSPFv3. By running OSPFv3 over IPv4 now, the eventual transition to dual-stack, and then to IPv6-only, can be orchestrated.

広く展開されている一部のVSAT機器には、（A）イーサネットアドレス解決プロトコル（ARP）とIPv4のみをサポートするイーサネットインターフェイス、または（B）IPv4とPPPパケットのみをサポートするシリアルインターフェイスがあります。このような展開と機器は、現在もIPv4 over OSPFv3を展開して使用でき、機器のアップグレードまたは交換後に、IPv6 over OSPFv3に移行できます。これにより、OSPFv2を実行してから、OSPFv3へのフラグデイスイッチを試行するよりも運用コストを削減できます。ここでIPv4を介してOSPFv3を実行することにより、最終的にデュアルスタックに移行し、次にIPv6のみに移行することができます。

2. Requirements Language

2. 要件言語

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。

3. Encapsulation in IPv4

3. IPv4でのカプセル化

An OSPFv3 packet can be directly encapsulated within an IPv4 packet as the payload, without the IPv6 packet header, as illustrated in Figure 1. For OSPFv3 transported over IPv4, the IPv4 packet has an IPv4 protocol type of 89, denoting that the payload is an OSPF packet. The payload of the IPv4 packet consists of an OSPFv3 packet, beginning with the OSPF packet header having its OSPF version field set to 3.

OSPFv3パケットは、図1に示すように、IPv6パケットヘッダーなしで、ペイロードとしてIPv4パケット内に直接カプセル化できます。IPv4で転送されるOSPFv3の場合、IPv4パケットのIPv4プロトコルタイプは89であり、ペイロードがOSPFパケット。 IPv4パケットのペイロードはOSPFv3パケットで構成され、OSPFバージョンフィールドが3に設定されたOSPFパケットヘッダーで始まります。

An OSPFv3 packet followed by an OSPF link-local signaling (LLS) extension data block [RFC5613] encapsulated in an IPv4 packet is illustrated in Figure 2.

図2に、IPv4パケットにカプセル化されたOSPFv3パケットと、それに続くOSPFリンクローカルシグナリング（LLS）拡張データブロック[RFC5613]を示します。

Since an IPv4 header without options is only 20 octets long and is shorter than an IPv6 header, an OSPFv3 packet encapsulated in a 20-octet IPv4 header is shorter than an OSPFv3 packet encapsulated in an IPv6 header. Consequently, the link MTU for IPv6 is sufficient to transport an OSPFv3 packet encapsulated in a 20-octet IPv4 header. If the link MTU is not sufficient to transport an OSPFv3 packet in IPv4, then OSPFv3 can rely on IP fragmentation and reassembly [RFC791].

オプションのないIPv4ヘッダーは長さが20オクテットにすぎず、IPv6ヘッダーより短いため、20オクテットのIPv4ヘッダーにカプセル化されたOSPFv3パケットは、IPv6ヘッダーにカプセル化されたOSPFv3パケットよりも短くなります。したがって、IPv6のリンクMTUは、20オクテットのIPv4ヘッダーにカプセル化されたOSPFv3パケットを転送するのに十分です。リンクMTUがIPv4でOSPFv3パケットを転送するのに十分でない場合、OSPFv3はIPの断片化と再構成に依存できます[RFC791]。

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
|   4   |  IHL  |Type of Service|          Total Length         |  ^
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
|         Identification        |Flags|      Fragment Offset    |  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
|  Time to Live | Protocol (89) |         Header Checksum       | IPv4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Header
|                       Source Address                          |  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
|                    Destination Address                        |  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
|                    Options                    |    Padding    |  v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
|       3       |     Type      |         Packet length         |  ^
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
|                         Router ID                             | OSPFv3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Header
|                          Area ID                              |  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
|          Checksum             |  Instance ID  |      0        |  v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
|                        OSPFv3 Body ...                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Note: "IHL" stands for Internet Header Length.

注：「IHL」はインターネットヘッダーの長さを表します。

Figure 1: An IPv4 Packet Encapsulating an OSPFv3 Packet

図1：OSPFv3パケットをカプセル化するIPv4パケット

                      +---------------+
                      | IPv4 Header   |
                      +---------------+
                      | OSPFv3 Header |
                      |...............|
                      |               |
                      | OSPFv3 Body   |
                      |               |
                      +---------------+
                      |               |
                      | LLS Data      |
                      |               |
                      +---------------+

Figure 2: The IPv4 Packet Encapsulating an OSPFv3 Packet with a Trailing OSPF Link-Local Signaling Data Block

図2：末尾のOSPFリンクローカルシグナリングデータブロックを含むOSPFv3パケットをカプセル化するIPv4パケット

3.1. Source Address

3.1. 送信元アドレス

For OSPFv3 over IPv4, the source address is the primary IPv4 address for the interface over which the packet is transmitted. All OSPFv3 routers on the link should share the same IPv4 subnet for IPv4 transport to function correctly.

OSPFv3 over IPv4の場合、送信元アドレスは、パケットが送信されるインターフェイスのプライマリIPv4アドレスです。 IPv4トランスポートが正しく機能するには、リンク上のすべてのOSPFv3ルーターが同じIPv4サブネットを共有する必要があります。

While OSPFv2 operates on a subnet, OSPFv3 operates on a link [RFC5340]. Accordingly, an OSPFv3 router implementation MAY support adjacencies with OSPFv3 neighbors on different IPv4 subnets. If this is supported, the IPv4 data plane MUST resolve IPv4 addresses to Layer 2 addresses using ARP on multi-access networks and point-to-point over LAN [RFC5309] for direct next hops on different IPv4 subnets. When OSPFv3 adjacencies on different IPv4 subnets are supported, Bidirectional Forwarding Detection (BFD) [RFC5881] cannot be used for adjacency loss detection since BFD is restricted to a single subnet.

OSPFv2はサブネットで動作しますが、OSPFv3はリンク[RFC5340]で動作します。したがって、OSPFv3ルーターの実装は、異なるIPv4サブネット上のOSPFv3ネイバーとの隣接関係をサポートする場合があります。これがサポートされている場合、IPv4データプレーンは、マルチアクセスネットワークでARPを使用し、異なるIPv4サブネットで直接ネクストホップのポイントツーポイントLAN [RFC5309]を使用して、IPv4アドレスをレイヤー2アドレスに解決する必要があります。異なるIPv4サブネット上のOSPFv3隣接がサポートされている場合、BFDは単一のサブネットに制限されるため、双方向転送検出（BFD）[RFC5881]を隣接損失検出に使用することはできません。

3.2. Destination Address

3.2. 宛先アドレス

As defined in OSPFv2, the IPv4 destination address of an OSPF protocol packet is either an IPv4 multicast address or the IPv4 unicast address of an OSPFv2 neighbor. Two well-known link-local multicast addresses are assigned to OSPFv2, the AllSPFRouters address (224.0.0.5) and the AllDRouters address (224.0.0.6). The multicast address used depends on the OSPF packet type, the OSPF interface type, and the OSPF router's role on multi-access networks.

OSPFv2で定義されているように、OSPFプロトコルパケットのIPv4宛先アドレスは、IPv4マルチキャストアドレスまたはOSPFv2ネイバーのIPv4ユニキャストアドレスです。 OSPFv2には、AllSPFRoutersアドレス（224.0.0.5）とAllDRoutersアドレス（224.0.0.6）の2つの既知のリンクローカルマルチキャストアドレスが割り当てられています。使用されるマルチキャストアドレスは、OSPFパケットタイプ、OSPFインターフェイスタイプ、およびマルチアクセスネットワークでのOSPFルータの役割によって異なります。

Thus, for an OSPFv3-over-IPv4 packet to be sent to AllSPFRouters, the destination address field in the IPv4 packet MUST be 224.0.0.5. For an OSPFv3-over-IPv4 packet to be sent to AllDRouters, the destination address field in the IPv4 packet MUST be 224.0.0.6.

したがって、OSPFv3-over-IPv4パケットをAllSPFRoutersに送信するには、IPv4パケットの宛先アドレスフィールドが224.0.0.5である必要があります。 OSPFv3-over-IPv4パケットをAllDRoutersに送信するには、IPv4パケットの宛先アドレスフィールドが224.0.0.6である必要があります。

When an OSPF router sends a unicast OSPF packet over a connected interface, the destination of such an IP packet is the address assigned to the receiving interface. Thus, a unicast OSPFv3 packet transported in an IPv4 packet would specify the OSPFv3 neighbor's IPv4 address as the destination address.

OSPFルーターが接続されたインターフェイスを介してユニキャストOSPFパケットを送信する場合、そのようなIPパケットの宛先は、受信インターフェイスに割り当てられたアドレスです。したがって、IPv4パケットで転送されるユニキャストOSPFv3パケットは、OSPFv3ネイバーのIPv4アドレスを宛先アドレスとして指定します。

3.3. OSPFv3 Header Checksum

3.3. OSPFv3ヘッダーチェックサム

For IPv4 transport, the pseudo-header used in the checksum calculation will contain the IPv4 source and destination addresses, the OSPFv3 protocol ID, and the OSPFv3 length from the OSPFv3 header (Appendix A.3.1 of [RFC5340]). The format is similar to the UDP pseudo-header as described in [RFC768] and is illustrated in Figure 3.

IPv4トランスポートの場合、チェックサム計算で使用される疑似ヘッダーには、IPv4送信元アドレスと宛先アドレス、OSPFv3プロトコルID、およびOSPFv3ヘッダーからのOSPFv3長さが含まれます（[RFC5340]の付録A.3.1）。 [RFC768]で説明されているように、形式はUDP疑似ヘッダーに似ており、図3に示されています。

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Source Address                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Destination Address                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     0         | Protocol (89) |     OSPFv3 Packet Length      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 3: Pseudo-header for OSPFv3 over IPv4

図3：OSPFv3 over IPv4の疑似ヘッダー

3.4. Operation over Virtual Links

3.4. 仮想リンクを介した操作

When an OSPF router sends an OSPF packet over a virtual link, the receiving router might not be directly connected to the sending router. Thus, the destination IP address of the IP packet must be a reachable unicast IP address for the virtual link endpoint. Because IPv6 is the presumed Internet protocol and an IPv4 destination is not routable, the OSPFv3 address family extension [RFC5838] specifies that only virtual links in the IPv6 address family are supported.

OSPFルーターが仮想リンクを介してOSPFパケットを送信する場合、受信ルーターが送信ルーターに直接接続されていない可能性があります。したがって、IPパケットの宛先IPアドレスは、仮想リンクエンドポイントの到達可能なユニキャストIPアドレスでなければなりません。 IPv6は推定インターネットプロトコルであり、IPv4宛先はルーティングできないため、OSPFv3アドレスファミリ拡張[RFC5838]は、IPv6アドレスファミリの仮想リンクのみがサポートされることを指定しています。

As illustrated in Figure 1, this document specifies OSPFv3 transport over IPv4. As a result, OSPFv3 virtual links can be supported with IPv4 address families by simply setting the IPv4 destination address to a reachable IPv4 unicast address for the virtual link endpoint. Hence, the restriction in Section 2.8 of RFC 5838 [RFC5838] is relaxed since virtual links can now be supported for IPv4 address families as long as the transport is also IPv4. If IPv4 transport, as specified herein, is used for IPv6 address families, virtual links cannot be supported. Hence, in OSPF routing domains that require virtual links, the IP transport MUST match the address family (IPv4 or IPv6).

図1に示すように、このドキュメントではIPv4を介したOSPFv3トランスポートを指定しています。その結果、IPv4宛先アドレスを仮想リンクエンドポイントの到達可能なIPv4ユニキャストアドレスに設定するだけで、OSPFv3仮想リンクをIPv4アドレスファミリでサポートできます。したがって、トランスポートもIPv4である限り、IPv4アドレスファミリで仮想リンクをサポートできるようになったため、RFC 5838 [RFC5838]のセクション2.8の制限が緩和されました。ここで指定されているIPv4トランスポートがIPv6アドレスファミリに使用される場合、仮想リンクはサポートできません。したがって、仮想リンクを必要とするOSPFルーティングドメインでは、IPトランスポートはアドレスファミリ（IPv4またはIPv6）と一致する必要があります。

4. Management Considerations

4. 管理上の考慮事項

4.1. Coexistence with OSPFv2

4.1. OSPFv2との共存

Since OSPFv2 [RFC2328] and OSPFv3 over IPv4 as described herein use exactly the same protocol and IPv4 addresses, OSPFv2 packets may be delivered to the OSPFv3 process and vice versa. When this occurs, the mismatched protocol packets will be dropped due to validation of the version in the first octet of the OSPFv2/OSPFv3 protocol header. Note that this will not prevent the packets from being delivered to the correct protocol process as standard socket implementations will deliver a copy to each socket matching the selectors.

ここで説明するOSPFv2 [RFC2328]とOSPFv3 over IPv4は、まったく同じプロトコルとIPv4アドレスを使用するため、OSPFv2パケットがOSPFv3プロセスに配信されたり、その逆の場合があります。これが発生すると、OSPFv2 / OSPFv3プロトコルヘッダーの最初のオクテットのバージョンが検証されるため、不一致のプロトコルパケットがドロップされます。標準のソケット実装がセレクターに一致する各ソケットにコピーを配信するため、これによってパケットが正しいプロトコルプロセスに配信されるのを妨げないことに注意してください。

Implementations of OSPFv3 over IPv4 transport SHOULD implement separate counters for a protocol mismatch and SHOULD provide means to suppress the ospfIfRxBadPacket and ospfVirtIfRxBadPacket SNMP notifications as described in [RFC4750] and the ospfv3IfRxBadPacket and ospv3VirtIfRxBadPacket SNMP notifications as described in [RFC5643] when an OSPFv2 packet is received by the OSPFv3 process or vice versa.

OSPFv3 over IPv4トランスポートの実装は、プロトコルの不一致に対して個別のカウンターを実装する必要があり（SHOULD）、[RFC4750]で説明されているospfIfRxBadPacketとospfVirtIfRxBadPacket SNMP通知を抑制し、ospfv3IfRxBadPacketとospv3VirtIfRxBadPacketでOSPFパケットが説明されているOSPFv56パケットのOSPF通知を抑制する必要があります。 OSPFv3プロセスで受信した、またはその逆。

5. Security Considerations

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

OSPFv3 [RFC5340] relies on IPsec [RFC4301] for authentication and confidentiality. "Authentication/Confidentiality in OSPFv3" [RFC4552] specifies how IPsec is used with OSPFv3 over IPv6 transport. In order to use OSPFv3 with IPv4 transport as specified herein, further work such as "Authentication/Confidentiality in OSPFv2" [IPsec-OSPF] would be required.

OSPFv3 [RFC5340]は、認証と機密性をIPsec [RFC4301]に依存しています。「OSPFv3での認証/機密保持」[RFC4552]は、IPv6トランスポート上のOSPFv3でIPsecを使用する方法を指定します。ここで指定されているIPv4トランスポートでOSPFv3を使用するには、「OSPFv2での認証/機密保持」[IPsec-OSPF]などの作業がさらに必要になります。

An optional OSPFv3 Authentication Trailer [RFC7166] also has been defined as an alternative to using IPsec. The calculation of the authentication data in the Authentication Trailer includes the source IPv6 address to protect an OSPFv3 router from man-in-the-middle attacks. For IPv4 encapsulation as described herein, the IPv4 source address should be placed in the first 4 octets of Apad followed by the hexadecimal value 0x878FE1F3 repeated (L-4)/4 times, where L is the length of the hash measured in octets.

オプションのOSPFv3認証トレーラー[RFC7166]も、IPsecを使用する代わりに定義されています。 Authentication Trailerの認証データの計算には、OSVv3ルーターを中間者攻撃から保護するためのソースIPv6アドレスが含まれています。ここで説明するIPv4カプセル化の場合、IPv4送信元アドレスはApadの最初の4オクテットに配置し、その後に16進数値0x878FE1F3を（L-4）/ 4回繰り返します。Lはオクテットで測定したハッシュの長さです。

The processing of the optional Authentication Trailer is contained entirely within the OSPFv3 protocol. In other words, each OSPFv3 router instance is responsible for the authentication, without involvement from IPsec or any other IP-layer function. Consequently, except for calculation of the Apad value, transporting OSPFv3 packets using IPv4 does not change the generation or validation of the optional OSPFv3 Authentication Trailer.

オプションの認証トレーラーの処理は、完全にOSPFv3プロトコル内に含まれています。つまり、各OSPFv3ルーターインスタンスは、IPsecや他のIPレイヤー機能の関与なしに、認証を担当します。したがって、Apad値の計算を除いて、IPv4を使用してOSPFv3パケットを転送しても、オプションのOSPFv3認証トレーラーの生成または検証は変更されません。

6. References

6. 参考文献

6.1. Normative References

6.1. 引用文献

[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, <http://www.rfc-editor.org/info/rfc791>.

[RFC791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、DOI 10.17487 / RFC0791、1981年9月、<http://www.rfc-editor.org/info/rfc791>。

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。

[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/RFC2328, April 1998, <http://www.rfc-editor.org/info/rfc2328>.

[RFC2328] Moy、J。、「OSPFバージョン2」、STD 54、RFC 2328、DOI 10.17487 / RFC2328、1998年4月、<http://www.rfc-editor.org/info/rfc2328>。

[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998, <http://www.rfc-editor.org/info/rfc2460>.

[RFC2460] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、DOI 10.17487 / RFC2460、1998年12月、<http://www.rfc-editor.org/info/ rfc2460>。

[RFC5309] Shen, N., Ed., and A. Zinin, Ed., "Point-to-Point Operation over LAN in Link State Routing Protocols", RFC 5309, DOI 10.17487/RFC5309, October 2008, <http://www.rfc-editor.org/info/rfc5309>.

[RFC5309] Shen、N。、編、およびA. Zinin、編、「リンクステートルーティングプロトコルにおけるLAN経由のポイントツーポイント操作」、RFC 5309、DOI 10.17487 / RFC5309、2008年10月、<http：/ /www.rfc-editor.org/info/rfc5309>。

[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, <http://www.rfc-editor.org/info/rfc5340>.

[RFC5340] Coltun、R.、Ferguson、D.、Moy、J。、およびA. Lindem、「OSPF for IPv6」、RFC 5340、DOI 10.17487 / RFC5340、2008年7月、<http：//www.rfc-editor .org / info / rfc5340>。

[RFC5838] Lindem, A., Ed., Mirtorabi, S., Roy, A., Barnes, M., and R. Aggarwal, "Support of Address Families in OSPFv3", RFC 5838, DOI 10.17487/RFC5838, April 2010, <http://www.rfc-editor.org/info/rfc5838>.

[RFC5838] Lindem、A.、Ed。、Mirtorabi、S.、Roy、A.、Barnes、M。、およびR. Aggarwal、「Support of Address Families in OSPFv3」、RFC 5838、DOI 10.17487 / RFC5838、April 2010 、<http://www.rfc-editor.org/info/rfc5838>。

6.2. Informative References

6.2. 参考引用

[IPsec-OSPF] Gupta, M. and N. Melam, "Authentication/Confidentiality for OSPFv2", Work in Progress, draft-gupta-ospf-ospfv2-sec-01, August 2009.

[IPsec-OSPF] Gupta、M。およびN. Melam、「Authentication / Confidentiality for OSPFv2」、Work in Progress、draft-gupta-ospf-ospfv2-sec-01、2009年8月。

[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, <http://www.rfc-editor.org/info/rfc768>.

[RFC768] Postel、J。、「User Datagram Protocol」、STD 6、RFC 768、DOI 10.17487 / RFC0768、1980年8月、<http://www.rfc-editor.org/info/rfc768>。

[RFC826] Plummer, D., "Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware", STD 37, RFC 826, DOI 10.17487/RFC0826, November 1982, <http://www.rfc-editor.org/info/rfc826>.

[RFC826]プラムマー、D。、「イーサネットアドレス解決プロトコル：またはネットワークプロトコルアドレスを48ビットイーサネットアドレスに変換してイーサネットハードウェアで送信する」、STD 37、RFC 826、DOI 10.17487 / RFC0826、1982年11月、<http：/ /www.rfc-editor.org/info/rfc826>。

[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, <http://www.rfc-editor.org/info/rfc2464>.

[RFC2464] Crawford、M。、「Transmission of IPv6 Packets over Ethernet Networks」、RFC 2464、DOI 10.17487 / RFC2464、1998年12月、<http://www.rfc-editor.org/info/rfc2464>。

[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, <http://www.rfc-editor.org/info/rfc4271>.

[RFC4271] Rekhter、Y。、編、Li、T。、編、S。Hares、編、「A Border Gateway Protocol 4（BGP-4）」、RFC 4271、DOI 10.17487 / RFC4271、2006年1月、<http://www.rfc-editor.org/info/rfc4271>。

[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, <http://www.rfc-editor.org/info/rfc4301>.

[RFC4301] Kent、S。およびK. Seo、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、DOI 10.17487 / RFC4301、2005年12月、<http://www.rfc-editor.org/info/rfc4301>。

[RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, June 2006, <http://www.rfc-editor.org/info/rfc4552>.

[RFC4552] Gupta、M。およびN. Melam、「Authentication / Confidentiality for OSPFv3」、RFC 4552、DOI 10.17487 / RFC4552、2006年6月、<http://www.rfc-editor.org/info/rfc4552>。

[RFC4750] Joyal, D., Ed., Galecki, P., Ed., Giacalone, S., Ed., Coltun, R., and F. Baker, "OSPF Version 2 Management Information Base", RFC 4750, DOI 10.17487/RFC4750, December 2006, <http://www.rfc-editor.org/info/rfc4750>.

[RFC4750] Joyal、D。、編、Galecki、P。、編、Giacarone、S。、編、Coltun、R、およびF.ベイカー、「OSPFバージョン2管理情報ベース」、RFC 4750、DOI 10.17487 / RFC4750、2006年12月、<http://www.rfc-editor.org/info/rfc4750>。

[RFC5613] Zinin, A., Roy, A., Nguyen, L., Friedman, B., and D. Yeung, "OSPF Link-Local Signaling", RFC 5613, DOI 10.17487/RFC5613, August 2009, <http://www.rfc-editor.org/info/rfc5613>.

[RFC5613] Zinin、A.、Roy、A.、Nguyen、L.、Friedman、B。、およびD. Yeung、「OSPF Link-Local Signaling」、RFC 5613、DOI 10.17487 / RFC5613、2009年8月、<http： //www.rfc-editor.org/info/rfc5613>。

[RFC5643] Joyal, D., Ed., and V. Manral, Ed., "Management Information Base for OSPFv3", RFC 5643, DOI 10.17487/RFC5643, August 2009, <http://www.rfc-editor.org/info/rfc5643>.

[RFC5643] Joyal、D。、編、およびV. Manral、編、「OSPFv3の管理情報ベース」、RFC 5643、DOI 10.17487 / RFC5643、2009年8月、<http://www.rfc-editor.org / info / rfc5643>。

[RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, DOI 10.17487/RFC5881, June 2010, <http://www.rfc-editor.org/info/rfc5881>.

[RFC5881] Katz、D。およびD. Ward、「IPv4およびIPv6（シングルホップ）の双方向転送検出（BFD）」、RFC 5881、DOI 10.17487 / RFC5881、2010年6月、<http：//www.rfc-editor .org / info / rfc5881>。

[RFC7166] Bhatia, M., Manral, V., and A. Lindem, "Supporting Authentication Trailer for OSPFv3", RFC 7166, DOI 10.17487/RFC7166, March 2014, <http://www.rfc-editor.org/info/rfc7166>.

[RFC7166] Bhatia、M.、Manral、V。、およびA. Lindem、「Supporting Authentication Trailer for OSPFv3」、RFC 7166、DOI 10.17487 / RFC7166、2014年3月、<http://www.rfc-editor.org/ info / rfc7166>。

Acknowledgments

謝辞

The authors would like to thank Alexander Okonnikov for his thorough review and valuable feedback and Suresh Krishnan for pointing out that clear specification for the pseudo-header used in the OSPFv3 packet checksum calculation was required. The authors would also like to thank Wenhu Lu for acting as document shepherd.

著者は、徹底的なレビューと貴重なフィードバックを提供してくれたAlexander Okonnikovと、OSPFv3パケットチェックサム計算で使用される疑似ヘッダーの明確な仕様が必要であることを指摘してくれたSuresh Krishnanに感謝します。著者は、ドキュメントシェパードとして行動してくれたWenhu Luにも感謝します。

Authors' Addresses

著者のアドレス

Ing-Wher Chen Ericsson

   Email: ichen@kuatrotech.com

Acee Lindem Cisco

シスコアシーリンデム

   Email: acee@cisco.com

RJ Atkinson Consultant

RJアトキンソンコンサルタント

   Email: rja.lists@gmail.com