[要約] RFC 5340は、IPv6におけるOSPF（Open Shortest Path First）のプロトコルに関する仕様を定めたものであり、IPv6ネットワークにおける経路選択とルーティングを効率化することを目的としています。
Network Working Group R. Coltun
Request for Comments: 5340 Acoustra Productions
Obsoletes: 2740 D. Ferguson
Category: Standards Track Juniper Networks
J. Moy
Sycamore Networks, Inc
A. Lindem, Ed.
Redback Networks
July 2008
OSPF for IPv6
IPv6のOSPF
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Abstract
概要
This document describes the modifications to OSPF to support version 6 of the Internet Protocol (IPv6). The fundamental mechanisms of OSPF (flooding, Designated Router (DR) election, area support, Short Path First (SPF) calculations, etc.) remain unchanged. However, some changes have been necessary, either due to changes in protocol semantics between IPv4 and IPv6, or simply to handle the increased address size of IPv6. These modifications will necessitate incrementing the protocol version from version 2 to version 3. OSPF for IPv6 is also referred to as OSPF version 3 (OSPFv3).
このドキュメントでは、インターネットプロトコル（IPv6）のバージョン6をサポートするためのOSPFの変更について説明します。OSPF（洪水、指定ルーター（DR）選挙、エリアサポート、ショートパスファースト（SPF）計算など）の基本的なメカニズムは変更されていません。ただし、IPv4とIPv6の間のプロトコルセマンティクスの変更、またはIPv6のアドレスサイズの増加を処理するために、いくつかの変更が必要でした。これらの変更により、バージョン2からバージョン3にプロトコルバージョンをインクリメントする必要があります。IPv6のOSPFは、OSPFバージョン3（OSPFV3）とも呼ばれます。
Changes between OSPF for IPv4, OSPF Version 2, and OSPF for IPv6 as described herein include the following. Addressing semantics have been removed from OSPF packets and the basic Link State Advertisements (LSAs). New LSAs have been created to carry IPv6 addresses and prefixes. OSPF now runs on a per-link basis rather than on a per-IP-subnet basis. Flooding scope for LSAs has been generalized. Authentication has been removed from the OSPF protocol and instead relies on IPv6's Authentication Header and Encapsulating Security Payload (ESP).
本明細書に記載されているように、IPv4、OSPFバージョン2、およびIPv6のOSPFのOSPF間の変更には、以下が含まれます。対処セマンティクスは、OSPFパケットと基本的なリンク状態広告（LSA）から削除されました。IPv6アドレスとプレフィックスを携帯するために、新しいLSAが作成されています。OSPFは、IP-IP-Subnetベースではなく、リンクごとに実行されます。LSAの洪水範囲が一般化されています。認証はOSPFプロトコルから削除されており、代わりにIPv6の認証ヘッダーとセキュリティペイロードのカプセル化に依存しています（ESP）。
Even with larger IPv6 addresses, most packets in OSPF for IPv6 are almost as compact as those in OSPF for IPv4. Most fields and packet-size limitations present in OSPF for IPv4 have been relaxed. In addition, option handling has been made more flexible.
IPv6アドレスが大きい場合でも、IPv6のOSPFのほとんどのパケットは、IPv4のOSPFのほとんどのパケットとほぼ同じくらいコンパクトです。IPv4のOSPFに存在するほとんどのフィールドとパケットサイズの制限は緩和されています。さらに、オプション処理がより柔軟になりました。
All of OSPF for IPv4's optional capabilities, including demand circuit support and Not-So-Stubby Areas (NSSAs), are also supported in OSPF for IPv6.
IPv4のすべてのOSPFは、Demand Circuit Supportやそれほど魅力的でないエリア（NSSA）を含むすべてのOSPFでサポートされています。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Differences from OSPF for IPv4 . . . . . . . . . . . . . . . . 5
2.1. Protocol Processing Per-Link, Not Per-Subnet . . . . . . . 5
2.2. Removal of Addressing Semantics . . . . . . . . . . . . . 5
2.3. Addition of Flooding Scope . . . . . . . . . . . . . . . . 6
2.4. Explicit Support for Multiple Instances per Link . . . . . 6
2.5. Use of Link-Local Addresses . . . . . . . . . . . . . . . 7
2.6. Authentication Changes . . . . . . . . . . . . . . . . . . 7
2.7. Packet Format Changes . . . . . . . . . . . . . . . . . . 8
2.8. LSA Format Changes . . . . . . . . . . . . . . . . . . . . 9
2.9. Handling Unknown LSA Types . . . . . . . . . . . . . . . . 10
2.10. Stub/NSSA Area Support . . . . . . . . . . . . . . . . . . 11
2.11. Identifying Neighbors by Router ID . . . . . . . . . . . . 11
3. Differences with RFC 2740 . . . . . . . . . . . . . . . . . . 11
3.1. Support for Multiple Interfaces on the Same Link . . . . . 11
3.2. Deprecation of MOSPF for IPv6 . . . . . . . . . . . . . . 12
3.3. NSSA Specification . . . . . . . . . . . . . . . . . . . . 12
3.4. Stub Area Unknown LSA Flooding Restriction Deprecated . . 12
3.5. Link LSA Suppression . . . . . . . . . . . . . . . . . . . 12
3.6. LSA Options and Prefix Options Updates . . . . . . . . . . 13
3.7. IPv6 Site-Local Addresses . . . . . . . . . . . . . . . . 13
4. Implementation Details . . . . . . . . . . . . . . . . . . . . 13
4.1. Protocol Data Structures . . . . . . . . . . . . . . . . . 14
4.1.1. The Area Data Structure . . . . . . . . . . . . . . . 15
4.1.2. The Interface Data Structure . . . . . . . . . . . . . 15
4.1.3. The Neighbor Data Structure . . . . . . . . . . . . . 16
4.2. Protocol Packet Processing . . . . . . . . . . . . . . . . 17
4.2.1. Sending Protocol Packets . . . . . . . . . . . . . . . 17
4.2.1.1. Sending Hello Packets . . . . . . . . . . . . . . 18
4.2.1.2. Sending Database Description Packets . . . . . . . 19
4.2.2. Receiving Protocol Packets . . . . . . . . . . . . . . 19
4.2.2.1. Receiving Hello Packets . . . . . . . . . . . . . 21
4.3. The Routing table Structure . . . . . . . . . . . . . . . 22
4.3.1. Routing Table Lookup . . . . . . . . . . . . . . . . . 23
4.4. Link State Advertisements . . . . . . . . . . . . . . . . 23
4.4.1. The LSA Header . . . . . . . . . . . . . . . . . . . . 23
4.4.2. The Link-State Database . . . . . . . . . . . . . . . 24
4.4.3. Originating LSAs . . . . . . . . . . . . . . . . . . . 25
4.4.3.1. LSA Options . . . . . . . . . . . . . . . . . . . 27
4.4.3.2. Router-LSAs . . . . . . . . . . . . . . . . . . . 27
4.4.3.3. Network-LSAs . . . . . . . . . . . . . . . . . . . 29
4.4.3.4. Inter-Area-Prefix-LSAs . . . . . . . . . . . . . . 30
4.4.3.5. Inter-Area-Router-LSAs . . . . . . . . . . . . . . 31
4.4.3.6. AS-External-LSAs . . . . . . . . . . . . . . . . . 32
4.4.3.7. NSSA-LSAs . . . . . . . . . . . . . . . . . . . . 33
4.4.3.8. Link-LSAs . . . . . . . . . . . . . . . . . . . . 34
4.4.3.9. Intra-Area-Prefix-LSAs . . . . . . . . . . . . . . 36
4.4.4. Future LSA Validation . . . . . . . . . . . . . . . . 40
4.5. Flooding . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.5.1. Receiving Link State Update Packets . . . . . . . . . 40
4.5.2. Sending Link State Update Packets . . . . . . . . . . 41
4.5.3. Installing LSAs in the Database . . . . . . . . . . . 43
4.6. Definition of Self-Originated LSAs . . . . . . . . . . . . 43
4.7. Virtual Links . . . . . . . . . . . . . . . . . . . . . . 44
4.8. Routing Table Calculation . . . . . . . . . . . . . . . . 44
4.8.1. Calculating the Shortest-Path Tree for an Area . . . . 45
4.8.2. The Next-Hop Calculation . . . . . . . . . . . . . . . 44
4.8.3. Calculating the Inter-Area Routes . . . . . . . . . . 47
4.8.4. Examining Transit Areas' Summary-LSAs . . . . . . . . 48
4.8.5. Calculating AS External and NSSA Routes . . . . . . . 48
4.9. Multiple Interfaces to a Single Link . . . . . . . . . . . 48
4.9.1. Standby Interface State . . . . . . . . . . . . . . . 50
5. Security Considerations . . . . . . . . . . . . . . . . . . . 52
6. Manageability Considerations . . . . . . . . . . . . . . . . . 52
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 52
7.1. MOSPF for OSPFv3 Deprecation IANA Considerations . . . . . 53
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 53
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 55
9.1. Normative References . . . . . . . . . . . . . . . . . . . 55
9.2. Informative References . . . . . . . . . . . . . . . . . . 56
Appendix A. OSPF Data Formats . . . . . . . . . . . . . . . . . . 57
A.1. Encapsulation of OSPF Packets . . . . . . . . . . . . . . 57
A.2. The Options Field . . . . . . . . . . . . . . . . . . . . 58
A.3. OSPF Packet Formats . . . . . . . . . . . . . . . . . . . 60
A.3.1. The OSPF Packet Header . . . . . . . . . . . . . . . . 60
A.3.2. The Hello Packet . . . . . . . . . . . . . . . . . . . 62
A.3.3. The Database Description Packet . . . . . . . . . . . 63
A.3.4. The Link State Request Packet . . . . . . . . . . . . 65
A.3.5. The Link State Update Packet . . . . . . . . . . . . . 66
A.3.6. The Link State Acknowledgment Packet . . . . . . . . . 67
A.4. LSA Formats . . . . . . . . . . . . . . . . . . . . . . . 68
A.4.1. IPv6 Prefix Representation . . . . . . . . . . . . . . 69
A.4.1.1. Prefix Options . . . . . . . . . . . . . . . . . . 69
A.4.2. The LSA Header . . . . . . . . . . . . . . . . . . . . 70
A.4.2.1. LSA Type . . . . . . . . . . . . . . . . . . . . . 72
A.4.3. Router-LSAs . . . . . . . . . . . . . . . . . . . . . 73
A.4.4. Network-LSAs . . . . . . . . . . . . . . . . . . . . . 76
A.4.5. Inter-Area-Prefix-LSAs . . . . . . . . . . . . . . . . 77
A.4.6. Inter-Area-Router-LSAs . . . . . . . . . . . . . . . . 78
A.4.7. AS-External-LSAs . . . . . . . . . . . . . . . . . . . 79
A.4.8. NSSA-LSAs . . . . . . . . . . . . . . . . . . . . . . 82
A.4.9. Link-LSAs . . . . . . . . . . . . . . . . . . . . . . 82
A.4.10. Intra-Area-Prefix-LSAs . . . . . . . . . . . . . . . . 84
Appendix B. Architectural Constants . . . . . . . . . . . . . . . 86
Appendix C. Configurable Constants . . . . . . . . . . . . . . . 86
C.1. Global Parameters . . . . . . . . . . . . . . . . . . . . 86
C.2. Area Parameters . . . . . . . . . . . . . . . . . . . . . 87
C.3. Router Interface Parameters . . . . . . . . . . . . . . . 88
C.4. Virtual Link Parameters . . . . . . . . . . . . . . . . . 90
C.5. NBMA Network Parameters . . . . . . . . . . . . . . . . . 91
C.6. Point-to-Multipoint Network Parameters . . . . . . . . . . 92
C.7. Host Route Parameters . . . . . . . . . . . . . . . . . . 92
This document describes the modifications to OSPF to support version 6 of the Internet Protocol (IPv6). The fundamental mechanisms of OSPF (flooding, Designated Router (DR) election, area support, (Shortest Path First) SPF calculations, etc.) remain unchanged. However, some changes have been necessary, either due to changes in protocol semantics between IPv4 and IPv6, or simply to handle the increased address size of IPv6. These modifications will necessitate incrementing the protocol version from version 2 to version 3. OSPF for IPv6 is also referred to as OSPF version 3 (OSPFv3).
このドキュメントでは、インターネットプロトコル（IPv6）のバージョン6をサポートするためのOSPFの変更について説明します。OSPFの基本的なメカニズム（洪水、指定ルーター（DR）選挙、エリアサポート、（最初の最短のパス）SPF計算など）の基本的なメカニズムは変更されません。ただし、IPv4とIPv6の間のプロトコルセマンティクスの変更、またはIPv6のアドレスサイズの増加を処理するために、いくつかの変更が必要でした。これらの変更により、バージョン2からバージョン3にプロトコルバージョンをインクリメントする必要があります。IPv6のOSPFは、OSPFバージョン3（OSPFV3）とも呼ばれます。
This document is organized as follows. Section 2 describes the differences between OSPF for IPv4 (OSPF version 2) and OSPF for IPv6 (OSPF version 3) in detail. Section 3 describes the difference between RFC 2740 and this document. Section 4 provides implementation details for the changes. Appendix A gives the OSPF for IPv6 packet and Link State Advertisement (LSA) formats. Appendix B lists the OSPF architectural constants. Appendix C describes configuration parameters.
このドキュメントは次のように整理されています。セクション2では、IPv4（OSPFバージョン2）のOSPF（OSPFバージョン2）とIPv6のOSPF（OSPFバージョン3）の違いについて詳しく説明します。セクション3では、RFC 2740とこのドキュメントの違いについて説明します。セクション4では、変更の実装の詳細を示します。付録Aでは、IPv6パケットおよびリンク状態広告（LSA）形式のOSPFを示しています。付録Bには、OSPFアーキテクチャ定数がリストされています。付録Cでは、構成パラメーターについて説明します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC-KEYWORDS].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[rfc-keywords]で説明されているように解釈されます。
This document attempts to use terms from both the OSPF for IPv4 specification ([OSPFV2]) and the IPv6 protocol specifications ([IPV6]). This has produced a mixed result. Most of the terms used both by OSPF and IPv6 have roughly the same meaning (e.g., interfaces). However, there are a few conflicts. IPv6 uses "link" similarly to IPv4 OSPF's "subnet" or "network". In this case, we have chosen to use IPv6's "link" terminology. "Link" replaces OSPF's "subnet" and "network" in most places in this document, although OSPF's network-LSA remains unchanged (and possibly unfortunately, a new link-LSA has also been created).
このドキュメントは、IPv4仕様（[OSPFV2]）とIPv6プロトコル仕様（[IPv6]）のOSPFの条件を使用しようとします。これにより、さまざまな結果が生まれました。OSPFとIPv6の両方で使用される用語のほとんどは、ほぼ同じ意味（たとえば、インターフェイス）です。ただし、いくつかの競合があります。IPv6は、IPv4 OSPFの「サブネット」または「ネットワーク」と同様に「リンク」を使用します。この場合、IPv6の「リンク」用語を使用することを選択しました。「Link」は、このドキュメントのほとんどの場所でOSPFの「サブネット」と「ネットワーク」を置き換えますが、OSPFのネットワークLSAは変化していません（おそらく残念ながら、新しいLink-LSAも作成されています）。
The names of some of the OSPF LSAs have also changed. See Section 2.8 for details.
OSPF LSAの一部の名前も変更されています。詳細については、セクション2.8を参照してください。
In the context of this document, an OSPF instance is a separate protocol instance complete with its own protocol data structures (e.g., areas, interfaces, neighbors), link-state database, protocol state machines, and protocol processing (e.g., SPF calculation).
このドキュメントのコンテキストでは、OSPFインスタンスは、独自のプロトコルデータ構造（領域、インターフェイス、近隣）、リンク状態データベース、プロトコル状態マシン、およびプロトコル処理（SPF計算など）を備えた個別のプロトコルインスタンスです。。
Most of the algorithms from OSPF for IPv4 [OSPFV2] have been preserved in OSPF for IPv6. However, some changes have been necessary, either due to changes in protocol semantics between IPv4 and IPv6, or simply to handle the increased address size of IPv6.
IPv4 [OSPFv2]のOSPFからのアルゴリズムのほとんどは、IPv6のOSPFに保存されています。ただし、IPv4とIPv6の間のプロトコルセマンティクスの変更、またはIPv6のアドレスサイズの増加を処理するために、いくつかの変更が必要でした。
The following subsections describe the differences between this document and [OSPFV2].
次のサブセクションでは、このドキュメントと[OSPFV2]の違いについて説明します。
IPv6 uses the term "link" to indicate "a communication facility or medium over which nodes can communicate at the link layer" ([IPV6]). "Interfaces" connect to links. Multiple IPv6 subnets can be assigned to a single link, and two nodes can talk directly over a single link, even if they do not share a common IPv6 subnet (IPv6 prefix).
IPv6は「リンク」という用語を使用して、「ノードがリンクレイヤーで通信できる通信施設または媒体」（[IPv6]）を示します。「インターフェイス」はリンクに接続します。複数のIPv6サブネットを単一のリンクに割り当てることができ、2つのノードは、一般的なIPv6サブネット（IPv6プレフィックス）を共有していなくても、単一のリンク上で直接通知できます。
For this reason, OSPF for IPv6 runs per-link instead of the IPv4 behavior of per-IP-subnet. The terms "network" and "subnet" used in the IPv4 OSPF specification ([OSPFV2]) should generally be replaced by link. Likewise, an OSPF interface now connects to a link instead of an IP subnet.
このため、IPv6のOSPFは、PER-IP-SubnetのIPv4動作ではなく、リンクごとに実行されます。IPv4 OSPF仕様（[OSPFV2]）で使用される「ネットワーク」および「サブネット」という用語は、通常、リンクに置き換える必要があります。同様に、OSPFインターフェイスは、IPサブネットの代わりにリンクに接続するようになりました。
This change affects the receiving of OSPF protocol packets, the contents of Hello packets, and the contents of network-LSAs.
この変更は、OSPFプロトコルパケットの受信、ハローパケットの内容、およびネットワークLSAの内容に影響します。
In OSPF for IPv6, addressing semantics have been removed from the OSPF protocol packets and the main LSA types, leaving a network-protocol-independent core. In particular: o IPv6 addresses are not present in OSPF packets, except in LSA payloads carried by the Link State Update packets. See Section 2.7 for details.
IPv6のOSPFでは、セマンティクスへの対処がOSPFプロトコルパケットとメインLSAタイプから削除され、ネットワークプロトコルに依存しないコアが残ります。特に：O IPv6アドレスは、Link State Updateパケットによって運ばれるLSAペイロードを除き、OSPFパケットには存在しません。詳細については、セクション2.7を参照してください。
o Router-LSAs and network-LSAs no longer contain network addresses, but simply express topology information. See Section 2.8 for details.
o Router-LSAとネットワークLSAは、ネットワークアドレスを含むのではなく、単にトポロジ情報を表現するだけです。詳細については、セクション2.8を参照してください。
o OSPF Router IDs, Area IDs, and LSA Link State IDs remain at the IPv4 size of 32 bits. They can no longer be assigned as (IPv6) addresses.
o OSPFルーターID、エリアID、およびLSAリンク状態IDは、32ビットのIPv4サイズのままです。（IPv6）アドレスとして割り当てることはできなくなりました。
o Neighboring routers are now always identified by Router ID. Previously, they had been identified by an IPv4 address on broadcast, NBMA (Non-Broadcast Multi-Access), and point-to-multipoint links.
o 隣接するルーターは、ルーターIDによって常に識別されます。以前は、ブロードキャストのIPv4アドレス、NBMA（ブロードキャスト以外のマルチアクセス）、およびポイントツーマルチポイントリンクによって識別されていました。
Flooding scope for LSAs has been generalized and is now explicitly coded in the LSA's LS type field. There are now three separate flooding scopes for LSAs:
LSAの洪水範囲は一般化されており、現在はLSAのLSタイプフィールドで明示的にコード化されています。現在、LSAには3つの別々の洪水スコープがあります。
o Link-local scope. LSA is only flooded on the local link and no further. Used for the new link-LSA. See Section 4.4.3.8 for details.
o リンクローカルスコープ。LSAはローカルリンクにのみ浸水しているだけでなく、それ以上はありません。新しいLink-LSAに使用されます。詳細については、セクション4.4.3.8を参照してください。
o Area scope. LSA is only flooded throughout a single OSPF area. Used for router-LSAs, network-LSAs, inter-area-prefix-LSAs, inter-area-router-LSAs, and intra-area-prefix-LSAs.
o エリアスコープ。LSAは、単一のOSPFエリア全体でのみ浸水しています。ルーター-LSA、ネットワークLSA、エリア間 - エリア - ペリフィクスLSA、エリア間ルーターLSA、およびエリア内 - エリア内型LSASに使用されます。
o AS scope. LSA is flooded throughout the routing domain. Used for AS-external-LSAs. A router that originates AS scoped LSAs is considered an AS Boundary Router (ASBR) and will set its E-bit in router-LSAs for regular areas.
o 範囲として。LSAは、ルーティングドメイン全体に浸水しています。As-External-LSAに使用されます。スコープされたLSAとして発生するルーターは、境界ルーター（ASBR）と見なされ、通常の領域のルーターLSAでeビットを設定します。
OSPF now supports the ability to run multiple OSPF protocol instances on a single link. For example, this may be required on a NAP segment shared between several providers. Providers may be supporting separate OSPF routing domains that wish to remain separate even though they have one or more physical network segments (i.e., links) in common. In OSPF for IPv4, this was supported in a haphazard fashion using the authentication fields in the OSPF for IPv4 header.
OSPFは、単一のリンクで複数のOSPFプロトコルインスタンスを実行する機能をサポートするようになりました。たとえば、これは、複数のプロバイダー間で共有される昼寝セグメントで必要になる場合があります。プロバイダーは、1つ以上の物理ネットワークセグメント（つまり、リンク）が共通している場合でも、個別のままにしたい個別のOSPFルーティングドメインをサポートしている場合があります。IPv4のOSPFでは、IPv4ヘッダーのOSPFの認証フィールドを使用して、これは偶然にサポートされていました。
Another use for running multiple OSPF instances is if you want, for one reason or another, to have a single link belong to two or more OSPF areas.
複数のOSPFインスタンスを実行するためのもう1つの用途は、何らかの理由で、1つのリンクを2つ以上のOSPF領域に属したい場合です。
Support for multiple protocol instances on a link is accomplished via an "Instance ID" contained in the OSPF packet header and OSPF interface data structures. Instance ID solely affects the reception of OSPF packets and applies to normal OSPF interfaces and virtual links.
リンク上の複数のプロトコルインスタンスのサポートは、OSPFパケットヘッダーとOSPFインターフェイスデータ構造に含まれる「インスタンスID」を介して達成されます。インスタンスIDは、OSPFパケットの受信にのみ影響し、通常のOSPFインターフェイスと仮想リンクに適用されます。
IPv6 link-local addresses are for use on a single link, for purposes of neighbor discovery, auto-configuration, etc. IPv6 routers do not forward IPv6 datagrams having link-local source addresses [IP6ADDR]. Link-local unicast addresses are assigned from the IPv6 address range FE80/10.
IPv6 Link-Localアドレスは、近隣発見、自動構成などの目的で、単一のリンクで使用するためのものです。IPv6ルーターは、リンクローカルソースアドレス[IP6ADDR]を持つIPv6データグラムを転送しません。Link-Local Unicastアドレスは、IPv6アドレス範囲FE80/10から割り当てられます。
OSPF for IPv6 assumes that each router has been assigned link-local unicast addresses on each of the router's attached physical links [IP6ADDR]. On all OSPF interfaces except virtual links, OSPF packets are sent using the interface's associated link-local unicast address as the source address. A router learns the link-local addresses of all other routers attached to its links and uses these addresses as next-hop information during packet forwarding.
IPv6のOSPFは、各ルーターが各ルーターに添付された物理リンク[IP6ADDR]にリンクローカルユニキャストアドレスが割り当てられていることを想定しています。仮想リンクを除くすべてのOSPFインターフェイスで、OSPFパケットは、インターフェイスの関連するリンクローカルユニキャストアドレスをソースアドレスとして使用して送信されます。ルーターは、リンクに添付されている他のすべてのルーターのリンクローカルアドレスを学習し、これらのアドレスをパケット転送中に次のホップ情報として使用します。
On virtual links, a global scope IPv6 address MUST be used as the source address for OSPF protocol packets.
仮想リンクでは、グローバルスコープIPv6アドレスをOSPFプロトコルパケットのソースアドレスとして使用する必要があります。
Link-local addresses appear in OSPF link-LSAs (see Section 4.4.3.8). However, link-local addresses are not allowed in other OSPF LSA types. In particular, link-local addresses MUST NOT be advertised in inter-area-prefix-LSAs (Section 4.4.3.4), AS-external-LSAs (Section 4.4.3.6), NSSA-LSAs (Section 4.4.3.7), or intra-area-prefix-LSAs (Section 4.4.3.9).
Link-Localアドレスは、OSPF Link-LSASに表示されます（セクション4.4.3.8を参照）。ただし、リンクローカルアドレスは、他のOSPF LSAタイプでは許可されていません。特に、リンクローカルアドレスは、エリア間対とエクステルのLSAS（セクション4.4.3.4）、AS-External-LSAS（セクション4.4.3.6）、NSSA-LSAS（セクション4.4.3.7）、または内部で宣伝されてはなりません。-area-prefix-lsas（セクション4.4.3.9）。
In OSPF for IPv6, authentication has been removed from the OSPF protocol. The "AuType" and "Authentication" fields have been removed from the OSPF packet header, and all authentication-related fields have been removed from the OSPF area and interface data structures.
IPv6のOSPFでは、OSPFプロトコルから認証が削除されました。「Autype」および「認証」フィールドはOSPFパケットヘッダーから削除され、すべての認証関連フィールドはOSPFエリアとインターフェイスデータ構造から削除されました。
When running over IPv6, OSPF relies on the IP Authentication Header (see [IPAUTH]) and the IP Encapsulating Security Payload (see [IPESP]) as described in [OSPFV3-AUTH] to ensure integrity and authentication/confidentiality of routing exchanges.
IPv6を介して実行する場合、OSPFは、[OSPFV3-Auth]に記載されているように、IP認証ヘッダー（[IPAuth]を参照）とIPカプセル化セキュリティペイロード（[IPSP]を参照）に依存して、ルーティング交換の整合性と認証/機密性を確保します。
Protection of OSPF packet exchanges against accidental data corruption is provided by the standard IPv6 Upper-Layer checksum (as described in Section 8.1 of [IPV6]), covering the entire OSPF packet and prepended IPv6 pseudo-header (see Appendix A.3.1).
偶発的なデータ腐敗に対するOSPFパケット交換の保護は、標準のIPv6上層チェックサム（[IPv6]のセクション8.1で説明されている）によって提供され、OSPFパケット全体と前提条件のIPv6 pseudo-header（付録A.3.1を参照）をカバーします。
OSPF for IPv6 runs directly over IPv6. Aside from this, all addressing semantics have been removed from the OSPF packet headers, making it essentially "network-protocol-independent". All addressing information is now contained in the various LSA types only.
IPv6のOSPFは、IPv6を直接実行します。これとは別に、すべての対処するセマンティクスはOSPFパケットヘッダーから削除されており、本質的に「ネットワークプロトコルに依存しない」ものになっています。すべてのアドレス指定情報は、さまざまなLSAタイプのみに含まれています。
In detail, changes in OSPF packet format consist of the following:
詳細には、OSPFパケット形式の変更は以下で構成されています。
o The OSPF version number has been incremented from 2 to 3.
o OSPFバージョン数は2から3に増加しました。
o The Options field in Hello packets and Database Description packets has been expanded to 24 bits.
o ハローパケットとデータベースの説明パケットのオプションフィールドは、24ビットに拡張されています。
o The Authentication and AuType fields have been removed from the OSPF packet header (see Section 2.6).
o 認証フィールドと自己型フィールドは、OSPFパケットヘッダーから削除されました（セクション2.6を参照）。
o The Hello packet now contains no address information at all. Rather, it now includes an Interface ID that the originating router has assigned to uniquely identify (among its own interfaces) its interface to the link. This Interface ID will be used as the network-LSA's Link State ID if the router becomes the Designated Router on the link.
o Helloパケットには、アドレス情報がまったく含まれていません。むしろ、元のルーターが（独自のインターフェイスの中で）リンクへのインターフェイスを一意に識別するように割り当てたインターフェイスIDが含まれるようになりました。このインターフェイスIDは、ルーターがリンク上の指定ルーターになった場合、ネットワークLSAのリンク状態IDとして使用されます。
o Two Options bits, the "R-bit" and the "V6-bit", have been added to the Options field for processing router-LSAs during the SPF calculation (see Appendix A.2). If the "R-bit" is clear, an OSPF speaker can participate in OSPF topology distribution without being used to forward transit traffic; this can be used in multi-homed hosts that want to participate in the routing protocol. The V6-bit specializes the R-bit; if the V6-bit is clear, an OSPF speaker can participate in OSPF topology distribution without being used to forward IPv6 datagrams. If the R-bit is set and the V6-bit is clear, IPv6 datagrams are not forwarded but datagrams belonging to another protocol family may be forwarded.
o 「Rビット」と「V6ビット」という2つのオプションビットが、SPF計算中にルーターLSAを処理するためのオプションフィールドに追加されました（付録A.2を参照）。「r-bit」が明確な場合、OSPFスピーカーは、輸送トラフィックを転送するために使用されることなく、OSPFトポロジの分布に参加できます。これは、ルーティングプロトコルに参加したいマルチホームホストで使用できます。V6-BITはRビットを専門としています。V6ビットが明確な場合、OSPFスピーカーは、IPv6データグラムを転送するために使用されることなく、OSPFトポロジ分布に参加できます。Rビットが設定され、V6ビットが明確である場合、IPv6データグラムは転送されませんが、別のプロトコルファミリーに属するデータグラムが転送される場合があります。
o The OSPF packet header now includes an "Instance ID" that allows multiple OSPF protocol instances to be run on a single link (see Section 2.4).
o OSPFパケットヘッダーには、複数のOSPFプロトコルインスタンスを単一のリンクで実行できるようにする「インスタンスID」が含まれるようになりました（セクション2.4を参照）。
All addressing semantics have been removed from the LSA header, router-LSAs, and network-LSAs. These two LSAs now describe the routing domain's topology in a network-protocol-independent manner. New LSAs have been added to distribute IPv6 address information and data required for next-hop resolution. The names of some of IPv4's LSAs have been changed to be more consistent with each other.
すべてのアドレス指定セマンティクスは、LSAヘッダー、ルーターLSA、およびネットワークLSAから削除されています。これらの2つのLSAは、ネットワークプロトコルに依存しない方法でルーティングドメインのトポロジを説明しています。新しいLSAが追加され、次のホップ解像度に必要なIPv6アドレス情報とデータを配布しています。IPv4のLSAの一部の名前は、互いにより一致するように変更されています。
In detail, changes in LSA format consist of the following:
詳細には、LSA形式の変更は次のもので構成されています。
o The Options field has been removed from the LSA header, expanded to 24 bits, and moved into the body of router-LSAs, network-LSAs, inter-area-router-LSAs, and link-LSAs. See Appendix A.2 for details.
o オプションフィールドはLSAヘッダーから削除され、24ビットに拡張され、ルーターLSA、ネットワークLSA、エリア間ルーターLSA、およびLink-LSAの本体に移動しました。詳細については、付録A.2を参照してください。
o The LSA Type field has been expanded (into the former Options space) to 16 bits, with the upper three bits encoding flooding scope and the handling of unknown LSA types (see Section 2.9).
o LSA型フィールドは（以前のオプションスペースに）16ビットに拡張されており、上部3ビットが洪水スコープと不明なLSAタイプの処理をコードすることで拡張されています（セクション2.9を参照）。
o Addresses in LSAs are now expressed as [prefix, prefix length] instead of [address, mask] (see Appendix A.4.1). The default route is expressed as a prefix with length 0.
o LSAのアドレスは、[アドレス、マスク]の代わりに[プレフィックス、プレフィックス長]として表されるようになりました（付録A.4.1を参照）。デフォルトルートは、長さ0のプレフィックスとして表されます。
o Router-LSAs and network-LSAs now have no address information and are network protocol independent.
o Router-LSAとネットワークLSAにはアドレス情報がなく、ネットワークプロトコルが独立しています。
o Router interface information MAY be spread across multiple router-LSAs. Receivers MUST concatenate all the router-LSAs originated by a given router when running the SPF calculation.
o ルーターインターフェイス情報は、複数のルーターLSAに広がる場合があります。受信機は、SPF計算を実行するときに特定のルーターによって発生するすべてのルーターLSAを連結する必要があります。
o A new LSA called the link-LSA has been introduced. Link-LSAs have link-local flooding scope; they are never flooded beyond the link with which they are associated. Link-LSAs have three purposes: 1) they provide the router's link-local address to all other routers attached to the link, 2) they inform other routers attached to the link of a list of IPv6 prefixes to associate with the link, and 3) they allow the router to advertise a collection of Options bits to associate with the network-LSA that will be originated for the link. See Section 4.4.3.8 for details.
o Link-LSAと呼ばれる新しいLSAが導入されました。Link-LSAには、Link-Local Flooding Scopeがあります。彼らは、彼らが関連付けられているリンクを超えて浸水することはありません。Link-LSAには3つの目的があります。1）リンクに接続された他のすべてのルーターにルーターのリンクローカルアドレスを提供し、2）IPv6プレフィックスのリストのリンクに接続された他のルーターにリンクに関連付けられ、3つの他のルーターを通知します。）それらは、ルーターがオプションビットのコレクションを宣伝し、リンク用に発信されるネットワークLSAに関連付けることができるようにします。詳細については、セクション4.4.3.8を参照してください。
o In IPv4, the router-LSA carries a router's IPv4 interface addresses, the IPv4 equivalent of link-local addresses. These are only used when calculating next hops during the OSPF routing calculation (see Section 16.1.1 of [OSPFV2]), so they do not need to be flooded past the local link. Hence, using link-LSAs to distribute these addresses is more efficient. Note that link-local addresses cannot be learned through the reception of Hellos in all cases. On NBMA links, next-hop routers do not necessarily exchange Hellos. Rather, these routers learn of each other's existence by way of the Designated Router (DR).
o IPv4では、Router-LSAには、IPv4がLink-Localアドレスに相当するRouterのIPv4インターフェイスアドレスを搭載しています。これらは、OSPFルーティング計算中に次のホップを計算するときにのみ使用されます（[OSPFV2]のセクション16.1.1を参照）、ローカルリンクを過ぎて浸水する必要はありません。したがって、Link-LSAを使用してこれらのアドレスを配布する方が効率的です。Link-Localアドレスは、すべての場合にHellosの受容を通じて学習できないことに注意してください。NBMAリンクでは、Next-Hopルーターが必ずしもHellosを交換するわけではありません。むしろ、これらのルーターは、指定されたルーター（DR）によって互いの存在を学びます。
o The Options field in the network LSA is set to the logical OR of the Options that each router on the link advertises in its link-LSA.
o ネットワークLSAのオプションフィールドは、リンク上の各ルーターがリンクLSAに宣伝する論理またはオプションに設定されます。
o Type-3 summary-LSAs have been renamed "inter-area-prefix-LSAs". Type-4 summary LSAs have been renamed "inter-area-router-LSAs".
o Type-3の要約LSAは、「エリア間対とLSAS」と改名されました。タイプ4の要約LSAは、「エリア間ルーターLSA」と改名されました。
o The Link State ID in inter-area-prefix-LSAs, inter-area-router-LSAs, NSSA-LSAs, and AS-external-LSAs has lost its addressing semantics and now serves solely to identify individual pieces of the Link State Database. All addresses or Router IDs that were formerly expressed by the Link State ID are now carried in the LSA bodies.
o エリア間 - ペルフィックスLSAS、エリア間ルーターLSA、NSSA-LSA、およびAs-External-LSAのリンク状態IDは、アドレス指定セマンティクスを失い、現在はリンク状態データベースの個々のピースを特定するためだけに役立ちます。以前にリンク状態IDで表現されていたすべてのアドレスまたはルーターIDは、LSAボディに携帯されています。
o Network-LSAs and link-LSAs are the only LSAs whose Link State ID carries additional meaning. For these LSAs, the Link State ID is always the Interface ID of the originating router on the link being described. For this reason, network-LSAs and link-LSAs are now the only LSAs whose size cannot be limited: a network-LSA MUST list all routers connected to the link and a link-LSA MUST list all of a router's addresses on the link.
o ネットワークLSAとリンクLSAは、リンク状態IDに追加の意味がある唯一のLSAです。これらのLSAの場合、リンク状態IDは、記載されているリンク上の発信ルーターのインターフェイスIDです。このため、ネットワークLSAとリンクLSAは、サイズを制限できない唯一のLSAです。ネットワークLSAはリンクに接続されたすべてのルーターをリストする必要があり、リンクLSAはリンク上のすべてのルーターのアドレスをリストする必要があります。
o A new LSA called the intra-area-prefix-LSA has been introduced. This LSA carries all IPv6 prefix information that in IPv4 is included in router-LSAs and network-LSAs. See Section 4.4.3.9 for details.
o エリア内-Prefix-LSAと呼ばれる新しいLSAが導入されました。このLSAには、IPv4のIPv6プレフィックス情報がすべてRouter-LSASおよびネットワークLSAに含まれていることを伝えます。詳細については、セクション4.4.3.9を参照してください。
o Inclusion of a forwarding address or external route tag in AS-external-LSAs is now optional. In addition, AS-external-LSAs can now reference another LSA, for inclusion of additional route attributes that are outside the scope of the OSPF protocol. For example, this reference could be used to attach BGP path attributes to external routes.
o As-External-LSAに転送アドレスまたは外部ルートタグを含めることがオプションになりました。さらに、AS-External-LSAは、OSPFプロトコルの範囲外の追加のルート属性を含めるために、別のLSAを参照できるようになりました。たとえば、この参照は、BGPパス属性を外部ルートに添付するために使用できます。
Handling of unknown LSA types has been made more flexible so that, based on the LS type, unknown LSA types are either treated as having link-local flooding scope, or are stored and flooded as if they were understood. This behavior is explicitly coded in the LSA Handling bit of the link state header's LS type field (see the U-bit in Appendix A.4.2.1).
未知のLSAタイプの処理はより柔軟になり、LSタイプに基づいて、未知のLSAタイプは、リンクローカル洪水範囲を持つものとして扱われるか、理解されているかのように保存および浸水します。この動作は、リンク状態ヘッダーのLSタイプフィールドのLSAハンドリングビットで明示的にコード化されています（付録A.4.2.1のUビットを参照）。
The IPv4 OSPF behavior of simply discarding unknown types is unsupported due to the desire to mix router capabilities on a single link. Discarding unknown types causes problems when the Designated Router supports fewer options than the other routers on the link.
単に不明なタイプを単純に破棄するというIPv4 OSPFの動作は、単一のリンクでルーター機能を混合したいという要望のためにサポートされていません。未知のタイプを破棄すると、指定されたルーターがリンク上の他のルーターよりも少ないオプションをサポートする場合、問題を引き起こします。
In OSPF for IPv4, stub and NSSA areas were designed to minimize link-state database and routing table sizes for the areas' internal routers. This allows routers with minimal resources to participate in even very large OSPF routing domains.
IPv4のOSPFでは、スタブとNSSAの領域は、エリアの内部ルーターのリンク状態データベースとルーティングテーブルサイズを最小限に抑えるように設計されています。これにより、最小限のリソースを備えたルーターが非常に大きなOSPFルーティングドメインに参加することができます。
In OSPF for IPv6, the concept of stub and NSSA areas is retained. In IPv6, of the mandatory LSA types, stub areas carry only router-LSAs, network-LSAs, inter-area-prefix-LSAs, link-LSAs, and intra-area-prefix-LSAs. NSSA areas are restricted to these types and, of course, NSSA-LSAs. This is the IPv6 equivalent of the LSA types carried in IPv4 stub areas: router-LSAs, network-LSAs, type 3 summary-LSAs and for NSSA areas: stub area types and NSSA-LSAs.
IPv6のOSPFでは、スタブとNSSA領域の概念が保持されています。IPv6では、必須のLSAタイプのうち、スタブエリアにはルーターLSA、ネットワークLSA、A-A-AREA-PREFIX-LSAS、LINK-LSAS、およびA-AREA-PREFIX-LSASのみが搭載されています。NSSA領域は、これらのタイプ、そしてもちろんNSSA-LSAに制限されています。これは、Router-LSA、Network-LSA、Type 3 Summary-LSAS、およびNSSA領域のIPv4スタブエリアで運ばれるLSAタイプに相当するIPv6型です。スタブエリアタイプとNSSA-LSA。
In OSPF for IPv6, neighboring routers on a given link are always identified by their OSPF Router ID. This contrasts with the IPv4 behavior where neighbors on point-to-point networks and virtual links are identified by their Router IDs while neighbors on broadcast, NBMA, and point-to-multipoint links are identified by their IPv4 interface addresses.
IPv6のOSPFでは、特定のリンク上の隣接するルーターは、OSPFルーターIDによって常に識別されます。これは、ポイントツーポイントネットワークと仮想リンク上の近隣がルーターIDによって識別され、ブロードキャスト、NBMA、およびポイントツーマルチポイントリンクがIPv4インターフェイスアドレスによって識別されるIPv4動作とは対照的です。
This change affects the reception of OSPF packets (see Section 8.2 of [OSPFV2]), the lookup of neighbors (Section 10 of [OSPFV2]), and the reception of Hello packets (Section 10.5 of [OSPFV2]).
この変更は、OSPFパケットの受信（[OSPFV2]のセクション8.2を参照）、近隣の検索（[OSPFV2]のセクション10）、およびハローパケットの受信（[OSPFV2]のセクション10.5）に影響します。
The Router ID of 0.0.0.0 is reserved and SHOULD NOT be used.
0.0.0.0のルーターIDは予約されており、使用しないでください。
OSPFv3 implementations based on RFC 2740 will fully interoperate with implementations based on this specification. There are, however, some protocol additions and changes (all of which are backward compatible).
RFC 2740に基づくOSPFV3の実装は、この仕様に基づいて実装と完全に相互に繰り返されます。ただし、いくつかのプロトコルの追加と変更があります（これらはすべて後方互換性があります）。
This protocol feature was only partially specified in the RFC 2740. The level of specification was insufficient to implement the feature. Section 4.9 specifies the additions and clarifications necessary for implementation. They are fully compatible with RFC 2740.
このプロトコル機能は、RFC 2740で部分的にしか指定されていませんでした。仕様のレベルは、機能を実装するには不十分でした。セクション4.9は、実装に必要な追加と説明を指定します。それらはRFC 2740と完全に互換性があります。
This protocol feature was only partially specified in RFC 2740. The level of specification was insufficient to implement the feature. There are no known implementations. Multicast Extensions to OSPF (MOSPF) support and its attendant protocol fields have been deprecated from OSPFv3. Refer to Section 4.4.3.2, Section 4.4.3.4, Section 4.4.3.6, Section 4.4.3.7, Appendix A.2, Appendix A.4.2.1, Appendix A.4.3, Appendix A.4.1.1, and Section 7.1.
このプロトコル機能は、RFC 2740で部分的にしか指定されていませんでした。仕様のレベルは、機能を実装するには不十分でした。既知の実装はありません。OSPF（MOSPF）サポートへのマルチキャスト拡張機能とそのアテンダントプロトコルフィールドは、OSPFV3から廃止されました。セクション4.4.3.2、セクション4.4.3.4、セクション4.4.3.6、セクション4.4.3.7、付録A.2、付録A.4.2.1、付録A.4.3、付録A.4.1.1、およびセクション7.1を参照してください。
This protocol feature was only partially specified in RFC 2740. The level of specification was insufficient to implement the function. This document includes an NSSA specification unique to OSPFv3. This specification coupled with [NSSA] provide sufficient specification for implementation. Refer to Section 4.8.5, Appendix A.4.3, Appendix A.4.8, and [NSSA].
このプロトコル機能は、RFC 2740で部分的にしか指定されていませんでした。仕様のレベルは、関数を実装するには不十分でした。このドキュメントには、OSPFV3に固有のNSSA仕様が含まれています。[NSSA]と組み合わせたこの仕様は、実装に十分な仕様を提供します。セクション4.8.5、付録A.4.3、付録A.4.8、および[NSSA]を参照してください。
In RFC 2740 [OSPFV3], flooding of unknown LSA was restricted within stub and NSSA areas. The text describing this restriction is included below.
RFC 2740 [OSPFV3]では、未知のLSAの洪水がスタブおよびNSSA領域内で制限されていました。この制限を説明するテキストを以下に示します。
However, unlike in IPv4, IPv6 allows LSAs with unrecognized LS types to be labeled "Store and flood the LSA, as if type understood" (see the U-bit in Appendix A.4.2.1). Uncontrolled introduction of such LSAs could cause a stub area's link-state database to grow larger than its component routers' capacities.
ただし、IPv4とは異なり、IPv6は、認識されていないLSタイプのLSAに「型が理解されているかのようにLSAにflood濫する」というラベルを付けることができます（付録A.4.2.1のUビットを参照）。このようなLSAの制御されていない導入により、スタブエリアのリンク状態データベースがコンポーネントルーターの容量よりも大きくなる可能性があります。
To guard against this, the following rule regarding stub areas has been established: an LSA whose LS type is unrecognized can only be flooded into/throughout a stub area if both a) the LSA has area or link-local flooding scope and b) the LSA has U-bit set to 0. See Section 3.5 for details.
これを守るために、スタブ領域に関する次のルールが確立されています。LSタイプが認識されていないLSAは、a）LSAには領域またはリンク局所洪水範囲があり、b）両方の場合、スタブ領域全体に浸水します。LSAにはUビットが0に設定されています。詳細については、セクション3.5を参照してください。
This restriction has been deprecated. OSPFv3 routers will flood link and area scope LSAs whose LS type is unrecognized and whose U-bit is set to 1 throughout stub and NSSA areas. There are no backward-compatibility issues other than OSPFv3 routers still supporting the restriction may not propagate newly defined LSA types.
この制限は廃止されました。OSPFV3ルーターは、LSタイプが認識されておらず、UビットがスタブおよびNSSAエリア全体で1に設定されているLSタイプがflood濫し、エリアスコープLSAを浸水させます。制限をサポートしているOSPFV3ルーター以外の後方互換性の問題はありません。新たに定義されたLSAタイプを伝播しない場合があります。
The LinkLSASuppression interface configuration parameter has been added. If LinkLSASuppression is configured for an interface and the interface type is not broadcast or NBMA, origination of the link-LSA may be suppressed. The LinkLSASuppression interface configuration parameter is described in Appendix C.3. Section 4.8.2 and Section 4.4.3.8 were updated to reflect the parameter's usage.
linklsasasasSuppressionインターフェイス構成パラメーターが追加されました。linklsasasuppressionがインターフェイスに対して構成され、インターフェイスタイプがブロードキャストまたはNBMAではない場合、Link-LSAの発信は抑制される可能性があります。LinklsaSasasSuppressionインターフェイス構成パラメーターについては、付録C.3で説明します。セクション4.8.2およびセクション4.4.3.8は、パラメーターの使用法を反映するように更新されました。
The LSA Options and Prefix Options fields have been updated to reflect recent protocol additions. Specifically, bits related to MOSPF have been deprecated, Options field bits common with OSPFv2 have been reserved, and the DN-bit has been added to the prefix-options. Refer to Appendix A.2 and Appendix A.4.1.1.
LSAオプションとプレフィックスオプションフィールドは、最近のプロトコルの追加を反映するように更新されています。具体的には、MOSPFに関連するビットは非推奨、OSPFV2によく見られるオプションフィールドビットが予約されており、DN-BITがプレフィックスオプションに追加されています。付録A.2および付録A.4.1.1を参照してください。
All references to IPv6 site-local addresses have been removed.
IPv6サイトローカルアドレスへのすべての参照が削除されました。
When going from IPv4 to IPv6, the basic OSPF mechanisms remain unchanged from those documented in [OSPFV2]. These mechanisms are briefly outlined in Section 4 of [OSPFV2]. Both IPv6 and IPv4 have a link-state database composed of LSAs and synchronized between adjacent routers. Initial synchronization is performed through the Database Exchange process, which includes the exchange of Database Description, Link State Request, and Link State Update packets. Thereafter, database synchronization is maintained via flooding, utilizing Link State Update and Link State Acknowledgment packets. Both IPv6 and IPv4 use OSPF Hello packets to discover and maintain neighbor relationships, as well as to elect Designated Routers and Backup Designated Routers on broadcast and NBMA links. The decision as to which neighbor relationships become adjacencies, and the basic ideas behind inter-area routing, importing external information in AS-external-LSAs, and the various routing calculations are also the same.
IPv4からIPv6に進むと、基本的なOSPFメカニズムは[OSPFv2]に記録されているメカニズムから変化しません。これらのメカニズムは、[OSPFV2]のセクション4で簡単に概説されています。IPv6とIPv4の両方に、LSAで構成されるリンク状態データベースがあり、隣接するルーター間で同期されています。初期同期は、データベースの説明、リンク状態要求、および状態更新パケットのリンクを含むデータベース交換プロセスを通じて実行されます。その後、データベースの同期は、洪水を介して維持され、リンク状態の更新とリンク状態の確認パケットを利用します。IPv6とIPv4の両方がOSPF Helloパケットを使用して、近隣の関係を発見および維持するだけでなく、ブロードキャストおよびNBMAリンクで指定されたルーターとバックアップ指定ルーターを選択します。隣人関係がどの隣接するかについての決定、およびエリア間ルーティングの背後にある基本的なアイデア、外部LSAで外部情報のインポート、およびさまざまなルーティング計算も同じです。
In particular, the following IPv4 OSPF functionality described in [OSPFV2] remains completely unchanged for IPv6:
特に、[OSPFv2]で説明されている次のIPv4 OSPF機能は、IPv6では完全に変化していません。
o Both IPv4 and IPv6 use OSPF packet types described in Section 4.3 of [OSPFV2], namely: Hello, Database Description, Link State Request, Link State Update, and Link State Acknowledgment packets. While in some cases (e.g., Hello packets) their format has changed somewhat, the functions of the various packet types remain the same.
o IPv4とIPv6の両方は、[OSPFV2]のセクション4.3で説明されているOSPFパケットタイプ、つまり、Hello、データベースの説明、リンク状態要求、リンク状態更新、およびリンク状態確認パケットを使用します。場合によっては（たとえば、ハローパケット）その形式が多少変更されていますが、さまざまなパケットタイプの関数は同じままです。
o The system requirements for an OSPF implementation remain unchanged, although OSPF for IPv6 requires an IPv6 protocol stack (from the network layer on down) since it runs directly over the IPv6 network layer.
o OSPF実装のシステム要件は変更されていませんが、IPv6のOSPFにはIPv6ネットワークレイヤーを直接実行するため、IPv6プロトコルスタック（下のネットワークレイヤーから）が必要です。
o The discovery and maintenance of neighbor relationships, and the selection and establishment of adjacencies, remain the same. This includes election of the Designated Router and Backup Designated Router on broadcast and NBMA links. These mechanisms are described in Sections 7, 7.1, 7.2, 7.3, 7.4, and 7.5 of [OSPFV2].
o 隣人の関係の発見と維持、および隣接の選択と確立は同じままです。これには、指定されたルーターの選挙と、ブロードキャストでのバックアップ指定ルーターとNBMAリンクが含まれます。これらのメカニズムは、[OSPFV2]のセクション7、7.1、7.2、7.3、7.4、および7.5で説明されています。
o The link types (or equivalently, interface types) supported by OSPF remain unchanged, namely: point-to-point, broadcast, NBMA, point-to-multipoint, and virtual links.
o OSPFがサポートするリンクタイプ（または同等に、インターフェイスタイプ）は、ポイントツーポイント、ブロードキャスト、NBMA、ポイントツーマルチポイント、仮想リンク、つまりポイントツーポイント、ポイント、および仮想リンクのままです。
o The interface state machine, including the list of OSPF interface states and events, and the Designated Router and Backup Designated Router election algorithm remain unchanged. These are described in Sections 9.1, 9.2, 9.3, and 9.4 of [OSPFV2].
o OSPFインターフェイスの状態とイベントのリストを含むインターフェイス状態マシン、および指定されたルーターとバックアップ指定されたルーター選挙アルゴリズムは変更されていません。これらは、[OSPFV2]のセクション9.1、9.2、9.3、および9.4で説明されています。
o The neighbor state machine, including the list of OSPF neighbor states and events, remains unchanged. The neighbor state machine is described in Sections 10.1, 10.2, 10.3, and 10.4 of [OSPFV2].
o OSPFの隣人のリストやイベントのリストを含む隣国のマシンは、変わらないままです。近隣の状態マシンは、[OSPFV2]のセクション10.1、10.2、10.3、および10.4で説明されています。
o Aging of the link-state database, as well as flushing LSAs from the routing domain through the premature aging process, remains unchanged from the description in Sections 14 and 14.1 of [OSPFV2].
o リンク状態データベースの老化、および早期老化プロセスを通じてルーティングドメインからLSAをフラッシングすることは、[OSOSPFV2]のセクション14および14.1の説明から変更されないままです。
However, some OSPF protocol mechanisms have changed as previously described in Section 2 herein. These changes are explained in detail in the following subsections, making references to the appropriate sections of [OSPFV2].
ただし、本明細書のセクション2で以前に説明されているように、一部のOSPFプロトコルメカニズムは変化しています。これらの変更は、次のサブセクションで詳細に説明されており、[OSPFV2]の適切なセクションに言及しています。
The following subsections provide a recipe for turning an IPv4 OSPF implementation into an IPv6 OSPF implementation.
次のサブセクションは、IPv4 OSPF実装をIPv6 OSPF実装に変えるためのレシピを提供します。
The major OSPF data structures are the same for both IPv4 and IPv6: areas, interfaces, neighbors, the link-state database, and the routing table. The top-level data structures for IPv6 remain those listed in Section 5 of [OSPFV2], with the following modifications:
主要なOSPFデータ構造は、IPv4とIPv6の両方で同じです：領域、インターフェイス、近隣、リンク状態データベース、およびルーティングテーブル。IPv6のトップレベルデータ構造は、[OSPFV2]のセクション5にリストされているもののままであり、次の変更があります。
o All LSAs with known LS type and AS flooding scope appear in the top-level data structure, instead of belonging to a specific area or link. AS-external-LSAs are the only LSAs defined by this specification that have AS flooding scope. LSAs with unknown LS type, U-bit set to 1 (flood even when unrecognized), and AS flooding scope also appear in the top-level data structure.
o 既知のLSタイプを持つすべてのLSAは、特定の領域またはリンクに属するのではなく、トップレベルのデータ構造に洪水範囲として表示されます。AS-External-LSAは、洪水範囲としてこの仕様で定義される唯一のLSAです。不明なLSタイプ、Uビットが1に設定されているLSA（認識されていない場合でも洪水）、およびフラッドスコープとしてトップレベルのデータ構造にも表示されます。
The IPv6 area data structure contains all elements defined for IPv4 areas in Section 6 of [OSPFV2]. In addition, all LSAs of known type that have area flooding scope are contained in the IPv6 area data structure. This always includes the following LSA types: router-LSAs, network-LSAs, inter-area-prefix-LSAs, inter-area-router-LSAs, and intra-area-prefix-LSAs. LSAs with unknown LS type, U-bit set to 1 (flood even when unrecognized), and area scope also appear in the area data structure. NSSA-LSAs are also included in an NSSA area's data structure.
IPv6面積データ構造には、[OSPFV2]のセクション6のIPv4領域に対して定義されたすべての要素が含まれています。さらに、面積洪水範囲を持つ既知のタイプのすべてのLSAは、IPv6エリアデータ構造に含まれています。これには常に、次のLSAタイプが含まれます。ルーター-LSA、ネットワークLSA、エリア間 - 型RSA、エリア間ルーターLSA、およびエリア内 - プレフィックスLSASです。不明なLSタイプ、Uビットが1に設定されたLSA（認識されていない場合でも洪水）、およびエリアデータ構造にもエリアスコープが表示されます。NSSA-LSAは、NSSAエリアのデータ構造にも含まれています。
In OSPF for IPv6, an interface connects a router to a link. The IPv6 interface structure modifies the IPv4 interface structure (as defined in Section 9 of [OSPFV2]) as follows:
IPv6のOSPFでは、インターフェイスがルーターをリンクに接続します。IPv6インターフェイス構造は、次のようにIPv4インターフェイス構造（[OSPFV2]のセクション9で定義されている）を変更します。
Interface ID Every interface is assigned an Interface ID, which uniquely identifies the interface with the router. For example, some implementations MAY be able to use the MIB-II IfIndex ([INTFMIB]) as the Interface ID. The Interface ID appears in Hello packets sent out the interface, the link-local-LSA originated by the router for the attached link, and the router-LSA originated by the router-LSA for the associated area. It will also serve as the Link State ID for the network-LSA that the router will originate for the link if the router is elected Designated Router. The Interface ID for a virtual link is independent of the Interface ID of the outgoing interface it traverses in the transit area.
インターフェイスIDすべてのインターフェイスにインターフェイスIDが割り当てられます。インターフェイスIDは、ルーターとのインターフェイスを一意に識別します。たとえば、一部の実装では、MIB-II IFINDEX（[intfmib]）をインターフェイスIDとして使用できる場合があります。インターフェイスIDは、インターフェイスから送信されたHello Packetsに表示されます。リンクローカルLSAは、接続されたリンクのルーターから発信され、Router-LSAは関連領域のルーター-LSAから発信されます。また、ルーターが指定されたルーターに選出された場合、ルーターがリンクに対して発生するネットワークLSAのリンク状態IDとしても機能します。仮想リンクのインターフェイスIDは、通過エリアで移動する発信インターフェイスのインターフェイスIDとは無関係です。
Instance ID Every interface is assigned an Instance ID. This should default to 0. It is only necessary to assign a value other than 0 on those links that will contain multiple separate communities of OSPF routers. For example, suppose that there are two communities of routers on a given ethernet segment that you wish to keep separate. The first community is assigned an Instance ID of 0 and all the routers in the first community will be assigned 0 as the Instance ID for interfaces connected to the ethernet segment. An Instance ID of 1 is assigned to the other routers' interfaces connected to the ethernet segment. The OSPF transmit and receive processing (see Section 4.2) will then keep the two communities separate.
インスタンスIDすべてのインターフェイスにインスタンスIDが割り当てられます。これにより、デフォルト0になります。OSPFルーターの複数の個別のコミュニティを含むリンクに0以外の値を割り当てるだけです。たとえば、特定のイーサネットセグメントに、別々に保ちたいというルーターの2つのコミュニティがあると仮定します。最初のコミュニティには0のインスタンスIDが割り当てられ、最初のコミュニティのすべてのルーターは、イーサネットセグメントに接続されたインターフェイスのインスタンスIDとして割り当てられます。1のインスタンスIDは、イーサネットセグメントに接続された他のルーターのインターフェイスに割り当てられます。OSPFの送信および受信処理（セクション4.2を参照）は、2つのコミュニティを分離し続けます。
List of LSAs with link-local scope All LSAs with link-local scope and that were originated/flooded on the link belong to the interface structure that connects to the link. This includes the collection of the link's link-LSAs.
Link-Local Scopeを持つLSAのリストはすべて、リンクローカルスコープを備えたすべてのLSAであり、リンクで発信/浸水したものがリンクに接続するインターフェイス構造に属します。これには、リンクのリンクLSAのコレクションが含まれます。
IP interface address For IPv6, the IPv6 address appearing in the source of OSPF packets sent on the interface is almost always a link-local address. The one exception is for virtual links that MUST use one of the router's own global IPv6 addresses as IP interface address.
IPインターフェイスアドレスIPv6のIPv6アドレスは、インターフェイスに送信されたOSPFパケットのソースに表示されるIPv6アドレスは、ほとんど常にリンクローカルアドレスです。1つの例外は、ルーター独自のグローバルIPv6アドレスの1つをIPインターフェイスアドレスとして使用する必要がある仮想リンクの場合です。
List of link prefixes A list of IPv6 prefixes can be configured for the attached link. These will be advertised by the router in link-LSAs, so that they can be advertised by the link's Designated Router in intra-area-prefix-LSAs.
リンクプレフィックスのリストIPv6プレフィックスのリストは、添付のリンク用に構成できます。これらはLink-LSASのルーターによって宣伝され、リンクの指定されたルーターがエリア内で指定したルーターによって宣伝されます。
In OSPF for IPv6, each router interface has a single metric representing the cost of sending packets on the interface. In addition, OSPF for IPv6 relies on the IP Authentication Header (see [IPAUTH]) and the IP Encapsulating Security Payload (see [IPESP]) as described in [OSPFV3-AUTH] to ensure integrity and authentication/ confidentiality of routing exchanges. For this reason, AuType and Authentication key are not associated with IPv6 OSPF interfaces.
IPv6のOSPFでは、各ルーターインターフェイスには、インターフェイスにパケットを送信するコストを表す単一のメトリックがあります。さらに、IPv6のOSPFは、[OSPFV3-Auth]に記載されているように、IP認証ヘッダー（[IPAuth]を参照）と[[IPSPS]）に記載されているセキュリティペイロードをカプセル化するIPに依存しています。このため、Autypeと認証キーはIPv6 OSPFインターフェイスに関連付けられていません。
Interface states, events, and the interface state machine remain unchanged from IPv4 as documented in Sections 9.1, 9.2, and 9.3 of [OSPFV2] respectively. The Designated Router and Backup Designated Router election algorithm also remains unchanged from the IPv4 election in Section 9.4 of [OSPFV2].
インターフェイス状態、イベント、およびインターフェイス状態マシンは、それぞれ[OSPFV2]のセクション9.1、9.2、および9.3に記載されているように、IPv4から変更されていません。指定されたルーターとバックアップ指定されたルーター選挙アルゴリズムも、[OSPFV2]のセクション9.4のIPv4選挙から変更されません。
The neighbor structure performs the same function in both IPv6 and IPv4. Namely, it collects all information required to form an adjacency between two routers when such an adjacency becomes necessary. Each neighbor structure is bound to a single OSPF interface. The differences between the IPv6 neighbor structure and the neighbor structure defined for IPv4 in Section 10 of [OSPFV2] are:
隣接構造は、IPv6とIPv4の両方で同じ関数を実行します。つまり、そのような隣接が必要になったときに、2つのルーター間に隣接を形成するために必要なすべての情報を収集します。各隣接構造は、単一のOSPFインターフェイスに結合しています。[OSPFv2]のセクション10でIPv4に対して定義されたIPv6隣接構造と隣接構造の違いは次のとおりです。
Neighbor's Interface ID The Interface ID that the neighbor advertises in its Hello packets must be recorded in the neighbor structure. The router will include the neighbor's Interface ID in the router's router-LSA when either a) advertising a point-to-point or point-to-multipoint link to the neighbor or b) advertising a link to a network where the neighbor has become the Designated Router.
NeighborのインターフェイスID隣人がHelloパケットに宣伝するインターフェイスIDは、近隣構造に記録する必要があります。ルーターには、a）隣人へのポイントツーポイントまたはポイントツーマルチポイントリンクを宣伝するか、b）隣人が次のネットワークへのリンクを宣伝する場合、ルーターのルーター-LSAに近隣のインターフェイスIDが含まれます。指定ルーター。
Neighbor IP address The neighbor's IPv6 address contained as the source address in OSPF for IPv6 packets. This will be an IPv6 link-local address for all link types except virtual links.
近隣IPアドレスIPv6パケットのOSPFのソースアドレスとして隣接するIPv6アドレスが含まれています。これは、仮想リンクを除くすべてのリンクタイプのIPv6リンクローカルアドレスになります。
Neighbor's Designated Router The neighbor's choice of Designated Router is now encoded as a Router ID instead of as an IP address.
近隣の指定ルーター指定されたルーターの隣人の選択は、IPアドレスとしてではなくルーターIDとしてエンコードされます。
Neighbor's Backup Designated Router The neighbor's choice of Backup Designated Router is now encoded as a Router ID instead of as an IP address.
近隣のバックアップ指定ルーター隣人が選択したルーターのバックアップの選択は、IPアドレスとしてではなくルーターIDとしてエンコードされます。
Neighbor states, events, and the neighbor state machine remain unchanged from IPv4 as documented in Sections 10.1, 10.2, and 10.3 of [OSPFV2] respectively. The decision as to which adjacencies to form also remains unchanged from the IPv4 logic documented in Section 10.4 of [OSPFV2].
[OSPFV2]のセクション10.1、10.2、および10.3にそれぞれ文書化されているように、隣国、イベント、および隣国州のマシンはIPv4から変化しません。[OSPFv2]のセクション10.4で文書化されたIPv4ロジックから、どの隣接が形成されるかについての決定も変更されていません。
OSPF for IPv6 runs directly over IPv6's network layer. As such, it is encapsulated in one or more IPv6 headers with the Next Header field of the immediately encapsulating IPv6 header set to the value 89.
IPv6のOSPFは、IPv6のネットワークレイヤーを直接実行します。そのため、1つ以上のIPv6ヘッダーにカプセル化され、すぐにカプセル化されたIPv6ヘッダーが値89に設定されている次のヘッダーフィールドがあります。
As for OSPF for IPv4, OSPF for IPv6 OSPF routing protocol packets are sent along adjacencies only (with the exception of Hello packets, which are used to discover the adjacencies). OSPF packet types and functions are the same in both IPv4 and IPv6, encoded by the Type field of the standard OSPF packet header.
IPv4のOSPFに関しては、IPv6 OSPFルーティングプロトコルパケットのOSPFは隣接に沿って送信されます（隣接を発見するために使用されるハローパケットを除く）。OSPFパケットタイプと関数は、標準のOSPFパケットヘッダーの型フィールドによってエンコードされたIPv4とIPv6の両方で同じです。
When an IPv6 router sends an OSPF routing protocol packet, it fills in the fields of the standard OSPF for IPv6 packet header (see Appendix A.3.1) as follows:
IPv6ルーターがOSPFルーティングプロトコルパケットを送信すると、次のようにIPv6パケットヘッダーの標準OSPFのフィールド（付録A.3.1を参照）に記入します。
Version # Set to 3, the version number of the protocol as documented in this specification.
バージョン＃は、この仕様で文書化されているプロトコルのバージョン番号である3に設定されています。
Type The type of OSPF packet, such as Link State Update or Hello packet.
Link State UpdateやHello Packetなど、OSPFパケットのタイプを入力します。
Packet length The length of the entire OSPF packet in bytes, including the standard OSPF packet header.
パケットの長さ標準のOSPFパケットヘッダーを含む、バイト内のOSPFパケット全体の長さ。
Router ID The identity of the router itself (who is originating the packet).
ルーターIDルーター自体の身元（パケットを発信している）。
Area ID The OSPF area for the interface on which the packet is being sent.
エリアIDパケットが送信されているインターフェイスのOSPFエリア。
Instance ID The OSPF Instance ID associated with the interface out of which the packet is being sent.
インスタンスIDパケットが送信されているインターフェイスに関連付けられたOSPFインスタンスID。
Checksum The standard IPv6 Upper-Layer checksum (as described in Section 8.1 of [IPV6]) covering the entire OSPF packet and prepended IPv6 pseudo-header (see Appendix A.3.1).
チェックサム標準のIPv6上層チェックサム（[IPv6]のセクション8.1で説明されているように）は、OSPFパケット全体と準備されたIPv6擬似ヘッダー全体をカバーしています（付録A.3.1を参照）。
Selection of OSPF routing protocol packets' IPv6 source and destination addresses is performed identically to the IPv4 logic in Section 8.1 of [OSPFV2]. The IPv6 destination address is chosen from among the addresses AllSPFRouters, AllDRouters, and the Neighbor IP address associated with the other end of the adjacency (which in IPv6, for all links except virtual links, is an IPv6 link-local address).
OSPFルーティングプロトコルパケットのIPv6ソースと宛先アドレスの選択は、[OSPFv2]のセクション8.1のIPv4ロジックと同じように実行されます。IPv6宛先アドレスは、隣接のもう一方の端に関連付けられているアドレス、AllSPFRouter、AlldRouter、および隣接IPアドレスの中から選択されます（仮想リンクを除くすべてのリンクについて、IPv6ではIPv6 Link-Localアドレスです）。
The sending of Link State Request packets and Link State Acknowledgment packets remains unchanged from the IPv4 procedures documented in Sections 10.9 and 13.5 of [OSPFV2] respectively. Sending Hello packets is documented in Section 4.2.1.1, and the sending of Database Description packets in Section 4.2.1.2. The sending of Link State Update packets is documented in Section 4.5.2.
リンク状態要求パケットとリンク状態の確認パケットの送信は、それぞれ[OSPFV2]のセクション10.9および13.5に文書化されたIPv4手順から変更されていません。ハローパケットの送信は、セクション4.2.1.1に文書化されており、セクション4.2.1.2のデータベース説明パケットの送信。リンク状態更新パケットの送信は、セクション4.5.2に文書化されています。
IPv6 changes the way OSPF Hello packets are sent in the following ways (compare to Section 9.5 of [OSPFV2]):
IPv6は、OSPFハローパケットが次の方法で送信される方法を変更します（[OSPFV2]のセクション9.5と比較）：
o Before the Hello packet is sent on an interface, the interface's Interface ID MUST be copied into the Hello packet.
o ハローパケットがインターフェイスに送信される前に、インターフェイスのインターフェイスIDをハローパケットにコピーする必要があります。
o The Hello packet no longer contains an IP network mask since OSPF for IPv6 runs per-link instead of per-subnet.
o Hello Packetには、IPv6用のOSPFがスブネットごとではなくリンクごとに実行されるため、IPネットワークマスクは含まれなくなりました。
o The choice of Designated Router and Backup Designated Router is now indicated within Hellos by their Router IDs instead of by their IP interface addresses. Advertising the Designated Router (or Backup Designated Router) as 0.0.0.0 indicates that the Designated Router (or Backup Designated Router) has not yet been chosen.
o 指定されたルーターとバックアップ指定ルーターの選択は、IPインターフェイスアドレスではなく、ルーターIDによってHellos内に示されています。指定されたルーター（またはバックアップ指定ルーター）を0.0.0.0として宣伝することは、指定されたルーター（またはバックアップ指定ルーター）がまだ選択されていないことを示しています。
o The Options field within Hello packets has moved around, getting larger in the process. More Options bits are now possible. Those that MUST be set correctly in Hello packets are as follows. The E-bit is set if and only if the interface attaches to a regular area, i.e., not a stub or NSSA area. Similarly, the N-bit is set if and only if the interface attaches to an NSSA area (see [NSSA]). Finally, the DC-bit is set if and only if the router wishes to suppress the sending of future Hellos over the interface (see [DEMAND]). Unrecognized bits in the Hello packet's Options field should be cleared.
o Hello Packets内のオプションフィールドが移動し、プロセスが大きくなりました。より多くのオプションビットが可能になりました。ハローパケットで正しく設定する必要があるものは次のとおりです。e-bitは、インターフェイスが通常の領域に取り付けられている場合、つまりスタブやNSSA領域ではなく、場合にのみ設定されます。同様に、インターフェイスがNSSA領域に接続されている場合にのみ、N-BITが設定されます（[NSSA]を参照）。最後に、ルーターがインターフェイスを介した将来のHellosの送信を抑制したい場合にのみDCビットが設定されます（[需要]を参照）。Hello Packetのオプションフィールドの認識されていないビットをクリアする必要があります。
Sending Hello packets on NBMA networks proceeds for IPv6 in exactly the same way as for IPv4, as documented in Section 9.5.1 of [OSPFV2].
NBMAネットワークでハローパケットを送信すると、[OSOSPFV2]のセクション9.5.1に記載されているように、IPv4とまったく同じ方法でIPv6の収益が発生します。
The sending of Database Description packets differs from Section 10.8 of [OSPFV2] in the following ways:
データベースの説明パケットの送信は、次の方法で[OSPFV2]のセクション10.8とは異なります。
o The Options field within Database Description packets has moved around, getting larger in the process. More Options bits are now possible. Those that MUST be set correctly in Database Description packets are as follows. The DC-bit is set if and only if the router wishes to suppress the sending of Hellos over the interface (see [DEMAND]). Unrecognized bits in the Database Description packet's Options field should be cleared.
o データベースの説明パケット内のオプションフィールドが移動し、プロセスが大きくなりました。より多くのオプションビットが可能になりました。データベースの説明パケットで正しく設定する必要があるものは次のとおりです。DCビットは、ルーターがインターフェイス上のHellosの送信を抑制したい場合にのみ設定されます（[需要]を参照）。データベースの説明パケットのオプションフィールドの認識されていないビットをクリアする必要があります。
Whenever a router receives an OSPF protocol packet, it is marked with the interface on which it was received. For routers that have virtual links configured, it may not be immediately obvious with which interface to associate the packet. For example, consider the Router RT11 depicted in Figure 6 of [OSPFV2]. If RT11 receives an OSPF protocol packet on its interface to Network N8, it may want to associate the packet with the interface to Area 2, or with the virtual link to Router RT10 (which is part of the backbone). In the following, we assume that the packet is initially associated with the non-virtual link.
ルーターがOSPFプロトコルパケットを受信するたびに、受信したインターフェイスがマークされています。仮想リンクが構成されているルーターの場合、パケットを関連付けるインターフェイスについてすぐには明らかではない場合があります。たとえば、[OSPFV2]の図6に示すルーターRT11を考えてみましょう。RT11がネットワークN8へのインターフェイスでOSPFプロトコルパケットを受信した場合、パケットをインターフェイスにエリア2に関連付けるか、ルーターRT10への仮想リンク（バックボーンの一部）に関連付けることができます。以下では、パケットが最初に非仮想的なリンクに関連付けられていると仮定します。
In order for the packet to be passed to OSPF for processing, the following tests must be performed on the encapsulating IPv6 headers: o The packet's IP destination address MUST be one of the IPv6 unicast addresses associated with the receiving interface (this includes link-local addresses), one of the IPv6 multicast addresses AllSPFRouters or AllDRouters, or an IPv6 global address (for virtual links).
処理のためにパケットをOSPFに渡すためには、次のテストをカプセル化IPv6ヘッダーで実行する必要があります。OパケットのIP宛先アドレスは、受信インターフェイスに関連付けられたIPv6ユニキャストアドレスの1つでなければなりません（これにはLink-Localが含まれますアドレス）、IPv6マルチキャストアドレスの1つは、AllSPFRouterまたはAlldRouters、またはIPv6グローバルアドレス（仮想リンク用）。
o The Next Header field of the immediately encapsulating IPv6 header MUST specify the OSPF protocol (89).
o すぐにカプセル化するIPv6ヘッダーの次のヘッダーフィールドは、OSPFプロトコル（89）を指定する必要があります。
o Any encapsulating IP Authentication Headers (see [IPAUTH]) and the IP Encapsulating Security Payloads (see [IPESP]) MUST be processed and/or verified to ensure integrity and authentication/ confidentiality of OSPF routing exchanges. This is described in [OSPFV3-AUTH].
o OSPFルーティング交換の整合性と認証/機密性を確保するために、IP認証ヘッダー（[IPAuth]を参照）およびセキュリティペイロードをカプセル化するIPカプセル化（[IPSP]を参照）を処理および/または確認する必要があります。これは[ospfv3-auth]で説明されています。
After processing the encapsulating IPv6 headers, the OSPF packet header is processed. The fields specified in the header must match those configured for the receiving OSPFv3 interface. If they do not, the packet SHOULD be discarded:
カプセル化IPv6ヘッダーを処理した後、OSPFパケットヘッダーが処理されます。ヘッダーで指定されたフィールドは、受信OSPFV3インターフェイス用に構成されたフィールドと一致する必要があります。そうでない場合は、パケットを破棄する必要があります。
o The version number field MUST specify protocol version 3.
o バージョン番号フィールドは、プロトコルバージョン3を指定する必要があります。
o The IPv6 Upper-Layer checksum (as described in Section 8.1 of [IPV6]), covering the entire OSPF packet and prepended IPv6 pseudo-header, must be verified (see Appendix A.3.1).
o IPv6上層チェックサム（[IPv6]のセクション8.1で説明されている）は、OSPFパケット全体と前提条件のIPv6擬似ヘッダー全体をカバーすることを検証する必要があります（付録A.3.1を参照）。
o The Area ID and Instance ID found in the OSPF header must be verified. If both of the following cases fail, the packet should be discarded. The Area ID and Instance ID specified in the header must either:
o OSPFヘッダーで見つかったエリアIDとインスタンスIDを検証する必要があります。次のケースの両方が失敗した場合、パケットを破棄する必要があります。ヘッダーで指定されているエリアIDとインスタンスIDは次のとおりです。
1. Match one of the Area ID(s) and Interface Instance ID(s) for the receiving link. Unlike IPv4, the IPv6 source address is not restricted to lie within the same IPv6 subnet as the receiving link. IPv6 OSPF runs per-link instead of per-IP-subnet.
1. 受信リンクの領域ID（s）とインターフェイスインスタンスID（s）のいずれかを一致させます。IPv4とは異なり、IPv6ソースアドレスは、受信リンクと同じIPv6サブネット内にあることに制限されていません。IPv6 OSPFは、PER-IP-Subnetではなくリンクごとに実行されます。
2. Match the backbone area and other criteria for a configured virtual link. The receiving router must be an ABR (Area Border Router) and the Router ID specified in the packet (the source router) must be the other end of a configured virtual link. Additionally, the receiving link must have an OSPFv3 interface that attaches to the virtual link's configured transit area and the Instance ID must match the virtual link's Instance ID. If all of these checks succeed, the packet is accepted and is associated with the virtual link (and the backbone area).
2. 構成された仮想リンクのバックボーン領域とその他の基準を一致させます。受信ルーターはABR（エリアボーダールーター）である必要があり、パケットで指定されたルーターID（ソースルーター）は、構成された仮想リンクの反対側でなければなりません。さらに、受信リンクには、仮想リンクの構成されたトランジットエリアに接続するOSPFV3インターフェイスが必要であり、インスタンスIDは仮想リンクのインスタンスIDと一致する必要があります。これらのチェックがすべて成功した場合、パケットは受け入れられ、仮想リンク（およびバックボーン領域）に関連付けられています。
o Locally originated packets SHOULD NOT be processed by OSPF except for support of multiple interfaces attached to the same link as described in Section 4.9. Locally originated packets have a source address equal to one of the router's local addresses.
o セクション4.9で説明されているのと同じリンクに接続された複数のインターフェイスのサポートを除き、ローカルに起源のパケットはOSPFによって処理されないでください。ローカルに起源のパケットには、ルーターのローカルアドレスの1つに等しいソースアドレスがあります。
o Packets whose IPv6 destination is AllDRouters should only be accepted if the state of the receiving OSPFv3 interface is DR or Backup (see Section 9.1 [OSPFV2]).
o IPv6宛先がAlldRoutersであるパケットは、受信OSPFv3インターフェイスの状態がDRまたはバックアップである場合にのみ受け入れられる必要があります（セクション9.1 [OSPFV2]を参照）。
After header processing, the packet is further processed according to its OSPF packet type. OSPF packet types and functions are the same for both IPv4 and IPv6.
ヘッダー処理後、パケットはOSPFパケットタイプに従ってさらに処理されます。OSPFパケットタイプと関数は、IPv4とIPv6の両方で同じです。
If the packet type is Hello, it should then be further processed by the Hello packet processing as described in Section 4.2.2.1. All other packet types are sent/received only on adjacencies. This means that the packet must have been sent by one of the router's active neighbors. The neighbor is identified by the Router ID appearing in the received packet's OSPF header. Packets not matching any active neighbor are discarded.
パケットタイプがHelloの場合、セクション4.2.2.1で説明されているように、ハローパケット処理によってさらに処理されるはずです。他のすべてのパケットタイプは、隣接でのみ送信/受信されます。これは、パケットがルーターのアクティブな隣人の1つによって送信されたに違いないことを意味します。隣人は、受信したパケットのOSPFヘッダーに表示されるルーターIDによって識別されます。アクティブな隣人と一致しないパケットは破棄されます。
The receive processing of Database Description packets, Link State Request packets, and Link State Acknowledgment packets is almost identical to the IPv4 procedures documented in Sections 10.6, 10.7, and 13.7 of [OSPFV2] respectively with the exceptions noted below.
データベース説明パケットの受信処理、リンク状態要求パケット、およびリンク状態確認パケットは、以下の例外を除いて、それぞれ[OSOSPFV2]のセクション10.6、10.7、および13.7に文書化されたIPv4手順とほぼ同じです。
o LSAs with unknown LS types in Database Description packets that have an acceptable flooding scope are processed the same as LSAs with known LS types. In OSPFv2 [OSPFV2], these would result in the adjacency being brought down with a SequenceMismatch event.
o データベース説明に不明なLSタイプを持つLSAは、許容可能な洪水スコープを持つパケットを、既知のLSタイプを持つLSAと同じように処理されます。OSPFV2 [OSPFV2]では、これらは隣接するシーケンセンセミスマッチイベントで倒されるようになります。
The receiving of Hello packets is documented in Section 4.2.2.1 and the receiving of Link State Update packets is documented in Section 4.5.1.
ハローパケットの受信はセクション4.2.2.1に文書化されており、リンク状態更新パケットの受信はセクション4.5.1に記載されています。
The receive processing of Hello packets differs from Section 10.5 of [OSPFV2] in the following ways:
ハローパケットの受信処理は、次の方法で[OSPFV2]のセクション10.5とは異なります。
o On all link types (e.g., broadcast, NBMA, point-to-point, etc.), neighbors are identified solely by their OSPF Router ID. For all link types except virtual links, the Neighbor IP address is set to the IPv6 source address in the IPv6 header of the received OSPF Hello packet.
o すべてのリンクタイプ（ブロードキャスト、NBMA、ポイントツーポイントなど）で、近隣はOSPFルーターIDによってのみ識別されます。仮想リンクを除くすべてのリンクタイプについて、neighter IPアドレスは、受信したOSPFハローパケットのIPv6ヘッダーのIPv6ソースアドレスに設定されます。
o There is no longer a Network Mask field in the Hello packet.
o ハローパケットには、ネットワークマスクフィールドはもうありません。
o The neighbor's choice of Designated Router and Backup Designated Router is now encoded as an OSPF Router ID instead of an IP interface address.
o 指定されたルーターとバックアップ指定ルーターの隣人の選択は、IPインターフェイスアドレスの代わりにOSPFルーターIDとしてエンコードされるようになりました。
The routing table used by OSPF for IPv4 is defined in Section 11 of [OSPFV2]. For IPv6, there are analogous routing table entries: there are routing table entries for IPv6 address prefixes and also for AS boundary routers. The latter routing table entries are only used to hold intermediate results during the routing table build process (see Section 4.8).
IPv4のためにOSPFが使用するルーティングテーブルは、[OSPFV2]のセクション11で定義されています。IPv6の場合、類似のルーティングテーブルエントリがあります。IPv6アドレスプレフィックスと境界ルーターのルーティングテーブルエントリがあります。後者のルーティングテーブルエントリは、ルーティングテーブルビルドプロセス中に中間結果を保持するためにのみ使用されます（セクション4.8を参照）。
Also, to hold the intermediate results during the shortest-path calculation for each area, there is a separate routing table for each area holding the following entries:
また、各エリアの最短パス計算中に中間結果を保持するために、次のエントリを保持する各エリアに別のルーティングテーブルがあります。
o An entry for each router in the area. Routers are identified by their OSPF Router ID. These routing table entries hold the set of shortest paths through a given area to a given router, which in turn allows calculation of paths to the IPv6 prefixes advertised by that router in intra-area-prefix-LSAs. If the router is also an area border router, these entries are also used to calculate paths for inter-area address prefixes. If in addition the router is the other endpoint of a virtual link, the routing table entry describes the cost and viability of the virtual link.
o エリア内の各ルーターのエントリ。ルーターは、OSPFルーターIDによって識別されます。これらのルーティングテーブルエントリは、特定の領域を通って特定のルーターまで最短のパスのセットを保持し、その結果、エリア内でそのルーターによって宣伝されているIPv6プレフィックスへのパスの計算が可能になります。ルーターがエリアボーダールーターでもある場合、これらのエントリは、エリア間アドレスのプレフィックスのパスを計算するためにも使用されます。さらに、ルーターが仮想リンクの他のエンドポイントである場合、ルーティングテーブルエントリは仮想リンクのコストと実行可能性を説明します。
o An entry for each transit link in the area. Transit links have associated network-LSAs. Both the transit link and the network-LSA are identified by a combination of the Designated Router's Interface ID on the link and the Designated Router's OSPF Router ID. These routing table entries allow later calculation of paths to IP prefixes advertised for the transit link in intra-area-prefix-LSAs.
o エリア内の各トランジットリンクのエントリ。トランジットリンクには、ネットワークLSAが関連付けられています。トランジットリンクとネットワークLSAの両方は、リンク上の指定されたルーターのインターフェイスIDと指定されたルーターのOSPFルーターIDの組み合わせによって識別されます。これらのルーティングテーブルエントリにより、エリア内でのトランジットリンクに宣伝されているIPプレフィックスへのパスの後で計算できます。
The fields in the IPv4 OSPF routing table (see Section 11 of [OSPFV2]) remain valid for IPv6: optional capabilities (routers only), path type, cost, type 2 cost, link state origin, and for each of the equal cost paths to the destination, the next-hop and advertising routers.
IPv4 OSPFルーティングテーブルのフィールド（[OSPFV2]のセクション11を参照）は、IPv6：オプションの機能（ルーターのみ）、パスタイプ、コスト、タイプ2コスト、リンク状態オリジン、および等しいコストパスごとに有効です目的地に、次のホップと広告ルーター。
For IPv6, the link-state origin field in the routing table entry is the router-LSA or network-LSA that has directly or indirectly produced the routing table entry. For example, if the routing table entry describes a route to an IPv6 prefix, the link state origin is the router-LSA or network-LSA that is listed in the body of the intra-area-prefix-LSA that has produced the route (see Appendix A.4.10).
IPv6の場合、ルーティングテーブルエントリのリンク状態のオリジンフィールドは、ルーターテーブルエントリを直接または間接的に生成したルーターLSAまたはネットワークLSAです。たとえば、ルーティングテーブルエントリがIPv6プレフィックスへのルートを記述している場合、リンク状態の原点は、ルートを生成した（エリア内 - エリア-Prefix-LSAの本体にリストされているルーター-LSAまたはネットワークLSA）です（付録A.4.10を参照してください。
Routing table lookup (i.e., determining the best matching routing table entry during IP forwarding) is the same for IPv6 as for IPv4.
ルーティングテーブルルックアップ（つまり、IP転送中に最適なルーティングテーブルエントリを決定する）は、IPv4と同じです。
For IPv6, the OSPF LSA header has changed slightly, with the LS type field expanding and the Options field being moved into the body of appropriate LSAs. Also, the formats of some LSAs have changed somewhat (namely, router-LSAs, network-LSAs, AS-external-LSAs, and NSSA-LSAs), while the names of other LSAs have been changed (type 3 and 4 summary-LSAs are now inter-area-prefix-LSAs and inter-area-router-LSAs respectively) and additional LSAs have been added (link-LSAs and intra-area-prefix-LSAs). Type of Service (TOS) has been removed from the OSPFv2 specification [OSPFV2] and is not encoded within OSPF for IPv6's LSAs.
IPv6の場合、OSPF LSAヘッダーはわずかに変化し、LSタイプフィールドが拡大し、オプションフィールドが適切なLSAの本体に移動されます。また、一部のLSAの形式は多少変化しました（すなわち、ルーターLSA、ネットワークLSA、AS-External-LSA、およびNSSA-LSA）、他のLSAの名前は変更されています（タイプ3および4 Summary-LSAS現在、それぞれエリア間対とエリア間ルーターLSAS）を追加し、追加のLSAが追加されています（Link-LSAおよびA-AREA-PREFIX-LSAS）。サービスの種類（TOS）はOSPFV2仕様[OSPFv2]から削除されており、IPv6のLSAのOSPF内でエンコードされていません。
These changes will be described in detail in the following subsections.
これらの変更については、以下のサブセクションで詳しく説明します。
In both IPv4 and IPv6, all OSPF LSAs begin with a standard 20-byte LSA header. However, the contents of this 20-byte header have changed in IPv6. The LS age, Advertising Router, LS Sequence Number, LS checksum, and length fields within the LSA header remain unchanged, as documented in Sections 12.1.1, 12.1.5, 12.1.6, 12.1.7, and A.4.1 of [OSPFV2], respectively. However, the following fields have changed for IPv6:
IPv4とIPv6の両方で、すべてのOSPF LSAは標準の20バイトLSAヘッダーで始まります。ただし、この20バイトヘッダーの内容はIPv6で変更されています。LS年齢、広告ルーター、LSシーケンス番号、LSチェックサム、およびLSAヘッダー内の長さフィールドは、セクション12.1.1、12.1.5、12.1.6、12.1.7、およびA.4.1に記載されているように、変更されていません。それぞれOSPFV2]。ただし、IPv6については、次のフィールドが変更されています。
Options The Options field has been removed from the standard 20-byte LSA header and moved into the body of router-LSAs, network-LSAs, inter-area-router-LSAs, and link-LSAs. The size of the Options field has increased from 8 to 24 bits, and some of the bit definitions have changed (see Appendix A.2). Additionally, a separate PrefixOptions field, 8 bits in length, is attached to each prefix advertised within the body of an LSA.
オプションオプションフィールドは、標準の20バイトLSAヘッダーから削除され、ルーターLSA、ネットワークLSA、エリア間ルーターLSA、およびLink-LSAのボディに移動しました。オプションフィールドのサイズは8ビットから24ビットに増加し、ビット定義の一部が変更されました（付録A.2を参照）。さらに、長さ8ビットの個別のプレフィキソップフィールドが、LSAの本体内に宣伝されている各プレフィックスに取り付けられています。
LS type The size of the LS type field has increased from 8 to 16 bits, with high-order bit encoding the handling of unknown types and the next two bits encoding flooding scope. See Appendix A.4.2.1 for the current coding of the LS type field.
LSタイプLSタイプフィールドのサイズは8ビットから16ビットに増加し、高次ビットは未知のタイプの取り扱いをエンコードし、次の2つのビットが洪水範囲をコードすることをエンコードしています。LSタイプフィールドの現在のコーディングについては、付録A.4.2.1を参照してください。
Link State ID The Link State ID remains at 32 bits in length. However, except for network-LSAs and link-LSAs, the Link State ID has shed any addressing semantics. For example, an IPv6 router originating multiple AS-external-LSAs could start by assigning the first a Link State ID of 0.0.0.1, the second a Link State ID of 0.0.0.2, and so on. Instead of the IPv4 behavior of encoding the network number within the AS-external-LSA's Link State ID, the IPv6 Link State ID simply serves as a way to differentiate multiple LSAs originated by the same router. For network-LSAs, the Link State ID is set to the Designated Router's Interface ID on the link. When a router originates a link-LSA for a given link, its Link State ID is set equal to the router's Interface ID on the link.
リンク状態IDリンク状態IDの長さは32ビットのままです。ただし、ネットワークLSAとLink-LSAを除き、Link State IDはアドレス指定セマンティクスを削減しました。たとえば、複数のas-External-LSAを発信するIPv6ルーターは、最初のAリンク状態ID 0.0.0.1、2番目のリンク状態ID 0.0.0.2などを割り当てることから開始できます。As-External-LSAのリンク状態ID内のネットワーク番号をエンコードするIPv4の動作の代わりに、IPv6リンク状態IDは、同じルーターから発信された複数のLSAを区別する方法として機能します。ネットワークLSAの場合、リンク状態IDは、リンク上の指定されたルーターのインターフェイスIDに設定されます。ルーターが特定のリンクのリンクLSAを発信する場合、リンク状態IDはリンク上のルーターのインターフェイスIDに等しく設定されます。
In IPv6, as in IPv4, individual LSAs are identified by a combination of their LS type, Link State ID, and Advertising Router fields. Given two instances of an LSA, the most recent instance is determined by examining the LSAs' LS sequence number, using LS checksum and LS age as tiebreakers (see Section 13.1 of [OSPFV2]).
IPv6では、IPv4のように、個々のLSAはLSタイプ、リンク状態ID、および広告ルーターフィールドの組み合わせによって識別されます。LSAの2つのインスタンスを考慮して、最新のインスタンスは、LSチェックサムとLS年齢をタイブレーカーとして使用してLSASのLSシーケンス番号を調べることによって決定されます（[OSPFV2]のセクション13.1を参照）。
In IPv6, the link-state database is split across three separate data structures. LSAs with AS flooding scope are contained within the top-level OSPF data structure (see Section 4.1) as long as either their LS type is known or their U-bit is 1 (flood even when unrecognized); this includes the AS-external-LSAs. LSAs with area flooding scope are contained within the appropriate area structure (see Section 4.1.1) as long as either their LS type is known or their U-bit is 1 (flood even when unrecognized); this includes router-LSAs, network-LSAs, inter-area-prefix-LSAs, inter-area-router-LSAs, NSSA-LSAs, and intra-area-prefix-LSAs. LSAs with an unknown LS type, the U-bit set to 0, and/or link-local flooding scope are contained within the appropriate interface structure (see Section 4.1.2); this includes link-LSAs.
IPv6では、リンク状態データベースは3つの別々のデータ構造に分割されています。洪水範囲を持つLSAは、LSタイプが既知であるか、Uビットが1（認識されていない場合でも洪水）のいずれかである限り、トップレベルのOSPFデータ構造（セクション4.1を参照）に含まれています。これには、as-entternal-LSAが含まれます。エリアフラッドスコープを持つLSAは、LSタイプが既知であるか、Uビットが1（認識されていない場合でも洪水）のいずれかである限り、適切なエリア構造内に含まれています（セクション4.1.1を参照）。これには、ルーター-LSA、ネットワークLSA、エリア間 - エリア - ペルフィックスLSA、A-AREA-Router-LSAS、NSSA-LSAS、およびA-AREA-PREFIX-LSASが含まれます。未知のLSタイプ、Uビットが0に設定されているLSA、および/またはリンクローカルフラッドスコープは、適切なインターフェイス構造内に含まれています（セクション4.1.2を参照）。これにはLink-LSAが含まれます。
To look up or install an LSA in the database, you first examine the LS type and the LSA's context (i.e., the area or link to which the LSA belongs). This information allows you to find the correct database of LSAs where you then search based on the LSA's type, Link State ID, and Advertising Router.
データベースにLSAを検索またはインストールするには、最初にLSタイプとLSAのコンテキスト（つまり、LSAが属する領域またはリンク）を調べます。この情報を使用すると、LSAの正しいデータベースを見つけることができ、LSAのタイプ、リンク状態ID、および広告ルーターに基づいて検索できます。
The process of reoriginating an LSA in IPv6 is the same as in IPv4: the LSA's LS sequence number is incremented, its LS age is set to 0, its LS checksum is calculated, and the LSA is added to the link state database and flooded on the appropriate interfaces.
IPv6のLSAを再調整するプロセスはIPv4と同じです。LSAのLSシーケンス番号が増加し、LS年齢が0に設定され、LSチェックサムが計算され、LSAがリンク状態データベースに追加され、浸水します。適切なインターフェイス。
The list of events causing LSAs to be reoriginated for IPv4 is given in Section 12.4 of [OSPFV2]. The following events and/or actions are added for IPv6:
LSAをIPv4の再認定原因となるイベントのリストは、[OSPFV2]のセクション12.4に記載されています。IPv6に対して次のイベントやアクションが追加されます。
o The state or interface ID of one of the router's interfaces changes. The router may need to (re)originate or flush its link-LSA and one or more router-LSAs and/or intra-area-prefix-LSAs. If the router is the Designated Router, the router may also need to (re)originate and/or flush the network-LSA corresponding to the interface.
o ルーターのインターフェイスの1つの状態またはインターフェイスIDが変更されます。ルーターは、Link-LSAおよび1つ以上のルーター-LSAおよび/またはエリア内-Prefix-LSAを（再）発信またはフラッシュする必要がある場合があります。ルーターが指定されたルーターである場合、ルーターはインターフェイスに対応するネットワークLSAを（再）発信および/またはフラッシュする必要があります。
o The identity of a link's Designated Router changes. The router may need to (re)originate or flush the link's network-LSA and one or more router-LSAs and/or intra-area-prefix-LSAs.
o リンクの指定されたルーターのアイデンティティが変更されます。ルーターは、リンクのネットワークLSAおよび1つまたは複数のルーターLSAおよび/またはエリア内型LSAを（再）発信またはフラッシュする必要がある場合があります。
o A neighbor transitions to/from "Full" state. The router may need to (re)originate or flush the link's network-LSA and one or more router-LSAs and/or intra-area-prefix-LSAs.
o 隣人は、「完全な」状態に往復します。ルーターは、リンクのネットワークLSAおよび1つまたは複数のルーターLSAおよび/またはエリア内型LSAを（再）発信またはフラッシュする必要がある場合があります。
o The Interface ID of a neighbor changes. This may cause a new instance of a router-LSA to be originated for the associated area.
o 隣人のインターフェイスIDが変更されます。これにより、Router-LSAの新しいインスタンスが関連領域に発信される可能性があります。
o A new prefix is added to an attached link, or a prefix is deleted (both through configuration). This causes the router to reoriginate its link-LSA for the link or, if it is the only router attached to the link, causes the router to reoriginate an intra-area-prefix-LSA.
o 添付のリンクに新しいプレフィックスが追加されるか、プレフィックスが削除されます（両方とも構成を介して）。これにより、ルーターがリンクのリンクLSAを再計算するか、リンクに取り付けられている唯一のルーターである場合、ルーターがエリア内で再び再調整します。
o A new link-LSA is received, causing the link's collection of prefixes to change. If the router is the Designated Router for the link, it originates a new intra-area-prefix-LSA.
o 新しいリンクLSAが受信され、リンクのプレフィックスのコレクションが変更されます。ルーターがリンクの指定されたルーターである場合、新しいエリア内 - エリア内型LSAを発信します。
o A new link-LSA is received, causing the logical OR of LSA options advertised by adjacent routers on the link to change. If the router is the Designated Router for the link, it originates a new network-LSA.
o 新しいLink-LSAが受信され、リンク上の隣接するルーターによって宣伝されている論理またはLSAオプションが変更されます。ルーターがリンクの指定されたルーターである場合、新しいネットワークLSAを発信します。
Detailed construction of the seven required IPv6 LSA types is supplied by the following subsections. In order to display example LSAs, the network map in Figure 15 of [OSPFV2] has been reworked to show IPv6 addressing, resulting in Figure 1. The OSPF cost of each interface is displayed in Figure 1. The assignment of IPv6 prefixes to network links is shown in Table 1. A single area address range has been configured for Area 1, so that outside of Area 1 all of its prefixes are covered by a single route to 2001:0db8:c001::/48. The OSPF interface IDs and the link-local addresses for the router interfaces in Figure 1 are given in Table 2.
7つの必要なIPv6 LSAタイプの詳細な構造は、次のサブセクションによって提供されます。LSAの例を表示するために、[OSPFV2]の図15のネットワークマップを再加工してIPv6アドレス指定を表示し、図1になります。各インターフェイスのOSPFコストを図1に示します。表1に示すものを示します。エリア1用に単一の領域アドレス範囲が構成されているため、エリア1の外側では、すべてのプレフィックスが2001年までの単一ルートでカバーされています。0DB8：C001 ::/48。図1のルーターインターフェイスのOSPFインターフェイスIDとリンクローカルアドレスを表2に示します。
..........................................
. Area 1.
. + .
. | .
. | 3+---+1 .
. N1 |--|RT1|-----+ .
. | +---+ \ .
. | \ ______ .
. + \/ \ 1+---+
. * N3 *------|RT4|------
. + /\_______/ +---+
. | / | .
. | 3+---+1 / | .
. N2 |--|RT2|-----+ 1| .
. | +---+ +---+ .
. | |RT3|----------------
. + +---+ .
. |2 .
. | .
. +------------+ .
. N4 .
..........................................
Figure 1: Area 1 with IP Addresses Shown
図1：IPアドレスが表示されている領域1
Network IPv6 prefix
-----------------------------------
N1 2001:0db8:c001:0200::/56
N2 2001:0db8:c001:0300::/56
N3 2001:0db8:c001:0100::/56
N4 2001:0db8:c001:0400::/56
Table 1: IPv6 Link Prefixes for Sample Network
表1：サンプルネットワークのIPv6リンクプレフィックス
Router Interface Interface ID link-local address
-------------------------------------------------------
RT1 to N1 1 fe80:0001::RT1
to N3 2 fe80:0002::RT1
RT2 to N2 1 fe80:0001::RT2
to N3 2 fe80:0002::RT2
RT3 to N3 1 fe80:0001::RT3
to N4 2 fe80:0002::RT3
RT4 to N3 1 fe80:0001::RT4
Table 2: OSPF Interface IDs and Link-Local Addresses
表2：OSPFインターフェイスIDとリンクローカルアドレス
Figure 1
図1
The Options field in LSAs should be coded as follows. The V6-bit should be set unless the router will not participate in transit IPv6 routing. The E-bit should be clear if and only if the attached area is an OSPF stub or OSPF NSSA area. The E-bit should always be set in AS scoped LSAs. The N-bit should be set if and only if the attached area is an OSPF NSSA area. The R-bit should be set unless the router will not participate in any transit routing. The DC-bit should be set if and only if the router can correctly process the DoNotAge bit when it appears in the LS age field of LSAs (see [DEMAND]). All unrecognized bits in the Options field should be cleared.
LSAのオプションフィールドは、次のようにコーディングする必要があります。ルーターがTransit IPv6ルーティングに参加しない限り、V6ビットを設定する必要があります。eビットは、接続された領域がOSPFスタブまたはOSPF NSSAエリアであるかどうかの場合にのみ明確でなければなりません。eビットは、常にスコープLSAとして設定する必要があります。接続された領域がOSPF NSSAエリアである場合にのみ、N-BITを設定する必要があります。ルーターが輸送ルーティングに参加しない限り、Rビットを設定する必要があります。ルーターがLSASのLS年齢フィールドに表示されたときにドノタージビットを正しく処理できる場合にのみ、DCビットを設定する必要があります（[需要]を参照）。オプションフィールドのすべての認識されていないビットをクリアする必要があります。
The V6-bit and R-bit are only examined in Router-LSAs during the SPF computation. In other LSA types containing options, they are set for informational purposes only.
V6ビットとRビットは、SPF計算中にルーターLSAでのみ検査されます。オプションを含む他のLSAタイプでは、情報目的のみに設定されています。
The LS type of a router-LSA is set to the value 0x2001. Router-LSAs have area flooding scope. A router MAY originate one or more router-LSAs for a given area. Each router-LSA contains an integral number of interface descriptions. Taken together, the collection of router-LSAs originated by the router for an area describes the collected states of all the router's interfaces attached to the area. When multiple router-LSAs are used, they are distinguished by their Link State ID fields.
ルーターLSAのLSタイプは、値0x2001に設定されています。ルーター-LSAには、面積洪水範囲があります。ルーターは、特定の領域の1つ以上のルーターLSAを発生する場合があります。各ルーター-LSAには、インターフェイス数のインターフェイスの説明が含まれています。まとめると、領域のルーターが起源とするルーター-LSAのコレクションは、エリアに接続されたすべてのルーターのインターフェイスの収集された状態について説明します。複数のルーターLSAを使用すると、リンク状態IDフィールドによって区別されます。
To the left of the Options field, the router capability bits V, E, and B should be set according to Section 12.4.1 of [OSPFV2].
オプションフィールドの左側には、ルーター機能ビットv、e、およびbは、[osospfv2]のセクション12.4.1に従って設定する必要があります。
Each of the router's interfaces to the area is then described by appending "link descriptions" to the router-LSA. Each link description is 16 bytes long, consisting of five fields: (link) Type, Metric, Interface ID, Neighbor Interface ID, and Neighbor Router ID (see Appendix A.4.3). Interfaces in the state "Down" or "Loopback" are not described (although looped back interfaces can contribute prefixes to intra-area-prefix-LSAs), nor are interfaces without any full adjacencies described (except in the case of multiple Standby Interfaces as described in Section 4.9). All other interfaces to the area add zero, one, or more link descriptions. The number and content of these depend on the interface type. Within each link description, the Metric field is always set to the interface's output cost, and the Interface ID field is set to the interface's OSPF Interface ID.
エリアへのルーターの各インターフェイスは、ルーターLSAに「リンク説明」を追加することによって説明されます。各リンクの説明は16バイトの長さで、5つのフィールドで構成されています：（リンク）タイプ、メトリック、インターフェイスID、隣接インターフェイスID、およびネイバールーターID（付録A.4.3を参照）。状態の「ダウン」または「ループバック」のインターフェイスは説明されていません（ただし、ループされたバックインターフェイスは、エリア内ペリフィックスLSAにプレフィックスを寄付することができますが）、完全な隣接のないインターフェイスも説明されていません（複数のスタンバイインターフェイスの場合を除き、セクション4.9で説明されています）。エリアへの他のすべてのインターフェイスは、ゼロ、1つ、またはそれ以上のリンクの説明を追加します。これらの数と内容は、インターフェイスタイプに依存します。各リンク説明内で、メトリックフィールドは常にインターフェイスの出力コストに設定され、インターフェイスIDフィールドはインターフェイスのOSPFインターフェイスIDに設定されます。
Point-to-point interfaces If the neighboring router is fully adjacent, add a Type 1 link description (point-to-point). The Neighbor Interface ID field is set to the Interface ID advertised by the neighbor in its Hello packets, and the Neighbor Router ID field is set to the neighbor's Router ID.
隣接するルーターが完全に隣接している場合は、ポイントツーポイントインターフェイスタイプ1リンク説明（ポイントツーポイント）を追加します。Neighbor Interface IDフィールドは、Hello PacketsでNeighborが宣伝したインターフェイスIDに設定され、Neighbor Router IDフィールドはNeighborのルーターIDに設定されています。
Broadcast and NBMA interfaces If the router is fully adjacent to the link's Designated Router or if the router itself is the Designated Router and is fully adjacent to at least one other router, add a single Type 2 link description (transit network). The Neighbor Interface ID field is set to the Interface ID advertised by the Designated Router in its Hello packets, and the Neighbor Router ID field is set to the Designated Router's Router ID.
ブロードキャストとNBMAインターフェイスルーターがリンクの指定ルーターに完全に隣接している場合、またはルーター自体が指定されたルーターであり、少なくとも1つの他のルーターに完全に隣接している場合、単一のタイプ2リンク説明（トランジットネットワーク）を追加します。近隣インターフェイスIDフィールドは、Helloパケットの指定されたルーターによって宣伝されているインターフェイスIDに設定され、NeighborルーターIDフィールドは指定されたルーターのルーターIDに設定されます。
Virtual links If the neighboring router is fully adjacent, add a Type 4 link description (virtual). The Neighbor Interface ID field is set to the Interface ID advertised by the neighbor in its Hello packets, and the Neighbor Router ID field is set to the neighbor's Router ID. Note that the output cost of a virtual link is calculated during the routing table calculation (see Section 4.7).
仮想リンク隣接するルーターが完全に隣接している場合は、タイプ4リンク説明（仮想）を追加します。Neighbor Interface IDフィールドは、Hello PacketsでNeighborが宣伝したインターフェイスIDに設定され、Neighbor Router IDフィールドはNeighborのルーターIDに設定されています。仮想リンクの出力コストは、ルーティングテーブルの計算中に計算されることに注意してください（セクション4.7を参照）。
Point-to-Multipoint interfaces For each fully adjacent neighbor associated with the interface, add a separate Type 1 link description (point-to-point) with the Neighbor Interface ID field set to the Interface ID advertised by the neighbor in its Hello packets and the Neighbor Router ID field set to the neighbor's Router ID.
インターフェイスに関連付けられている完全に隣接する各隣人のポイントツーマルチポイントインターフェイスは、Helloパケットと隣人が宣伝したインターフェイスIDに設定されたNeighbor Interface IDフィールドに個別のタイプ1リンク説明（ポイントツーポイント）を追加し、隣のルーターIDフィールドは、隣のルーターIDに設定されています。
As an example, consider the router-LSA that router RT3 would originate for Area 1 in Figure 1. Only a single interface must be described, namely, that which connects to the transit network N3. It assumes that RT4 has been elected the Designated Router of Network N3.
例として、図1の領域1でルーターRT3が発生するルーター-LSAを考えてみましょう。つまり、トランジットネットワークN3に接続するインターフェイス、つまり、単一のインターフェイスのみを説明する必要があります。RT4がネットワークN3の指定されたルーターを選出されたと想定しています。
; RT3's router-LSA for Area 1
;エリア1のRT3のルーター-LSA
LS age = 0 ;newly (re)originated
LS type = 0x2001 ;router-LSA
Link State ID = 0 ;first fragment
Advertising Router = 192.0.2.3 ;RT3's Router ID
bit E = 0 ;not an AS boundary router
bit B = 1 ;area border router
Options = (V6-bit|E-bit|R-bit)
Type = 2 ;connects to N3
Metric = 1 ;cost to N3
Interface ID = 1 ;RT3's Interface ID on N3
Neighbor Interface ID = 1 ;RT4's Interface ID on N3
Neighbor Router ID = 192.0.2.4 ; RT4's Router ID
RT3's router-LSA for Area 1
エリア1のRT3のルーター-LSA
For example, if another router was added to Network N4, RT3 would have to advertise a second link description for its connection to (the now transit) network N4. This could be accomplished by reoriginating the above router-LSA, this time with two link descriptions. Or, a separate router-LSA could be originated with a separate Link State ID (e.g., using a Link State ID of 1) to describe the connection to N4.
たとえば、別のルーターがネットワークN4に追加された場合、RT3は（現在のトランジット）ネットワークN4への接続の2番目のリンク説明を宣伝する必要があります。これは、上記のルーター-LSAを再起動することで実現できます。今回は2つのリンクの説明を使用しています。または、別のルーター-LSAを、N4への接続を説明するために、個別のリンク状態ID（例：1のリンク状態IDを使用）で発信することができます。
Host routes for stub networks no longer appear in the router-LSA. Rather, they are included in intra-area-prefix-LSAs.
スタブネットワークのホストルートは、ルーターLSAに表示されなくなりました。むしろ、それらはエリア内-Prefix-LSAに含まれています。
The LS type of a network-LSA is set to the value 0x2002. Network-LSAs have area flooding scope. A network-LSA is originated for every broadcast or NBMA link with an elected Designated Router that is fully adjacent with at least one other router on the link. The network-LSA is originated by the link's Designated Router and lists all routers on the link with which it is fully adjacent.
ネットワークLSAのLSタイプは、値0x2002に設定されています。ネットワークLSAには、面積洪水範囲があります。ネットワークLSAは、リンク上の少なくとも1つの他のルーターと完全に隣接する選択された指定されたルーターを使用して、放送またはNBMAリンクごとに発信されます。ネットワークLSAは、リンクの指定されたルーターによって発信され、完全に隣接するリンク上のすべてのルーターをリストします。
The procedure for originating network-LSAs in IPv6 is the same as the IPv4 procedure documented in Section 12.4.2 of [OSPFV2], with the following exceptions:
IPv6のネットワークLSAを発信する手順は、[OSPFV2]のセクション12.4.2に記載されているIPv4手順と同じです。
o An IPv6 network-LSA's Link State ID is set to the Interface ID of the Designated Router on the link.
o IPv6 Network-LSAのリンク状態IDは、リンク上の指定されたルーターのインターフェイスIDに設定されます。
o IPv6 network-LSAs do not contain a Network Mask. All addressing information formerly contained in the IPv4 network-LSA has now been consigned to intra-Area-Prefix-LSAs originated by the link's Designated Router.
o IPv6 Network-LSAには、ネットワークマスクが含まれていません。以前はIPv4ネットワークLSAに含まれていたすべてのアドレス指定情報は、リンクの指定されたルーターによって発信されたエリア内 - エリア内型LSAに委託されています。
o The Options field in the network-LSA is set to the logical OR of the Options fields contained within the link's associated link-LSAs corresponding to fully adjacent neighbors. In this way, the network link exhibits a capability when at least one fully adjacent neighbor on the link requests that the capability be advertised.
o ネットワークLSAのオプションフィールドは、完全に隣接する近隣に対応するリンクの関連するリンクLSA内に含まれる論理またはオプションフィールドに設定されます。このようにして、ネットワークリンクは、リンク上の少なくとも1つの完全に隣接する近隣が機能を宣伝することを要求する場合に機能を示します。
As an example, assuming that Router RT4 has been elected the Designated Router of Network N3 in Figure 1, the following network-LSA is originated:
例として、図1のネットワークN3の指定されたルーターをルーターRT4が選出されたと仮定すると、次のネットワークLSAが発信されます。
; Network-LSA for Network N3
;ネットワークN3のネットワークLSA
LS age = 0 ;newly (re)originated
LS type = 0x2002 ;network-LSA
Link State ID = 1 ;RT4's Interface ID on N3
Advertising Router = 192.0.2.4 ;RT4's Router ID
Options = (V6-bit|E-bit|R-bit)
Attached Router = 192.0.2.4 ;Router ID
Attached Router = 192.0.2.1 ;Router ID
Attached Router = 192.0.2.2 ;Router ID
Attached Router = 192.0.2.3 ;Router ID
Network-LSA for Network N3
ネットワークN3のネットワークLSA
The LS type of an inter-area-prefix-LSA is set to the value 0x2003. Inter-area-prefix-LSAs have area flooding scope. In IPv4, inter-area-prefix-LSAs were called type 3 summary-LSAs. Each inter-area-prefix-LSA describes a prefix external to the area, yet internal to the Autonomous System.
エリア間領域間LSAのLSタイプは、値0x2003に設定されています。エリア間型LSAには、面積洪水範囲があります。IPv4では、エリア間対と型LSAがタイプ3サマリLSAと呼ばれていました。各エリア間型LSAは、エリアの外部のプレフィックスを記述しますが、自律システムの内部について説明します。
The procedure for originating inter-area-prefix-LSAs in IPv6 is the same as the IPv4 procedure documented in Sections 12.4.3 and 12.4.3.1 of [OSPFV2], with the following exceptions:
IPv6でエリア間対と型型LSAを発信する手順は、[OSPFv2]のセクション12.4.3および12.4.3.1に記録されているIPv4手順と同じです。以下の例外を除きます。
o The Link State ID of an inter-area-prefix-LSA has lost all of its addressing semantics and simply serves to distinguish multiple inter-area-prefix-LSAs that are originated by the same router.
o Area Inter-Area-Prefix-LSAのリンク状態IDは、そのアドレス指定セマンティクスのすべてを失い、同じルーターから発信される複数のエリア間対プレフィックスLSAを区別するのに役立ちます。
o The prefix is described by the PrefixLength, PrefixOptions, and Address Prefix fields embedded within the LSA body. Network Mask is no longer specified.
o 接頭辞は、LSA本体に埋め込まれたプレフィックスレング、プレフィキソップ、およびアドレスプレフィックスフィールドで説明されています。ネットワークマスクは指定されなくなりました。
o The NU-bit in the PrefixOptions field should be clear.
o プレフィキソップティオンフィールドのNUビットは明確にする必要があります。
o Link-local addresses MUST never be advertised in inter-area-prefix-LSAs.
o Link-Localアドレスは、エリア間型LSAで決して宣伝してはなりません。
As an example, the following shows the inter-area-prefix-LSA that Router RT4 originates into the OSPF backbone area, condensing all of Area 1's prefixes into the single prefix 2001:0db8:c001::/48. The cost is set to 4, which is the maximum cost of all of the individual component prefixes. The prefix is padded out to an even number of 32-bit words, so that it consumes 64 bits of space instead of 48 bits.
例として、以下は、ルーターRT4がOSPFバックボーン領域に由来するエリア間 - プレフィックスLSAを示しており、エリア1のすべてのプレフィックスを単一プレフィックス2001：0DB8：C001 ::/48に凝縮します。コストは4に設定されています。これは、個々のコンポーネントプレフィックスのすべての最大コストです。接頭辞は、48ビットではなく64ビットのスペースを消費するように、偶数32ビットの単語にパッドアウトされています。
; Inter-area-prefix-LSA for Area 1 addresses ; originated by Router RT4 into the backbone
;エリア1アドレスのためのエリア間 - プレフィックスLSA。Router RT4からバックボーンに由来します
LS age = 0 ;newly (re)originated
LS type = 0x2003 ;inter-area-prefix-LSA
Advertising Router = 192.0.2.4 ;RT4's ID
Metric = 4 ;maximum to components
PrefixLength = 48
PrefixOptions = 0
Address Prefix = 2001:0db8:c001 ;padded to 64-bits
Inter-area-prefix-LSA for Area 1 addresses originated by Router RT4 into the backbone
エリア1のエリア間 - ペルフィックスLSAは、ルーターRT4からバックボーンに由来するアドレス
The LS type of an inter-area-router-LSA is set to the value 0x2004. Inter-area-router-LSAs have area flooding scope. In IPv4, inter-area-router-LSAs were called type 4 summary-LSAs. Each inter-area-router-LSA describes a path to a destination OSPF router (i.e., an AS Boundary Router (ASBR)) that is external to the area yet internal to the Autonomous System.
エリア間ルーターLSAのLSタイプは、値0x2004に設定されています。エリア間ルーターLSAには、面積洪水範囲があります。IPv4では、エリア間ルーターLSAはタイプ4サマリLSAと呼ばれていました。各エリア間ルーターLSAは、宛先OSPFルーター（つまり、AS境界ルーター（ASBR））へのパスを、自律システムの内部の領域の外部であることを説明しています。
The procedure for originating inter-area-router-LSAs in IPv6 is the same as the IPv4 procedure documented in Section 12.4.3 of [OSPFV2], with the following exceptions:
IPv6でエリア間ルーター間LSAを発信する手順は、[OSPFV2]のセクション12.4.3に記載されているIPv4手順と同じです。
o The Link State ID of an inter-area-router-LSA is no longer the destination router's OSPF Router ID and now simply serves to distinguish multiple inter-area-router-LSAs that are originated by the same router. The destination router's Router ID is now found in the body of the LSA.
o エリア間ルーターLSAのリンク状態IDは、宛先ルーターのOSPFルーターIDではなくなり、同じルーターから発信される複数のエリア間ルーターLSAを区別するのに役立ちます。宛先ルーターのルーターIDは、LSAの本体にあります。
o The Options field in an inter-area-router-LSA should be set equal to the Options field contained in the destination router's own router-LSA. The Options field thus describes the capabilities supported by the destination router.
o エリア間ルーターLSAのオプションフィールドは、宛先ルーターのルーターLSAに含まれるオプションフィールドに等しく設定する必要があります。したがって、オプションフィールドは、宛先ルーターによってサポートされる機能を説明します。
As an example, consider the OSPF Autonomous System depicted in Figure 6 of [OSPFV2]. Router RT4 would originate into Area 1 the following inter-area-router-LSA for destination router RT7.
例として、[OSPFV2]の図6に示すOSPF自律システムを検討してください。ルーターRT4は、宛先ルーターRT7のエリア1エリア間ルーターLSAのエリア1に発生します。
; inter-area-router-LSA for AS boundary router RT7 ; originated by Router RT4 into Area 1
;境界ルーターrt7としてのエリア間ルーターLSA;Router RT4からエリア1に由来します
LS age = 0 ;newly (re)originated
LS type = 0x2004 ;inter-area-router-LSA
Advertising Router = 192.0.2.4 ;RT4's ID
Options = (V6-bit|E-bit|R-bit) ;RT7's capabilities
Metric = 14 ;cost to RT7
Destination Router ID = Router RT7's ID
Inter-area-router-LSA for AS boundary router RT7 originated by Router RT4 into Area 1
As boundary Router RT7のエリア間LSAは、Router RT4からエリア1に由来します
The LS type of an AS-external-LSA is set to the value 0x4005. AS-external-LSAs have AS flooding scope. Each AS-external-LSA describes a path to a prefix external to the Autonomous System.
AS-External-LSAのLSタイプは、値0x4005に設定されています。AS-External-LSAには洪水範囲としてあります。各ASExternal-LSAは、自律システムの外部にあるプレフィックスへのパスを説明します。
The procedure for originating AS-external-LSAs in IPv6 is the same as the IPv4 procedure documented in Section 12.4.4 of [OSPFV2], with the following exceptions:
IPv6のAs-External-LSAを発信する手順は、[OSPFv2]のセクション12.4.4に記載されているIPv4手順と同じです。
o The Link State ID of an AS-external-LSA has lost all of its addressing semantics and simply serves to distinguish multiple AS-external-LSAs that are originated by the same router.
o As-External-LSAのリンク状態IDは、そのアドレス指定セマンティクスのすべてを失い、同じルーターから発生する複数のASExternal-LSAを区別するのに役立ちます。
o The prefix is described by the PrefixLength, PrefixOptions, and Address Prefix fields embedded within the LSA body. Network Mask is no longer specified.
o 接頭辞は、LSA本体に埋め込まれたプレフィックスレング、プレフィキソップ、およびアドレスプレフィックスフィールドで説明されています。ネットワークマスクは指定されなくなりました。
o The NU-bit in the PrefixOptions field should be clear.
o プレフィキソップティオンフィールドのNUビットは明確にする必要があります。
o Link-local addresses can never be advertised in AS-external-LSAs.
o Link-Localアドレスは、AS-External-LSAで宣伝することはできません。
o The forwarding address is present in the AS-external-LSA if and only if the AS-external-LSA's bit F is set.
o 転送アドレスは、As-External-LSAのビットfが設定されている場合にのみ、As-External-LSAに存在します。
o The external route tag is present in the AS-external-LSA if and only if the AS-external-LSA's bit T is set.
o 外部ルートタグは、External-LSAのビットtが設定されている場合にのみ、As-External-LSAに存在します。
o The capability for an AS-external-LSA to reference another LSA has been supported through the inclusion of the Referenced LS Type field and the optional Referenced Link State ID field (the latter present if and only if the Referenced LS Type is non-zero). This capability is for future use; the Referenced LS Type should be set to 0, and received non-zero values for this field should be ignored until its use is defined.
o As-External-LSAが別のLSAを参照する機能は、参照されたLSタイプフィールドとオプションの参照リンク状態フィールドを含めることでサポートされています（参照されたLSタイプがゼロではない場合にのみ後者が存在します）。この機能は将来の使用のためです。参照されたLSタイプは0に設定し、このフィールドのゼロ以外の値を受信したものは、その使用が定義されるまで無視する必要があります。
As an example, consider the OSPF Autonomous System depicted in Figure 6 of [OSPFV2]. Assume that RT7 has learned its route to N12 via BGP and that it wishes to advertise a Type 2 metric into the AS. Also assume that the IPv6 prefix for N12 is the value 2001:0db8:0a00::/40. RT7 would then originate the following AS-external-LSA for the external network N12. Note that within the AS-external-LSA, N12's prefix occupies 64 bits of space in order to maintain 32-bit alignment.
例として、[OSPFV2]の図6に示すOSPF自律システムを検討してください。RT7がBGPを介してN12へのルートを学んだこと、およびASにタイプ2メトリックを宣伝したいと考えていると仮定します。また、N12のIPv6プレフィックスは、値2001：0DB8：0A00 ::/40であると仮定します。次に、RT7は、外部ネットワークN12の次のas-enterternal-LSAを発生します。As-External-LSA内では、N12の接頭辞は32ビットのアライメントを維持するために64ビットのスペースを占有していることに注意してください。
; AS-external-LSA for Network N12, ; originated by Router RT7
;ネットワークN12のAS-External-LSA、;Router RT7から生まれました
LS age = 0 ;newly (re)originated
LS type = 0x4005 ;AS-external-LSA
Link State ID = 123 ;LSA type/scope unique identifier
Advertising Router = Router RT7's ID
bit E = 1 ;Type 2 metric
bit F = 0 ;no forwarding address
bit T = 1 ;external route tag included
Metric = 2
PrefixLength = 40
PrefixOptions = 0
Referenced LS Type = 0 ;no Referenced Link State ID
Address Prefix = 2001:0db8:0a00 ;padded to 64-bits
External Route Tag = as per BGP/OSPF interaction
AS-external-LSA for Network N12, originated by Router RT7
ネットワークN12のASEXTERNAL-LSA、ルーターRT7から発生しました
The LS type of an NSSA-LSA is set to the value 0x2007. NSSA-LSAs have area flooding scope. Each NSSA-LSA describes a path to a prefix external to the Autonomous System whose flooding scope is restricted to a single NSSA area.
NSSA-LSAのLSタイプは、値0x2007に設定されています。NSSA-LSAには、面積洪水範囲があります。各NSSA-LSAは、洪水範囲が単一のNSSA領域に限定されている自律システムの外部にある接頭辞へのパスを説明しています。
The procedure for originating NSSA-LSAs in IPv6 is the same as the IPv4 procedure documented in [NSSA], with the following exceptions: o The Link State ID of an NSSA-LSA has lost all of its addressing semantics and simply serves to distinguish multiple NSSA-LSAs that are originated by the same router in the same area.
IPv6でNSSA-LSAを発信する手順は、次の例外を除き、[NSSA]で文書化されたIPv4手順と同じです。ONSSA-LSAのリンク状態IDは、そのアドレス指定のすべてを失い、単に複数を区別するためにサービスを提供しています。同じ領域の同じルーターから発信されるNSSA-LSA。
o The prefix is described by the PrefixLength, PrefixOptions, and Address Prefix fields embedded within the LSA body. Network Mask is no longer specified.
o 接頭辞は、LSA本体に埋め込まれたプレフィックスレング、プレフィキソップ、およびアドレスプレフィックスフィールドで説明されています。ネットワークマスクは指定されなくなりました。
o The NU-bit in the PrefixOptions field should be clear.
o プレフィキソップティオンフィールドのNUビットは明確にする必要があります。
o Link-local addresses can never be advertised in NSSA-LSAs.
o Link-Localアドレスは、NSSA-LSAで宣伝することはできません。
o The forwarding address is present in the NSSA-LSA if and only if the NSSA-LSA's bit F is set.
o NSSA-LSAのビットfが設定されている場合にのみ、転送アドレスはNSSA-LSAに存在します。
o The external route tag is present in the NSSA-LSA if and only if the NSSA-LSA's bit T is set.
o NSSA-LSAのビットtが設定されている場合にのみ、外部ルートタグはNSSA-LSAに存在します。
o The capability for an NSSA-LSA to reference another LSA has been supported through the inclusion of the Referenced LS Type field and the optional Referenced Link State ID field (the latter present if and only if the Referenced LS Type is non-zero). This capability is for future use; the Referenced LS Type should be set to 0, and received non-zero values for this field should be ignored until its use is defined.
o NSSA-LSAが別のLSAを参照する機能は、参照されたLSタイプフィールドとオプションの参照リンク状態IDフィールドを含めることでサポートされています（参照されたLSタイプがゼロではない場合にのみ後者が存在します）。この機能は将来の使用のためです。参照されたLSタイプは0に設定し、このフィールドのゼロ以外の値を受信したものは、その使用が定義されるまで無視する必要があります。
An example of an NSSA-LSA would only differ from an AS-external-LSA in that the LS type would be 0x2007 rather than 0x4005.
NSSA-LSAの例は、LSタイプが0x4005ではなく0x2007になるという点で、AS-External-LSAとのみ異なります。
The LS type of a link-LSA is set to the value 0x0008. Link-LSAs have link-local flooding scope. A router originates a separate link-LSA for each attached link that supports two or more (including the originating router itself) routers. Link-LSAs SHOULD NOT be originated for virtual links.
link-lsaのLSタイプは、値0x0008に設定されています。Link-LSAには、Link-Local Flooding Scopeがあります。ルーターは、2つ以上の（元のルーター自体を含む）ルーターをサポートする各添付リンクの個別のリンクLSAを発信します。Link-LSAは、仮想リンクのために発信するべきではありません。
Link-LSAs have three purposes:
Link-LSAには3つの目的があります。
1. They provide the router's link-local address to all other routers attached to the link.
1. それらは、リンクに接続された他のすべてのルーターにルーターのリンクローカルアドレスを提供します。
2. They inform other routers attached to the link of a list of IPv6 prefixes to associate with the link.
2. 彼らは、IPv6プレフィックスのリストのリンクに接続された他のルーターに、リンクに関連付けることを通知します。
3. They allow the router to advertise a collection of Options bits in the network-LSA originated by the Designated Router on a broadcast or NBMA link.
3. ルーターは、ブロードキャストまたはNBMAリンクで指定されたルーターによって発信されるネットワークLSAのオプションビットのコレクションを宣伝することができます。
A link-LSA for a given Link L is built in the following fashion:
特定のリンクLのリンクLSAは、次の方法で構築されます。
o The Link State ID is set to the router's Interface ID on Link L.
o リンク状態IDは、リンクLのルーターのインターフェイスIDに設定されています。
o The Router Priority of the router's interface to Link L is inserted into the link-LSA.
o リンクLへのルーターのインターフェイスのルーターの優先度は、Link-LSAに挿入されます。
o The link-LSA's Options field is set to reflect the router's capabilities. On multi-access links, the Designated Router will logically OR the link-LSA Options fields for all fully adjacent neighbors in Link L's network-LSA.
o Link-LSAのオプションフィールドは、ルーターの機能を反映するように設定されています。マルチアクセスリンクでは、指定されたルーターは論理的に、またはLink LのネットワークLSAのすべての完全に隣接する隣接するリンクLSAオプションフィールドになります。
o The router inserts its link-local address on Link L into the link-LSA. This information will be used when the other routers on Link L do their next-hop calculations (see Section 4.8.2).
o ルーターは、リンクlにリンクローカルアドレスをリンクLSAに挿入します。この情報は、リンクLの他のルーターが次のホップ計算を行うときに使用されます（セクション4.8.2を参照）。
o Each IPv6 address prefix that has been configured on Link L is added to the link-LSA by specifying values for the PrefixLength, PrefixOptions, and Address Prefix fields.
o リンクlで構成されている各IPv6アドレスプレフィックスは、プレフィックス長、プレフィキソップ、アドレスのプレフィックスフィールドの値を指定することにより、リンクLSAに追加されます。
After building a link-LSA for a given link, the router installs the link-LSA into the associated interface data structure and floods the link-LSA on the link. All other routers on the link will receive the link-LSA, but they will not flood the link-LSA on other links.
特定のリンクのリンクLSAを構築した後、ルーターはリンクLSAを関連するインターフェイスデータ構造にインストールし、リンク上のリンクLSAにあふれます。リンク上の他のすべてのルーターはリンクLSAを受け取りますが、他のリンクでLink-LSAにあふれません。
If LinkLSASuppression is configured for the interface and the interface type is not broadcast or NBMA, origination of the link-LSA may be suppressed. This implies that other routers on the link will ascertain the router's next-hop address using a mechanism other than the link-LSA (see Section 4.8.2). Refer to Appendix C.3 for a description of the LinkLSASuppression interface configuration parameter.
インターフェイス用にLinklSaSasuppressionが構成され、インターフェイスタイプがブロードキャストまたはNBMAがない場合、Link-LSAの発信が抑制される可能性があります。これは、リンク上の他のルーターが、リンクLSA以外のメカニズムを使用してルーターのネクストホップアドレスを確認することを意味します（セクション4.8.2を参照）。LinklsaSasaSasasasSasasSasSasasSupressionインターフェイス構成パラメーターの説明については、付録C.3を参照してください。
As an example, consider the link-LSA that RT3 will build for N3 in Figure 1. Suppose that the prefix 2001:0db8:c001:0100::/56 has been configured within RT3 for N3. This will result in the following link-LSA that RT3 will flood only on N3. Note that not all routers on N3 need be configured with the prefix; those not configured will learn the prefix when receiving RT3's link-LSA.
例として、図1のN3に対してRT3が構築するリンクLSAを考えてみましょう。プレフィックス2001：0DB8：C001：0100 ::/56がN3のRT3内で構成されていると仮定します。これにより、次のLink-LSAがN3でのみFlook洪水になるというリンクLSAになります。N3のすべてのルーターをプレフィックスで構成する必要はないことに注意してください。構成されていないものは、RT3のLink-LSAを受信するときにプレフィックスを学習します。
; RT3's link-LSA for N3
;N3のRT3のリンクLSA
LS age = 0 ;newly (re)originated
LS type = 0x0008 ;link-LSA
Link State ID = 1 ;RT3's Interface ID on N3
Advertising Router = 192.0.2.3 ;RT3's Router ID
Rtr Priority = 1 ;RT3's N3 Router Priority
Options = (V6-bit|E-bit|R-bit)
Link-local Interface Address = fe80:0001::RT3
# prefixes = 1
PrefixLength = 56
PrefixOptions = 0
Address Prefix = 2001:0db8:c001:0100 ;pad to 64-bits
RT3's link-LSA for N3
N3のRT3のリンクLSA
The LS type of an intra-area-prefix-LSA is set to the value 0x2009. Intra-area-prefix-LSAs have area flooding scope. An intra-area-prefix-LSA has one of two functions. It either associates a list of IPv6 address prefixes with a transit network link by referencing a network-LSA, or associates a list of IPv6 address prefixes with a router by referencing a router-LSA. A stub link's prefixes are associated with its attached router.
エリア内-Prefix-LSAのLSタイプは、値0x2009に設定されています。エリア内-Prefix-LSAには、面積洪水範囲があります。エリア内-Prefix-LSAには、2つの機能のいずれかがあります。ネットワークLSAを参照することにより、IPv6アドレスのプレフィックスのリストをトランジットネットワークリンクに関連付けるか、ルーターLSAを参照してIPv6アドレスプレフィックスのリストをルーターと関連付けます。スタブリンクのプレフィックスは、取り付けられたルーターに関連付けられています。
A router MAY originate multiple intra-area-prefix-LSAs for a given area. Each intra-area-prefix-LSA has a unique Link State ID and contains an integral number of prefix descriptions.
ルーターは、特定の領域の複数のエリア内型LSAを発生する場合があります。各エリア内-Prefix-LSAには、一意のリンク状態IDがあり、積分数のプレフィックス説明が含まれています。
A link's Designated Router originates one or more intra-area-prefix-LSAs to advertise the link's prefixes throughout the area. For a link L, L's Designated Router builds an intra-area-prefix-LSA in the following fashion:
リンクの指定されたルーターは、1つまたは複数のエリア内型LSAを発信し、エリア全体のリンクのプレフィックスを宣伝します。リンクlの場合、L'S指定ルーターは、次の方法でエリア内型LSAを構築します。
o In order to indicate that the prefixes are to be associated with the Link L, the fields Referenced LS Type, Referenced Link State ID, and Referenced Advertising Router are set to the corresponding fields in Link L's network-LSA (namely, LS type, Link State ID, and Advertising Router respectively). This means that the Referenced LS Type is set to 0x2002, the Referenced Link State ID is set to the Designated Router's Interface ID on Link L, and the Referenced Advertising Router is set to the Designated Router's Router ID.
o プレフィックスがリンクLに関連付けられていることを示すために、フィールドはLSタイプ、参照されるリンク状態ID、および参照される広告ルーターを参照します。状態ID、およびそれぞれ広告ルーター）。これは、参照されたLSタイプが0x2002に設定され、参照されるリンク状態IDがリンクLの指定されたルーターのインターフェイスIDに設定され、参照される広告ルーターが指定されたルーターのルーターIDに設定されることを意味します。
o Each link-LSA associated with Link L is examined (these are in the Designated Router's interface structure for Link L). If the link-LSA's Advertising Router is fully adjacent to the Designated Router and the Link State ID matches the neighbor's interface ID, the list of prefixes in the link-LSA is copied into the intra-area-prefix-LSA that is being built. Prefixes having the NU-bit and/or LA-bit set in their Options field SHOULD NOT be copied, nor should link-local addresses be copied. Each prefix is described by the PrefixLength, PrefixOptions, and Address Prefix fields. Multiple prefixes having the same PrefixLength and Address Prefix are considered to be duplicates. In this case, their PrefixOptions fields should be logically OR'ed together, and a single instance of the duplicate prefix should be included in the intra-area-prefix-LSA. The Metric field for all prefixes is set to 0.
o リンクLに関連付けられた各リンクLSAが調べられます（これらは、リンクLの指定されたルーターのインターフェイス構造にあります）。Link-LSAの広告ルーターが指定されたルーターに完全に隣接しており、Link State IDがNeighborのインターフェイスIDと一致する場合、Link-LSAのプレフィックスのリストは、構築されているエリア内型LSAにコピーされます。オプションフィールドにNUビットおよび/またはLAビットが設定されているプレフィックスは、コピーしてはいけません。また、Link-Localアドレスをコピーする必要もありません。各プレフィックスには、プレフィックスレングス、プレフィキソップ、アドレスのプレフィックスフィールドで説明されています。同じプレフィックスレングスとアドレスプレフィックスを持つ複数のプレフィックスは、複製と見なされます。この場合、それらのプレフィックスオプションフィールドは論理的に並べられ、重複するプレフィックスの単一のインスタンスをエリア内-Prefix-LSAに含める必要があります。すべてのプレフィックスのメトリックフィールドは0に設定されています。
o The "# prefixes" field is set to the number of prefixes that the router has copied into the LSA. If necessary, the list of prefixes can be spread across multiple intra-area-prefix-LSAs in order to keep the LSA size small.
o 「＃プレフィックス」フィールドは、ルーターがLSAにコピーしたプレフィックスの数に設定されています。必要に応じて、LSAサイズを小さく保つために、接頭辞のリストを複数のエリア内型LSAに広げることができます。
A router builds an intra-area-prefix-LSA to advertise prefixes for its attached stub links, looped-back interfaces, and hosts. A Router RTX would build its intra-area-prefix-LSA in the following fashion:
ルーターは、添付のスタブリンク、ループバックインターフェイス、およびホストのプレフィックスを宣伝するために、エリア内型RSAを構築します。ルーターRTXは、次の方法で、エリア内-Prefix-LSAを構築します。
o In order to indicate that the prefixes are to be associated with the Router RTX itself, RTX sets the Referenced LS Type to 0x2001, the Referenced Link State ID to 0, and the Referenced Advertising Router to RTX's own Router ID.
o プレフィックスがルーターRTX自体に関連付けられることを示すために、RTXは参照されたLSタイプを0x2001に、参照されるリンク状態IDを0、および参照される広告ルーターにRTX独自のルーターIDに設定します。
o Router RTX examines its list of interfaces to the area. If the interface is in the state Down, its prefixes are not included. If the interface has been reported in RTX's router-LSA as a Type 2 link description (link to transit network), prefixes that will be included in the intra-area-prefix-LSA for the link are skipped. However, any prefixes that would normally have the LA-bit set SHOULD be advertised independent of whether or not the interface is advertised as a transit link. If the interface type is point-to-multipoint or the interface is in the state Loopback, the global scope IPv6 addresses associated with the interface (if any) are copied into the intra-area-prefix-LSA with the PrefixOptions LA-bit set, the PrefixLength set to 128, and the metric set to 0. Otherwise, the list of global prefixes configured in RTX for the link are copied into the intra-area-prefix-LSA by specifying the PrefixLength, PrefixOptions, and Address Prefix fields. The Metric field for each of these prefixes is set to the interface's output cost.
o Router RTXは、インターフェイスのリストをエリアに調べます。インターフェイスが状態にある場合、そのプレフィックスは含まれていません。インターフェイスがRTXのRouter-LSAでタイプ2リンク説明（トランジットネットワークへのリンク）として報告されている場合、リンクのエリア内-Prefix-LSAに含まれるプレフィックスがスキップされます。ただし、通常、LAビットセットを持つプレフィックスは、インターフェイスがトランジットリンクとして宣伝されているかどうかとは無関係に宣伝する必要があります。インターフェイスタイプがポイントツーマルチポイントであるか、インターフェイスが状態ループバックにある場合、インターフェイスに関連付けられたグローバルスコープIPv6アドレスは、プレフィキソプティオンLAビットセットを使用してA-AREA-PREFIX-LSAにコピーされます、128に設定され、メトリックは0に設定されています。それ以外の場合、リンク用のRTXで構成されたグローバルプレフィックスのリストは、プレフィックスレングス、プレフィックスオプション、およびアドレスフィールドフィールドを指定することにより、エリア内 - エリアプレフィックスLSAにコピーされます。これらの各プレフィックスのメトリックフィールドは、インターフェイスの出力コストに設定されています。
o RTX adds the IPv6 prefixes for any directly attached hosts belonging to the area (see Appendix C.7) to the intra-area-prefix-LSA.
o RTXは、エリアに属する直接接続されたホスト（付録C.7を参照）にIPv6プレフィックスをエリア内型LSAに追加します。
o If RTX has one or more virtual links configured through the area, it includes one of its global scope IPv6 interface addresses in the LSA (if it hasn't already), setting the LA-bit in the PrefixOptions field, the PrefixLength to 128, and the Metric to 0. This information will be used later in the routing calculation so that the two ends of the virtual link can discover each other's IPv6 addresses.
o RTXにエリアを介して構成された1つ以上の仮想リンクがある場合、LSAにグローバルスコープIPv6インターフェイスアドレスの1つ（まだない場合）が含まれており、プレフィックスオプションフィールドにLAビットを設定します。メトリックは0になります。この情報は、ルーティング計算の後半で使用され、仮想リンクの2つの端が互いのIPv6アドレスを発見できるようにします。
o The "# prefixes" field is set to the number of prefixes that the router has copied into the LSA. If necessary, the list of prefixes can be spread across multiple intra-area-prefix-LSAs in order to keep the LSA size small.
o 「＃プレフィックス」フィールドは、ルーターがLSAにコピーしたプレフィックスの数に設定されています。必要に応じて、LSAサイズを小さく保つために、接頭辞のリストを複数のエリア内型LSAに広げることができます。
For example, the intra-area-prefix-LSA originated by RT4 for Network N3 (assuming that RT4 is N3's Designated Router) and the intra-area-prefix-LSA originated into Area 1 by Router RT3 for its own prefixes are pictured below.
たとえば、ネットワークN3のRT4（RT4がN3の指定ルーターであると仮定）と、独自の接頭辞についてRouter RT3のエリア1に発信されたA-A-AREA-PREFIX-LSAは、ネットワークN3のRT4から発信されました。
; RT4's Intra-area-prefix-LSA for network link N3
;ネットワークリンクN3用のRT4のエリア内 - プレフィックスLSA
LS age = 0 ;newly (re)originated
LS type = 0x2009 ;Intra-area-prefix-LSA
Link State ID = 5 ;LSA type/scope unique identifier
Advertising Router = 192.0.2.4 ;RT4's Router ID
# prefixes = 1
Referenced LS Type = 0x2002 ;network-LSA reference
Referenced Link State ID = 1
Referenced Advertising Router = 192.0.2.4
PrefixLength = 56 ;N3's prefix
PrefixOptions = 0
Metric = 0
Address Prefix = 2001:0db8:c001:0100 ;pad
; RT3's Intra-area-prefix-LSA for its own prefixes
;独自のプレフィックスについては、RT3のエリア内-Prefix-LSA
LS age = 0 ;newly (re)originated
LS type = 0x2009 ;Intra-area-prefix-LSA
Link State ID = 177 ;LSA type/scope unique identifier
Advertising Router = 192.0.2.3 ;RT3's Router ID
# prefixes = 1
Referenced LS Type = 0x2001 ;router-LSA reference
Referenced Link State ID = 0
Referenced Advertising Router = 192.0.2.3
PrefixLength = 56 ;N4's prefix
PrefixOptions = 0
Metric = 2 ;N4 interface cost
Address Prefix = 2001:0db8:c001:0400 ;pad
Intra-area-prefix-LSA for Network Link N3
ネットワークリンクN3用のエリア内-Prefix-LSA
When network conditions change, it may be necessary for a router to move prefixes from one intra-area-prefix-LSA to another. For example, if the router is the Designated Router for a link but the link has no other attached routers, the link's prefixes are advertised in an intra-area-prefix-LSA referring to the Designated Router's router-LSA. When additional routers appear on the link, a network-LSA is originated for the link and the link's prefixes are moved to an intra-area-prefix-LSA referring to the network-LSA.
ネットワークの条件が変化すると、ルーターがプレフィックスを1つのエリア内型LSAから別のエリアに移動する必要がある場合があります。たとえば、ルーターがリンクの指定されたルーターであるが、リンクには他に付属されているルーターがない場合、リンクのプレフィックスは、指定されたルーターのルーターLSAを指すエリア内で宣伝されています。リンクに追加のルーターが表示されると、ネットワークLSAがリンク用に発信され、リンクのプレフィックスがネットワークLSAを参照してエリア内型LSAに移動します。
Note that in the intra-area-prefix-LSA, the Referenced Advertising Router is always equal to the router that is originating the intra-area-prefix-LSA (i.e., the LSA's Advertising Router). The reason the Referenced Advertising Router field appears is that, even though it is currently redundant, it may not be in the future. We may sometime want to use the same LSA format to advertise address prefixes for other protocol suites. In this case, the Designated Router may not be running the other protocol suite, and so another of the link's routers may need to originate the intra-area-prefix-LSA. In that case, the Referenced Advertising Router and Advertising Router would be different.
エリア内-Prefix-LSAでは、参照される広告ルーターは常に、エリア内-Prefix-LSA（つまり、LSAの広告ルーター）を発信しているルーターに等しいことに注意してください。参照された広告ルーターフィールドが表示される理由は、現在冗長であるにもかかわらず、将来的にはない可能性があるためです。同じLSA形式を使用して、他のプロトコルスイートのアドレスプレフィックスを宣伝することをお勧めします。この場合、指定されたルーターが他のプロトコルスイートを実行していない可能性があるため、リンクのルーターの別のルーターがエリア内対プレフィックスLSAを発信する必要がある場合があります。その場合、参照された広告ルーターと広告ルーターは異なります。
It is expected that new LSAs will be defined that will not be processed during the Shortest Path First (SPF) calculation as described in Section 4.8, for example, OSPFv3 LSAs corresponding to information advertised in OSPFv2 using opaque LSAs [OPAQUE]. In general, the new information advertised in future LSAs should not be used unless the OSPFv3 router originating the LSA is reachable. However, depending on the application and the data advertised, this reachability validation MAY be done less frequently than every SPF calculation.
セクション4.8で説明されているように、最も短いパス（SPF）計算で処理されない新しいLSAが定義されると予想されます。一般に、将来のLSAで宣伝されている新しい情報は、LSAを発信するOSPFV3ルーターに到達可能でない限り使用すべきではありません。ただし、アプリケーションと宣伝されたデータに応じて、この到達可能性の検証は、すべてのSPF計算よりも頻繁に行われる場合があります。
To facilitate inter-area reachability validation, any OSPFv3 router originating AS scoped LSAs is considered an AS Boundary Router (ASBR).
エリア間の到達可能性検証を促進するために、スコープされたLSAとして発生するOSPFV3ルーターは、境界ルーター（ASBR）と見なされます。
Most of the flooding algorithm remains unchanged from the IPv4 flooding mechanisms described in Section 13 of [OSPFV2]. In particular, the protocol processes for determining which LSA instance is newer (Section 13.1 of [OSPFV2]), responding to updates of self-originated LSAs (Section 13.4 of [OSPFV2]), sending Link State Acknowledgment packets (Section 13.5 of [OSPFV2]), retransmitting LSAs (Section 13.6 of [OSPFV2]), and receiving Link State Acknowledgment packets (Section 13.7 of [OSPFV2]), are exactly the same for IPv6 and IPv4.
洪水アルゴリズムのほとんどは、[OSPFV2]のセクション13で説明されているIPv4洪水メカニズムから変化していません。特に、どのLSAインスタンスがより新しいかを判断するためのプロトコルプロセス（[OSPFV2]のセクション13.1）、自己造影LSAの更新（[OSPFV2]のセクション13.4）に応答し、リンク状態の確認パケット（[OSPFV22のセクション13.5）が送信されます。]）、LSAS（[OSPFV2]のセクション13.6）を再送信し、リンク状態の確認パケット（[OSPFV2]のセクション13.7）を受信することは、IPv6およびIPv4でまったく同じです。
However, the addition of flooding scope and unknown LSA type handling (see Appendix A.4.2.1) has caused some changes in the OSPF flooding algorithm: the reception of Link State Updates (Section 13 in [OSPFV2]) and the sending of Link State Updates (Section 13.3 of [OSPFV2]) must take into account the LSA's scope and U-bit setting. Also, installation of LSAs into the OSPF database (Section 13.2 of [OSPFV2]) causes different events in IPv6, due to the reorganization of LSA types and the IPv6 LSA contents. These changes are described in detail below.
ただし、洪水範囲と不明なLSAタイプの取り扱い（付録A.4.2.1を参照）の追加により、OSPF洪水アルゴリズムのいくつかの変更が生じました。リンク状態の更新の受信（[OSPFv2]のセクション13）とリンクの送信状態の更新（[OSPFV2]のセクション13.3）は、LSAのスコープとUビット設定を考慮する必要があります。また、LSAタイプとIPv6 LSA含有量の再編成により、LSAをOSPFデータベース（[OSPFV2]のセクション13.2）にインストールすると、IPv6のさまざまなイベントが発生します。これらの変更については、以下で詳しく説明しています。
The encoding of flooding scope in the LS type and the need to process unknown LS types cause modifications to the processing of received Link State Update packets. As in IPv4, each LSA in a received Link State Update packet is examined. In IPv4, eight steps are executed for each LSA, as described in Section 13 of [OSPFV2]. For IPv6, all the steps are the same, except that Steps 2 and 3 are modified as follows:
LSタイプの洪水範囲のエンコードと未知のLSタイプを処理する必要性により、受信リンク状態更新パケットの処理が変更されます。IPv4のように、受信したリンク状態更新パケットの各LSAが調べられます。IPv4では、[OSPFV2]のセクション13で説明されているように、各LSAに対して8つのステップが実行されます。IPv6の場合、すべての手順は同じですが、ステップ2と3が次のように変更されていることを除きます。
(2) Examine the LSA's LS type. Discard the LSA and get the next one from the Link State Update packet if the interface area has been configured as a stub or NSSA area and the LS type indicates "AS flooding scope".
(2) LSAのLSタイプを調べます。インターフェイス領域がスタブまたはNSSA領域として構成されており、LSタイプが「洪水範囲として」を示す場合、LSAをLSAを廃棄し、リンク状態更新パケットから次のものを取得します。
This generalizes the IPv4 behavior where AS-external-LSAs and AS-scoped opaque LSAs [OPAQUE] are not flooded throughout stub or NSSA areas.
これにより、Exterternal-LSASおよびAsscoped Opaque LSA [不透明]がスタブまたはNSSAエリア全体に浸水しないIPv4動作が一般化されます。
(3) Else if the flooding scope in the LSA's LS type is set to "reserved", discard the LSA and get the next one from the Link State Update packet.
(3) それ以外の場合、LSAのLSタイプの洪水スコープが「予約済み」に設定され、LSAを破棄し、Link State Updateパケットから次の範囲を取得する場合。
Steps 5b (sending Link State Update packets) and 5d (installing LSAs in the link-state database) in Section 13 of [OSPFV2] are also somewhat different for IPv6, as described in Sections 4.5.2 and 4.5.3 below.
手順5B（リンク状態更新パケットの送信）と5D（[OSPFV2]のセクション13の5D（リンク状態データベースにLSAのインストール）も、以下のセクション4.5.2および4.5.3で説明されているように、IPv6では多少異なります。
The sending of Link State Update packets is described in Section 13.3 of [OSPFV2]. For IPv4 and IPv6, the steps for sending a Link State Update packet are the same (steps 1 through 5 of Section 13.3 in [OSPFV2]). However, the list of eligible interfaces on which to flood the LSA is different. For IPv6, the eligible interfaces are selected based on the following factors:
リンク状態更新パケットの送信は、[OSPFV2]のセクション13.3で説明されています。IPv4およびIPv6の場合、リンク状態更新パケットを送信する手順は同じです（[OSPFV2]のセクション13.3のステップ1〜5）。ただし、LSAに浸水させる適格なインターフェイスのリストは異なります。IPv6の場合、対象のインターフェイスは次の要因に基づいて選択されます。
o The LSA's flooding scope.
o LSAの洪水範囲。
o For LSAs with area or link-local flooding scope, the particular area or interface with which the LSA is associated.
o 領域またはリンクローカルの洪水範囲を持つLSAの場合、LSAが関連付けられている特定のエリアまたはインターフェイス。
o Whether the LSA has a recognized LS type.
o LSAにLSタイプが認識されているかどうか。
o The setting of the U-bit in the LS type. If the U-bit is set to 0, unrecognized LS types are treated as having link-local scope. If set to 1, unrecognized LS types are stored and flooded as if they were recognized.
o LSタイプのUビットの設定。Uビットが0に設定されている場合、認識されていないLSタイプは、リンクローカルスコープを持つものとして扱われます。1に設定すると、認識されていないLSタイプが保存され、認識されているかのように浸水します。
Choosing the set of eligible interfaces then breaks into the following cases:
対象となるインターフェイスのセットを選択すると、次のケースに分割されます。
Case 1 The LSA's LS type is recognized. In this case, the set of eligible interfaces is set depending on the flooding scope encoded in the LS type. If the flooding scope is "AS flooding scope", the eligible interfaces are all router interfaces excepting virtual links. In addition, AS-external-LSAs are not flooded on interfaces connecting to stub or NSSA areas. If the flooding scope is "area flooding scope", the eligible interfaces are those interfaces connecting to the LSA's associated area. If the flooding scope is "link-local flooding scope", then there is a single eligible interface, the one connecting to the LSA's associated link (which is also the interface on which the LSA was received in a Link State Update packet).
ケース1 LSAのLSタイプが認識されます。この場合、適格なインターフェイスのセットは、LSタイプでエンコードされた洪水スコープに応じて設定されます。洪水スコープが「洪水スコープとして」の場合、適格なインターフェイスはすべて仮想リンクを除くルーターインターフェイスです。さらに、AS-External-LSAは、スタブまたはNSSA領域に接続するインターフェイスに浸水しません。洪水範囲が「エリアフラッドスコープ」の場合、適格なインターフェイスは、LSAの関連領域に接続するインターフェイスです。洪水範囲が「リンクローカルフラッディングスコープ」の場合、LSAの関連リンクに接続する単一の適格なインターフェイスがあります（これは、LSAがリンク状態更新パケットで受信されたインターフェイスでもあります）。
Case 2 The LS type is unrecognized and the U-bit in the LS type is set to 0 (treat the LSA as if it had link-local flooding scope). In this case, there is a single eligible interface, namely, the interface on which the LSA was received.
ケース2 LSタイプは認識されておらず、LSタイプのUビットは0に設定されています（LSAをリンクローカルフラッディング範囲があるかのように扱います）。この場合、単一の適格なインターフェイス、つまりLSAが受信されたインターフェイスがあります。
Case 3 The LS type is unrecognized, and the U-bit in the LS type is set to 1 (store and flood the LSA as if the type is understood). In this case, select the eligible interfaces based on the encoded flooding scope the same as in Case 1 above.
ケース3 LSタイプは認識されず、LSタイプのUビットは1に設定されています（まるでタイプが理解されているかのようにLSAを保存して浸水させます）。この場合、上記のケース1と同じエンコードされた洪水範囲に基づいて適格なインターフェイスを選択します。
A further decision must sometimes be made before adding an LSA to a given neighbor's link-state retransmission list (Step 1d in Section 13.3 of [OSPFV2]). If the LS type is recognized by the router but not by the neighbor (as can be determined by examining the Options field that the neighbor advertised in its Database Description packet) and the LSA's U-bit is set to 0, then the LSA should be added to the neighbor's link-state retransmission list if and only if that neighbor is the Designated Router or Backup Designated Router for the attached link. The LS types described in detail by this document, namely, router-LSAs (LS type 0x2001), network-LSAs (0x2002), inter-area-prefix-LSAs (0x2003), inter-area-router-LSAs (0x2004), NSSA-LSAs (0x2007), AS-external-LSAs (0x4005), link-LSAs (0x0008), and Intra-Area-Prefix-LSAs (0x2009), are assumed to be understood by all routers. However, all LS types MAY not be understood by all routers. For example, a new LSA type with its U-bit set to 0 MAY only be understood by a subset of routers. This new LS type should only be flooded to an OSPF neighbor that understands the LS type or when the neighbor is the Designated Router or Backup Designated Router for the attached link.
LSAを特定の近隣のリンク状態の再送信リストに追加する前に、さらなる決定を下す必要があります（[OSPFV2]のセクション13.3のステップ1D）。LSタイプはルーターによって認識されますが、隣人によっては認識されません（データベースの説明パケットで隣人が宣伝したオプションフィールドを調べることで決定できます）とLSAのUビットが0に設定されている場合、LSAはその隣人が添付のリンクの指定されたルーターまたはバックアップ指定ルーターである場合にのみ、近隣のリンク状態の再送信リストに追加されます。このドキュメント、すなわちルーターLSA（LSタイプ0x2001）、ネットワークLSAS（0x2002）、エリア間 - ペルフィックスLSAS（0x2003）、エリア間ルーターLSAS（0x2004）、つまり、このドキュメントで詳細に説明されているLSタイプNSSA-LSAS（0x2007）、As-External-LSAS（0x4005）、Link-LSAS（0x0008）、およびA-Area-Prefix-LSAS（0x2009）は、すべてのルーターで理解されていると想定されています。ただし、すべてのLSタイプはすべてのルーターでは理解できない場合があります。たとえば、Uビットを0に設定した新しいLSAタイプは、ルーターのサブセットによってのみ理解できます。この新しいLSタイプは、LSタイプを理解しているOSPF隣人にのみ浸水する必要があります。
The previous paragraph solves a problem for IPv4 OSPF extensions, which require that the Designated Router support the extension in order to have the new LSA types flooded across broadcast and NBMA networks.
前の段落では、IPv4 OSPF拡張機能の問題を解決します。これにより、指定されたルーターが、新しいLSAタイプをブロードキャストとNBMAネットワーク全体に浸水させるために拡張機能をサポートする必要があります。
There are three separate places to store LSAs, depending on their flooding scope. LSAs with AS flooding scope are stored in the global OSPF data structure (see Section 4.1) as long as their LS type is known or their U-bit is 1. LSAs with area flooding scope are stored in the appropriate area data structure (see Section 4.1.1) as long as their LS type is known or their U-bit is 1. LSAs with link-local flooding scope, and those LSAs with unknown LS type and U-bit set to 0 (treat the LSA as if it had link-local flooding scope), are stored in the appropriate interface data structure.
LSAの洪水範囲に応じて、LSAを保存するための3つの別々の場所があります。as洪水スコープを持つLSAは、LSタイプが既知であるか、Uビットが1である限り、グローバルOSPFデータ構造に保存されます（セクション4.1を参照）。4.1.1）LSタイプが既知であるか、Uビットが1である限り、リンクローカルフラッディングスコープを持つLSA、およびLSが未知のLSタイプとUビットが0に設定されているLSALink-Local Flooding Scope）は、適切なインターフェイスデータ構造に保存されます。
When storing the LSA into the link-state database, a check must be made to see whether the LSA's contents have changed. Changes in contents are indicated exactly as in Section 13.2 of [OSPFV2]. When an LSA's contents have been changed, the following parts of the routing table must be recalculated, based on the LSA's LS type:
LSAをLink-Stateデータベースに保存する場合、LSAの内容が変更されたかどうかを確認するためにチェックを行う必要があります。内容物の変化は、[OSPFV2]のセクション13.2とまったく同じように示されています。LSAの内容が変更された場合、LSAのLSタイプに基づいて、ルーティングテーブルの次の部分を再計算する必要があります。
Router-LSAs, Network-LSAs, Intra-Area-Prefix-LSAs, and Link-LSAs The entire routing table is recalculated, starting with the shortest-path calculation for each area (see Section 4.8).
Router-LSA、ネットワークLSA、イントラエリア-Prefix-LSAS、およびLink-LSASルーティングテーブル全体が再計算され、各領域の最短パス計算から始まります（セクション4.8を参照）。
Inter-Area-Prefix-LSAs and Inter-Area-Router-LSAs The best route to the destination described by the LSA must be recalculated (see Section 16.5 in [OSPFV2]). If this destination is an AS boundary router, it may also be necessary to re-examine all the AS-external-LSAs.
エリア間型型LSAおよびエリア間ルーターLSAS LSAによって記述された目的地への最適なルートは、再計算する必要があります（[OSPFV2]のセクション16.5を参照）。この目的地が境界ルーターである場合、すべてのas-fernal-LSAを再検討する必要もあります。
AS-external-LSAs and NSSA-LSAs The best route to the destination described by the AS-external-LSA or NSSA-LSA must be recalculated (see Section 16.6 in [OSPFV2] and Section 2.0 in [NSSA]).
As-External-LSAおよびNSSA-LSAS As-External-LSAまたはNSSA-LSAによって記述された目的地への最適なルートを再計算する必要があります（[NSSA]のセクション2.0を参照）。
As in IPv4, any old instance of the LSA must be removed from the database when the new LSA is installed. This old instance must also be removed from all neighbors' link-state retransmission lists.
IPv4のように、新しいLSAがインストールされているときに、LSAの古いインスタンスをデータベースから削除する必要があります。この古いインスタンスは、すべての隣人のリンク状態の再送信リストから削除する必要があります。
In IPv6, the definition of a self-originated LSA has been simplified from the IPv4 definition appearing in Sections 13.4 and 14.1 of [OSPFV2]. For IPv6, self-originated LSAs are those LSAs whose Advertising Router is equal to the router's own Router ID.
IPv6では、[OSOSPFV2]のセクション13.4および14.1に表示されるIPv4定義から、自己陽子LSAの定義が簡素化されています。IPv6の場合、自己造影LSAは、広告ルーターがルーター自身のルーターIDに等しいLSAです。
OSPF virtual links for IPv4 are described in Section 15 of [OSPFV2]. Virtual links are the same in IPv6, with the following exceptions:
IPv4のOSPF仮想リンクは、[OSPFV2]のセクション15で説明されています。仮想リンクはIPv6では同じですが、以下の例外を除きます。
o LSAs having AS flooding scope are never flooded over virtual adjacencies, nor are LSAs with AS flooding scope summarized over virtual adjacencies during the database exchange process. This is a generalization of the IPv4 treatment of AS-external-LSAs.
o 洪水範囲としてのLSAは、仮想隣接に浸水することはなく、データベース交換プロセス中に仮想隣接を介して洪水範囲を伴うLSAもありません。これは、As-External-LSAのIPv4処理の一般化です。
o The IPv6 interface address of a virtual link MUST be an IPv6 address having global scope, instead of the link-local addresses used by other interface types. This address is used as the IPv6 source for OSPF protocol packets sent over the virtual link. Hence, a link-LSA SHOULD NOT be originated for a virtual link since the virtual link has no link-local address or associated prefixes.
o 仮想リンクのIPv6インターフェイスアドレスは、他のインターフェイスタイプで使用されるリンクローカルアドレスの代わりに、グローバルスコープを持つIPv6アドレスでなければなりません。このアドレスは、仮想リンクを介して送信されたOSPFプロトコルパケットのIPv6ソースとして使用されます。したがって、仮想リンクにはリンクローカルアドレスや関連するプレフィックスがないため、仮想リンクのリンクLSAを作成しないでください。
o Likewise, the virtual neighbor's IPv6 address is an IPv6 address with global scope. To enable the discovery of a virtual neighbor's IPv6 address during the routing calculation, the neighbor advertises its virtual link's IPv6 interface address in an intra-area-prefix-LSA originated for the virtual link's transit area (see Section 4.4.3.9 and Section 4.8.1).
o 同様に、Virtual NeighborのIPv6アドレスは、グローバルスコープを備えたIPv6アドレスです。ルーティング計算中に仮想近隣のIPv6アドレスを発見できるようにするために、近隣は、仮想リンクのトランジットエリアで発信されたエリア内-PREFIX-LSAで仮想リンクのIPv6インターフェイスアドレスを宣伝します（セクション4.4.3.9およびセクション4.8を参照してください。1）。
o Like all other IPv6 OSPF interfaces, virtual links are assigned unique (within the router) Interface IDs. These are advertised in Hellos sent over the virtual link and in the router's router-LSAs.
o 他のすべてのIPv6 OSPFインターフェイスと同様に、仮想リンクは一意（ルーター内）インターフェイスIDを割り当てられます。これらは、仮想リンクを介して送信されたHellosとルーターのルーターLSAで宣伝されています。
The IPv6 OSPF routing calculation proceeds along the same lines as the IPv4 OSPF routing calculation, following the five steps specified by Section 16 of [OSPFV2]. High-level differences between the IPv6 and IPv4 calculations include:
IPv6 OSPFルーティング計算は、[OSPFV2]のセクション16で指定された5つのステップに従って、IPv4 OSPFルーティング計算と同じ行に沿って進みます。IPv6とIPv4の計算の間の高レベルの違いは次のとおりです。
o Prefix information has been removed from router-LSAs and network-LSAs and is now advertised in intra-area-prefix-LSAs. Whenever [OSPFV2] specifies that stub networks within router-LSAs be examined, IPv6 will instead examine prefixes within intra-area-prefix-LSAs.
o プレフィックス情報はRouter-LSASおよびネットワークLSAから削除されており、現在はAREA-Prefix-LSASで宣伝されています。[OSPFV2]がルーターLSA内のスタブネットを調べることを指定するたびに、IPv6は代わりにエリア内-Prefix-LSA内の接頭辞を調べます。
o Type 3 and 4 summary-LSAs have been renamed inter-area-prefix-LSAs and inter-area-router-LSAs respectively.
o タイプ3および4の要約LSAは、それぞれエリア間型LSAとエリア間ルーターLSAと改名されています。
o Addressing information is no longer encoded in Link State IDs and is now only found within the body of LSAs.
o アドレス指定情報は、リンク状態IDでエンコードされなくなり、LSAの本体内でのみ見つかります。
o In IPv6, a router can originate multiple router-LSAs, distinguished by Link State ID, within a single area. These router-LSAs MUST be treated as a single aggregate by the area's shortest-path calculation (see Section 4.8.1).
o IPv6では、ルーターは、単一の領域内で、リンク状態IDによって区別される複数のルーターLSAを発信できます。これらのルーターLSAは、この地域の最短パス計算によって単一の骨材として扱わなければなりません（セクション4.8.1を参照）。
For each area, the shortest-path tree calculation creates routing table entries for the area's routers and transit links (see Section 4.8.1). These entries are then used when processing intra-area-prefix-LSAs, inter-area-prefix-LSAs, and inter-area-router-LSAs, as described in Section 4.8.3.
各領域について、最短パスツリー計算により、エリアのルーターとトランジットリンクのルーティングテーブルエントリが作成されます（セクション4.8.1を参照）。セクション4.8.3で説明されているように、これらのエントリは、エリア内型LSA、エリア間型LSA、およびエリア間ルーターLSASを処理するときに使用されます。
Events generated as a result of routing table changes (Section 16.7 of [OSPFV2]) and the equal-cost multipath logic (Section 16.8 of [OSPFV2]) are identical for both IPv4 and IPv6.
ルーティングテーブルの変更の結果として生成されたイベント（[OSPFV2]のセクション16.7）および等しいマルチパスロジック（[OSPFV2]のセクション16.8）は、IPv4とIPv6の両方で同一です。
The IPv4 shortest-path calculation is contained in Section 16.1 of [OSPFV2]. The graph used by the shortest-path tree calculation is identical for both IPv4 and IPv6. The graph's vertices are routers and transit links, represented by router-LSAs and network-LSAs respectively. A router is identified by its OSPF Router ID, while a transit link is identified by its Designated Router's Interface ID and OSPF Router ID. Both routers and transit links have associated routing table entries within the area (see Section 4.3).
IPv4最短パス計算は、[OSPFV2]のセクション16.1に含まれています。最も短いパスツリーの計算で使用されるグラフは、IPv4とIPv6の両方で同じです。グラフの頂点は、ルーターとネットワークLSAでそれぞれ表されるルーターとトランジットリンクです。ルーターはOSPFルーターIDによって識別され、指定されたルーターのインターフェイスIDおよびOSPFルーターIDによってトランジットリンクが識別されます。ルーターとトランジットリンクの両方に、エリア内のルーティングテーブルエントリが関連付けられています（セクション4.3を参照）。
Section 16.1 of [OSPFV2] splits up the shortest-path calculations into two stages. First, the Dijkstra calculation is performed, and then the stub links are added onto the tree as leaves. The IPv6 calculation maintains this split.
[OSPFV2]のセクション16.1は、最短パスの計算を2つの段階に分割します。最初に、Dijkstraの計算が実行され、次にスタブリンクが葉としてツリーに追加されます。IPv6計算は、この分割を維持します。
The Dijkstra calculation for IPv6 is identical to that specified for IPv4, with the following exceptions (referencing the steps from the Dijkstra calculation as described in Section 16.1 of [OSPFV2]):
IPv6のDijkstra計算は、次の例外を除いて、IPv4で指定されたものと同一です（[OSPFV2]のセクション16.1で説明されているDijkstra計算の手順を参照）：
o The Vertex ID for a router is the OSPF Router ID. The Vertex ID for a transit network is a combination of the Interface ID and OSPF Router ID of the network's Designated Router.
o ルーターの頂点IDはOSPFルーターIDです。トランジットネットワークの頂点IDは、ネットワークの指定ルーターのインターフェイスIDとOSPFルーターIDの組み合わせです。
o In Step 2, when a router Vertex V has just been added to the shortest-path tree, there may be multiple LSAs associated with the router. All router-LSAs with the Advertising Router set to V's OSPF Router ID MUST be processed as an aggregate, treating them as fragments of a single large router-LSA. The Options field and the router type bits (bits Nt, V, E, and B) should always be taken from the router-LSA with the smallest Link State ID.
o ステップ2では、ルーター頂点Vが最短パスツリーに追加されたばかりの場合、ルーターに関連付けられている複数のLSAがある場合があります。VのOSPFルーターIDに設定された広告ルーターを備えたすべてのルーターLSAは、集計として処理され、単一の大きなルーターLSAのフラグメントとして扱う必要があります。オプションフィールドとルータータイプビット（ビットNT、V、E、およびB）は、常に最小のリンク状態IDを使用してルーター-LSAから取得する必要があります。
o Step 2a is not needed in IPv6, as there are no longer stub network links in router-LSAs.
o Router-LSAにはスタブネットワークリンクがなくなったため、IPv6ではステップ2aは必要ありません。
o In Step 2b, if W is a router and the router-LSA V6-bit or R-bit is not set in the LSA options, the transit link W is ignored and V's next link is examined.
o ステップ2Bでは、Wがルーターであり、ルーターLSA V6ビットまたはRビットがLSAオプションに設定されていない場合、トランジットリンクWは無視され、Vの次のリンクが調べられます。
o In Step 2b, if W is a router, there may again be multiple LSAs associated with the router. All router-LSAs with the Advertising Router set to W's OSPF Router ID MUST be processed as an aggregate, treating them as fragments of a single large router-LSA.
o ステップ2Bでは、Wがルーターの場合、ルーターに関連付けられた複数のLSAが再び存在する場合があります。WのOSPFルーターIDに設定された広告ルーターを備えたすべてのルーターLSAは、集計として処理する必要があり、それらを単一の大きなルーターLSAのフラグメントとして扱う必要があります。
o In Step 4, there are now per-area routing table entries for each of an area's routers rather than just the area border routers. These entries subsume all the functionality of IPv4's area border router routing table entries, including the maintenance of virtual links. When the router added to the area routing table in this step is the other end of a virtual link, the virtual neighbor's IP address is set as follows: The collection of intra-area-prefix-LSAs originated by the virtual neighbor is examined, with the virtual neighbor's IP address being set to the first prefix encountered with the LA-bit set.
o ステップ4には、エリアボーダールーターだけでなく、エリアの各ルーターのエリアごとのルーティングテーブルエントリがあります。これらのエントリは、仮想リンクのメンテナンスを含むIPv4のエリアボーダールータールーティングテーブルエントリのすべての機能を覆います。このステップのエリアルーティングテーブルに追加されたルーターが仮想リンクのもう一方の端である場合、仮想近隣のIPアドレスは次のように設定されます。仮想隣接のIPアドレスは、LAビットセットで遭遇した最初のプレフィックスに設定されています。
o Routing table entries for transit networks, which are no longer associated with IP networks, are also calculated in Step 4 and added to the per-area routing table.
o IPネットワークに関連付けられなくなったトランジットネットワークのルーティングテーブルエントリもステップ4で計算され、エリアごとのルーティングテーブルに追加されます。
The next stage of the shortest-path calculation proceeds similarly to the two steps of the second stage of Section 16.1 in [OSPFV2]. However, instead of examining the stub links within router-LSAs, the list of the area's intra-area-prefix-LSAs is examined. A prefix advertisement whose NU-bit is set SHOULD NOT be included in the routing calculation. The cost of any advertised prefix is the sum of the prefix's advertised metric plus the cost to the transit vertex (either router or transit network) identified by intra-area-prefix-LSA's Referenced LS Type, Referenced Link State ID, and Referenced Advertising Router fields. This latter cost is stored in the transit vertex's routing table entry for the area.
最短パス計算の次の段階は、[OSPFV2]のセクション16.1の第2段階の2つのステップと同様に進みます。ただし、ルーターLSA内のスタブリンクを調べる代わりに、エリア内のエリア内型LSAのリストを調べます。NUビットが設定されているプレフィックス広告は、ルーティング計算に含めないでください。宣伝されているプレフィックスのコストは、プレフィックスの宣伝されたメトリックの合計と、エリア内で参照されたLSタイプ、参照される広告Routerで参照されているLSタイプによって識別されるトランジット頂点（ルーターまたはトランジットネットワーク）のコストの合計です。田畑。この後者のコストは、エリアのトランジット頂点のルーティングテーブルエントリに保存されます。
This specification does not require that the above algorithm be used to calculate the intra-area shortest-path tree. However, if another algorithm or optimization is used, an identical shortest-path tree must be produced. It is also important that any alternate algorithm or optimization maintain the requirement that transit vertices must be bidirectional for inclusion in the tree. Alternate algorithms and optimizations are beyond the scope of this specification.
この仕様では、上記のアルゴリズムを使用して、エリア内で最も短いパスツリーを計算する必要はありません。ただし、別のアルゴリズムまたは最適化が使用される場合、同一の最短パスツリーを作成する必要があります。また、代替アルゴリズムまたは最適化が、ツリーに含めるためにトランジット頂点が双方向でなければならないという要件を維持することも重要です。代替アルゴリズムと最適化は、この仕様の範囲を超えています。
In IPv6, the calculation of the next-hop's IPv6 address (which will be a link-local address) proceeds along the same lines as the IPv4 next-hop calculation (see Section 16.1.1 of [OSPFV2]). However, there are some differences. When calculating the next-hop IPv6 address for a router (call it Router X) that shares a link with the calculating router, the calculating router assigns the next-hop IPv6 address to be the link-local interface address contained in Router X's link-LSA (see Appendix A.4.9) for the link. This procedure is necessary for some link types, for example NBMA, where the two routers need not be neighbors and might not be exchanging OSPF Hello packets. For other link types, the next-hop address may be determined via the IPv6 source address in the neighbor's Hello packet.
IPv6では、Next-HopのIPv6アドレスの計算（Link-Localアドレスになります）は、IPv4 Next-Hop計算と同じ行に沿って進みます（[OSPFV2]のセクション16.1.1を参照）。ただし、いくつかの違いがあります。計算ルーターとリンクを共有するルーター（ルーターXを呼び出す）のネクストホップIPv6アドレスを計算するとき、計算ルーターは、Next-HOP IPv6アドレスをルーターXのリンクに含まれるリンクローカルインターフェイスアドレスに割り当てます。リンクについては、LSA（付録A.4.9を参照）。この手順は、2つのルーターが隣人ではなく、OSPFハローパケットを交換していない場合があるNBMAなどのリンクタイプに必要です。他のリンクタイプの場合、Next-Hopアドレスは、NeighborのHello PacketのIPv6ソースアドレスを介して決定できます。
Additionally, when calculating routes for the area's intra-area-prefix-LSAs, the parent vertex can be either a router-LSA or network-LSA. This is in contrast to the second stage of the OSPFv2 intra-area SPF (Section 16.1 in [OSPFV2]) where the parent vertex is always a router-LSA. In the case where the intra-area-prefix-LSA's referenced LSA is a directly connected network-LSA, the prefixes are also considered to be directly connected. In this case, the next hop is solely the outgoing link and no IPv6 next-hop address is selected.
さらに、エリア内のエリア内型LSASのルートを計算する場合、親の頂点はルーターLSAまたはネットワークLSAのいずれかになります。これは、親の頂点が常にルーター-LSAであるOSPFV2エリア内SPF（[OSPFV2]のセクション16.1）の第2段階とは対照的です。A-AREA-Prefix-LSAの参照されたLSAが直接接続されたネットワークLSAである場合、プレフィックスも直接接続されていると見なされます。この場合、次のホップは発信リンクのみであり、IPv6 Next-Hopアドレスは選択されていません。
Calculation of inter-area routes for IPv6 proceeds along the same lines as the IPv4 calculation in Section 16.2 of [OSPFV2], with the following modifications:
IPv6のエリア間ルートの計算は、[OSPFv2]のセクション16.2のIPv4計算と同じ線に沿って進行し、次の修正を伴います。
o The names of the Type 3 summary-LSAs and Type 4 summary-LSAs have been changed to inter-area-prefix-LSAs and inter-area-router-LSAs respectively.
o タイプ3の要約LSAとタイプ4の要約LSAの名前は、それぞれエリア間型LSAとエリア間LSAに変更されています。
o The Link State ID of the above LSA types no longer encodes the network or router described by the LSA. Instead, an address prefix is contained in the body of an inter-area-prefix-LSA and an advertised AS boundary router's OSPF Router ID is carried in the body of an inter-area-router-LSA.
o 上記のLSAタイプのリンク状態IDは、LSAによって記述されたネットワークまたはルーターをエンコードしなくなりました。代わりに、アドレスのプレフィックスは、エリア間型LSAの本文に含まれており、境界ルーターのOSPFルーターIDとして宣伝されているものは、エリア間ルーターLSAの本体に運ばれます。
o Prefixes having the NU-bit set in their PrefixOptions field should be ignored by the inter-area route calculation.
o 接頭辞フィールドフィールドにnu-bitセットを持つプレフィックスは、エリア間ルートの計算で無視する必要があります。
When a single inter-area-prefix-LSA or inter-area-router-LSA has changed, the incremental calculations outlined in Section 16.5 of [OSPFV2] can be performed instead of recalculating the entire routing table.
単一のエリア間 - プレフィックスLSAまたはエリア間ルーターLSAが変更された場合、[OSPFV2]のセクション16.5で概説されている増分計算を実行することができます。
Examination of transit areas' summary-LSAs in IPv6 proceeds along the same lines as the IPv4 calculation in Section 16.3 of [OSPFV2], modified in the same way as the IPv6 inter-area route calculation in Section 4.8.3.
IPv6の輸送エリアの概要LSAの調査は、[OSPFV2]のセクション16.3のIPv4計算と同じ線に沿って進行します。
The IPv6 AS external route calculation proceeds along the same lines as the IPv4 calculation in Section 16.4 of [OSPFV2] and Section 2.5 of [NSSA], with the following exceptions:
外部ルート計算としてのIPv6は、[NSSA]の[OSPFV2]のセクション16.4およびセクション2.5のIPv4計算と同じ行に沿って進みます。
o The Link State ID of the AS-external-LSA and NSSA-LSA types no longer encodes the network described by the LSA. Instead, an address prefix is contained in the body of the LSA.
o As-External-LSAおよびNSSA-LSA型のリンク状態IDは、LSAによって記述されたネットワークをエンコードしなくなりました。代わりに、アドレスプレフィックスはLSAの本体に含まれています。
o The default route in AS-external-LSAs or NSSA-LSAs is advertised by a zero-length prefix.
o As-External-LSASまたはNSSA-LSAのデフォルトルートは、ゼロ長のプレフィックスで宣伝されています。
o Instead of comparing the AS-external-LSA's or NSSA-LSA's Forwarding Address field to 0.0.0.0 to see whether a forwarding address has been used, the bit F in the respective LSA is examined. A forwarding address is in use if and only if bit F is set.
o As-External-LSAまたはNSSA-LSAの転送アドレスフィールドを0.0.0.0に比較する代わりに、転送アドレスが使用されているかどうかを確認すると、それぞれのLSAのビットFが調べられます。ビットFが設定されている場合にのみ、転送アドレスが使用されています。
o Prefixes having the NU-bit set in their PrefixOptions field should be ignored by the inter-area route calculation.
o 接頭辞フィールドフィールドにnu-bitセットを持つプレフィックスは、エリア間ルートの計算で無視する必要があります。
o AS Boundary Router (ASBR) and forwarding address selection will proceed the same as if RFC1583Compatibility is disabled. Furthermore, RFC1583Compatibility is not an OSPF for IPv6 configuration parameter. Refer to Appendix C.1.
o 境界ルーター（ASBR）および転送アドレスの選択は、RFC1583Compativibilityが無効になっている場合と同じで進行します。さらに、RFC1583CompatibilityはIPv6構成パラメーターのOSPFではありません。付録C.1を参照してください。
When a single AS-external-LSA or NSSA-LSA has changed, the incremental calculations outlined in Section 16.6 of [OSPFV2] can be performed instead of recalculating the entire routing table.
単一のas-pernal-lsaまたはnssa-lsaが変更された場合、ルーティングテーブル全体を再計算する代わりに、[OSPFV2]のセクション16.6で概説した増分計算を実行できます。
In OSPF for IPv6, a router may have multiple interfaces to a single link associated with the same OSPF instance and area. All interfaces will be used for the reception and transmission of data traffic while only a single interface sends and receives OSPF control traffic. In more detail:
IPv6のOSPFでは、ルーターには、同じOSPFインスタンスと領域に関連付けられた単一のリンクへの複数のインターフェイスがある場合があります。すべてのインターフェイスは、データトラフィックの受信と送信に使用されますが、単一のインターフェイスのみがOSPF制御トラフィックを送信および受信します。さらに詳細に：
o Each of the multiple interfaces is assigned a different Interface ID. A router will automatically detect that multiple interfaces are attached to the same link when a Hello packet is received with one of the router's link-local addresses as the source address and an Interface ID other than the Interface ID of the receiving interface.
o 複数のインターフェイスのそれぞれには、異なるインターフェイスIDが割り当てられます。ルーターは、Routerのリンクローカルアドレスの1つをソースアドレスとインターフェイスID以外のインターフェイスID以外のインターフェイスIDでHelloパケットが受信したときに、複数のインターフェイスが同じリンクに接続されていることを自動的に検出します。
o Each of the multiple interfaces MUST be configured with the same Interface Instance ID to be considered on the same link. If an interface has multiple Instance IDs, it will be grouped with other interfaces based on matching Instance IDs. Each Instance ID will be treated uniquely with respect to groupings of multiple interfaces on the same link. For example, if interface A is configured with Instance IDs 1 and 35, and interface B is configured with Instance ID 35, interface B may be the Active Interface for Instance ID 35 but interface A will be active for Instance ID 1.
o 同じリンクで考慮されるように、同じインターフェイスインスタンスIDで複数のインターフェイスを構成する必要があります。インターフェイスに複数のインスタンスIDがある場合、一致するインスタンスIDに基づいて他のインターフェイスとグループ化されます。各インスタンスIDは、同じリンク上の複数のインターフェイスのグループ化に関して一意に扱われます。たとえば、インターフェイスAがインスタンスID 1および35で構成され、インターフェイスBがインスタンスID 35で構成されている場合、インターフェイスBはたとえばID 35のアクティブインターフェイスにすることができますが、インターフェイスAはID 1のアクティブになります。
o The router will ignore OSPF packets other than Hello packets on all but one of the interfaces attached to the link. It will only send its OSPF control packets (including Hello packets) on a single interface. This interface is designated the Active Interface and other interfaces attached to the same link will be designated Standby Interfaces. The choice of the Active Interface is implementation dependent. For example, the interface with the highest Interface ID could be chosen. If the router is elected Designated Router, it will be the Active Interface's Interface ID that will be used as the network-LSA's Link State ID.
o ルーターは、リンクに接続されたインターフェイスの1つを除くすべてのハローパケット以外のOSPFパケットを無視します。OSPFコントロールパケット（ハローパケットを含む）を単一のインターフェイスに送信します。このインターフェイスは、アクティブなインターフェイスに指定され、同じリンクに接続されている他のインターフェイスは、指定されたスタンバイインターフェイスになります。アクティブインターフェイスの選択は実装依存です。たとえば、最高のインターフェイスIDを持つインターフェイスを選択できます。ルーターが指定されたルーターに選出された場合、それはNetwork-LSAのリンク状態IDとして使用されるアクティブインターフェイスのインターフェイスIDになります。
o All of the interfaces to the link (Active and Standby) will appear in the router-LSA. In addition, a link-LSA will be generated for each of the interfaces. In this way, all interfaces will be included in OSPF's routing calculations.
o リンクへのすべてのインターフェイス（アクティブおよびスタンバイ）がルーターLSAに表示されます。さらに、各インターフェイスに対してリンクLSAが生成されます。このようにして、すべてのインターフェイスはOSPFのルーティング計算に含まれます。
o Any link-local scope LSAs that are originated for a Standby Interface will be flooded over the Active Interface. If a Standby Interface goes down, then the link-local scope LSAs originated for the Standby Interfaces MUST be flushed on the Active Interface.
o スタンバイインターフェイス用に発信されるリンクローカルスコープLSAは、アクティブなインターフェイスにあふれます。スタンバイインターフェイスがダウンした場合、スタンバイインターフェイス用に発信されたリンクローカルスコープLSAをアクティブなインターフェイスにフラッシュする必要があります。
o Prefixes on Standby Interfaces will be processed the same way as prefixes on the Active Interface. For example, if the router is the DR for the link, the Active Interface's prefixes are included in an intra-area-prefix-LSA which is associated with the Active Interface's network-LSA; prefixes from Standby Interfaces on the link will also be included in that intra-area-prefix LSA. Similarly, if the link is a stub link, then the prefixes for the Active and Standby Interfaces will all be included in the same intra-area-prefix-LSA that is associated with the router-LSA.
o スタンバイインターフェイス上のプレフィックスは、アクティブインターフェイスのプレフィックスと同じ方法で処理されます。たとえば、ルーターがリンクのDRである場合、Active Interfaceのプレフィックスは、アクティブインターフェイスのネットワークLSAに関連付けられているエリア内Prefix-LSAに含まれています。リンク上のスタンバイインターフェイスのプレフィックスも、そのエリア内型LSAに含まれます。同様に、リンクがスタブリンクの場合、アクティブおよびスタンバイインターフェイスのプレフィックスはすべて、ルーターLSAに関連付けられている同じエリア内型LSAに含まれます。
o If the Active Interface fails, a new Active Interface will have to take over. The new Active Interface SHOULD form all new neighbor adjacencies with routers on the link. This failure can be detected when the router's other interfaces to the Active Interface's link cease to hear the router's Hellos or through internal mechanisms, e.g., monitoring the Active Interface's status.
o アクティブなインターフェイスが失敗した場合、新しいアクティブインターフェイスを引き継ぐ必要があります。新しいアクティブインターフェイスは、リンク上のルーターを使用して、すべての新しい隣接隣接を形成する必要があります。この障害は、アクティブインターフェイスのリンクへのルーターの他のインターフェイスが、ルーターのHellosを聞くことをやめたり、アクティブインターフェイスのステータスを監視したりする内部メカニズムを介して停止したときに検出できます。
o If the network becomes partitioned with different local interfaces attaching to different network partitions, multiple interfaces will become Active Interfaces and function independently.
o ネットワークが異なるネットワークパーティションに接続するさまざまなローカルインターフェイスでパーティション化されると、複数のインターフェイスがアクティブなインターフェイスになり、独立して機能します。
o During the SPF calculation when a network-LSA for a network that is directly connected to the root vertex is being examined, all of the multiple interfaces to the link of adjacent router-LSAs must be used in the next-hop calculation. This can be accomplished during the back link check (see Section 16.1, Step 2 (B), in [OSPFV2]) by examining each link of the router-LSA and making a list of the links that point to the network-LSA. The Interface IDs for links in this list are then used to find the corresponding link-LSAs and the link-local addresses used as next hops when installing equal-cost paths in the routing table.
o ルート頂点に直接接続されているネットワークのネットワークLSAが調べられているSPF計算中、隣接するルーターLSAのリンクへのすべての複数のインターフェイスを次のホップ計算で使用する必要があります。これは、ルーターLSAの各リンクを調べ、ネットワークLSAを指すリンクのリストを作成することにより、バックリンクチェック（[OSPFV2]のセクション16.1、ステップ2（b）を参照）で実現できます。このリストのリンクのインターフェイスIDを使用して、対応するリンクLSAと、ルーティングテーブルに等しいコストパスをインストールするときに次のホップとして使用されるリンクローカルアドレスを見つけます。
o The interface state machine is modified to add the state Standby. See Section 4.9.1 for a description of the Standby state.
o インターフェイス状態マシンは、状態のスタンバイを追加するように変更されています。スタンバイ状態の説明については、セクション4.9.1を参照してください。
In this state, the interface is one of multiple interfaces to a link and this interface is designated Standby and is not sending or receiving control packets. The interface will continue to receive the Hello packets sent by the Active Interface. The interface will maintain a timer, the Active Interface Timer, with the same interval as the RouterDeadInterval. This timer will be reset whenever an OSPF Hello packet is received from the Active Interface to the link.
この状態では、インターフェイスはリンクへの複数のインターフェイスの1つであり、このインターフェイスはスタンバイに指定されており、コントロールパケットを送信または受信していません。インターフェイスは、アクティブインターフェイスによって送信されたハローパケットを引き続き受信します。インターフェイスは、RouterDeadIntervalと同じ間隔でタイマーであるアクティブなインターフェイスタイマーを維持します。このタイマーは、OSPFハローパケットがアクティブなインターフェイスからリンクまで受信されるたびにリセットされます。
Two new events are added to the list of events that cause interface state changes: MultipleInterfacesToLink and ActiveInterfaceDead. The descriptions of these events are as follows: MultipleInterfacesToLink An interfaces on the router has received a Hello packet from another interface on the same router. One of the interfaces is designated as the Active Interface and the other interface is designated as a Standby Interface. The Standby Interface transitions to the Standby state.
インターフェイスの状態の変更を引き起こすイベントのリストに2つの新しいイベントが追加されます：MulipthinterfaceStolinkとActiveInterfaceDead。これらのイベントの説明は次のとおりです。MultioninterfaceStolinkルーターのインターフェイスは、同じルーター上の別のインターフェイスからハローパケットを受信しました。インターフェイスの1つはアクティブインターフェイスとして指定され、もう1つのインターフェイスはスタンバイインターフェイスとして指定されます。スタンバイインターフェイスは、スタンバイ状態に移行します。
ActiveInterfaceDead There has been an indication that a Standby Interface is no longer on a link with an Active Interface. The firing of the Active Interface Timer is one indication of this event, as it indicates that the Standby Interface has not received an OSPF Hello packet from the Active Interface for the RouterDeadInterval. Other indications may come from internal notifications, such as the Active Interface being disabled through a configuration change. Any indication internal to the router, such that the router knows the Active Interface is no longer active on the link, can trigger the ActiveInterfaceDead event for a Standby Interface.
ActiveInterFaceDeadスタンバイインターフェイスがアクティブなインターフェイスとのリンク上にないことを示しています。Active Interfaceタイマーの発射は、スタンバイインターフェイスがRouterDeadIntervalのアクティブインターフェイスからOSPFハローパケットを受信していないことを示すため、このイベントの1つの兆候です。その他の適応症は、構成変更を通じて無効になっているアクティブインターフェイスなど、内部通知から生じる場合があります。ルーターの内部の兆候は、ルーターがアクティブなインターフェイスがリンクでアクティブになっていないことを知っているように、スタンバイインターフェイスのアクティブインターフェイスヘッドイベントをトリガーできます。
Interface state machine additions include:
インターフェイス状態マシンの追加には以下が含まれます。
State(s): Waiting, DR Other, Backup, or DR
状態：待っている、Dr other、Backup、またはdr
Event: MultipleInterfacesToLink
イベント：mulipthinterfaceStolink
New state: Standby
新しい状態：スタンバイ
Action: All interface variables are reset and interface timers disabled. Also, all neighbor connections associated with the interface are destroyed. This is done by generating the event KillNbr on all associated neighbors. The Active Interface Timer is started and the interface will listen for OSPF Hello packets from the link's Active Interface.
アクション：すべてのインターフェイス変数はリセットされ、インターフェイスタイマーが無効になります。また、インターフェイスに関連付けられたすべての隣接接続は破壊されます。これは、関連するすべての隣人にイベントKillnbrを生成することによって行われます。Active Interfaceタイマーが開始され、インターフェイスはリンクのアクティブインターフェイスからOSPF Helloパケットをリッスンします。
State(s): Standby
状態：スタンバイ
Event: ActiveInterfaceDead
イベント：ActiveInterFaceDead
New state: Down
新しい状態：ダウン
Action: The Active Interface Timer is first disabled. Then the InterfaceUp event is invoked.
アクション：Active Interfaceタイマーは最初に無効になります。その後、インターフェイスアップイベントが呼び出されます。
Standby Interface State Machine Additions
スタンバイインターフェース状態マシンの追加
When running over IPv6, OSPFv3 relies on the IP Authentication Header (see [IPAUTH]) and the IP Encapsulating Security Payload (see [IPESP]) to ensure integrity and authentication/confidentiality of protocol packets. This is described in [OSPFV3-AUTH].
IPv6を介して実行する場合、OSPFV3はIP認証ヘッダー（[IPAUTH]を参照）とIPカプセル化セキュリティペイロード（[IPSP]を参照）に依存して、プロトコルパケットの整合性と認証/機密性を確保します。これは[ospfv3-auth]で説明されています。
Most OSPFv3 implementations will be running on systems that support multiple protocols with their own independent security assumptions and domains. When IPsec is used to protect OSPFv3 packets, it is important for the implementation to check the IPsec Security Association (SA) and local SA database to ensure the OSPF packet originated from a source that is trusted for OSPFv3. This is required to eliminate the possibility that the packet was authenticated using an SA defined for another protocol running on the same system.
ほとんどのOSPFV3実装は、独自の独立したセキュリティの仮定とドメインを使用して、複数のプロトコルをサポートするシステムで実行されます。IPSECがOSPFV3パケットを保護するために使用される場合、実装がIPSECセキュリティ協会（SA）とローカルSAデータベースをチェックして、OSPFV3に信頼されているソースからOSPFパケットが発生するようにすることが重要です。これは、同じシステムで実行されている別のプロトコルに対して定義されたSAを使用してパケットが認証された可能性を排除するために必要です。
The mechanisms in [OSPFV3-AUTH] do not provide protection against compromised, malfunctioning, or misconfigured routers. Such routers can, either accidentally or deliberately, cause malfunctions affecting the whole routing domain. The reader is encouraged to consult [GENERIC-THREATS] for a more comprehensive description of threats to routing protocols.
[OSPFV3-Auth]のメカニズムは、侵害された、誤動作、または誤解されたルーターに対する保護を提供しません。このようなルーターは、誤ってまたは故意に、ルーティングドメイン全体に影響を与える誤動作を引き起こす可能性があります。読者は、ルーティングプロトコルに対する脅威のより包括的な説明について、[ジェネリック脅威]を参照することをお勧めします。
The Management Information Base (MIB) for OSPFv3 is defined in [OSPFV3-MIB].
OSPFV3の管理情報ベース（MIB）は[OSPFV3-MIB]で定義されています。
Most OSPF for IPv6 IANA considerations are documented in [OSPF-IANA]. IANA has updated the reference for RFC 2740 to this document.
IPv6 IANAの考慮事項のほとんどのOSPFは、[OSPF-Iana]に文書化されています。IANAは、RFC 2740の参照をこのドキュメントに更新しました。
Additionally, this document introduces the following IANA requirements that were not present in [OSPFV3]:
さらに、このドキュメントでは、[OSPFV3]には存在しなかった次のIANA要件を紹介します。
o Reserves the options with the values 0x000040 and 0x000080 for migrated OSPFv2 options in the OSPFv3 Options registry defined in [OSPF-IANA]. For information on the OSPFv3 Options field, refer to Appendix A.2.
o [OSPF-Aiana]で定義されているOSPFV3オプションレジストリの移行されたOSPFV2オプションの値0x000040および0x000080を使用してオプションを留保します。OSPFV3オプションフィールドの詳細については、付録A.2を参照してください。
o Adds the prefix option P-bit with value 0x08 to the OSPFv3 Prefix Options registry defined in [OSPF-IANA]. For information on OSPFv3 Prefix Options, refer to Appendix A.4.1.1.
o [OSPF-AINA]で定義されているOSPFV3プレフィックスオプションレジストリに値0x08を持つプレフィックスオプションPビットを追加します。OSPFV3プレフィックスオプションの詳細については、付録A.4.1.1を参照してください。
o Adds the prefix option DN-bit with value 0x10 to the OSPFv3 Prefix Options registry defined in [OSPF-IANA]. For information on OSPFv3 Prefix Options, refer to Appendix A.4.1.1.
o [OSPF-AINA]で定義されているOSPFV3プレフィックスオプションレジストリに値0x10を持つプレフィックスオプションdn-bitを追加します。OSPFV3プレフィックスオプションの詳細については、付録A.4.1.1を参照してください。
With the deprecation of MOSPF for OSPFv3, the following code points are available for reassignment. Refer to [OSPF-IANA] for information on the respective registries. This document:
OSPFV3のMOSPFの非難により、次のコードポイントが再割り当てに利用可能です。それぞれのレジストリの情報については、[OSPF-AINA]を参照してください。このドキュメント：
o Deprecates the MC-bit with value 0x000004 in the OSPFv3 Options registry.
o OSPFV3オプションレジストリの値0x000004でMCビットを非難します。
o Deprecates Group-membership-LSA with value 6 in OSPFv3 LSA Function Code registry.
o OSPFV3 LSA関数コードレジストリの値6でグループメンバーシップLSAを非難します。
o Deprecates MC-bit with value 0x04 in the OSPFv3 Prefix Options registry.
o OSPFV3プレフィックスオプションレジストリで値0x04でMCビットを非難します。
The W-bit in the OSPFv3 Router Properties has also been deprecated. This requires a new registry for OSPFv3 router properties since it will diverge from the OSPFv2 Router Properties.
OSPFV3ルーター特性のWビットも非推奨されています。これには、OSPFV2ルータープロパティから分岐するため、OSPFV3ルータープロパティの新しいレジストリが必要です。
Registry Name: OSPFv3 Router Properties Registry Reference: RFC 5340 Registration Procedures: Standards Action
レジストリ名：OSPFV3ルータープロパティレジストリリファレンス：RFC 5340登録手順：標準アクション
Registry:
Value Description Reference
------ ------------- ---------
0x01 B-bit RFC 5340
0x02 E-bit RFC 5340
0x04 V-bit RFC 5340
0x08 Deprecated RFC 5340
0x10 Nt-bit RFC 5340
OSPFv3 Router Properties Registry
OSPFV3ルータープロパティレジストリ
The RFC text was produced using Marshall Rose's xml2rfc tool.
RFCテキストは、Marshall RoseのXML2RFCツールを使用して作成されました。
The following individuals contributed comments that were incorporated into this document:
次の個人は、このドキュメントに組み込まれたコメントを提供しました。
o Harold Rabbie for his description of protocol details that needed to be clarified for OSPFv3 NSSA support.
o Harold Rabbieは、OSPFV3 NSSAサポートのために明確にする必要があるプロトコルの詳細について説明してくれました。
o Nic Neate for his pointing out that there needed to be changes for unknown LSA types handling in the processing of Database Description packets.
o データベースの説明パケットの処理で処理されている不明なLSAタイプの変更が必要であることを指摘して、彼が指摘したことを指摘しました。
o Jacek Kwiatkowski for being the first to point out that the V6- and R-bits are not taken into account in the OSPFv3 intra-area SPF calculation.
o jacek kwiatkowskiは、V6およびRビットがOSPFV3およびA-A-AREA SPF計算で考慮されていないことを最初に指摘したことです。
o Michael Barnes recognized that the support for multiple interfaces to a single link was broken (see Section 4.9) and provided the description of the current protocol mechanisms. Abhay Roy reviewed and suggested improvements to the mechanisms.
o マイケル・バーンズは、単一のリンクへの複数のインターフェイスのサポートが壊れていることを認識し（セクション4.9を参照）、現在のプロトコルメカニズムの説明を提供しました。Abhay Royは、メカニズムの改善をレビューし、提案しました。
o Alan Davey reviewed and commented on document revisions.
o Alan Daveyは、文書の改訂についてレビューし、コメントしました。
o Vivek Dubey reviewed and commented on document revisions.
o Vivek Dubeyは、文書の改訂についてレビューし、コメントしました。
o Manoj Goyal and Vivek Dubey complained enough about link-LSAs being unnecessary to compel introduction of the LinkLSASuppression interface configuration parameter.
o Manoj GoyalとVivek Dubeyは、LinkLSASASASASASASASSUPPRESSIONインターフェイス構成パラメーターの導入を強要するのに不要であることについて十分に不満を述べました。
o Manoj Goyal for pointing out that the next-hop calculation for intra-area-prefix-LSAs corresponding to network vertices was unclear.
o ネットワークの頂点に対応するエリア内型LSAの次のホップ計算が不明であることを指摘したManoj Goyal。
o Ramana Koppula reviewed and commented on document revisions.
o Ramana Koppulaは、文書の改訂についてレビューしてコメントしました。
o Paul Wells reviewed and commented on document revisions.
o ポール・ウェルズは、文書の改訂についてレビューし、コメントしました。
o Amir Khan reviewed and commented on document revisions.
o アミール・カーンは、文書の改訂についてレビューし、コメントしました。
o Dow Street and Wayne Wheeler commented on the addition of the DN-bit to OSPFv3.
o Dow StreetとWayne Wheelerは、OSPFV3にDN-BITの追加についてコメントしました。
o Mitchell Erblichs provided numerous editorial comments.
o Mitchell Erblichsは多くの編集コメントを提供しました。
o Russ White provided numerous editorial comments.
o Russ Whiteは多くの編集コメントを提供しました。
o Kashima Hiroaki provided editorial comments.
o 西野hiroakiは編集コメントを提供しました。
o Sina Mirtorabi suggested that OSPFv3 should be aligned with OSPFv2 with respect to precedence and should map it to IPv6 traffic class as specified in RFC 2474. Steve Blake helped with the text.
o Sina Mirtorabiは、OSPFV3を優先順位に関してOSPFV2と整列させ、RFC 2474で指定されているIPv6トラフィッククラスにマッピングする必要があることを提案しました。スティーブブレイクはテキストを支援しました。
o Faraz Shamin reviewed a late version of the document and provided editorial comments.
o Faraz Shaminは、ドキュメントの後期バージョンをレビューし、編集コメントを提供しました。
o Christian Vogt performed the General Area Review Team (Gen-ART) review and provided comments.
o Christian Vogtは、一般的なエリアレビューチーム（Gen-Art）レビューを実行し、コメントを提供しました。
o Dave Ward, Dan Romascanu, Tim Polk, Ron Bonica, Pasi Eronen, and Lars Eggert provided comments during the IESG review. Also, thanks to Pasi for the text in Section 5 relating to routing threats.
o Dave Ward、Dan Romascanu、Tim Polk、Ron Bonica、Pasi Eronen、およびLars Eggertは、IESGレビュー中にコメントを提供しました。また、ルーティングの脅威に関連するセクション5のテキストについては、PASIに感謝します。
[DEMAND] Moy, J., "Extending OSPF to Support Demand Circuits", RFC 1793, April 1995.
[需要] Moy、J。、「需要回路をサポートするためのOSPFの拡張」、RFC 1793、1995年4月。
[DIFF-SERV] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[Diff-Serv] Nichols、K.、Blake、S.、Baker、F。、およびD. Black、「IPv4およびIPv6ヘッダーの差別化されたサービスフィールド（DSフィールド）の定義」、RFC 2474、1998年12月。
[DN-BIT] Rosen, E., Peter, P., and P. Pillay-Esnault, "Using a Link State Advertisement (LSA) Options Bit to Prevent Looping in BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4576, June 2006.
[DN-Bit] Rosen、E.、Peter、P。、およびP. Pillay-Esnault、「Link State Advertisement（LSA）オプションを使用してBGP/MPLS IP仮想ネットワーク（VPNS）のループを防ぐ」、RFC4576、2006年6月。
[INTFMIB] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000.
[intfmib] McCloghrie、K。およびF. Kastenholz、「The Interfaces Group MIB」、RFC 2863、2000年6月。
[IP6ADDR] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[IP6ADDR] Hinden、R。およびS. Deering、「IPバージョン6アドレス指定アーキテクチャ」、RFC 4291、2006年2月。
[IPAUTH] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[IPAUTH] Kent、S。、「IP認証ヘッダー」、RFC 4302、2005年12月。
[IPESP] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[IPESP] Kent、S。、「セキュリティペイロードのカプセル化（ESP）」、RFC 4303、2005年12月。
[IPV4] Postal, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[IPv4] Postal、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[IPv6] Deering、S。and R. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、1998年12月。
[NSSA] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option", RFC 3101, January 2003.
[NSSA] Murphy、P。、「OSPF Not-Sotubby Area（NSSA）オプション」、RFC 3101、2003年1月。
[OSPF-IANA] Kompella, K. and B. Fenner, "IANA Considerations for OSPF", BCP 130, RFC 4940, July 2007.
[Ospf-Iana] Kompella、K。およびB. Fenner、「OSPFのIANA考慮事項」、BCP 130、RFC 4940、2007年7月。
[OSPFV2] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[OSPFV2] Moy、J。、 "OSPFバージョン2"、STD 54、RFC 2328、1998年4月。
[OSPFV3-AUTH] Gupta, M. and N. Melam, "Authentication/ Confidentiality for OSPFv3", RFC 4552, June 2006.
[OSPFV3-Auth] Gupta、M。およびN. Melam、「OSPFV3の認証/機密性」、RFC 4552、2006年6月。
[RFC-KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-Keywords] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[GENERIC-THREATS] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to Routing Protocols", RFC 4593, October 2006.
[Generic-Threats] Barbir、A.、Murphy、S。、およびY. Yang、「ルーティングプロトコルに対する一般的な脅威」、RFC 4593、2006年10月。
[MOSPF] Moy, J., "Multicast Extensions to OSPF", RFC 1584, March 1994.
[Mospf] Moy、J。、「OSPFへのマルチキャスト拡張」、RFC 1584、1994年3月。
[MTUDISC] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[Mtudisc] Mogul、J。およびS. Deering、「Path MTU Discovery」、RFC 1191、1990年11月。
[OPAQUE] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, July 1998.
[Opaque] Coltun、R。、「OSPF Opaque LSAオプション」、RFC 2370、1998年7月。
[OSPFV3] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", RFC 2740, December 1999.
[OSPFV3] Coltun、R.、Ferguson、D。、およびJ. Moy、「OSPF for IPv6」、RFC 2740、1999年12月。
[OSPFV3-MIB] Joyal, D. and V. Manral, "Management Information Base for OSPFv3", Work in Progress, September 2007.
[OSPFV3-MIB] Joyal、D。およびV. Manral、「OSPFV3の管理情報基盤」、2007年9月、作業中。
[SERV-CLASS] Babiarz, J., Chan, K., and F. Baker, "Configuration Guidelines for DiffServ Service Classes", RFC 4594, August 2006.
[サーブクラス] Babiarz、J.、Chan、K。、およびF. Baker、「Diffserv Service Classeの構成ガイドライン」、RFC 4594、2006年8月。
This appendix describes the format of OSPF protocol packets and OSPF LSAs. The OSPF protocol runs directly over the IPv6 network layer. Before any data formats are described, the details of the OSPF encapsulation are explained.
この付録では、OSPFプロトコルパケットとOSPF LSAの形式について説明します。OSPFプロトコルは、IPv6ネットワークレイヤーを直接実行します。データ形式が記載される前に、OSPFカプセル化の詳細について説明します。
Next, the OSPF Options field is described. This field describes various capabilities that may or may not be supported by pieces of the OSPF routing domain. The OSPF Options field is contained in OSPF Hello packets, Database Description packets, and OSPF LSAs.
次に、OSPFオプションフィールドについて説明します。このフィールドは、OSPFルーティングドメインの一部によってサポートされる場合とサポートされている可能性のあるさまざまな機能を説明しています。OSPFオプションフィールドは、OSPFハローパケット、データベース説明パケット、およびOSPF LSAに含まれています。
OSPF packet formats are detailed in Section A.3.
OSPFパケット形式は、セクションA.3で詳細に説明されています。
A description of OSPF LSAs appears in Section A.4. This section describes how IPv6 address prefixes are represented within LSAs, details the standard LSA header, and then provides formats for each of the specific LSA types.
OSPF LSAの説明は、セクションA.4に表示されます。このセクションでは、IPv6アドレスのプレフィックスがLSA内でどのように表現されるか、標準のLSAヘッダーの詳細を説明し、特定のLSAタイプのそれぞれに形式を提供する方法について説明します。
OSPF runs directly over the IPv6's network layer. OSPF packets are therefore encapsulated solely by IPv6 and local data-link headers.
OSPFは、IPv6のネットワークレイヤーを直接実行します。したがって、OSPFパケットは、IPv6およびローカルデータリンクヘッダーのみによってカプセル化されます。
OSPF does not define a way to fragment its protocol packets, and depends on IPv6 fragmentation when transmitting packets larger than the link MTU. If necessary, the length of OSPF packets can be up to 65,535 bytes. The OSPF packet types that are likely to be large (Database Description, Link State Request, Link State Update, and Link State Acknowledgment packets) can usually be split into multiple protocol packets without loss of functionality. This is recommended; IPv6 fragmentation should be avoided whenever possible. Using this reasoning, an attempt should be made to limit the size of OSPF packets sent over virtual links to 1280 bytes unless Path MTU Discovery is being performed [MTUDISC].
OSPFは、プロトコルパケットを断片化する方法を定義せず、Link MTUよりも大きいパケットを送信する場合のIPv6フラグメンテーションに依存します。必要に応じて、OSPFパケットの長さは最大65,535バイトになります。大規模になる可能性のあるOSPFパケットタイプ（データベースの説明、リンク状態要求、リンク状態更新、およびリンク状態確認パケット）は、機能を失うことなく複数のプロトコルパケットに分割できます。これが推奨されます。IPv6の断片化は、可能な限り避ける必要があります。この推論を使用して、Path MTU発見が実行されない限り、仮想リンクを介して送信されるOSPFパケットのサイズを1280バイトに制限する試みを行う必要があります[Mtudisc]。
The other important features of OSPF's IPv6 encapsulation are:
OSPFのIPv6カプセル化の他の重要な機能は次のとおりです。
o Use of IPv6 multicast. Some OSPF messages are multicast when sent over broadcast networks. Two distinct IP multicast addresses are used. Packets sent to these multicast addresses should never be forwarded; they are meant to travel a single hop only. As such, the multicast addresses have been chosen with link-local scope and packets sent to these addresses should have their IPv6 Hop Limit set to 1. b AllSPFRouters This multicast address has been assigned the value FF02::5. All routers running OSPF should be prepared to receive packets sent to this address. Hello packets are always sent to this destination. Also, certain OSPF protocol packets are sent to this address during the flooding procedure.
o IPv6マルチキャストの使用。一部のOSPFメッセージは、ブロードキャストネットワークを介して送信されるとマルチキャストです。2つの異なるIPマルチキャストアドレスが使用されています。これらのマルチキャストアドレスに送信されたパケットは、決して転送されないでください。彼らは単一のホップのみを旅行することを目的としています。そのため、マルチキャストアドレスはリンクローカルスコープで選択されており、これらのアドレスに送信されたパケットはIPv6ホップ制限を1に設定する必要があります。OSPFを実行しているすべてのルーターは、このアドレスに送信されたパケットを受信するために準備する必要があります。こんにちはパケットは常にこの目的地に送信されます。また、洪水手順中に特定のOSPFプロトコルパケットがこのアドレスに送信されます。
AllDRouters This multicast address has been assigned the value FF02::6. Both the Designated Router and Backup Designated Router must be prepared to receive packets destined to this address. Certain OSPF protocol packets are sent to this address during the flooding procedure.
AlldRoutersこのマルチキャストアドレスには、値FF02 :: 6が割り当てられています。指定されたルーターとバックアップ指定されたルーターの両方が、このアドレスに向けられたパケットを受信するために準備する必要があります。特定のOSPFプロトコルパケットは、洪水手順中にこのアドレスに送信されます。
o OSPF is IP protocol 89. This number SHOULD be inserted in the Next Header field of the encapsulating IPv6 header.
o OSPFはIPプロトコル89です。この数値は、カプセル化IPv6ヘッダーの次のヘッダーフィールドに挿入する必要があります。
o The OSPFv2 specification (Appendix A.1 in [OSPFV2]) indicates that OSPF protocol packets are sent with IP precedence set to Internetwork Control (B'110') [IPV4]. If routers in the OSPF routing domain map their IPv6 Traffic Class octet to the Differentiated Services Code Point (DSCP) as specified in [DIFF-SERV], then OSPFv3 packets SHOULD be sent with their DSCP set to CS6 (B'110000'), as specified in [SERV-CLASS]. In networks supporting this mapping, OSPF packets will be given precedence over IPv6 data traffic.
o OSPFV2仕様（[OSPFV2]の付録A.1）は、OSPFプロトコルパケットがIPの優先順位をインターネットワークコントロール（B'110 '）[IPv4]に設定して送信されることを示しています。OSPFルーティングドメインのルーターは、[diff-serv]で指定されているように、IPv6トラフィッククラスのオクテットを差別化されたサービスコードポイント（DSCP）にマッピングする場合、OSPFv3パケットはDSCPセットをCS6（B'110000 '）に送信する必要があります。[サーブクラス]で指定されているとおり。このマッピングをサポートするネットワークでは、OSPFパケットがIPv6データトラフィックよりも優先されます。
The 24-bit OSPF Options field is present in OSPF Hello packets, Database Description packets, and certain LSAs (router-LSAs, network-LSAs, inter-area-router-LSAs, and link-LSAs). The Options field enables OSPF routers to support (or not support) optional capabilities, and to communicate their capability level to other OSPF routers. Through this mechanism, routers of differing capabilities can be mixed within an OSPF routing domain.
24ビットOSPFオプションフィールドは、OSPF Hello Packets、データベース説明パケット、および特定のLSA（Router-LSA、Network-LSA、Inter-Area-Router-LSA、およびLink-LSA）に存在します。オプションフィールドにより、OSPFルーターはオプションの機能をサポート（またはサポートしていない）ことを可能にし、その機能レベルを他のOSPFルーターと通信できます。このメカニズムを通じて、異なる機能のルーターはOSPFルーティングドメイン内で混合できます。
An option mismatch between routers can cause a variety of behaviors, depending on the particular option. Some option mismatches prevent neighbor relationships from forming (e.g., the E-bit below); these mismatches are discovered through the sending and receiving of Hello packets. Some option mismatches prevent particular LSA types from being flooded across adjacencies; these are discovered through the sending and receiving of Database Description packets. Some option mismatches prevent routers from being included in one or more of the various routing calculations because of their reduced functionality; these mismatches are discovered by examining LSAs.
ルーター間のオプションの不一致は、特定のオプションに応じて、さまざまな動作を引き起こす可能性があります。いくつかのオプションの不一致により、隣人の関係が形成されないようになります（例：以下のeビット）。これらの不一致は、ハローパケットの送信と受信を通じて発見されます。一部のオプションの不一致により、特定のLSAタイプが隣接を越えてあふれないようにします。これらは、データベースの説明パケットの送信と受信を通じて発見されます。いくつかのオプションの不一致により、機能が低下しているため、ルーターがさまざまなルーティング計算の1つ以上に含まれないようにします。これらの不一致は、LSAを調べることによって発見されます。
Seven bits of the OSPF Options field have been assigned. Each bit is described briefly below. Routers should reset (i.e., clear) unrecognized bits in the Options field when sending Hello packets or Database Description packets and when originating LSAs. Conversely, routers encountering unrecognized Options bits in received Hello packets, Database Description packets, or LSAs should ignore the unrecognized bits and process the packet or LSA normally.
OSPFオプションフィールドの7ビットが割り当てられています。各ビットについては、以下で簡単に説明します。ルーターは、ハローパケットまたはデータベースの説明パケットを送信するとき、およびLSAを発信するときに、オプションフィールドに認識されていないビットをリセットする（つまり、クリア）する必要があります。逆に、受信したハローパケット、データベースの説明パケット、またはLSAで認識されていないオプションビットに遭遇するルーターは、認識されていないビットを無視し、パケットまたはLSAを通常処理する必要があります。
1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+--+--+
| | | | | | | | | | | | | | | | |*|*|DC|R|N|x| E|V6|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+--+--+
The Options field
オプションフィールド
The Options field
オプションフィールド
V6-bit If this bit is clear, the router/link should be excluded from IPv6 routing calculations. See Section 4.8 for details.
V6ビットこのビットがクリアする場合、ルーター/リンクはIPv6ルーティング計算から除外する必要があります。詳細については、セクション4.8を参照してください。
E-bit This bit describes the way AS-external-LSAs are flooded, as described in Sections 3.6, 9.5, 10.8, and 12.1.2 of [OSPFV2].
e-bitこのビットは、[OSPFV2]のセクション3.6、9.5、10.8、および12.1.2で説明されているように、As-External-LSAが浸水する方法を説明しています。
x-Bit This bit was previously used by MOSPF (see [MOSPF]), which has been deprecated for OSPFv3. The bit should be set to 0 and ignored when received. It may be reassigned in the future.
X-Bitこのビットは、以前はMOSPF（[MOSPF]を参照）で使用されていました。ビットは0に設定し、受け取ったときに無視する必要があります。それは将来再割り当てされるかもしれません。
N-bit This bit indicates whether or not the router is attached to an NSSA as specified in [NSSA].
n-bitこのビットは、[NSSA]で指定されているように、ルーターがNSSAに取り付けられているかどうかを示します。
R-bit This bit (the `Router' bit) indicates whether the originator is an active router. If the router bit is clear, then routes that transit the advertising node cannot be computed. Clearing the router bit would be appropriate for a multi-homed host that wants to participate in routing, but does not want to forward non-locally addressed packets.
rビットこのビット（「ルーター」ビット）は、オリジネーターがアクティブルーターであるかどうかを示します。ルータービットがクリアされている場合、広告ノードをトランジットするルーティングは計算できません。ルータービットをクリアすることは、ルーティングに参加したいが、対立的ではないパケットを転送したくないマルチホームホストに適しています。
DC-bit This bit describes the router's handling of demand circuits, as specified in [DEMAND].
DCビットこのビットは、[需要]で指定されているように、ルーターの需要回路の処理について説明しています。
*-bit These bits are reserved for migration of OSPFv2 protocol extensions.
* - これらのビットは、OSPFV2プロトコル拡張の移行のために予約されています。
There are five distinct OSPF packet types. All OSPF packet types begin with a standard 16-byte header. This header is described first. Each packet type is then described in a succeeding section. In these sections, each packet's format is displayed and the packet's component fields are defined.
5つの異なるOSPFパケットタイプがあります。すべてのOSPFパケットタイプは、標準の16バイトヘッダーで始まります。このヘッダーについて最初に説明します。各パケットタイプは、後続のセクションで説明されています。これらのセクションでは、各パケットの形式が表示され、パケットのコンポーネントフィールドが定義されています。
All OSPF packet types (other than the OSPF Hello packets) deal with lists of LSAs. For example, Link State Update packets implement the flooding of LSAs throughout the OSPF routing domain. The format of LSAs is described in Section A.4.
すべてのOSPFパケットタイプ（OSPFハローパケット以外）は、LSAのリストを扱います。たとえば、Link State Updateパケットは、OSPFルーティングドメイン全体にLSAの洪水を実装します。LSAの形式については、セクションA. 4で説明します。
The receive processing of OSPF packets is detailed in Section 4.2.2. The sending of OSPF packets is explained in Section 4.2.1.
OSPFパケットの受信処理については、セクション4.2.2で詳しく説明しています。OSPFパケットの送信は、セクション4.2.1で説明されています。
Every OSPF packet starts with a standard 16-byte header. Together with the encapsulating IPv6 headers, the OSPF header contains all the information necessary to determine whether the packet should be accepted for further processing. This determination is described in Section 4.2.2.
すべてのOSPFパケットは、標準の16バイトヘッダーから始まります。IPv6ヘッダーのカプセル化とともに、OSPFヘッダーには、パケットをさらに処理するために受け入れるべきかどうかを判断するために必要なすべての情報が含まれています。この決定は、セクション4.2.2で説明されています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version # | Type | Packet length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Instance ID | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The OSPF Packet Header
OSPFパケットヘッダー
Version # The OSPF version number. This specification documents version 3 of the OSPF protocol.
バージョン＃OSPFバージョン番号。この仕様は、OSPFプロトコルのバージョン3を文書化します。
Type The OSPF packet types are as follows. See Appendix A.3.2 through Appendix A.3.6 for details.
タイプOSPFパケットタイプは次のとおりです。詳細については、付録A.3.2から付録A.3.6をご覧ください。
Type Description
---------------------------------
1 Hello
2 Database Description
3 Link State Request
4 Link State Update
5 Link State Acknowledgment
Packet length The length of the OSPF protocol packet in bytes. This length includes the standard OSPF header.
パケットの長さバイト単位のOSPFプロトコルパケットの長さ。この長さには、標準のOSPFヘッダーが含まれます。
Router ID The Router ID of the packet's source.
ルーターIDパケットのソースのルーターID。
Area ID A 32-bit number identifying the area to which this packet belongs. All OSPF packets are associated with a single area. Most travel a single hop only. Packets traversing a virtual link are labeled with the backbone Area ID of 0.
エリアIDこのパケットが属する領域を識別する32ビット番号。すべてのOSPFパケットは、単一の領域に関連付けられています。ほとんどの人は単一のホップのみを移動します。仮想リンクをトラバースするパケットは、0のバックボーン領域IDにラベル付けされています。
Checksum OSPF uses the standard checksum calculation for IPv6 applications: The 16-bit one's complement of the one's complement sum of the entire contents of the packet, starting with the OSPF packet header, and prepending a "pseudo-header" of IPv6 header fields, as specified in Section 8.1 of [IPV6]. The "Upper-Layer Packet Length" in the pseudo-header is set to the value of the OSPF packet header's length field. The Next Header value used in the pseudo-header is 89. If the packet's length is not an integral number of 16-bit words, the packet is padded with a byte of zero before checksumming. Before computing the checksum, the checksum field in the OSPF packet header is set to 0.
チェックサムOSPFは、IPv6アプリケーションの標準チェックサム計算を使用します。OSPFパケットヘッダーから始まり、IPv6ヘッダーフィールドの「擬似ヘッダー」の準備を開始するパケットの内容全体の16ビットの補完合計を補完する16ビットの補体を使用します。[IPv6]のセクション8.1で指定されているとおり。擬似ヘッダーの「上層層パケット長」は、OSPFパケットヘッダーの長さフィールドの値に設定されています。Pseudo-Headerで使用される次のヘッダー値は89です。パケットの長さが16ビットの単語の積分数でない場合、パケットはチェックサムの前にゼロのバイトでパディングされます。チェックサムを計算する前に、OSPFパケットヘッダーのチェックサムフィールドは0に設定されています。
Instance ID Enables multiple instances of OSPF to be run over a single link. Each protocol instance would be assigned a separate Instance ID; the Instance ID has link-local significance only. Received packets whose Instance ID is not equal to the receiving interface's Instance ID are discarded.
インスタンスIDを使用すると、OSPFの複数のインスタンスを単一のリンクで実行できます。各プロトコルインスタンスには、個別のインスタンスIDが割り当てられます。インスタンスIDには、リンクローカルの重要性のみがあります。インスタンスIDが受信インターフェイスのインスタンスIDに等しくない受信パケットが破棄されます。
0 These fields are reserved. They SHOULD be set to 0 when sending protocol packets and MUST be ignored when receiving protocol packets.
0これらのフィールドは予約されています。プロトコルパケットを送信するときに0に設定する必要があり、プロトコルパケットを受信するときは無視する必要があります。
Hello packets are OSPF packet type 1. These packets are sent periodically on all interfaces (including virtual links) in order to establish and maintain neighbor relationships. In addition, Hello packets are multicast on those links having a multicast or broadcast capability, enabling dynamic discovery of neighboring routers.
こんにちはパケットはOSPFパケットタイプ1です。これらのパケットは、近隣の関係を確立および維持するために、すべてのインターフェイス（仮想リンクを含む）で定期的に送信されます。さらに、ハローパケットは、マルチキャストまたはブロードキャスト機能を備えたリンクのマルチキャストであり、隣接するルーターの動的な発見を可能にします。
All routers connected to a common link must agree on certain parameters (HelloInterval and RouterDeadInterval). These parameters are included in Hello packets allowing differences to inhibit the forming of neighbor relationships. The Hello packet also contains fields used in Designated Router election (Designated Router ID and Backup Designated Router ID), and fields used to detect bidirectional communication (the Router IDs of all neighbors whose Hellos have been recently received).
一般的なリンクに接続されているすべてのルーターは、特定のパラメーター（hellointervalおよびrouterdeadeadinterval）に同意する必要があります。これらのパラメーターは、隣接関係の形成を阻害する違いを可能にするハローパケットに含まれています。Hello Packetには、指定されたルーター選挙（指定されたルーターIDおよびバックアップ指定ルーターID）で使用されるフィールド、および双方向通信（最近受け取ったすべての隣人のルーターID）を検出するために使用されるフィールドも含まれています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | 1 | Packet Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Instance ID | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rtr Priority | Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HelloInterval | RouterDeadInterval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Designated Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Backup Designated Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
The OSPF Hello Packet
OSPFハローパケット
Interface ID 32-bit number uniquely identifying this interface among the collection of this router's interfaces. For example, in some implementations it may be possible to use the MIB-II IfIndex ([INTFMIB]).
インターフェースID 32ビット番号このルーターのインターフェイスのコレクション間でこのインターフェイスを一意に識別します。たとえば、いくつかの実装では、MIB-II IFINDEX（[intfmib]）を使用することが可能になる場合があります。
Rtr Priority This router's Router Priority. Used in (Backup) Designated Router election. If set to 0, the router will be ineligible to become (Backup) Designated Router.
RTR優先このルーターのルーターの優先度。（バックアップ）指定ルーター選挙で使用されます。0に設定すると、ルーターは（バックアップ）指定ルーターになる資格がありません。
Options The optional capabilities supported by the router, as documented in Section A.2.
オプションセクションA.2に記載されているように、ルーターによってサポートされるオプションの機能。
HelloInterval The number of seconds between this router's Hello packets.
HelloIntervalこのルーターのハローパケットの間の秒数。
RouterDeadInterval The number of seconds before declaring a silent router down.
RouterDeadIntervalサイレントルーターを宣言する前の秒数。
Designated Router ID The sending router's view of the identity of the Designated Router for this network. The Designated Router is identified by its Router ID. It is set to 0.0.0.0 if there is no Designated Router.
指定ルーターIDこのネットワークの指定されたルーターのアイデンティティの送信ルーターのビュー。指定されたルーターは、ルーターIDによって識別されます。指定されたルーターがない場合、0.0.0.0に設定されます。
Backup Designated Router ID The sending router's view of the identity of the Backup Designated Router for this network. The Backup Designated Router is identified by its IP Router ID. It is set to 0.0.0.0 if there is no Backup Designated Router.
バックアップ指定ルーターIDこのネットワークのバックアップ指定ルーターのIDの送信ルーターのビュー。指定されたルーターは、IPルーターIDによって識別されます。バックアップ指定ルーターがない場合、0.0.0.0に設定されます。
Neighbor ID The Router IDs of each router on the network with neighbor state 1-Way or greater.
ネットワーク上の各ルーターのルーターIDは、隣の状態を1方向以上にします。
Database Description packets are OSPF packet type 2. These packets are exchanged when an adjacency is being initialized. They describe the contents of the link-state database. Multiple packets may be used to describe the database. For this purpose, a poll-response procedure is used. One of the routers is designated to be the master and the other is the slave. The master sends Database Description packets (polls) that are acknowledged by Database Description packets sent by the slave (responses). The responses are linked to the polls via the packets' DD sequence numbers.
データベースの説明パケットはOSPFパケットタイプ2です。これらのパケットは、隣接が初期化されているときに交換されます。リンク状態データベースの内容について説明します。データベースを説明するために複数のパケットを使用できます。この目的のために、投票応答手順が使用されます。ルーターの1つはマスターに指定されており、もう1つは奴隷です。マスターは、Slave（Responses）によって送信されたデータベース説明パケットによって認められるデータベースの説明パケット（世論調査）を送信します。応答は、パケットのDDシーケンス番号を介して投票にリンクされています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+
| 3 | 2 | Packet Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+
| Checksum | Instance ID | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+
| 0 | Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+
| Interface MTU | 0 |0|0|0|0|0|I|M|MS|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+
| DD sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+
| |
+- -+
| |
+- An LSA Header -+
| |
+- -+
| |
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+
| ... |
The OSPF Database Description Packet
OSPFデータベース説明パケット
The format of the Database Description packet is very similar to both the Link State Request packet and the Link State Acknowledgment packet. The main part of all three is a list of items, each item describing a piece of the link-state database. The sending of Database Description packets is documented in Section 10.8 of [OSPFV2]. The reception of Database Description packets is documented in Section 10.6 of [OSPFV2].
データベース説明パケットの形式は、リンク状態要求パケットとリンク状態確認パケットの両方に非常に似ています。3つすべての主要部分はアイテムのリストで、各アイテムはリンク状態データベースの一部を説明しています。データベースの説明パケットの送信は、[OSPFV2]のセクション10.8に文書化されています。データベース説明パケットの受信は、[OSPFV2]のセクション10.6に記載されています。
Options The optional capabilities supported by the router, as documented in Section A.2.
オプションセクションA.2に記載されているように、ルーターによってサポートされるオプションの機能。
Interface MTU The size in bytes of the largest IPv6 datagram that can be sent out the associated interface without fragmentation. The MTUs of common Internet link types can be found in Table 7-1 of [MTUDISC].
インターフェイスMTUは、断片化せずに関連するインターフェイスを送信できる最大のIPv6データグラムのバイトでサイズを使用します。一般的なインターネットリンクタイプのMTUは、[Mtudisc]の表7-1にあります。
Interface MTU should be set to 0 in Database Description packets sent over virtual links.
インターフェイスMTUは、仮想リンクを介して送信されたデータベース説明パケットで0に設定する必要があります。
I-bit The Init bit. When set to 1, this packet is the first in the sequence of Database Description packets.
Initビットをビットします。1に設定すると、このパケットはデータベース説明パケットのシーケンスで最初のものです。
M-bit The More bit. When set to 1, it indicates that more Database Description packets are to follow.
MITが多い。1に設定すると、より多くのデータベース説明パケットが従うことを示します。
MS-bit The Master/Slave bit. When set to 1, it indicates that the router is the master during the Database Exchange process. Otherwise, the router is the slave.
MSビットマスター/スレーブビット。1に設定すると、データベース交換プロセス中にルーターがマスターであることを示します。それ以外の場合、ルーターは奴隷です。
DD sequence number Used to sequence the collection of Database Description packets. The initial value (indicated by the Init bit being set) should be unique. The DD sequence number then increments until the complete database for both the master and slave routers have been exchanged.
データベース説明パケットのコレクションをシーケンスするために使用されるDDシーケンス番号。初期値（設定されているinitビットで示される）は一意でなければなりません。DDシーケンス番号は、マスタールーターとスレーブルーターの両方の完全なデータベースが交換されるまで増加します。
The rest of the packet consists of a (possibly partial) list of the link-state database's pieces. Each LSA in the database is described by its LSA header. The LSA header is documented in Appendix A.4.2. It contains all the information required to uniquely identify both the LSA and the LSA's current instance.
残りのパケットは、リンク状態のデータベースのピースの（おそらく部分的な）リストで構成されています。データベース内の各LSAは、LSAヘッダーによって説明されています。LSAヘッダーは、付録A.4.2に文書化されています。LSAとLSAの現在のインスタンスの両方を一意に識別するために必要なすべての情報が含まれています。
Link State Request packets are OSPF packet type 3. After exchanging Database Description packets with a neighboring router, a router may find that parts of its link-state database are out-of-date. The Link State Request packet is used to request the pieces of the neighbor's database that are more up-to-date. Multiple Link State Request packets may need to be used.
リンク状態リクエストパケットはOSPFパケットタイプ3です。データベースの説明パケットを隣接するルーターと交換した後、ルーターはリンク状態のデータベースの一部が時代遅れであることがわかります。Link State Request Packetは、より最新の近隣のデータベースのピースを要求するために使用されます。複数のリンク状態要求パケットを使用する必要がある場合があります。
A router that sends a Link State Request packet has in mind the precise instance of the database pieces it is requesting. Each instance is defined by its LS sequence number, LS checksum, and LS age, although these fields are not specified in the Link State Request packet itself. The router may receive even more recent LSA instances in response.
リンク状態リクエストパケットを送信するルーターは、要求しているデータベースピースの正確なインスタンスを念頭に置いています。各インスタンスは、LSシーケンス番号、LSチェックサム、およびLS年齢で定義されますが、これらのフィールドはリンク状態要求パケット自体では指定されていません。ルーターは、応答してさらに最近のLSAインスタンスを受信する場合があります。
The sending of Link State Request packets is documented in Section 10.9 of [OSPFV2]. The reception of Link State Request packets is documented in Section 10.7 of [OSPFV2].
リンク状態リクエストパケットの送信は、[OSPFV2]のセクション10.9に文書化されています。Link State Requestパケットの受信は、[OSPFV2]のセクション10.7に記載されています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | 3 | Packet Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Instance ID | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | LS Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
The OSPF Link State Request Packet
OSPFリンク状態リクエストパケット
Each LSA requested is specified by its LS type, Link State ID, and Advertising Router. This uniquely identifies the LSA without specifying its instance. Link State Request packets are understood to be requests for the most recent instance of the specified LSAs.
要求された各LSAは、LSタイプ、リンク状態ID、および広告ルーターによって指定されます。これは、インスタンスを指定せずにLSAを一意に識別します。リンク状態リクエストパケットは、指定されたLSAの最新のインスタンスのリクエストであると理解されています。
Link State Update packets are OSPF packet type 4. These packets implement the flooding of LSAs. Each Link State Update packet carries a collection of LSAs one hop further from their origin. Several LSAs may be included in a single packet.
リンク状態更新パケットは、OSPFパケットタイプ4です。これらのパケットは、LSAの洪水を実装しています。各リンク状態アップデートパケットには、LSAS One Hopのコレクションがその起源からさらに登場します。いくつかのLSAが単一のパケットに含まれる場合があります。
Link State Update packets are multicast on those physical networks that support multicast/broadcast. In order to make the flooding procedure reliable, flooded LSAs are acknowledged in Link State Acknowledgment packets. If retransmission of certain LSAs is necessary, the retransmitted LSAs are always carried by unicast Link State Update packets. For more information on the reliable flooding of LSAs, consult Section 4.5.
リンク状態更新パケットは、マルチキャスト/ブロードキャストをサポートする物理ネットワークのマルチキャストです。洪水手順を信頼できるものにするために、浸水したLSAはLink State Ancoundage Packetで認められています。特定のLSAの再送信が必要な場合、再送信されたLSAは常にユニキャストリンク状態更新パケットによって運ばれます。LSAの信頼できる洪水の詳細については、セクション4.5を参照してください。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | 4 | Packet Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Instance ID | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # LSAs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- +-+
| LSAs |
+- +-+
| ... |
The OSPF Link State Update Packet
OSPFリンク状態更新パケット
# LSAs The number of LSAs included in this update.
＃LSASこのアップデートに含まれるLSAの数。
The body of the Link State Update packet consists of a list of LSAs. Each LSA begins with a common 20-byte header, described in Appendix A.4.2. Detailed formats of the different types of LSAs are described Appendix A.4.
リンク状態更新パケットの本文は、LSAのリストで構成されています。各LSAは、付録A.4.2に記載されている一般的な20バイトヘッダーで始まります。さまざまなタイプのLSAの詳細な形式については、付録A.4について説明します。
Link State Acknowledgment packets are OSPF packet type 5. To make the flooding of LSAs reliable, flooded LSAs are explicitly or implicitly acknowledged. Explicit acknowledgment is accomplished through the sending and receiving of Link State Acknowledgment packets. The sending of Link State Acknowledgment packets is documented in Section 13.5 of [OSPFV2]. The reception of Link State Acknowledgment packets is documented in Section 13.7 of [OSPFV2].
リンク状態の確認パケットは、LSAの洪水を信頼できるものにするために、OSPFパケットタイプ5です。明示的な謝辞は、リンク状態の確認パケットの送信と受信を通じて達成されます。リンク状態の確認パケットの送信は、[OSPFV2]のセクション13.5に文書化されています。Link State Ancoundmentパケットの受信は、[OSPFV2]のセクション13.7に記載されています。
Multiple LSAs MAY be acknowledged in a single Link State Acknowledgment packet. Depending on the state of the sending interface and the sender of the corresponding Link State Update packet, a Link State Acknowledgment packet is sent to the multicast address AllSPFRouters, the multicast address AllDRouters, or to a neighbor's unicast address (see Section 13.5 of [OSPFV2] for details).
複数のLSAは、単一のリンク状態確認パケットで確認される場合があります。送信インターフェイスの状態と対応するリンク状態更新パケットの送信者に応じて、リンク状態確認パケットがマルチキャストアドレスAllSPFRouter、マルチキャストアドレスAlldRouters、または近隣のユニキャストアドレスに送信されます（[ospfv222.5のセクション13.5を参照してください] 詳細については）。
The format of this packet is similar to that of the Data Description packet. The body of both packets is simply a list of LSA headers.
このパケットの形式は、データ説明パケットの形式と似ています。両方のパケットの本体は、単にLSAヘッダーのリストです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | 5 | Packet Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Instance ID | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- -+
| |
+- An LSA Header -+
| |
+- -+
| |
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
The OSPF Link State Acknowledgment Packet
OSPFリンク状態確認パケット
Each acknowledged LSA is described by its LSA header. The LSA header is documented in Appendix A.4.2. It contains all the information required to uniquely identify both the LSA and the LSA's current instance.
認められた各LSAは、LSAヘッダーによって説明されています。LSAヘッダーは、付録A.4.2に文書化されています。LSAとLSAの現在のインスタンスの両方を一意に識別するために必要なすべての情報が含まれています。
This document defines eight distinct types of LSAs. Each LSA begins with a standard 20-byte LSA header. This header is explained in Appendix A.4.2. Succeeding sections describe each LSA type individually.
このドキュメントでは、8つの異なるタイプのLSAを定義します。各LSAは、標準の20バイトLSAヘッダーで始まります。このヘッダーについては、付録A.4.2で説明しています。後続のセクションでは、各LSAタイプを個別に説明します。
Each LSA describes a piece of the OSPF routing domain. Every router originates a router-LSA. A network-LSA is advertised for each link by its Designated Router. A router's link-local addresses are advertised to its neighbors in link-LSAs. IPv6 prefixes are advertised in intra-area-prefix-LSAs, inter-area-prefix-LSAs, AS-external-LSAs, and NSSA-LSAs. Location of specific routers can be advertised across area boundaries in inter-area-router-LSAs. All LSAs are then flooded throughout the OSPF routing domain. The flooding algorithm is reliable, ensuring that all routers common to a flooding scope have the same collection of LSAs associated with that flooding scope. (See Section 4.5 for more information concerning the flooding algorithm.) This collection of LSAs is called the link-state database.
各LSAは、OSPFルーティングドメインの一部について説明します。すべてのルーターはルーター-LSAを起源とします。ネットワークLSAは、指定されたルーターによってリンクごとに宣伝されます。ルーターのLink-Localアドレスは、Link-LSAの近隣に宣伝されています。IPv6プレフィックスは、エリア内-PREFIX-LSA、AS-External-LSAS、およびNSSA-LSASでエリア内で宣伝されています。特定のルーターの位置は、エリア間ルーターLSAのエリア境界を越えて宣伝できます。すべてのLSAは、OSPFルーティングドメイン全体に浸水します。洪水アルゴリズムは信頼性が高く、洪水範囲に共通するすべてのルーターが、その洪水範囲に関連付けられたLSAのコレクションと同じコレクションを持つことを保証します。（洪水アルゴリズムに関する詳細については、セクション4.5を参照してください。）このLSAのコレクションは、Link-Stateデータベースと呼ばれます。
From the link-state database, each router constructs a shortest-path tree with itself as root. This yields a routing table (see Section 11 of [OSPFV2]). For details on the routing table build process, see Section 4.8.
リンク状態のデータベースから、各ルーターは、それ自体がルートとしてより短いパスツリーを構築します。これにより、ルーティングテーブルが生成されます（[OSPFV2]のセクション11を参照）。ルーティングテーブルビルドプロセスの詳細については、セクション4.8を参照してください。
IPv6 addresses are bit strings of length 128. IPv6 routing protocols, and OSPF for IPv6 in particular, advertise IPv6 address prefixes. IPv6 address prefixes are bit strings whose length ranges between 0 and 128 bits (inclusive).
IPv6アドレスは、長さ128のビット文字列です。IPv6ルーティングプロトコル、特にIPv6のOSPFは、IPv6アドレスのプレフィックスを宣伝します。IPv6アドレスのプレフィックスは、長さの範囲が0〜128ビット（包括的）の範囲であるビット文字列です。
Within OSPF, IPv6 address prefixes are always represented by a combination of three fields: PrefixLength, PrefixOptions, and Address Prefix. PrefixLength is the length in bits of the prefix. PrefixOptions is an 8-bit field describing various capabilities associated with the prefix (see Appendix A.4.1.1). Address Prefix is an encoding of the prefix itself as an even multiple of 32-bit words, padding with zero bits as necessary. This encoding consumes ((PrefixLength + 31) / 32) 32-bit words.
OSPF内では、IPv6アドレスプレフィックスは、プレフィックスレングス、プレフィックスオプション、およびアドレスプレフィックスの3つのフィールドの組み合わせで常に表されます。プレフィックスルの長さは、プレフィックスのビットの長さです。プレフィックスオプションは、プレフィックスに関連するさまざまな機能を記述する8ビットフィールドです（付録A.4.1.1を参照）。アドレスプレフィックスは、必要に応じてゼロビットのパディングである32ビット単語の倍数としてプレフィックス自体をエンコードすることです。このエンコード消費量（（prefixLength 31） / 32）32ビット単語。
The default route is represented by a prefix of length 0.
デフォルトルートは、長さ0のプレフィックスで表されます。
Examples of IPv6 Prefix representation in OSPF can be found in Appendix A.4.5, Appendix A.4.7, Appendix A.4.8, Appendix A.4.9, and Appendix A.4.10.
OSPFのIPv6プレフィックス表現の例は、付録A.4.5、付録A.4.7、付録A.4.8、付録A.4.9、および付録A.4.10にあります。
Each prefix is advertised along with an 8-bit field of capabilities. These serve as input to the various routing calculations. For example, they can indicate that prefixes are to be ignored in some cases or are to be marked as not readvertisable in others.
各プレフィックスは、8ビットの機能フィールドとともに宣伝されています。これらは、さまざまなルーティング計算への入力として機能します。たとえば、プレフィックスは場合によっては無視されるか、他の場合には読み込まれないものとしてマークされることを示すことができます。
0 1 2 3 4 5 6 7
+--+--+--+--+--+-+--+--+
| | | |DN| P|x|LA|NU|
+--+--+--+--+--+-+--+--+
The PrefixOptions Field
プレフィックスオプションフィールド
NU-bit The "no unicast" capability bit. If set, the prefix should be excluded from IPv6 unicast calculations. If not set, it should be included.
nu-bit「ユニキャストなし」機能ビット。設定されている場合、プレフィックスはIPv6ユニキャスト計算から除外する必要があります。設定されていない場合は、含める必要があります。
LA-bit The "local address" capability bit. If set, the prefix is actually an IPv6 interface address of the Advertising Router. Advertisement of local interface addresses is described in Section 4.4.3.9. An implementation MAY also set the LA-bit for prefixes advertised with a host PrefixLength (128).
LAビット「ローカルアドレス」機能ビット。設定すると、プレフィックスは実際には広告ルーターのIPv6インターフェイスアドレスです。ローカルインターフェイスアドレスの広告については、セクション4.4.3.9で説明しています。実装は、ホストプレフィックスレングス（128）で宣伝されているプレフィックスのLAビットを設定することもできます。
x-bit This bit was previously defined as a "multicast" capability bit. However, the use was never adequately specified and has been deprecated for OSPFv3. The bit should be set to 0 and ignored when received. It may be reassigned in the future.
X-Bitこのビットは、以前は「マルチキャスト」機能ビットとして定義されていました。ただし、使用は決して適切に指定されておらず、OSPFV3に対して非推奨されています。ビットは0に設定し、受け取ったときに無視する必要があります。それは将来再割り当てされるかもしれません。
P-bit The "propagate" bit. Set on NSSA area prefixes that should be readvertised by the translating NSSA area border [NSSA].
「伝播」ビットをpビットします。翻訳されたNSSAエリアの境界[NSSA]によって読み込まれる必要があるNSSAエリアのプレフィックスに設定します。
DN-bit This bit controls an inter-area-prefix-LSAs or AS-external-LSAs re-advertisement in a VPN environment as specified in [DN-BIT].
dn-bitこのビットは、[dn-bit]で指定されているように、VPN環境でのエリア間型lsasまたはas-fernal-lsasの再承認を制御します。
All LSAs begin with a common 20-byte header. This header contains enough information to uniquely identify the LSA (LS type, Link State ID, and Advertising Router). Multiple instances of the LSA may exist in the routing domain at the same time. It is then necessary to determine which instance is more recent. This is accomplished by examining the LS age, LS sequence number, and LS checksum fields that are also contained in the LSA header.
すべてのLSAは、一般的な20バイトヘッダーで始まります。このヘッダーには、LSA（LSタイプ、リンク状態ID、および広告ルーター）を一意に識別するのに十分な情報が含まれています。LSAの複数のインスタンスがルーティングドメインに同時に存在する可能性があります。その場合、どのインスタンスがより最近のインスタンスを決定する必要があります。これは、LSAヘッダーにも含まれているLS年齢、LSシーケンス番号、およびLSチェックサムフィールドを調べることで実現されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Age | LS Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The LSA Header
LSAヘッダー
LS Age The time in seconds since the LSA was originated.
LSは、LSAが発生してから数秒で時代を年齢にします。
LS Type The LS type field indicates the function performed by the LSA. The high-order three bits of LS type encode generic properties of the LSA, while the remainder (called LSA function code) indicate the LSA's specific functionality. See Appendix A.4.2.1 for a detailed description of LS type.
LSタイプLSタイプフィールドは、LSAによって実行される関数を示します。LSタイプの高次3ビットはLSAの一般的なプロパティをエンコードし、残り（LSA関数コードと呼ばれる）はLSAの特定の機能を示しています。LSタイプの詳細な説明については、付録A.4.2.1を参照してください。
Link State ID The originating router's identifier for the LSA. The combination of the Link State ID, LS type, and Advertising Router uniquely identify the LSA in the link-state database.
リンク状態ID LSAの発信ルーターの識別子。リンク状態ID、LSタイプ、および広告ルーターの組み合わせにより、LINK-STATEデータベースのLSAを一意に識別します。
Advertising Router The Router ID of the router that originated the LSA. For example, in network-LSAs this field is equal to the Router ID of the network's Designated Router.
広告ルーターLSAを発信したルーターのルーターID。たとえば、ネットワークLSASでは、このフィールドはネットワークの指定ルーターのルーターIDに等しくなります。
LS sequence number Successive instances of an LSA are given successive LS sequence numbers. The sequence number can be used to detect old or duplicate LSA instances. See Section 12.1.6 in [OSPFV2] for more details.
LSシーケンス番号LSAの連続的なインスタンスには、連続したLSシーケンス番号が与えられます。シーケンス番号を使用して、古いLSAインスタンスまたは重複インスタンスを検出できます。詳細については、[OSPFV2]のセクション12.1.6を参照してください。
LS checksum The Fletcher checksum of the complete contents of the LSA, including the LSA header but excluding the LS age field. See Section 12.1.7 in [OSPFV2] for more details.
LSチェックサムLSAヘッダーを含むが、LSエイジフィールドを除外するLSAの完全な内容のフレッチャーチェックサム。詳細については、[OSPFV2]のセクション12.1.7を参照してください。
length The length in bytes of the LSA. This includes the 20-byte LSA header.
LSAのバイトの長さの長さ。これには、20バイトのLSAヘッダーが含まれます。
The LS type field indicates the function performed by the LSA. The high-order three bits of LS type encode generic properties of the LSA, while the remainder (called LSA function code) indicate the LSA's specific functionality. The format of the LS type is as follows:
LSタイプフィールドは、LSAによって実行される関数を示します。LSタイプの高次3ビットはLSAの一般的なプロパティをエンコードし、残り（LSA関数コードと呼ばれる）はLSAの特定の機能を示しています。LSタイプの形式は次のとおりです。
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|U |S2|S1| LSA Function Code |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
LSA Type
LSAタイプ
The U-bit indicates how the LSA should be handled by a router that does not recognize the LSA's function code. Its values are:
Uビットは、LSAの関数コードを認識しないルーターによってLSAをどのように処理するかを示します。その値は次のとおりです。
U-bit LSA Handling
-------------------------------------------------------------
0 Treat the LSA as if it had link-local flooding scope
1 Store and flood the LSA as if the type is understood
U-Bit
Uビット
The S1 and S2 bits indicate the flooding scope of the LSA. The values are:
S1およびS2ビットは、LSAの洪水範囲を示しています。値は次のとおりです。
S2 S1 Flooding Scope
-------------------------------------------------------------
0 0 Link-Local Scoping - Flooded only on originating link
0 1 Area Scoping - Flooded only in originating area
1 0 AS Scoping - Flooded throughout AS
1 1 Reserved
Flooding Scope
洪水範囲
The LSA function codes are defined as follows. The origination and processing of these LSA function codes are defined elsewhere in this document, except for the NSSA-LSA (see [NSSA]) and 0x2006, which was previously used by MOSPF (see [MOSPF]). MOSPF has been deprecated for OSPFv3. As shown below, each LSA function b code also implies a specific setting for the U, S1, and S2 bits.
LSA関数コードは次のように定義されています。これらのLSA関数コードの発信と処理は、NSSA-LSA（[NSSA]を参照）および0x2006を除き、このドキュメントの他の場所で定義されています。モスフはOSPFV3のために非推奨されています。以下に示すように、各LSA関数Bコードは、U、S1、およびS2ビットの特定の設定も意味します。
LSA Function Code LS Type Description
----------------------------------------------------
1 0x2001 Router-LSA
2 0x2002 Network-LSA
3 0x2003 Inter-Area-Prefix-LSA
4 0x2004 Inter-Area-Router-LSA
5 0x4005 AS-External-LSA
6 0x2006 Deprecated (may be reassigned)
7 0x2007 NSSA-LSA
8 0x0008 Link-LSA
9 0x2009 Intra-Area-Prefix-LSA
LSA Function Code
LSA関数コード
Router-LSAs have LS type equal to 0x2001. Each router in an area originates one or more router-LSAs. The complete collection of router-LSAs originated by the router describe the state and cost of the router's interfaces to the area. For details concerning the construction of router-LSAs, see Section 4.4.3.2. Router-LSAs are only flooded throughout a single area.
ルーター-LSAのLSタイプは0x2001に等しい。エリア内の各ルーターは、1つ以上のルーターLSAを発生します。ルーターから生まれたルーター-LSAの完全なコレクションは、ルーターのインターフェイスの状態とコストをエリアへのコストについて説明しています。ルーター-LSAの構築に関する詳細については、セクション4.4.3.2を参照してください。ルーター-LSAは、単一の領域全体でのみ浸水します。
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
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Age |0|0|1| 1 |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Sequence Number |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Checksum | Length |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |Nt|x|V|E|B| Options |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | 0 | Metric |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor Interface ID |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor Router ID |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | 0 | Metric |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor Interface ID |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor Router ID |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
Router-LSA Format
Router-LSA形式
A single router may originate one or more router-LSAs, distinguished by their Link State IDs (which are chosen arbitrarily by the originating router). The Options field and V, E, and B bits should be the same in all router-LSAs from a single originator. However, in the case of a mismatch, the values in the LSA with the lowest Link State ID take precedence. When more than one router-LSA is received from a single router, the links are processed as if concatenated into a single LSA.
単一のルーターは、リンク状態ID（発信ルーターによって任意に選択される）で区別される1つ以上のルーターLSAを発信する場合があります。オプションフィールドとV、E、およびBビットは、単一のオリジネーターからのすべてのルーターLSAで同じでなければなりません。ただし、ミスマッチの場合、LSAが最も低いLSAの値が優先されます。単一のルーターから複数のルーターLSAを受信すると、リンクは単一のLSAに連結されているかのように処理されます。
Bit V When set, the router is an endpoint of one or more fully adjacent virtual links having the described area as transit area (V is for virtual link endpoint).
ビットv設定すると、ルーターは、説明された領域をトランジットエリアとして持つ1つ以上の完全に隣接する仮想リンクのエンドポイントです（Vは仮想リンクエンドポイント用）。
Bit E When set, the router is an AS boundary router (E is for external).
ビットEセットすると、ルーターは境界ルーターです（Eは外部用です）。
Bit B When set, the router is an area border router (B is for border).
ビットBセットすると、ルーターはエリアボーダールーターです（Bは境界用です）。
Bit x This bit was previously used by MOSPF (see [MOSPF]) and has been deprecated for OSPFv3. The bit should be set to 0 and ignored when received. It may be reassigned in the future.
ビットxこのビットは以前はMOSPF（[MOSPF]を参照）で使用されており、OSPFV3で非推奨されています。ビットは0に設定し、受け取ったときに無視する必要があります。それは将来再割り当てされるかもしれません。
Bit Nt When set, the router is an NSSA border router that is unconditionally translating NSSA-LSAs into AS-external-LSAs (Nt stands for NSSA translation). Note that such routers have their NSSATranslatorRole area configuration parameter set to Always. (See [NSSA].)
ビットNTセットすると、ルーターはNSSAボーダールーターであり、NSSA-LSAをAs-External-LSAに無条件に変換します（NTはNSSA翻訳の略）。このようなルーターには、NSSSATRASRASLATORROLE AREAの構成パラメーターが常に設定されていることに注意してください。（[nssa]を参照してください。）
Options The optional capabilities supported by the router, as documented in Appendix A.2.
オプション付録A.2に記載されているように、ルーターによってサポートされるオプションの機能。
The following fields are used to describe each router interface. The Type field indicates the kind of interface being described. It may be an interface to a transit network, a point-to-point connection to another router, or a virtual link. The values of all the other fields describing a router interface depend on the interface's Type field.
次のフィールドを使用して、各ルーターインターフェイスを説明します。タイプフィールドは、説明されているインターフェイスの種類を示します。これは、トランジットネットワークへのインターフェイス、別のルーターへのポイントツーポイント接続、または仮想リンクである場合があります。ルーターインターフェイスを記述する他のすべてのフィールドの値は、インターフェイスのタイプフィールドに依存します。
Type The kind of interface being described. One of the following:
説明されているインターフェイスの種類を入力します。次のいずれか：
Type Description
---------------------------------------------------
1 Point-to-point connection to another router
2 Connection to a transit network
3 Reserved
4 Virtual link
Router Link Types
ルーターリンクタイプ
Metric The cost of using this router interface for outbound traffic.
メトリックアウトバウンドトラフィックにこのルーターインターフェイスを使用するコスト。
Interface ID The Interface ID assigned to the interface being described. See Section 4.1.2 and Appendix C.3.
インターフェイスID説明されているインターフェイスに割り当てられたインターフェイスID。セクション4.1.2および付録C.3を参照してください。
Neighbor Interface ID The Interface ID the neighbor router has associated with the link, as advertised in the neighbor's Hello packets. For transit (type 2) links, the link's Designated Router is the neighbor described. For other link types, the sole adjacent neighbor is described.
ネイバーのインターフェイスIDインターフェイスIDネイバーのハローパケットで宣伝されているように、ネイバールーターがリンクに関連付けています。トランジット（タイプ2）リンクの場合、リンクの指定されたルーターは、説明されているネイバーです。他のリンクタイプについては、唯一の隣接する隣人が説明されています。
Neighbor Router ID The Router ID the of the neighbor router. For transit (type 2) links, the link's Designated Router is the neighbor described. For other link types, the sole adjacent neighbor is described.
ネイバールーターIDネイバールーターのルーターID。トランジット（タイプ2）リンクの場合、リンクの指定されたルーターは、説明されているネイバーです。他のリンクタイプについては、唯一の隣接する隣人が説明されています。
For transit (Type 2) links, the combination of Neighbor Interface ID and Neighbor Router ID allows the network-LSA for the attached link to be found in the link-state database.
Transit（Type 2）リンクの場合、Neighbor Interface IDとNeighbor Router IDの組み合わせにより、添付のリンクのネットワークLSAがリンク状態データベースにあります。
Network-LSAs have LS type equal to 0x2002. A network-LSA is originated for each broadcast and NBMA link in the area that includes two or more adjacent routers. The network-LSA is originated by the link's Designated Router. The LSA describes all routers attached to the link including the Designated Router itself. The LSA's Link State ID field is set to the Interface ID that the Designated Router has been advertising in Hello packets on the link.
ネットワークLSAのLSタイプは0x2002に等しい。ネットワークLSAは、2つ以上の隣接するルーターを含むエリアの放送ごとに、NBMAリンクごとに発信されます。ネットワークLSAは、リンクの指定されたルーターによって発信されます。LSAは、指定されたルーター自体を含むリンクに取り付けられたすべてのルーターを説明します。LSAのリンク状態IDフィールドは、指定されたルーターがリンク上のハローパケットに広告を掲載しているというインターフェイスIDに設定されています。
The distance from the network to all attached routers is zero. This is why the Metric fields need not be specified in the network-LSA. For details concerning the construction of network-LSAs, see Section 4.4.3.3.
ネットワークからすべての接続されたルーターまでの距離はゼロです。これが、メトリックフィールドをネットワークLSAで指定する必要がない理由です。ネットワークLSAの構築に関する詳細については、セクション4.4.3.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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Age |0|0|1| 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attached Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
Network-LSA Format
ネットワークLSA形式
Attached Router The Router IDs of each of the routers attached to the link. Actually, only those routers that are fully adjacent to the Designated Router are listed. The Designated Router includes itself in this list. The number of routers included can be deduced from the LSA header's length field.
リンクに取り付けられた各ルーターのルーターIDを取り付けました。実際、指定されたルーターに完全に隣接するルーターのみがリストされています。指定されたルーターには、このリストにそれ自体が含まれています。含まれるルーターの数は、LSAヘッダーの長さフィールドから推測できます。
Inter-area-prefix-LSAs have LS type equal to 0x2003. These LSAs are the IPv6 equivalent of OSPF for IPv4's type 3 summary-LSAs (see Section 12.4.3 of [OSPFV2]). Originated by area border routers, they describe routes to IPv6 address prefixes that belong to other areas. A separate inter-area-prefix-LSA is originated for each IPv6 address prefix. For details concerning the construction of inter-area-prefix-LSAs, see Section 4.4.3.4.
エリア間型-LSASのLSタイプは0x2003に等しい。これらのLSAは、IPv4のタイプ3サマリLSAのOSPFに相当するIPv6です（[OSPFV2]のセクション12.4.3を参照）。エリアボーダールーターから生まれ、他のエリアに属するIPv6アドレスのプレフィックスへのルートについて説明します。IPv6アドレスのプレフィックスごとに、別のエリア間 - プレフィックスLSAが発信されます。エリア間型LSAの構築に関する詳細については、セクション4.4.3.4を参照してください。
For stub areas, inter-area-prefix-LSAs can also be used to describe a (per-area) default route. Default summary routes are used in stub areas instead of flooding a complete set of external routes. When describing a default summary route, the inter-area-prefix-LSA's PrefixLength is set to 0.
スタブ領域の場合、エリア間 - プレフィックスLSAを使用して（エリアごとの）デフォルトルートを記述することもできます。デフォルトの概要ルートは、外部ルートの完全なセットに浸水する代わりに、スタブエリアで使用されます。デフォルトの概要ルートを記述する場合、エリア間領域のrefix-lsaのプレフィックス長さは0に設定されています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Age |0|0|1| 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PrefixLength | PrefixOptions | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Prefix |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Inter-Area-Prefix-LSA Format
インターエリア-Prefix-LSA形式
Metric The cost of this route. Expressed in the same units as the interface costs in router-LSAs. When the inter-area-prefix-LSA is describing a route to a range of addresses (see Appendix C.2), the cost is set to the maximum cost to any reachable component of the address range.
メトリックこのルートのコスト。ルーターLSAのインターフェイスコストと同じユニットで表されます。エリア間 - プレフィックスLSAがさまざまなアドレスへのルートを記述している場合（付録C.2を参照）、コストはアドレス範囲の任意の範囲のコンポーネントに最大コストに設定されます。
PrefixLength, PrefixOptions, and Address Prefix Representation of the IPv6 address prefix, as described in Appendix A.4.1.
付録A.4.1で説明するように、IPv6アドレスプレフィックスのプレフィックスレングス、プレフィックス、アドレスプレフィックス表現。
Inter-area-router-LSAs have LS type equal to 0x2004. These LSAs are the IPv6 equivalent of OSPF for IPv4's type 4 summary-LSAs (see Section 12.4.3 of [OSPFV2]). Originated by area border routers, they describe routes to AS boundary routers in other areas. To see why it is necessary to advertise the location of each ASBR, consult Section 16.4 in [OSPFV2]. Each LSA describes a route to a single router. For details concerning the construction of inter-area-router-LSAs, see Section 4.4.3.5.
エリア間ルーターLSAのLSタイプは0x2004に等しい。これらのLSAは、IPv4のタイプ4要約LSAのOSPFに相当するIPv6です（[OSPFV2]のセクション12.4.3を参照）。エリアボーダールーターから生まれ、他のエリアの境界ルーターとしてルートを説明しています。各ASBRの場所を宣伝する必要がある理由を確認するには、[OSPFV2]のセクション16.4を参照してください。各LSAは、単一のルーターへのルートについて説明します。エリア間ルーターLSAの構築に関する詳細については、セクション4.4.3.5を参照してください。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Age |0|0|1| 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Inter-Area-Router-LSA Format
エリア間ルーターLSA形式
Options The optional capabilities supported by the router, as documented in Appendix A.2.
オプション付録A.2に記載されているように、ルーターによってサポートされるオプションの機能。
Metric The cost of this route. Expressed in the same units as the interface costs in router-LSAs.
メトリックこのルートのコスト。ルーターLSAのインターフェイスコストと同じユニットで表されます。
Destination Router ID The Router ID of the router being described by the LSA.
宛先ルーターID LSAによって記述されているルーターのルーターID。
AS-external-LSAs have LS type equal to 0x4005. These LSAs are originated by AS boundary routers and describe destinations external to the AS. Each LSA describes a route to a single IPv6 address prefix. For details concerning the construction of AS-external-LSAs, see Section 4.4.3.6.
As-External-LSAのLSタイプは0x4005に等しい。これらのLSAは、境界ルーターとして発信され、ASの外部の目的地を記述します。各LSAは、単一のIPv6アドレスプレフィックスへのルートについて説明します。As-External-LSAの構築に関する詳細については、セクション4.4.3.6を参照してください。
AS-external-LSAs can be used to describe a default route. Default routes are used when no specific route exists to the destination. When describing a default route, the AS-external-LSA's PrefixLength is set to 0.
AS-External-LSAを使用して、デフォルトのルートを記述できます。宛先に特定のルートが存在しない場合、デフォルトルートが使用されます。デフォルトのルートを記述する場合、As-External-LSAのプレフィックスLengthが0に設定されています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Age |0|1|0| 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |E|F|T| Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PrefixLength | PrefixOptions | Referenced LS Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Prefix |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- -+
| |
+- Forwarding Address (Optional) -+
| |
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| External Route Tag (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Referenced Link State ID (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AS-external-LSA Format
AS-External-LSA形式
bit E The type of external metric. If bit E is set, the metric specified is a Type 2 external metric. This means the metric is considered larger than any intra-AS path. If bit E is zero, the specified metric is a Type 1 external metric. This means that it is expressed in the same units as other LSAs (i.e., the same units as the interface costs in router-LSAs).
ビットe外部メトリックのタイプ。ビットEが設定されている場合、指定されたメトリックはタイプ2の外部メトリックです。これは、メトリックがどのパスでも大きいと見なされることを意味します。ビットEがゼロの場合、指定されたメトリックはタイプ1の外部メトリックです。これは、他のLSAと同じ単位で表されることを意味します（つまり、ルーターLSAのインターフェイスコストと同じ単位）。
bit F If set, a Forwarding Address has been included in the LSA.
BIT Fセットの場合、転送アドレスがLSAに含まれています。
bit T If set, an External Route Tag has been included in the LSA.
BIT T SETの場合、外部ルートタグがLSAに含まれています。
Metric The cost of this route. Interpretation depends on the external type indication (bit E above).
メトリックこのルートのコスト。解釈は、外部タイプの表示（上記のビット）に依存します。
PrefixLength, PrefixOptions, and Address Prefix Representation of the IPv6 address prefix, as described in Appendix A.4.1.
付録A.4.1で説明するように、IPv6アドレスプレフィックスのプレフィックスレングス、プレフィックス、アドレスプレフィックス表現。
Referenced LS Type If non-zero, an LSA with this LS type is to be associated with this LSA (see Referenced Link State ID below).
参照LSタイプ非ゼロの場合、このLSタイプを持つLSAはこのLSAに関連付けられます（以下の参照リンク状態IDを参照）。
Forwarding address A fully qualified IPv6 address (128 bits). Included in the LSA if and only if bit F has been set. If included, data traffic for the advertised destination will be forwarded to this address. It MUST NOT be set to the IPv6 Unspecified Address (0:0:0:0:0:0:0:0) or an IPv6 Link-Local Address (Prefix FE80/10). While OSPFv3 routes are normally installed with link-local addresses, an OSPFv3 implementation advertising a forwarding address MUST advertise a global IPv6 address. This global IPv6 address may be the next-hop gateway for an external prefix or may be obtained through some other method (e.g., configuration).
フォワーディングアドレスは、完全に適格なIPv6アドレス（128ビット）を使用します。BIT Fが設定されている場合にのみ、LSAに含まれます。含まれている場合、広告された宛先のデータトラフィックはこのアドレスに転送されます。IPv6未指定アドレス（0：0：0：0：0：0：0：0）またはIPv6リンクローカルアドレス（プレフィックスFE80/10）に設定してはなりません。OSPFV3ルートは通常、Link-Localアドレスでインストールされていますが、OSPFV3の実装広告は、フォワーディングアドレスがグローバルIPv6アドレスを宣伝する必要があります。このグローバルIPv6アドレスは、外部プレフィックスの次のホップゲートウェイであるか、他の方法（構成など）で取得される場合があります。
External Route Tag A 32-bit field that MAY be used to communicate additional information between AS boundary routers. Included in the LSA if and only if bit T has been set.
外部ルートタグ境界ルーター間で追加情報を通信するために使用できる32ビットフィールド。BIT Tが設定されている場合にのみ、LSAに含まれます。
Referenced Link State ID Included if and only if Reference LS Type is non-zero. If included, additional information concerning the advertised external route can be found in the LSA having LS type equal to "Referenced LS Type", Link State ID equal to "Referenced Link State ID", and Advertising Router the same as that specified in the AS-external-LSA's link-state header. This additional information is not used by the OSPF protocol itself. It may be used to communicate information between AS boundary routers. The precise nature of such information is outside the scope of this specification.
参照リンク状態IDには、参照LSタイプがゼロではない場合にのみ含まれています。含まれている場合、「参照LSタイプ」に等しいLSタイプ、「参照リンク状態ID」に等しいリンク状態ID、およびASで指定されているものと同じように広告ルーターに等しいLSAを有するLSAに広告された外部ルートに関する追加情報があります。-External-LSAのリンク状態ヘッダー。この追加情報は、OSPFプロトコル自体では使用されません。境界ルーターの間で情報を通信するために使用できます。このような情報の正確な性質は、この仕様の範囲外です。
All, none, or some of the fields labeled Forwarding address, External Route Tag, and Referenced Link State ID MAY be present in the AS-external-LSA (as indicated by the setting of bit F, bit T, and Referenced LS Type respectively). When present, Forwarding Address always comes first, External Route Tag next, and the Referenced Link State ID last.
すべて、なし、またはフォワーディングアドレス、外部ルートタグ、および参照されたリンク状態IDというラベルのあるフィールドの一部は、as-fernal-LSAに存在する場合があります（ビットf、ビットt、および参照されたLSタイプの設定でそれぞれ示されています。）。存在する場合、転送アドレスは常に最初に、外部ルートタグは次に、参照されるリンク状態IDが最後になります。
NSSA-LSAs have LS type equal to 0x2007. These LSAs are originated by AS boundary routers within an NSSA and describe destinations external to the AS that may or may not be propagated outside the NSSA (refer to [NSSA]). Other than the LS type, their format is exactly the same as AS-external LSAs as described in Appendix A.4.7.
NSSA-LSAのLSタイプは0x2007に等しい。これらのLSAは、NSSA内の境界ルーターとして発信され、NSSAの外部で伝播される場合とはない場合があるASの外部の目的地を記述します（[NSSA]を参照）。LSタイプを除いて、それらの形式は、付録A.4.7に記載されているように、External LSAとまったく同じです。
A global IPv6 address MUST be selected as forwarding address for NSSA-LSAs that are to be propagated by NSSA area border routers. The selection should proceed the same as OSPFv2 NSSA support [NSSA] with additional checking to ensure IPv6 link-local address are not selected.
NSSAエリアボーダールーターによって伝播するNSSA-LSAの転送アドレスとしてグローバルIPv6アドレスを選択する必要があります。選択は、IPv6 Link-Localアドレスが選択されていないことを確認するために追加のチェックを使用して、OSPFV2 NSSAサポート[NSSA]と同じで進行する必要があります。
Link-LSAs have LS type equal to 0x0008. A router originates a separate link-LSA for each attached physical link. These LSAs have link-local flooding scope; they are never flooded beyond the associated link. Link-LSAs have three purposes:
Link-LSAのLSタイプは0x0008に等しい。ルーターは、添付された物理リンクごとに個別のリンクLSAを発信します。これらのLSAには、リンクローカルの洪水範囲があります。関連するリンクを超えて浸水することはありません。Link-LSAには3つの目的があります。
1. They provide the router's link-local address to all other routers attached to the link.
1. それらは、リンクに接続された他のすべてのルーターにルーターのリンクローカルアドレスを提供します。
2. They inform other routers attached to the link of a list of IPv6 prefixes to associate with the link.
2. 彼らは、IPv6プレフィックスのリストのリンクに接続された他のルーターに、リンクに関連付けることを通知します。
3. They allow the router to advertise a collection of Options bits in the network-LSA originated by the Designated Router on a broadcast or NBMA link.
3. ルーターは、ブロードキャストまたはNBMAリンクで指定されたルーターによって発信されるネットワークLSAのオプションビットのコレクションを宣伝することができます。
For details concerning the construction of links-LSAs, see Section 4.4.3.8.
Links-LSAの構築に関する詳細については、セクション4.4.3.8を参照してください。
A link-LSA's Link State ID is set equal to the originating router's Interface ID on the link.
Link-LSAのリンク状態IDは、リンク上の元のルーターのインターフェイスIDに等しく設定されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Age |0|0|0| 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rtr Priority | Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- -+
| |
+- Link-local Interface Address -+
| |
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # prefixes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PrefixLength | PrefixOptions | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Prefix |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PrefixLength | PrefixOptions | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Prefix |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Link-LSA Format
Link-LSA形式
Rtr Priority The Router Priority of the interface attaching the originating router to the link.
RTRの優先順位リンクに元気なルーターを取り付けるインターフェイスのルーターの優先度。
Options The set of Options bits that the router would like set in the network-LSA that will be originated by the Designated Router on broadcast or NBMA links.
オプションブロードキャストまたはNBMAリンクで指定されたルーターによって発信されるネットワークLSAにルーターが設定したいオプションビットのセット。
Link-local Interface Address The originating router's link-local interface address on the link.
リンクローカルインターフェイスアドレスリンク上の元のルーターのリンクローカルインターフェイスアドレス。
# prefixes The number of IPv6 address prefixes contained in the LSA.
＃プレフィックスLSAに含まれるIPv6アドレスプレフィックスの数。
The rest of the link-LSA contains a list of IPv6 prefixes to be associated with the link.
リンクLSAの残りの部分には、リンクに関連付けられるIPv6プレフィックスのリストが含まれています。
PrefixLength, PrefixOptions, and Address Prefix Representation of an IPv6 address prefix, as described in Appendix A.4.1.
付録A.4.1で説明したように、IPv6アドレスプレフィックスのプレフィックスレング、プレフィックスオプション、およびアドレスプレフィックス表現。
Intra-area-prefix-LSAs have LS type equal to 0x2009. A router uses intra-area-prefix-LSAs to advertise one or more IPv6 address prefixes that are associated with a local router address, an attached stub network segment, or an attached transit network segment. In IPv4, the first two were accomplished via the router's router-LSA and the last via a network-LSA. In OSPF for IPv6, all addressing information that was advertised in router-LSAs and network-LSAs has been removed and is now advertised in intra-area-prefix-LSAs. For details concerning the construction of intra-area-prefix-LSA, see Section 4.4.3.9.
エリア内-Prefix-LSASは、LSタイプが0x2009に等しい。ルーターは、エリア内-Prefix-LSAを使用して、ローカルルーターアドレス、添付のスタブネットワークセグメント、または添付されたトランジットネットワークセグメントに関連付けられている1つ以上のIPv6アドレスプレフィックスを宣伝します。IPv4では、最初の2つはルーターのルーターLSAを介して行われ、最後の2つはネットワークLSAを介して達成されました。IPv6のOSPFでは、ルーターLSAおよびネットワークLSAで宣伝されたすべてのアドレス指定情報が削除されており、現在はエリア内-Prefix-LSAで宣伝されています。エリア内-Prefix-LSAの構築に関する詳細については、セクション4.4.3.9を参照してください。
A router can originate multiple intra-area-prefix-LSAs for each router or transit network. Each such LSA is distinguished by its unique Link State ID.
ルーターは、各ルーターまたはトランジットネットワークに対して複数のエリア内型LSAを発生させることができます。このようなLSAはそれぞれ、その一意のリンク状態IDによって区別されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Age |0|0|1| 9 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # Prefixes | Referenced LS Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Referenced Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Referenced Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PrefixLength | PrefixOptions | Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Prefix |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PrefixLength | PrefixOptions | Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Prefix |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Intra-Area-Prefix LSA Format
エリア内-Prefix LSA形式
# prefixes The number of IPv6 address prefixes contained in the LSA.
＃プレフィックスLSAに含まれるIPv6アドレスプレフィックスの数。
Referenced LS Type, Referenced Link State ID, and Referenced Advertising Router Identifies the router-LSA or network-LSA with which the IPv6 address prefixes should be associated. If Referenced LS Type is 0x2001, the prefixes are associated with a router-LSA, Referenced Link State ID should be 0, and Referenced Advertising Router should be the originating router's Router ID. If Referenced LS Type is 0x2002, the prefixes are associated with a network-LSA, Referenced Link State ID should be the Interface ID of the link's Designated Router, and Referenced Advertising Router should be the Designated Router's Router ID.
参照されたLSタイプ、参照リンク状態ID、および参照される広告ルーターは、IPv6アドレスのプレフィックスを関連付けるルーターLSAまたはネットワークLSAを識別します。参照されたLSタイプが0x2001の場合、プレフィックスはルーターLSAに関連付けられ、参照されるリンク状態IDは0、参照される広告ルーターは原始ルーターのルーターIDである必要があります。参照されたLSタイプが0x2002の場合、プレフィックスはネットワークLSAに関連付けられ、参照されるリンク状態IDはリンクの指定ルーターのインターフェイスIDである必要があり、参照される広告ルーターは指定ルーターのルーターIDでなければなりません。
The rest of the intra-area-prefix-LSA contains a list of IPv6 prefixes to be associated with the router or transit link, as well as their associated costs.
エリア内-Prefix-LSAの残りの部分には、ルーターまたはトランジットリンクに関連付けられるIPv6プレフィックスのリスト、および関連するコストが含まれています。
PrefixLength, PrefixOptions, and Address Prefix Representation of an IPv6 address prefix, as described in Appendix A.4.1.
付録A.4.1で説明したように、IPv6アドレスプレフィックスのプレフィックスレング、プレフィックスオプション、およびアドレスプレフィックス表現。
Metric The cost of this prefix. Expressed in the same units as the interface costs in router-LSAs.
メトリックこのプレフィックスのコスト。ルーターLSAのインターフェイスコストと同じユニットで表されます。
Architectural constants for the OSPF protocol are defined in Appendix B of [OSPFV2]. The only difference for OSPF for IPv6 is that DefaultDestination is encoded as a prefix with length 0 (see Appendix A.4.1).
OSPFプロトコルのアーキテクチャ定数は、[OSPFV2]の付録Bに定義されています。IPv6のOSPFの唯一の違いは、デフォルト延期が長さ0のプレフィックスとしてエンコードされることです（付録A.4.1を参照）。
The OSPF protocol has quite a few configurable parameters. These parameters are listed below. They are grouped into general functional categories (area parameters, interface parameters, etc.). Sample values are given for some of the parameters.
OSPFプロトコルには、かなりの数の構成可能なパラメーターがあります。これらのパラメーターを以下に示します。それらは、一般的な機能カテゴリ（エリアパラメーター、インターフェイスパラメーターなど）にグループ化されます。いくつかのパラメーターに対してサンプル値が与えられます。
Some parameter settings need to be consistent among groups of routers. For example, all routers in an area must agree on that area's parameters. Similarly, all routers attached to a network must agree on that network's HelloInterval and RouterDeadInterval.
一部のパラメーター設定は、ルーターのグループ間で一貫性を保つ必要があります。たとえば、エリア内のすべてのルーターは、そのエリアのパラメーターに同意する必要があります。同様に、ネットワークに接続されているすべてのルーターは、そのネットワークのhellotervalとrouterdeadIntervalに同意する必要があります。
Some parameters may be determined by router algorithms outside of this specification (e.g., the address of a host connected to the router via a SLIP line). From OSPF's point of view, these items are still configurable.
一部のパラメーターは、この仕様の外側のルーターアルゴリズムによって決定される場合があります（たとえば、スリップラインを介してルーターに接続されたホストのアドレス）。OSPFの観点から、これらのアイテムはまだ構成可能です。
In general, a separate copy of the OSPF protocol is run for each area. Because of this, most configuration parameters are defined on a per-area basis. The few global configuration parameters are listed below.
一般に、各エリアに対してOSPFプロトコルの個別のコピーが実行されます。このため、ほとんどの構成パラメーターはエリアごとに定義されます。いくつかのグローバル構成パラメーターを以下に示します。
Router ID This is a 32-bit number that uniquely identifies the router in the Autonomous System. If a router's OSPF Router ID is changed, the router's OSPF software should be restarted before the new Router ID takes effect. Before restarting due to a Router ID change, the router should flush its self-originated LSAs from the routing domain (see Section 14.1 of [OSPFV2]). Otherwise, they will persist for up to MaxAge seconds.
ルーターIDこれは、自律システムのルーターを一意に識別する32ビット番号です。ルーターのOSPFルーターIDが変更された場合、新しいルーターIDが有効になる前にルーターのOSPFソフトウェアを再起動する必要があります。ルーターIDの変更により再起動する前に、ルーターはルーティングドメインから自己陽子化されたLSAをフラッシュする必要があります（[OSPFV2]のセクション14.1を参照）。それ以外の場合、それらは最大秒間続きます。
Because the size of the Router ID is smaller than an IPv6 address, it cannot be set to one of the router's IPv6 addresses (as is commonly done for IPv4). Possible Router ID assignment procedures for IPv6 include: a) assign the IPv6 Router ID as one of the router's IPv4 addresses or b) assign IPv6 Router IDs through some local administrative procedure (similar to procedures used by manufacturers to assign product serial numbers).
ルーターIDのサイズはIPv6アドレスよりも小さいため、ルーターのIPv6アドレスのいずれかに設定することはできません（IPv4に対して一般的に行われているように）。IPv6の可能なルーターID割り当て手順には、a）IPv6ルーターIDをルーターのIPv4アドレスのいずれかに割り当てるか、b）いくつかのローカル管理手順を介してIPv6ルーターIDを割り当てます（製造業者が製品のシリアル番号を割り当てるために使用する手順と同様）。
The Router ID of 0.0.0.0 is reserved and SHOULD NOT be used.
0.0.0.0のルーターIDは予約されており、使用しないでください。
All routers belonging to an area must agree on that area's configuration. Disagreements between two routers will lead to an inability for adjacencies to form between them, with a resulting hindrance to the flow of both routing protocol information and data traffic. The following items must be configured for an area:
エリアに属するすべてのルーターは、そのエリアの構成に同意する必要があります。2つのルーター間の意見の相違は、それらの間に隣接が形成されないことにつながり、ルーティングプロトコル情報とデータトラフィックの両方の流れを妨げます。次のアイテムは、エリアに対して構成する必要があります。
Area ID This is a 32-bit number that identifies the area. The Area ID of 0 is reserved for the backbone.
エリアIDこれは、エリアを識別する32ビット番号です。0の面積IDはバックボーン用に予約されています。
List of address ranges Address ranges control the advertisement of routes across area boundaries. Each address range consists of the following items:
アドレス範囲のリストアドレス範囲は、エリアの境界を越えたルートの広告を制御します。各アドレス範囲は、次の項目で構成されています。
[IPv6 prefix, prefix length] Describes the collection of IPv6 addresses contained in the address range.
[IPv6プレフィックス、プレフィックス長い]アドレス範囲に含まれるIPv6アドレスのコレクションについて説明します。
Status Set to either Advertise or DoNotAdvertise. Routing information is condensed at area boundaries. External to the area, at most a single route is advertised (via a inter-area-prefix-LSA) for each address range. The route is advertised if and only if the address range's Status is set to Advertise. Unadvertised ranges allow the existence of certain networks to be intentionally hidden from other areas. Status is set to Advertise by default.
ステータスが広告またはdonotadvertiseに設定されています。ルーティング情報は、面積境界で凝縮されます。エリアの外部では、せいぜい各アドレス範囲の単一のルートが（エリア間型LSAを介して）宣伝されています。アドレス範囲のステータスが宣伝されるように設定されている場合にのみ、ルートが宣伝されます。宣伝されていない範囲により、特定のネットワークの存在を他の領域から意図的に隠すことができます。ステータスはデフォルトで広告するように設定されています。
ExternalRoutingCapability Whether AS-external-LSAs will be flooded into/throughout the area. If AS-external-LSAs are excluded from the area, the area is called a stub area or NSSA. Internal to stub areas, routing to external destinations will be based solely on a default inter-area route. The backbone cannot be configured as a stub or NSSA area. Also, virtual links cannot be configured through stub or NSSA areas. For more information, see Section 3.6 of [OSPFV2] and [NSSA].
外部ルーティングのキャピールAS-External-LSAがエリア全体に浸水するかどうか。エクステルタルLSAがエリアから除外されている場合、このエリアはスタブエリアまたはNSSAと呼ばれます。内部からスタブ領域から外部宛先へのルーティングは、デフォルトのエリア間ルートのみに基づいています。バックボーンは、スタブまたはNSSA領域として構成することはできません。また、仮想リンクは、スタブまたはNSSA領域を介して構成することはできません。詳細については、[OSPFV2]および[NSSA]のセクション3.6を参照してください。
StubDefaultCost If the area has been configured as a stub area, and the router itself is an area border router, then the StubDefaultCost indicates the cost of the default inter-area-prefix-LSA that the router should advertise into the area. See Section 12.4.3.1 of [OSPFV2] for more information.
StubDefaultCost領域がスタブエリアとして構成されている場合、ルーター自体がエリアボーダールーターである場合、StubDefaultCostは、ルーターが領域に宣伝すべきデフォルトのエリア間プレフィックスLSAのコストを示します。詳細については、[OSPFV2]のセクション12.4.3.1を参照してください。
NSSATranslatorRole and TranslatorStabilityInterval These area parameters are described in Appendix D of [NSSA]. Additionally, an NSSA Area Border Router (ABR) is also required to allow configuration of whether or not an NSSA default route is advertised in an NSSA-LSA. If advertised, its metric and metric type are configurable. These requirements are also described in Appendix D of [NSSA].
nssatranslaturroleおよび翻訳stabilityインターバルこれらの領域パラメーターは、[NSSA]の付録Dに記載されています。さらに、NSSAのデフォルトルートがNSSA-LSAで宣伝されているかどうかの構成を許可するには、NSSAエリアボーダールーター（ABR）も必要です。宣伝されている場合、そのメトリックタイプとメトリックタイプは構成可能です。これらの要件は、[NSSA]の付録Dでも説明されています。
ImportSummaries When set to enabled, prefixes external to the area are imported into the area via the advertisement of inter-area-prefix-LSAs. When set to disabled, inter-area routes are not imported into the area. The default setting is enabled. This parameter is only valid for stub or NSSA areas.
インポートサマリは、有効になるように設定されている場合、エリアの外部のプレフィックスが、エリア間型LSAの広告を介してエリアにインポートされます。無効に設定すると、エリア間ルートはエリアにインポートされません。デフォルト設定が有効になっています。このパラメーターは、スタブまたはNSSA領域に対してのみ有効です。
Some of the configurable router interface parameters (such as Area ID, HelloInterval, and RouterDeadInterval) actually imply properties of the attached links. Therefore, these parameters must be consistent across all the routers attached to that link. The parameters that must be configured for a router interface are:
構成可能なルーターインターフェイスパラメーターの一部（エリアID、helloterdeadedIntervalなど）は、実際に添付のリンクのプロパティを意味します。したがって、これらのパラメーターは、そのリンクに接続されたすべてのルーターで一貫している必要があります。ルーターインターフェイスに設定する必要があるパラメーターは次のとおりです。
IPv6 link-local address The IPv6 link-local address associated with this interface. May be learned through auto-configuration.
IPv6 Link-Localアドレスこのインターフェイスに関連付けられたIPv6リンクローカルアドレス。自動構成を通じて学習できます。
Area ID The OSPF area to which the attached link belongs.
接続されたリンクが属するOSPFエリアの領域。
Instance ID The OSPF protocol instance associated with this OSPF interface. Defaults to 0.
インスタンスIDこのOSPFインターフェイスに関連付けられたOSPFプロトコルインスタンス。デフォルトは0です。
Interface ID 32-bit number uniquely identifying this interface among the collection of this router's interfaces. For example, in some implementations it may be possible to use the MIB-II IfIndex ([INTFMIB]).
インターフェースID 32ビット番号このルーターのインターフェイスのコレクション間でこのインターフェイスを一意に識別します。たとえば、いくつかの実装では、MIB-II IFINDEX（[intfmib]）を使用することが可能になる場合があります。
IPv6 prefixes The list of IPv6 prefixes to associate with the link. These will be advertised in intra-area-prefix-LSAs.
IPv6プレフィックスIPv6プレフィックスのリストをリンクに関連付けます。これらは、エリア内で宣伝されます。
Interface output cost(s) The cost of sending a packet on the interface, expressed in the link-state metric. This is advertised as the link cost for this interface in the router's router-LSA. The interface output cost MUST always be greater than 0.
インターフェイス出力コストリンク状態メトリックで表されるインターフェイスにパケットを送信するコスト。これは、ルーターのルーターLSAのこのインターフェイスのリンクコストとして宣伝されています。インターフェイス出力コストは常に0より大きくなければなりません。
RxmtInterval The number of seconds between LSA retransmissions for adjacencies belonging to this interface. Also used when retransmitting Database Description and Link State Request packets. This should be well over the expected round-trip delay between any two routers on the attached link. The setting of this value should be conservative or needless retransmissions will result. Sample value for a local area network: 5 seconds.
rxmtintervalこのインターフェイスに属する隣接のLSA再送信の間の秒数。また、データベースの説明を再送信するときにも使用され、状態要求パケットをリンクします。これは、接続されたリンク上の任意の2つのルーター間の予想される往復遅延をはるかに超える必要があります。この値の設定は、保守的または不必要な再送信を引き起こす必要があります。ローカルエリアネットワークのサンプル値：5秒。
InfTransDelay The estimated number of seconds it takes to transmit a Link State Update packet over this interface. LSAs contained in the update packet must have their age incremented by this amount before transmission. This value should take into account the transmission and propagation delays of the interface. It MUST be greater than 0. Sample value for a local area network: 1 second.
Inftransdelayこのインターフェイスにリンク状態更新パケットを送信するのにかかる秒数の推定数。更新パケットに含まれるLSAは、送信前にこの量によって年齢を増加させる必要があります。この値は、インターフェイスの送信と伝播の遅延を考慮に入れる必要があります。0より大きくなければなりません。ローカルエリアネットワークのサンプル値：1秒。
Router Priority An 8-bit unsigned integer. When two routers attached to a network both attempt to become the Designated Router, the one with the highest Router Priority takes precedence. If there is still a tie, the router with the highest Router ID takes precedence. A router whose Router Priority is set to 0 is ineligible to become the Designated Router on the attached link. Router Priority is only configured for interfaces to broadcast and NBMA networks.
ルーターの優先順位8ビットの符号なし整数。ネットワークに取り付けられた2つのルーターの両方が指定されたルーターになろうとする場合、ルーターの優先度が最も高いルーターが優先されます。まだネクタイがある場合、最高のルーターIDを持つルーターが優先されます。ルーターの優先度が0に設定されているルーターは、接続されたリンクの指定されたルーターになる資格がありません。ルーターの優先度は、ブロードキャストとNBMAネットワークのインターフェイスに対してのみ構成されています。
HelloInterval The length of time, in seconds, between Hello packets that the router sends on the interface. This value is advertised in the router's Hello packets. It MUST be the same for all routers attached to a common link. The smaller the HelloInterval, the faster topological changes will be detected. However, more OSPF routing protocol traffic will ensue. Sample value for a X.25 PDN: 30 seconds. Sample value for a local area network (LAN): 10 seconds.
HelloIntervalルーターがインターフェイスに送信するハローパケット間の時間の長さ。この値は、ルーターのハローパケットに宣伝されています。一般的なリンクに取り付けられたすべてのルーターで同じでなければなりません。HelloIntervalが小さいほど、より速いトポロジーの変化が検出されます。ただし、OSPFルーティングプロトコルトラフィックが増えます。X.25 PDNのサンプル値：30秒。ローカルエリアネットワーク（LAN）のサンプル値：10秒。
RouterDeadInterval After ceasing to hear a router's Hello packets, the number of seconds before its neighbors declare the router down. This is also advertised in the router's Hello packets in their RouterDeadInterval field. This should be some multiple of the HelloInterval (e.g., 4). This value again MUST be the same for all routers attached to a common link.
RouterDeadIntervalルーターのハローパケットを聞くのをやめた後、隣人がルーターを宣言する前の秒数。これは、RouterDeadedIntervalフィールドのルーターのハローパケットにも宣伝されています。これは、HelloInterval（例：4）の複数である必要があります。この値は、共通のリンクに取り付けられたすべてのルーターで同じでなければなりません。
LinkLSASuppression Indicates whether or not origination of a link-LSA is suppressed. If set to "enabled" and the interface type is not broadcast or NBMA, the router will not originate a link-LSA for the link. This implies that other routers on the link will ascertain the router's next-hop address using a mechanism other than the link-LSA (see Section 4.8.2). The default value is "disabled" for interface types described in this specification. It is implicitly "disabled" if the interface type is broadcast or NBMA. Future interface types MAY specify a different default.
Linklsasasuppressionは、Link-LSAの発信が抑制されるかどうかを示します。「有効」に設定されていて、インターフェイスタイプがブロードキャストまたはNBMAでない場合、ルーターはリンクのリンクLSAを発生しません。これは、リンク上の他のルーターが、リンクLSA以外のメカニズムを使用してルーターのネクストホップアドレスを確認することを意味します（セクション4.8.2を参照）。デフォルト値は、この仕様で説明されているインターフェイスタイプの「無効」です。インターフェイスタイプがブロードキャストまたはNBMAである場合、暗黙的に「無効」されます。将来のインターフェイスタイプは、異なるデフォルトを指定する場合があります。
Virtual links are used to restore/increase connectivity of the backbone. Virtual links may be configured between any pair of area border routers having interfaces to a common (non-backbone) area. The virtual link appears as a point-to-point link with no global IPv6 addresses in the graph for the backbone. The virtual link must be configured in both of the area border routers.
仮想リンクは、バックボーンの接続性を復元/増加させるために使用されます。仮想リンクは、インターフェイスを持つ領域ボーダールーターの任意のペア間で、共通（非バックボーン）エリアに構成できます。仮想リンクは、バックボーンのグラフにグローバルIPv6アドレスがないポイントツーポイントリンクとして表示されます。仮想リンクは、両方のエリアボーダールーターで構成する必要があります。
A virtual link appears in router-LSAs (for the backbone) as if it were a separate router interface to the backbone. As such, it has most of the parameters associated with a router interface (see Appendix C.3). Virtual links do not have link-local addresses, but instead use one of the router's global-scope IPv6 addresses as the IP source in OSPF protocol packets it sends on the virtual link. Router Priority is not used on virtual links. Interface output cost is not configured on virtual links, but is dynamically set to be the cost of the transit area intra-area path between the two endpoint routers. The parameter RxmtInterval may be configured and should be well over the expected round-trip delay between the two routers. This may be hard to estimate for a virtual link; it is better to err on the side of making it too long.
仮想リンクは、バックボーンへの別のルーターインターフェースであるかのように、ルーターLSA（バックボーン用）に表示されます。そのため、ルーターインターフェイスに関連付けられたパラメーターのほとんどがあります（付録C.3を参照）。仮想リンクにはリンクローカルアドレスはありませんが、代わりに、ルーターのグローバルスコープIPv6アドレスの1つを、仮想リンクで送信するOSPFプロトコルパケットのIPソースとして使用します。ルーターの優先度は、仮想リンクでは使用されません。インターフェイスの出力コストは仮想リンクで構成されていませんが、2つのエンドポイントルーター間のエリア内パスの通過エリアのコストとなるように動的に設定されています。パラメーターRXMTINTERVALが構成されている場合があり、2つのルーター間の予想される往復遅延を上回る必要があります。これは、仮想リンクの推定が難しい場合があります。あまりにも長くする側で誤りを犯す方が良いです。
A virtual link is defined by the following two configurable parameters: the Router ID of the virtual link's other endpoint and the (non-backbone) area that the virtual link traverses (referred to as the virtual link's transit area). Virtual links cannot be configured through stub or NSSA areas. Additionally, an Instance ID may be configured for virtual links from different protocol instances in order to utilize the same transit area (without requiring different Router IDs for demultiplexing).
仮想リンクは、次の2つの構成可能なパラメーターによって定義されます。仮想リンクの他のエンドポイントのルーターIDと、仮想リンクが横断する（仮想リンクのトランジットエリアと呼ばれる）（非帯域骨）領域です。仮想リンクは、スタブまたはNSSA領域を介して構成することはできません。さらに、同じトランジットエリアを利用するために、異なるプロトコルインスタンスの仮想リンクに対してインスタンスIDを構成することができます（異なるルーターIDを要求することなく）。
OSPF treats an NBMA network much like it treats a broadcast network. Since there may be many routers attached to the network, a Designated Router is selected for the network. This Designated Router then originates a network-LSA listing all routers attached to the NBMA network.
OSPFは、放送ネットワークを扱うようにNBMAネットワークを扱います。ネットワークに多くのルーターが接続されている可能性があるため、ネットワーク用に指定されたルーターが選択されています。この指定されたルーターは、NBMAネットワークに接続されているすべてのルーターをリストするネットワークLSAを発信します。
However, due to the lack of broadcast capabilities, it may be necessary to use configuration parameters in the Designated Router selection. These parameters will only need to be configured in those routers that are themselves eligible to become the Designated Router (i.e., those routers whose Router Priority for the network is non-zero), and then only if no automatic procedure for discovering neighbors exists:
ただし、ブロードキャスト機能がないため、指定されたルーター選択で構成パラメーターを使用する必要がある場合があります。これらのパラメーターは、指定されたルーター（つまり、ネットワークのルーターの優先度がゼロであるルーター）になる資格があるルーターでのみ構成する必要があります。
List of all other attached routers The list of all other routers attached to the NBMA network. Each router is configured with its Router ID and IPv6 link-local address on the network. Also, for each router listed, that router's eligibility to become the Designated Router must be defined. When an interface to an NBMA network first comes up, the router only sends Hello packets to those neighbors eligible to become the Designated Router until such time that a Designated Router is elected.
他のすべての添付ルーターのリストNBMAネットワークに接続された他のすべてのルーターのリスト。各ルーターは、ネットワーク上のルーターIDおよびIPv6リンクローカルアドレスで構成されています。また、リストされているルーターごとに、指定されたルーターになるルーターの適格性を定義する必要があります。NBMAネットワークへのインターフェイスが最初に登場すると、ルーターは、指定されたルーターが選出されるまで指定されたルーターになる資格のある隣人にハローパケットを送信します。
PollInterval If a neighboring router has become inactive (Hello packets have not been seen for RouterDeadInterval seconds), it may still be necessary to send Hello packets to the dead neighbor. These Hello packets will be sent at the reduced rate PollInterval, which should be much larger than HelloInterval. Sample value for a PDN X.25 network: 2 minutes.
Pollinterval隣接するルーターが非アクティブになっている場合（RouterDeadeadInterval秒でHello Packetsは見られていません）、Dead NeighborにHelloパケットを送信する必要がある場合があります。これらのハローパケットは、reductedレートPollintervalで送信されます。PDN X.25ネットワークのサンプル値：2分。
On point-to-multipoint networks, it may be necessary to configure the set of neighbors that are directly reachable over the point-to-multipoint network. Each neighbor is configured with its Router ID and IPv6 link-local address on the network. Designated Routers are not elected on point-to-multipoint networks, so the Designated Router eligibility of configured neighbors is not defined.
ポイントツーマルチポイントネットワークでは、ポイントツーマルチポイントネットワーク上で直接到達可能な近隣のセットを構成する必要がある場合があります。各隣接は、ネットワーク上のルーターIDおよびIPv6リンクローカルアドレスで構成されています。指定されたルーターは、ポイントツーマルチポイントネットワークで選出されていないため、設定された近隣の指定されたルーターの適格性は定義されていません。
Host prefixes are advertised in intra-area-prefix-LSAs. They indicate either local router addresses, router interfaces to point-to-point networks, looped router interfaces, or IPv6 hosts that are directly connected to the router (e.g., via a PPP connection). For each host directly connected to the router, the following items must be configured:
ホストのプレフィックスは、エリア内-Prefix-LSAで宣伝されています。それらは、ローカルルーターアドレス、ポイントツーポイントネットワークへのルーターインターフェイス、ループルーターインターフェイス、またはルーターに直接接続されたIPv6ホストのいずれかを示します（例：PPP接続を介して）。ルーターに直接接続されている各ホストについて、次のアイテムを構成する必要があります。
Host IPv6 prefix An IPv6 prefix belonging to the directly connected host. This must not be a valid IPv6 global prefix.
ホストIPv6プレフィックス直接接続されたホストに属するIPv6プレフィックス。これは有効なIPv6グローバルプレフィックスであってはなりません。
Cost of link to host The cost of sending a packet to the host, in terms of the link-state metric. However, since the host probably has only a single connection to the Internet, the actual configured cost(s) in many cases is unimportant (i.e., will have no effect on routing).
リンクのコストリンク状態メトリックの観点から、ホストのパケットをホストに送信するコスト。ただし、ホストはおそらくインターネットへの単一の接続しかないため、多くの場合、実際の構成コストは重要ではありません（つまり、ルーティングに影響はありません）。
Area ID The OSPF area to which the host's prefix belongs.
ホストのプレフィックスが属するOSPFエリアの領域。
Authors' Addresses
著者のアドレス
Rob Coltun Acoustra Productions 3204 Brooklawn Terrace Chevy Chase, MD 20815 USA
Rob Coltun Acoustra Productions 3204 Brooklawn Terrace Chevy Chase、MD 20815 USA
Dennis Ferguson Juniper Networks 1194 N. Mathilda Avenue Sunnyvale, CA 94089 USA
デニスファーガソンジュニパーネットワーク1194 N.マチルダアベニューサニーベール、カリフォルニア州94089 USA
EMail: dennis@juniper.net
John Moy Sycamore Networks, Inc 10 Elizabeth Drive Chelmsford, MA 01824 USA
John Moy Sycamore Networks、Inc 10 Elizabeth Drive Chelmsford、MA 01824 USA
EMail: jmoy@sycamorenet.com
Acee Lindem (editor) Redback Networks 102 Carric Bend Court Cary, NC 27519 USA
Acee Lindem（編集者）Redback Networks 102 Carric Bend Court Cary、NC 27519 USA
EMail: acee@redback.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。