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
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).
この文書は、インターネットプロトコルのバージョン6（IPv6）をサポートするために、OSPFへの変更について説明します。 OSPFの基本的なメカニズム（洪水、指定ルータ（DR）選挙、地域支援、ショートパスファースト（SPF）計算、等）が変更されないまま。しかし、いくつかの変更は、IPv4とIPv6間のプロトコル意味論の変化に起因するいずれか、必要とされている、または単にのIPv6の増加アドレスサイズを処理するために。これらの修飾は、IPv6のためのOSPFはまた、OSPFバージョン3（OSPFv3の）と呼ばれるバージョン3にバージョン2のプロトコル・バージョンをインクリメント必要であろう。
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).
IPv6のIPv4のOSPF、OSPFバージョン2、およびOSPFの間で変化する本明細書に記載されるようには以下のものが挙げられます。アドレッシングセマンティクスは、OSPFパケットと基本的なリンクステートアドバタイズメント（LSA）から削除されました。新しいLSAは、IPv6アドレスとプレフィックスを運ぶために作成されています。 OSPFは現在、リンクごとのベースではなく、あたり-IPサブネットベースで動作します。 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.
デマンド回線のサポートとそれほどスタビーエリア（あるNSSA）を含めたIPv4のオプション機能のOSPFのすべても、IPv6の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).
この文書は、インターネットプロトコルのバージョン6（IPv6）をサポートするために、OSPFへの変更について説明します。 OSPFの基本的なメカニズム（洪水、指定ルータ（DR）選挙、地域支援、（最短パス優先）SPF計算、等）が変更されないまま。しかし、いくつかの変更は、IPv4とIPv6間のプロトコル意味論の変化に起因するいずれか、必要とされている、または単にのIPv6の増加アドレスサイズを処理するために。これらの修飾は、IPv6のためのOSPFはまた、OSPFバージョン3（OSPFv3の）と呼ばれるバージョン3にバージョン2のプロトコル・バージョンをインクリメント必要であろう。
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（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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "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仕様のOSPF（【のOSPFv2]）とIPv6プロトコル仕様（[IPV6]）の両方からの用語を使用することを試みます。これは、混合結果を生産しています。 OSPFとIPv6の両方で使用される用語のほとんどは、ほぼ同じ意味（例えば、インタフェース）を有します。しかし、いくつかの競合があります。 IPv6は、IPv4のOSPFの「サブネット」と同様に「リンク」または「ネットワーク」を使用しています。この場合、我々は、IPv6の「リンク」の用語を使用することを選択しました。 OSPFのネットワークLSAが変わらない（そしておそらく、残念ながら、新しいリンクLSAも作成されている）が、「リンク」、この文書のほとんどの場所でのOSPFの「サブネット」と「ネットワーク」を置き換えます。
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プレフィックス）を共有していない場合でも、1つのリンクを介して直接話をすることができます。
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が実行さごとのリンクの代わりにあたり-IPサブネットの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プロトコルパケットの受信、Helloパケットの内容、およびネットワーク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型から除去されています。特に：IPv6アドレスOリンクステートアップデートパケットによって運ば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-ルータの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によって識別されます。以前は、NBMA（非ブロードキャストマルチアクセス）、放送上のIPv4アドレスによって識別され、ポイント・ツー・マルチポイントリンクされていました。
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はそれ以上のローカルリンク上で浸水しないとされます。新しいリンク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、およびエリア内プレフィックス-LSAのために使用します。
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スコープAS。 LSAは、ルーティングドメイン全体にフラッディングされます。 ASの外部のLSAのために使用されます。 ASスコープのLSAを発信するルータがAS境界ルータ（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プロトコルインスタンスを実行する機能をサポートしています。例えば、これはいくつかのプロバイダの間で共有さNAPセグメントに必要とされ得ます。プロバイダは、彼らの共通の1つまたは複数の物理ネットワークセグメント（すなわち、リンク）を有していても、別個のまましたい別のOSPFルーティングドメインをサポートすることができます。 IPv4のOSPFでは、これはOSPF IPv4のヘッダに認証フィールドを使用して、無計画な方法でサポートされていました。
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インスタンスを実行するための別の用途は、あなたがしたい場合は、何らかの理由で、単一のリンクを持っているために、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リンクローカルアドレスは、近隣探索、自動設定などのIPv6ルーターがIPv6が[IP6ADDR]リンクローカル送信元アドレスを持つデータグラム転送しないの目的のために、単一リンク上で使用するためのものです。リンクローカルユニキャストアドレスは、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).
リンクローカルアドレスは、OSPFのリンクのLSA（セクション4.4.3.8を参照）に表示されます。ただし、リンクローカルアドレスは、他のOSPF LSAタイプでは許可されません。具体的には、リンクローカルアドレスは、エリア間プレフィックス-のLSAで広告してはならない（セクション4.4.3.4）、AS-のLSA-外部（セクション4.4.3.6）、NSSA-のLSA（セクション4.4.3.7）、またはイントラ-area-プレフィックスのLSA（セクション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は、IP認証ヘッダに依存している（[IPAUTH]参照）、完全性およびルーティング交換の認証/秘匿性を確保するために、[OSPFv3の-AUTH]で説明したようにIPカプセル化セキュリティペイロード（[IPESP]参照します）。
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パケット交換の保護は、全体のOSPFパケットをカバーする、（[IPV6]のセクション8.1に記載されているように）標準のIPv6上層チェックサムによって提供される（付録A.3.1を参照）のIPv6疑似ヘッダを付加されています。
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 Helloパケットおよびデータベース記述パケット内のオプションフィールドは24ビットに拡張されました。
o The Authentication and AuType fields have been removed from the OSPF packet header (see Section 2.6).
認証およびAuTypeフィールドO（2.6節を参照）OSPFパケットヘッダから削除されました。
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ビット」、SPF計算の間ルータLSAを処理するためのオプションフィールドに追加されている（付録A.2参照）。 「R-ビットが」クリアされている場合、OSPFスピーカーはトランジットトラフィックを転送するために使用されることなく、OSPFトポロジー分配に参加することができます。これは、ルーティングプロトコルに参加したい、マルチホームホストで使用することができます。 V6ビットは、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).
OSPFパケットのヘッダーは、現在複数のOSPFプロトコルインスタンスが単一のリンク上で実行されることを可能にする「インスタンスID」を含むO（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から削除されています。これら二つの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オプションフィールドは24ビットに拡張され、LSAヘッダから除去され、ルータのLSA、ネットワークLSAを、インターエリアルータのLSA、およびリンク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タイプフィールドが氾濫範囲および未知のLSAタイプの取り扱いをコードする上位3ビットと、16ビット（旧オプション空間に）拡張された（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.
LSAの中にOアドレスは、現在の代わりに[プレフィクス、プレフィクス長] [アドレス、マスク]として表される（付録A.4.1を参照）。デフォルトルートは、長さ0のプレフィックスとして表現されます。
o Router-LSAs and network-LSAs now have no address information and are network protocol independent.
O-ルータの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新しいLSAは、リンクLSAが導入されていると呼ばれます。リンクLSAは、リンクローカルフラッディングスコープを持っています。それらが関連付けられているリンクを超えてあふれされることはありません。リンク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では、ルータLSAは、ルータのIPv4インタフェースアドレス、リンクローカルアドレスのIPv4の同等物を運びます。これらは、OSPFルーティング計算中に次のホップを計算するときだけ（[OSPFv2の]の16.1.1項を参照）が使用されているので、それらはローカルリンクを過ぎて殺到する必要はありません。したがって、これらのアドレスを配布するために、リンクLSAを使用すると、より効率的です。リンクローカルアドレスは、すべての場合にハローズの受信を通じて学習することができないことに注意してください。 NBMAリンクでは、ネクストホップルータは、必ずしもhelloを交換しません。むしろ、これらのルータは、指定ルータ（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内のオプションフィールドが論理的にORリンク上の各ルータはそのリンク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タイプ3要約LSAは、「インターエリア・プレフィックスLSAの」名前が変更されました。タイプ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.
エリア間プレフィックス-のLSAでリンクステートID O、インターエリアルータLSAを、NSSA-のLSA、およびASの外部のLSAは、そのアドレス指定の意味を失い、今リンクステートデータベースの個々の部分を識別するためだけに機能しています。以前はリンクステート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新しいLSAは、エリア内プレフィックス-LSAが導入されていると呼ばれます。このLSAは、IPv4でルータのLSAとネットワークLSAの中に含まれていること、すべてのIPv6プレフィックス情報を運びます。詳細については、セクション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外部のLSAに転送アドレスまたは外部ルートタグの包含はオプションになりました。また、ASの外部の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).
、LSタイプに基づいて、未知のLSAタイプはいずれかのリンクローカルフラッディングスコープを持つものとして扱われ、またはそれらが理解しているかのように格納され、フラッディングされるように、未知のLSAタイプの取り扱いは、より柔軟なされました。この動作は、明示的に（付録A.4.2.1にUビットを参照）リンクステートヘッダーのLSタイプフィールドのLSA取扱ビットで符号化されます。
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、リンクのLSA、およびエリア内プレフィックス-LSAをルータだけ-LSAを運びます。 NSSAエリアはもちろん、NSSA-LSAを、これらのタイプに限定しています。ネットワークのLSA、ルータのLSA、タイプ3要約LSAと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で識別されます。これは、放送、NBMA、およびポイントツーマルチポイントリンク上の隣人が自分のIPv4インターフェイスアドレスで識別されている間、ポイントツーポイントネットワークと仮想のリンクの上の隣人を自分のルータIDで識別された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）、およびHelloパケット（[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]と相まってこの仕様は、実装のために十分な仕様を提供します。 [NSSA]セクション4.8.5、付録A.4.3、付録A.4.8を参照してください、と。
In RFC 2740 [OSPFV3], flooding of unknown LSA was restricted within stub and NSSA areas. The text describing this restriction is included below.
[OSPFv3の] RFC 2740では、未知の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.
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.
これを防ぐために、スタブ領域に関する以下のルールが確立されている：両方A）LSAは、エリア又はリンクローカルフラッディングスコープを持っている場合、そのLSタイプ未認識であるLSAは、スタブエリア全体にわたって/に浸水することができ、B） LSAは、詳細については、0節を参照してください3.5へのUビットがセットされています。
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に設定されたリンクとエリアスコープLSAをフラッディングします。まだ新しく定義されたLSAタイプを伝播しないかもしれない制限をサポートしているのOSPFv3ルータ以外の下位互換性の問題はありません。
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.
LinkLSASuppressionインターフェイスコンフィギュレーションパラメータが追加されました。 LinkLSASuppressionがインタフェースとインタフェースタイプに設定されている場合、ブロードキャストまたはNBMAされていない、リンクLSAの発信を抑制することができます。 LinkLSASuppressionインターフェイスコンフィギュレーションパラメータは、付録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ビットは、プレフィクスオプションに追加されました。付録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の構成と隣接ルータ間で同期しています。最初の同期は、データベース記述、リンク状態要求、およびリンクステートアップデートパケットの交換を含むデータベースExchangeの過程を通じて行われます。その後、データベースの同期は、リンクステートアップデートおよびリンクステート確認応答パケットを利用し、洪水を介して維持されます。 IPv6とIPv4の両方が発見し、ネイバー関係を維持するだけでなく、放送とNBMAリンクに指定ルータとバックアップ指定ルータを選出するためにOSPF Helloパケットを使用します。決定はにどのようネイバー関係はASの外部の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パケットタイプを使用し、すなわち：こんにちは、データベース記述、リンク状態要求、リンクステートアップデート、およびリンクステート確認応答パケット。いくつかの場合（例えば、ハローパケット）にそのフォーマットが多少変更されているが、様々なパケットタイプの機能は同じままです。
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.
それはIPv6ネットワーク層上で直接実行されるため、OSPFは、IPv6の（下のネットワーク層から）のIPv6プロトコルスタックを必要とするがOSPF実装のシステム要件O、変わりません。
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リンク上のDesignated Routerの選挙とバックアップ指定ルータが含まれています。これらのメカニズムは、セクション7、7.1、7.2、7.3、7.4に記載し、[OSPFv2の】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インターフェイスの状態とイベントのリストを含むインタフェース・ステート・マシン、および指定ルータとバックアップ指定ルータ選挙アルゴリズムが変更されないまま。これらは、セクション9.1、9.2、9.3に記載し、[OSPFv2の】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].
OSPFネイバーの状態とイベントのリストを含むネイバーステートマシン、O、変わりません。ネイバーステートマシンは、セクション10.1、10.2、10.3に記載され、そして[OSPFv2の]の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をフラッシュ、セクション14及び【のOSPFv2]の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.
以下のサブセクションでは、IPv6 OSPFの実装にIPv4の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.
知られているLSタイプとフラッディングスコープAS OすべてのLSAは、代わりに、特定の領域またはリンクに属するのは、トップレベルのデータ構造で表示されます。 ASの外部のLSAは、フラッディングスコープとして持つこの仕様で定義されている唯一のLSAです。未知のLSタイプのLSAは、Uビットが1（洪水場合であっても認識されていない）に設定され、フラッディングスコープとしても、トップレベルのデータ構造に現れます。
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を、インターエリアルータのLSA、およびエリア内プレフィックス-のLSA：これは、常に次のLSAタイプが含まれています。未知のLSタイプのLSAは、Uビットが1（洪水場合であっても認識されていない）に設定し、領域範囲は、領域データ構造に現れます。 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では、インターフェイスはリンクにルータを接続しています。次のように（[のOSPFv2]のセクション9で定義されるように）IPv6インタフェース構造は、IPv4インタフェースの構造を変更します。
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は、接続リンクのルータ、および関連するエリアのルータLSAによって発信ルータLSAが発信インターフェイス、リンクローカル-LSAを送ったHelloパケットに表示されます。また、ルータが指定ルータに選出されている場合、ルータは、リンクのために発信することを、ネットワーク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が割り当てられます。 OSPFルータの複数の個別のコミュニティが含まれていますこれらのリンクに0以外の値を割り当てることが必要なだけである0をデフォルトとすべきです。たとえば、あなたが独立しておきたい特定のイーサネットセグメント上のルータの2つのコミュニティがあるとします。最初のコミュニティは、0のインスタンスIDが割り当てられ、最初のコミュニティ内のすべてのルータは、イーサネットセグメントに接続されたインターフェイスのインスタンスIDとして0が割り当てられます。 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.
すべてのリンクローカルスコープ付きの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.
IPv6のIPインターフェースアドレス、インターフェイス上で送信されるOSPFパケットの送信元に現れたIPv6アドレスは、ほとんど常にリンクローカルアドレスです。唯一の例外は、IPインターフェイスアドレスとしてルータ自身のグローバルIPv6アドレスのいずれかを使用しなければならない仮想リンクのためです。
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プレフィックスのリストが添付リンクに設定することができ接頭辞。彼らは、エリア内プレフィックス-のLSA内のリンクの指定ルータによってアドバタイズできるように、これらは、リンクのLSAのルータによってアドバタイズされます。
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では、各ルータインターフェイスは、インターフェイス上でパケットを送信するコストを表す単一のメトリックを有します。 [OSPFv3の-AUTH]で説明されるように加えて、IPv6のためのOSPFは、交換ルーティングの完全性及び認証/秘匿性を確保するために、（[IPESP]参照）IP認証ヘッダ（[IPAUTH]参照）、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].
界面状態、イベント、及び界面状態マシンはセクション9.1、9.2に記載のようにIPv4から変化しないままで、それぞれ9.3 [OSPFv2の]。指定ルータとバックアップ指定ルータ選挙アルゴリズムは、[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.
隣人がそのHelloパケットでアドバタイズ隣人のインタフェースIDザ・インタフェース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.
指定ルータの近隣の指定ルータ隣人の選択は今ルータIDとしてIPアドレスの代わりとしてエンコードされます。
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.
ルータを指定されたバックアップの隣人のバックアップ代表ルータの隣人の選択は、今のルータIDとしてIPアドレスの代わりとしてエンコードされます。
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].
隣接状態、イベント、および隣接ステートマシンは、セクション10.1、10.2に記載されているように、IPv4から変化しないままで、それぞれ10.3 [OSPFv2の]。また、形成する隣接関係としての決定は、[の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のネットワーク層の上に直接実行されます。このように、値89に設定され、直ちにカプセル化IPv6ヘッダの次ヘッダフィールドを有する1つのまたは複数のIPv6ヘッダーでカプセル化されます。
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.
OSPFのようにIPv6のOSPFルーティングプロトコルパケットのIPv4、OSPFのみ（隣接関係を発見するために使用されるHelloパケットを除いて）隣接関係に沿って送られます。 OSPFパケットタイプと機能は、標準的なOSPFパケットヘッダのTypeフィールドによってコードされる、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パケットヘッダ（付録A.3.1を参照）、以下のようにするための標準的なOSPFのフィールドを埋めます。
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.
そのようなリンクステートアップデートまたはHelloパケットとして、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宛先アドレスがアドレスAllSPFRouters、AllDRouters、および（IPv6では、仮想リンク以外のすべてのリンクについて、IPv6リンクローカルアドレスである）隣接の他端に関連付けられた近隣IPアドレスの中から選択されます。
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に記載Helloパケットを送信されて、セクション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 Helloパケットは、次の方法で送信された方法を変更する（9.5節に比較の[OSPFv2の]）：
o Before the Hello packet is sent on an interface, the interface's Interface ID MUST be copied into the Hello packet.
Helloパケットがインターフェイスで送信される前に、O、インタフェースのインタフェースIDは、Helloパケットにコピーする必要があります。
o The Hello packet no longer contains an IP network mask since OSPF for IPv6 runs per-link instead of per-subnet.
IPv6のOSPFはリンクごとの代わりごとのサブネット走るので、Helloパケットoをもはや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指定ルータとバックアップ指定ルータの選択は、今ではルーターIDではなく、自分のIPインタフェースアドレスでハローズ内に示されています。指定ルータのアドバタイズ（またはルータを指定されたバックアップ）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パケット内のオプションフィールドには、プロセスが大きくなって、周りに移動しました。その他のオプションのビットが可能になりました。次のようにHelloパケットに正しく設定しなければならないものがあります。 Eビットは、インターフェースは、通常の領域、すなわち、ないスタブまたはNSSAエリアに付着場合にだけ設定されています。同様に、Nビットは、インタフェースがNSSAエリア（[NSSA]参照）に取り付けられる場合にのみ設定されています。最後に、DCビットが設定されている場合、ルータは、インタフェースを介して、将来のハローズの送信を抑制することを望む場合にのみ（参照[DEMAND]）。 HelloパケットのOptions分野の認識されていないビットはクリアされなければなりません。
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].
[OSPFv2の]のセクション9.5.1に記載されているように、IPv4のとまったく同じように、IPv6のNBMAネットワークが進むにHelloパケットを送信します。
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ビットがセットされている（参照[DEMAND]）。データベース記述パケットのOptions分野の認識されていないビットはクリアされなければなりません。
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プロトコルパケットを受信するたびに、それが受信したインターフェイスが付いています。仮想リンクが設定されているルータの場合、それはパケットを関連付けるためにどのインタフェースを持つすぐに明らかではないかもしれません。例えば、ルータRT11は[のOSPFv2]の図6に示されている考えます。 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ヘッダーに実行する必要がありますパケットのIP宛先アドレスが受信インタフェースに関連付けられたIPv6ユニキャストアドレスのいずれかである必要がありO（これはリンクローカル含みますアドレス）、IPv6マルチキャストアドレスのAllSPFRoutersまたはAllDRoutersの1、または仮想リンクのための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].
任意のカプセル化IP認証ヘッダ（[IPAUTH]参照）、IPカプセル化セキュリティペイロードO（[IPESP]参照）、完全性およびOSPFルーティング交換の認証/秘匿性を確保するために処理及び/又は検証されなければなりません。これは、[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).
全体のOSPFパケットを覆うIPv6の上位層チェックサム（[IPV6]のセクション8.1に記載されているように）、Oおよび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:
OSPFヘッダに見出さOエリア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はリンクごとの代わりにあたり-IPサブネットで実行されます。
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が設定された仮想リンクのもう一方の端でなければなりません。また、受信リンクは仮想リンクのインスタンスIDと一致している必要があり、仮想リンクの構成されたトランジットエリアとインスタンスIDに接続するOSPFv3のインタフェースを持っている必要があります。これらのチェックのすべてが成功した場合、パケットは受け入れられ、仮想リンク（およびバックボーンエリア）に関連しています。
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]).
そのIPv6の宛先であるAllDRouters受信のOSPFv3インタフェースの状態がDRまたはバックアップ（セクション9.1を参照の【のOSPFv2]）である場合にのみ受け入れられるべきであるOパケット。
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.
パケットタイプがこんにちは場合には、セクション4.2.2.1で説明したように、それはその後、さらにHelloパケット処理によって処理されなければなりません。他のすべてのパケットタイプは、隣接番組だけで受信/送信されます。これは、パケットがルータの活発な隣人のいずれかによって送信されていなければならないことを意味します。ネイバーは、受信されたパケットの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.
データベース記述パケット、リンク状態要求パケット、及びリンク状態確認応答パケットの受信処理は、セクション10.6、10.7に記載のIPv4手順とほぼ同一であり、以下に述べる例外を除いて、それぞれ【のOSPFv2]の13.7。
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 LSAは、未知のLSに許容可能な氾濫範囲を持っているデータベース記述パケット内の型は、既知のLSタイプのLSAのと同じように処理されます。 OSPFv2の[OSPFv2の]では、これらはSequenceMismatchイベントに倒されて隣接してしまいます。
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.
Helloパケットの受信は、セクション4.2.2.1に記載されており、リンクステートアップデートパケットの受信は、セクション4.5.1に記載されています。
The receive processing of Hello packets differs from Section 10.5 of [OSPFV2] in the following ways:
Helloパケットの受信処理は以下の方法で【の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によって識別されます。仮想リンク以外のすべてのリンクタイプでは、ネイバーIPアドレスが受信OSPF HelloパケットのIPv6ヘッダーのIPv6ソースアドレスに設定されています。
o There is no longer a Network Mask field in the Hello packet.
Oネットワークマスクフィールドは、Helloパケットにはもうありません。
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指定ルータとバックアップ指定ルータの隣人の選択は、今OSPFルータIDの代わりに、IPインターフェイスアドレスとしてエンコードされます。
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アドレスのプレフィックスのためともAS境界ルータのルーティングテーブルエントリがあります。後者のルーティングテーブルエントリのみ、ルーティングテーブルの構築プロセス中に中間結果を保持するために使用される（セクション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によって識別されます。これらのルーティングテーブルエントリは、次に、エリア内プレフィックスLSAの中でそのルータによってアドバタイズ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の組み合わせによって識別されます。これらのルーティングテーブルエントリは、イントラ領域プレフィックスのLSAにトランジットリンクにアドバタイズ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プレフィックスへのルートを記述している場合、例えば、リンク状態の起源は、ルートを作成したエリア内プレフィックス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のようなIPv6のための同じです。
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-外部LSAとNSSA-のLSA）、他のLSAの名称が変更されているが（タイプ3および4要約LSAの変更されました今エリア間プレフィックス-のLSAおよびインターエリアルータLSAは、それぞれ）と追加のLSAは（リンクのLSAとエリア内プレフィックス-LSAを）追加されました。サービスのタイプ（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に変更されています。 LSAヘッダ内LSの年齢、広告ルータ、LSシーケンス番号、LSチェックサム、および長さフィールドは、セクション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、およびリンクLSAの本体内に移動されています。 （付録A.2を参照）オプションフィールドのサイズは24ビットに8から増加しており、ビット定義の一部が変更されています。また、別PrefixOptionsフィールドは、長さが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タイプフィールドのサイズは、上位ビットが未知のタイプの取り扱いおよび氾濫範囲をコード次の2ビットを符号化して、8ビットから16ビットに増加しているタイプ。 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とリンクのLSAを除き、リンクステートIDは、任意のアドレス指定のセマンティクスを流しました。例えば、複数のASの外部のLSAを発信IPv6ルータはそうで0.0.0.1の最初のリンク状態ID、0.0.0.2の第2のリンクステートIDを割り当てることによって開始し、可能性があります。代わりに、ASの外部の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つのインスタンスを考えると、最新のインスタンスは、（[OSPFv2の]のセクション13.1を参照してください）タイブレークとしてLSチェックサムとLS時代を使用して、LSAのLSシーケンス番号を調べることによって決定されます。
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つの別々のデータ構造に分割されています。 AS氾濫範囲とのLSAは、トップレベルOSPFデータ構造内に含まれているいずれかのそのLSタイプが知られているか、または、それらのUビットが1（洪水場合であっても認識されていない）である限り（セクション4.1を参照）。これはASの外部のLSAを含んでいます。エリアフラッディングスコープを持つLSAは限り、いずれかのそれらのLSタイプが知られているか、または、それらのUビットが1（洪水場合であっても認識されていない）であるように（セクション4.1.1を参照）、適切なエリア構造内に含まれます。これは、ルータのLSA、ネットワークLSAを、インターエリア・プレフィックスLSAを、インターエリアルータLSAを、NSSA-のLSA、およびエリア内プレフィックス-LSAを含んでいます。 （セクション4.1.2を参照）未知のLSタイプのLSAは、Uビットは0に設定され、及び/又はリンクローカルフラッディングスコープは、適切なインターフェース構造内に含まれています。これは、リンク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のタイプ、リンクステートID、および広告ルータに基づいて検索LSAの正しいデータベースを検索することができます。
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をreoriginatingのプロセスは、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:
IPv4のreoriginatedするLSAを引き起こすイベントのリストが[の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.
ルータのインタフェースの変更のいずれかの状態又はインタフェースID O。ルータが発信またはそのリンクLSAと1つまたは複数のルータのLSAおよび/またはエリア内プレフィックス-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が変更されます。これは、ルータ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をreoriginateする原因となるか、それがリンクに接続ルータだけであれば、エリア内プレフィックス-LSAをreoriginateにルータを引き起こします。
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新しいリンク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のネットワークマップは、図1に各インタフェースのOSPFコストをネットワークリンクにIPv6プレフィックスの割当同図に表示され、その結果、IPv6アドレスを示すために再加工されました0DB8：C001 :: / 48エリア1の外部は、そのプレフィックスのすべてが2001年単一の経路によって覆われているので、単一領域アドレス範囲は、エリア1に設定されている表1に示されています。図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の中のオプションフィールドは、符号化されなければなりません。ルータはトランジットIPv6ルーティングに参加しない場合を除きV6ビットを設定する必要があります。取り付け領域は、OSPFスタブやOSPF NSSA領域である場合にのみEビットは明らかであろう。 E-ビットは常にASスコープのLSAに設定する必要があります。 Nビットは、接続領域がOSPF NSSA領域である場合にのみ設定されるべきです。ルータは、任意の輸送ルーティングに参加しない場合を除き、Rビットが設定されるべきです。それはLSAのLS時代分野に表示されたときに、ルータが正しくDoNotAgeビットを処理できる場合にのみ、および場合DCビットが設定されるべきである（参照[DEMAND]）。オプションフィールド内のすべての認識されていないビットはクリアされなければなりません。
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は[のOSPFv2]のセクション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,
地域へのルータのインターフェイスの各々は、ルータLSAに「リンクの説明」を追加することによって説明されます。各リンクの説明は、5つのフィールドからなる、16バイト長である：（リンク）型、
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.
メトリック、インタフェース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リンク記述（ポイントツーポイント）を追加します。ネイバーインターフェイスIDフィールドは、そのHelloパケットに隣人によって広告インタフェースIDに設定され、近隣ルーターIDフィールドは、ネイバーのルータ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に設定されており、近隣ルーター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リンクの説明（仮想）を追加します。ネイバーインターフェイスIDフィールドは、そのHelloパケットに隣人によって広告インタフェースIDに設定され、近隣ルーターIDフィールドは、ネイバーのルータ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に隣接インタフェース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.
一例として、ルータRT3は、単一のインターフェースを記述する必要があり、図1の領域1のための起源であろう、すなわち、それは中継網N3に接続することをルータLSAを考えます。これは、RT4は、ネットワークN3の指定ルータに選出されていることを前提としています。
; RT3's router-LSA for Area 1
; RT3のルータLSAエリア1について
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
LSの年齢= 0; AS境界ルータビットB = 1ではない、新たに（再）0x2001 = LSタイプを発信し、ルータLSAリンクステートID = 0;最初のフラグメント広告ルータ= 192.0.2.3; RT3のルータIDは、E = 0ビット;エリアボーダルータオプション=（V6ビット| Eビット| Rビット）TYPE = 2; N3メトリック= 1に接続され、N3ネイバーインタフェースID = 1にRT3のインターフェースID; N3インタフェースID = 1のコストRT4のN3近隣ルーターID = 192.0.2.4のインターフェイスID; RT4のルータID
RT3's router-LSA for Area 1
RT3のルータLSAエリア1について
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のリンクの説明を宣伝する必要があります。これは、2つのリンクの記述で、この時間を上記ルータLSAをreoriginatingすることによって達成することができます。または、別ルータLSAは、N4への接続を記述するために（例えば、1のリンクステートIDを使用して）別のリンクステートIDで発信することができます。
Host routes for stub networks no longer appear in the router-LSA. Rather, they are included in intra-area-prefix-LSAs.
スタブネットワークのためのホストルートはもはやルータLSAには表示されません。むしろ、それらはエリア内プレフィックス-の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のネットワーク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のネットワーク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内に含まれるオプションのフィールドで設定されています。リンク上の少なくとも一つの完全隣接隣人は機能をアドバタイズすることを要求したときにこのように、ネットワークリンクが機能を発揮します。
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:
一例として、ルータRT4は、図1のネットワークN3の代表ルータに選出されたと仮定すると、次のネットワーク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
LS年齢= 0;新規（再）0x2002 = LSタイプを発信し、ネットワークLSAリンクステートID = 1; RT4のインタフェースIDは、N3広告ルータ= 192.0.2.4に、RT4のルータIDオプション=（V6ビット| E-ビットは|ルータ= 192.0.2.4結合したRビット）、ルータID接続ルータ= 192.0.2.1;ルータIDルータ= 192.0.2.2取り付けられたルータID、ルータIDルータ= 192.0.2.3付属
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を発信するための手順は、以下の例外を除いて、セクション12.4.3および【のOSPFv2]の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エリア間プレフィックス-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の本体内に埋め込まれPrefixLength、PrefixOptions、およびアドレスプレフィックスフィールドによって記述されます。ネットワークマスクはもはや指定されていません。
o The NU-bit in the PrefixOptions field should be clear.
O PrefixOptionsフィールドにNU-ビットは、明確にする必要があります。
o Link-local addresses MUST never be advertised in inter-area-prefix-LSAs.
Oリンクローカルアドレスは、エリア間プレフィックス-の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.
0DB8：C001 :: / 48例として、次のルータRT4は、単一のプレフィックス2001にエリア1のプレフィックスの全てを凝縮、OSPFバックボーンエリアに発信することエリア間プレフィックスLSAを示しています。コストは、個々の成分プレフィックスの全ての最大コストである、4に設定されています。それは空間の64ビットの代わりに48ビットを消費するように接頭辞は、32ビットワードの偶数にパディングされます。
; Inter-area-prefix-LSA for Area 1 addresses
; originated by Router RT4 into the backbone
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
LSの年齢= 0;新規（再）発祥LSタイプ= 0x2003;エリア間プレフィックス-LSAの広告ルータ= 192.0.2.4; RT4のIDメトリック= 4;コンポーネントへの最大PrefixLength = 48 PrefixOptions = 0アドレスプレフィックス= 2001：0DB8 ：C001; 64ビットにパディング
Inter-area-prefix-LSA for Area 1 addresses originated by Router RT4 into the backbone
インターエリア・プレフィックスLSAバックボーンにルータRT4によって発信エリア1つのアドレスについて
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.
一例として、OSPF自律システムは、[のOSPFv2]の図6に示されている考えます。ルータRT4は、宛先ルータRT7のためのエリア1次インターエリアルータLSAに発信します。
; inter-area-router-LSA for AS boundary router RT7
; originated by Router RT4 into Area 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
LSの年齢= 0;新規（再）発祥LSタイプ= 0x2004;インターエリアルータLSAの広告ルータ= 192.0.2.4; RT4のIDオプション=（V6ビット| E-ビット| R-ビット）; RT7の能力メトリック= 14; RT7先へのコストのルータID =ルータRT7のID
Inter-area-router-LSA for AS boundary router RT7 originated by Router RT4 into Area 1
エリア1にルータRT4によって発信AS境界ルータRT7のためのインターエリアルータLSA
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の外部のLSAのLSタイプは、値0x4005に設定されています。 ASの外部のLSAは、フラッディングスコープとして持っています。各ASの外部の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-外部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の外部のLSAのリンク状態IDは、そのアドレス指定のセマンティクスの全てを失い、単に同じルータによって発信された複数のASの外部の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の本体内に埋め込まれPrefixLength、PrefixOptions、およびアドレスプレフィックスフィールドによって記述されます。ネットワークマスクはもはや指定されていません。
o The NU-bit in the PrefixOptions field should be clear.
O PrefixOptionsフィールドにNU-ビットは、明確にする必要があります。
o Link-local addresses can never be advertised in AS-external-LSAs.
Oリンクローカルアドレスは、ASの外部の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.
ASの外部のLSAのビットFがセットされている場合だけO転送先アドレスは、ASの外部の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.
ASの外部のLSAのビットTが設定されている場合だけ外部ルートタグOなどの外部の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別のLSAを参照するASの外部のLSAのための能力は、参照LSタイプフィールドの包含およびオプション参照さLink州IDフィールド（後者存在する場合、参照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.
一例として、OSPF自律システムは、[のOSPFv2]の図6に示されている考えます。 RT7は、BGPを経由して、それはASにタイプ2のメトリックをアドバタイズするように望んでいることをN12へのルートを学習したことを前提としています。 0DB8：0A00 :: / 40またN12のためのIPv6プレフィックスが値2001であることを前提としています。 RT7は、外部ネットワークN12のために、以下のASの外部のLSAを発信します。 AS-外部LSA内で、N12のプレフィックスは32ビットの整列を維持するために、空間の64ビットを占有することに留意されたいです。
; AS-external-LSA for Network N12,
; originated by 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
LSの年齢= 0;新規（再）発祥LSタイプ= 0x4005; ASの外部のLSAリンクステートID = 123; LSAタイプ/スコープ固有の識別子広告ルータ=ルータRT7のIDビットE = 1;タイプ2メトリックビットF = 0 ; NO転送先アドレスビットT = 1は、外部ルートタグは、メトリックが含ま= 2 PrefixLength = 40 PrefixOptions = 0参照さLSタイプ= 0; NO参照さLink州IDアドレスプレフィックス= 2001：0DB8：0A00、64ビットの外部ルートタグに埋め= BGP / OSPF相互作用あたりとして
AS-external-LSA for Network N12, originated by Router RT7
ルータRT7によって発信ネットワークN12のためのASの外部のLSA、
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:
IPv6ではNSSA-LSAを発信するための手順は、以下の例外を除いて、[NSSA]に記載のIPv4手順と同じです。
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.
O NSSA-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の本体内に埋め込まれPrefixLength、PrefixOptions、およびアドレスプレフィックスフィールドによって記述されます。ネットワークマスクはもはや指定されていません。
o The NU-bit in the PrefixOptions field should be clear.
O PrefixOptionsフィールドにNU-ビットは、明確にする必要があります。
o Link-local addresses can never be advertised in NSSA-LSAs.
Oリンクローカルアドレスは、NSSA-LSAの中で宣伝することはできません。
o The forwarding address is present in the NSSA-LSA if and only if the NSSA-LSA's bit F is set.
NSSA-LSAのビットFが設定されている場合だけO転送アドレスは、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.
NSSA-LSAのビットTが設定されている場合だけO外部ルートタグは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.
参照さLSタイプフィールドの包含およびオプション参照さLink州IDフィールドを介して支持されているNSSA-LSAは別のLSAを参照するための能力O（後者存在する場合、参照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タイプが0x2007なく0x4005であろうことにASの外部の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.
リンクLSAのLSタイプは、値0x0008でに設定されています。リンクLSAは、リンクローカルフラッディングスコープを持っています。ルータは、ルータ（発信元ルータ自体を含む）は、2つ以上をサポートする各取り付けリンクのための別個のリンクLSAを発信します。リンクLSAは仮想リンクのために発信してはいけない（SHOULD NOT）。
Link-LSAs have three purposes:
リンク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:
リンクLSA与えられたリンクLについては、以下の方法で構築されています。
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をリンクにルータのインターフェイスのルータプライオリティは、リンク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リンクLSAのOptionsフィールドは、ルータの機能を反映するように設定されています。マルチアクセスリンクでは、指定ルータは、論理的ORリンクLSAのオプションは、リンクL'sのネットワーク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ルータは、リンクLSAにリンクL上のリンクローカルアドレスを挿入します。リンク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アドレスのプレフィックスはPrefixLength、PrefixOptions、およびアドレスプレフィックスのフィールドに値を指定することで、リンク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を受信しますが、彼らは他のリンク上のリンク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.
LinkLSASuppressionがインタフェースとインタフェースタイプに設定されている場合、ブロードキャストまたはNBMAされていない、リンクLSAの発信を抑制することができます。これは、リンク上の他のルータはリンクLSA（セクション4.8.2を参照）以外のメカニズムを使用してルータのネクストホップアドレスを確認することを意味します。 LinkLSASuppressionインターフェイスコンフィギュレーションパラメータの説明については、付録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.
例として、リンクLSA RT3は接頭辞2001と仮定し、図1にN3のために構築することを検討してください。0DB8：C001：0100 :: / 56は、N3のためRT3内で設定されています。これは、次のリンク-LSA RT3のみN3にあふれすることになります。 N3上のすべてのルータが接頭辞を使用して構成する必要はないことに注意してください。 RT3のリンク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
LS年齢= 0;新規（再）0x0008で= LSタイプを発信し、リンクLSAリンクステートID = 1; RT3のインタフェースIDは、N3広告ルータ= 192.0.2.3に、RT3のルータIDのRTR優先順位= 1; RT3のN3ルータの優先順位オプション= （V6ビット| Eビット| Rビット）リンクローカルインタフェースアドレス= FE80：0001 :: RT3＃プレフィックス= 1 PrefixLength = 56 PrefixOptions = 0アドレスプレフィックス= 2001：0DB8：C001：0100;パッド64しますビット
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.
エリア内プレフィックスLSAのLSタイプは、値0x2009に設定されています。エリア内プレフィックス-LSAはエリアフラッディングスコープを持っています。エリア内プレフィックス-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を生じてもよいです。各エリア内プレフィックス-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、、参照広告ルータで参照フィールドは、リンクLのネットワークLSA（すなわち、LS型の対応するフィールドに設定されていますそれぞれリンクステート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
OリンクLに関連付けられた各リンクLSAは（これらは、リンクLの代表ルータのインタフェース構造である）を調べています。リンクLSAの広告ルータは、指定に完全に隣接している場合
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.
ルータおよびリンクステートIDは、隣人のインタフェースIDと一致して、リンクLSAにおける接頭辞のリストが構築されているエリア内プレフィックス-LSAにコピーされます。そのオプションフィールドに設定さNU-bitおよび/またはLA-ビットを持つ接頭辞がコピーされるべきではないにもリンクローカルアドレスをコピーする必要があります。各プレフィックスはPrefixLength、PrefixOptions、およびアドレスプレフィックスフィールドによって記述されています。同じPrefixLengthとアドレスプレフィックスを持つ複数のプレフィックスは重複と見なされます。この場合には、それらのPrefixOptionsフィールドは、論理的に論理和されるべきであり、重複したプレフィックスの単一のインスタンスは、エリア内プレフィックス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:
ルータは、添付のスタブリンク、ループバック・インターフェース、およびホストのプレフィックスを通知するエリア内プレフィックスLSAを構築します。ルータRTXは、次の方法でそのエリア内プレフィックス-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は0x2001を基準LSタイプを設定し、0を基準とリンクステートID、および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ルータRTXは、領域へのインタフェースのリストを調べます。インターフェイスがダウン状態にある場合は、そのプレフィックスが含まれていません。インタフェースはタイプ2のリンク記述（トランジットネットワークへのリンク）としてRTXのルータLSAで報告されている場合は、リンクのために、エリア内プレフィックス-LSAに含まれるプレフィックスはスキップされます。しかしながら、通常LAビットセットを有するであろう任意のプレフィックスインターフェイスがトランジットリンクとして広告されているか否かとは無関係にアドバタイズされるべきです。インターフェイスタイプがポイントツーマルチポイントであるか、または界面状態ループバックである場合、インターフェース（もしあれば）に関連付けられたグローバルスコープのIPv6アドレスはPrefixOptions LA-ビットが設定されたエリア内プレフィックスLSAにコピーされますPrefixLengthは、そうでなければ0に128に設定し、メトリックセット、リンクに対してRTXに設定されたグローバルプレフィックスのリストがPrefixLength、PrefixOptions、およびアドレスプレフィックスフィールドを指定することにより、エリア内プレフィックス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は、イントラエリアプリフィクスLSAに（付録C.7参照）の領域に属するすべての直接接続されたホストのIPv6プレフィックスを追加します。
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.
128 PrefixLength、PrefixOptionsフィールドにLAビットを設定し、RTXは領域を通じて構成された1つのまたは複数の仮想リンクを持っている場合（それが既にいない場合）、それはLSAにグローバルスコープのIPv6インタフェースアドレスのいずれかを含み、O仮想リンクの両端が互いのIPv6アドレスを発見することができるように、およびメトリックは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に広がることができます。
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.
独自のプレフィックスが以下描かれているため、例えば、エリア内プレフィックスLSAは、ネットワークN3のためRT4（RT4がN3の代表ルータであると仮定）とエリア内プレフィックスLSAによって発信ルータRT3により、エリア1に発信しました。
; 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
LSの年齢= 0;新規（再）発祥LSタイプ= 0x2009;イントラ・エリア・プレフィックスLSAリンクステートID = 5; LSAタイプ/スコープ固有の識別子広告ルータ= 192.0.2.4; RT4のルータID番号の接頭辞= 1参照先LSタイプ= 0x2002;ネットワークLSAの参照参考リンクステートID = 1対象広告ルータ= 192.0.2.4 PrefixLength = 56; N3の接頭PrefixOptions = 0メートル= 0アドレスプレフィックス= 2001：0DB8：C001：0100;パッド
; RT3's Intra-area-prefix-LSA for its own prefixes
;独自のプレフィックスのRT3のイントラ・エリア・プレフィックス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
LSの年齢= 0;新規（再）発祥LSタイプ= 0x2009;イントラ・エリア・プレフィックスLSAリンクステートID = 177; LSAタイプ/範囲固有の識別子広告ルータ= 192.0.2.3; RT3のルータID番号の接頭辞= 1参照先LSタイプ= 0x2001;リンクステートID = 0対象広告ルータ= 192.0.2.3 PrefixLength = 56を参照されたルータLSAの参照、N4のプレフィックスPrefixOptions =メートル= 2 0; N4インタフェースコストアドレスプレフィックス= 2001：0DB8：C001：0400;パッド
Intra-area-prefix-LSA for Network Link N3
ネットワークリンクN3ため、エリア内プレフィックス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.
ネットワークの状態が変化したときに、ルータが別のエリア内プレフィックスLSAからプレフィックスを移動することが必要であってもよいです。ルータはリンクの代表ルータですが、リンクは、他の接続されたルータを持っていない場合たとえば、リンクのプレフィックスが指定ルータのルータ - 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.
エリア内プレフィックス-LSAで、対象広告ルータは常に、エリア内プレフィックス-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.
例えば、のOSPFv3のLSAは不透明LSA [OPAQUE]を使用してのOSPFv2で広告情報に対応する新規のLSAは、セクション4.8で説明したように最短パス優先（SPF）計算中に処理されないように定義されることが期待されます。 LSAを発信するのOSPFv3ルータが到達可能でない限り、一般的には、将来のLSAでアドバタイズ新しい情報は使用すべきではありません。ただし、アプリケーションに応じて、データがアドバタイズ、この到達可能性の検証は、すべてのSPF計算よりも少ない頻度で行うことができます。
To facilitate inter-area reachability validation, any OSPFv3 router originating AS scoped LSAs is considered an AS Boundary Router (ASBR).
エリア間の到達可能性の検証を容易にするために、ASスコープのLSAを発信するあらゆるのOSPFv3ルータがAS境界ルータ（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インスタンスを決定するためのプロトコルのプロセスは、自己由来のLSA（【のOSPFv2]のセクション13.4）の更新に応答し、新しい（[のOSPFv2]のセクション13.1）であり、リンク状態確認応答パケットを送信する（[OSPFv2のセクション13.5 ]）のLSA [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-ビットの設定を行う必要があります。また、OSPFデータベース（[のOSPFv2]のセクション13.2）へのLSAのインストールは、LSAタイプとIPv6のLSAの内容の再編成のために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
LSタイプの洪水の範囲のエンコードおよび未知のLSタイプを処理する必要が受信したリンクステートアップデートパケットの処理に変更を引き起こします。 IPv4の、受信したリンクの各LSAのよう
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:
州Updateパケットを調べています。 【のOSPFv2]のセクション13に記載されるようにIPv4では、8つのステップは、各LSAのために実行されます。それは次のように2および3が改変されている手順以外IPv6の場合、すべてのステップは、同じです。
(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タイプを調べます。 LSAを破棄し、インタフェース領域がスタブまたはNSSAエリアとして設定されていて、LSタイプが「フラッディングスコープAS」を示す場合、リンクステートアップデートパケットから、次のいずれかを取得します。
This generalizes the IPv4 behavior where AS-external-LSAs
and AS-scoped opaque LSAs [OPAQUE] are not flooded
throughout stub or NSSA areas.
(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を破棄し、リンクステートアップデートパケットから次のいずれかを取得。
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.
セクション4.5.2および4.5.3以下に記載されるように【のOSPFv2]のセクション13の手順5bと（リンク状態更新パケットを送信する）および5D（リンクステートデータベースにLSAをインストール）は、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.
LSAの氾濫範囲O。
o For LSAs with area or link-local flooding scope, the particular area or interface with which the LSA is associated.
領域またはリンクローカルフラッディングスコープ、LSAが関連付けられている特定の領域またはインタフェースとのLSAについては、O。
o Whether the LSA has a recognized LS type.
LSAが認識LSタイプがあるかどうか、O。
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.
LS型でUビットの設定O。 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).
LSAのLSタイプ1の場合は、認識されています。この場合、対象インターフェイスのセットは、LSタイプに符号化氾濫範囲に応じて設定されます。氾濫範囲がある場合は、「フラッディングスコープAS」、適格なインターフェイスは、仮想リンクを除いて、すべてのルータインターフェイスです。また、ASの外部のLSAは、スタブまたはNSSAエリアに接続するインターフェイスにフラッディングされません。氾濫範囲は「エリアフラッディングスコープ」である場合は、資格のインターフェイスはLSAの関連する領域に接続するインタフェースです。フラッディングスコープ「は、リンクローカルフラッディングスコープ」であれば、単一のインタフェース資格があり、（また、LSAがリンクステートアップデートパケットで受信したインターフェイスである）LSAの関連するリンクに接続している1。
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.
LSタイプ2の場合は、認識されないとLS型でUビットは、（それがリンクローカルフラッディングスコープを持っていたかのようにLSAを治療する）を0に設定されています。この場合、単一の対象インターフェース、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.
さらに判決は、時々与えられた隣人のリンクステート再送リスト（[OSPFv2の]のセクション13.3でステップ1D）にLSAを追加する前に行う必要があります。 （隣人がそのデータベース記述パケットでアドバタイズというオプションフィールドを調べることによって決定することができる）LSタイプがなく、隣人によってルータによって認識され、LSAのUビットが0に設定されている場合は、LSAはする必要があります隣人のリンクステート再送リストに追加した場合は、その隣人が接続リンクの代表ルータまたはバックアップ指定ルータである場合にのみ。本文書により詳細に説明LSタイプ、すなわち、ルータのLSA（LS型0x2001）、ネットワークのLSA（0x2002）、インターエリアプレフィックスのLSA（0x2003）、インターエリアルータのLSA（0x2004）、 NSSA-のLSA（0x2007）、AS-外部のLSA（0x4005）は、リンクのLSA（0x0008で）、およびエリア内プレフィクスのLSA（0x2009）、すべてのルータによって理解されるものとします。しかし、すべてのLSタイプは、すべてのルータによって理解することはできません。例えば、0に設定されたUビットを持つ新しい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.
前の段落は、指定ルータはブロードキャストおよびNBMAネットワーク間で浸水新しいLSAタイプを持っているために、拡張をサポートすることを必要とIPv4のOSPF拡張のための問題を解決します。
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を格納するための3つの別々の場所があります。氾濫範囲ASとLSAがあれば、それらのLSタイプが知られているか、または、それらのUビットが領域氾濫範囲と1のLSAは、適切なエリアデータ構造に格納されている（セクションを参照されたように（セクション4.1を参照）グローバルOSPFデータ構造に格納されています4.1.1）限り、そのLSタイプが知られているか、または自分のUビットが1のリンクローカルフラッディングスコープを持つLSAを、そして0に設定し、未知のLSタイプとUビットとのそれらのLSA（それが持っていたかのようにLSAを扱うですとリンクローカルフラッディングスコープ）、適切なインターフェイスデータ構造体に格納されています。
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を格納すると、チェックが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).
ルータのLSA、ネットワークのLSA、エリア内プレフィクスのLSA、およびリンクのLSA全体ルーティングテーブルは各領域の最短パスの計算で始まる、再計算される（セクション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と相互領域-ルータ - LSAのLSAによって記述宛先への最適なルートは、（[OSPFv2の]セクション16.5を参照）を再計算しなければなりません。この先がAS境界ルータである場合、それはまた、すべてのASの外部の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-外部のLSAとNSSA-のLSA AS-外部LSAまたはNSSA-LSAによって記述宛先への最適なルートは、（[OSPFv2の]セクション16.6及び[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では、自己由来LSAの定義は、セクション13.4及び【のOSPFv2]の14.1に現れるIPv4の定義から簡略化されています。 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の外部の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は、仮想リンクのために発信してはいけない（SHOULD NOT）。
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同様に、仮想の隣人のIPv6アドレスは、グローバルスコープを持つIPv6アドレスです。ルーティング計算の中に仮想の隣人のIPv6アドレスの発見を有効にするには、隣人が仮想リンクのトランジットエリアの起源・プレフィックス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.
他のすべてのIPv6 OSPFインタフェースと同様O、仮想リンクは、インターフェースのID（ルータ内で）一意に割り当てられています。これらは、仮想リンク上およびルータのルータの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:
【のOSPFv2]のセクション16で指定された5つのステップ次のIPv4 OSPFルーティング計算と同じ線に沿ってIPv6の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プレフィックス情報は、ルータのLSAとネットワークLSAのから削除されており、現在エリア内プレフィックス-のLSAでアドバタイズされます。 [OSPFv2には]ルータのLSA内のスタブネットワークを検討することを指定するたびに、IPv6は、代わりに、エリア内プレフィックス-の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を使用し、インターエリアルータのLSAれます。
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とネットワークLSAのに代表されるルータやトランジットリンクされています。トランジットリンクは、指定ルータのインターフェイスIDとOSPFルータ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つの段階に最短パス計算を分割します。まず、ダイクストラの計算が行われ、その後、スタブリンク葉としてツリーに追加されます。 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]):
（【のOSPFv2]のセクション16.1に記載されているようにダイクストラ計算の手順を参照）IPv6のダイクストラ計算は、以下の例外を除いて、IPv4の指定されたものと同一です。
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ルータ頂点Vはちょうど最短経路ツリーに追加されたステップ2では、ルータに関連付けられた複数のLSAが存在してもよいです。広告ルータとのすべてのルータLSAは、単一の大規模なルータLSAの断片として扱う、集合体として処理しなければなりませんVのOSPFルータIDを設定します。オプションフィールドとルータタイプビット（ビット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.
ルータのLSAでもはやスタブネットワークリンクがあるので、Oステップ2aは、IPv6では必要ありません。
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.
Wは、ルータおよびルータLSA V6ビットまたはRビットは、LSAオプションで設定されていないいる場合、Oステップ2bにおいて、トランジットリンク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.
Wがルータである場合、Oステップ2bにおいて、再びルータに関連付けられた複数のLSAが存在してもよいです。広告ルータとのすべてのルータLSAは、単一の大規模なルータLSAの断片として扱う、集合体として処理しなければなりませんWのOSPFルータIDを設定します。
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.
ステップ4中のO、毎エリア面積のルータだけではなく、エリア境界ルータの各々についてテーブルエントリをルーティング今あります。これらのエントリは、仮想リンクのメンテナンスを含めたIPv4のエリア境界ルータのルーティングテーブルエントリのすべての機能を、包摂します。仮想の隣人によって発信エリア内プレフィックス-LSAのコレクションをして、検討されています。この段階でエリアルーティングテーブルに追加ルータが仮想リンクのもう一方の端がある場合は、次のように、仮想の隣人の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.
もはやIPネットワークに関連付けられている中継ネットワークのためのルーティングテーブルエントリ、O、また、ステップ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の第二段階の二段階と同様に進みます。しかし、代わりにルータのLSA、エリアのエリア内プレフィックス-LSAのリスト内のスタブのリンクを調べる検査されます。 NU-ビットが設定されているプレフィックス広告は、ルーティング計算に含めるべきではありません。任意の広告を出して接頭辞のコストは、イントラエリアプリフィクスLSAの参考とLSタイプ、参照されたリンクステートID、および参照先の広告ルータで識別トランジット頂点（ルータまたはトランジットネットワークのいずれか）へのプレフィックスのアドバタイズされたメトリックコストプラスの合計ですフィールド。この後者のコストは、領域のトランジット頂点のルーティングテーブルエントリに格納されています。
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では、（リンクローカルアドレスであろう）ネクストホップのIPv6アドレスの計算は、（[のOSPFv2]のセクション16.1.1を参照）のIPv4ネクストホップ計算と同じ線に沿って進みます。しかし、いくつかの違いがあります。計算のルータとのリンクを共有するルータのネクストホップのIPv6アドレスを（ルータXそれを呼び出す）を計算すると、計算のルータは、ルータXのリンク - に含まれるリンクローカルインターフェイスアドレスであることをネクストホップのIPv6アドレスを割り当てリンクのLSA（付録A.4.9を参照）。この手順は、2つのルータが隣人である必要はなく、OSPF Helloパケットを交換していない可能性がありますたとえばNBMA、のために、いくつかのリンクタイプのために必要です。他のリンクタイプの場合、次ホップアドレスは、ネイバーのHelloパケット内の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.
エリアのエリア内プレフィックス-のLSAのルートを計算するとき、また、親頂点は、ルータLSAまたはネットワークLSAのいずれかになります。これは、親頂点が常にルータLSAでのOSPFv2エリア内のSPF（[OSPFv2の]セクション16.1）の第二段階とは対照的です。エリア内プレフィックスLSAの参照LSAは、直接接続されたネットワークLSAである場合、接頭辞は直接接続されていると考えられます。この場合、次のホップは単に発信リンクで、何のIPv6ネクストホップアドレスが選択されていません。
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接頭辞は、そのPrefixOptionsフィールドに設定NU-ビットエリア間経路計算によって無視されるべき有します。
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の検討は、セクション4.8.3でIPv6のエリア間ルート計算と同じ方法で変更【の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:
以下の例外を除いて【のOSPFv2]のセクション16.4および[NSSA]のセクション2.5でIPv4の計算と同じ線に沿って外部ルート計算が進むにつれてIPv6の、：
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の外部の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外部のLSAまたは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代わりに、転送先アドレスが使用されたかどうかを確認するために0.0.0.0にAS-外部LSAのまたはNSSA-LSAの転送アドレスフィールドを比較し、それぞれのLSAのビットFが検査されます。転送先アドレスは、ビットFがセットされている場合に限り使用されています。
o Prefixes having the NU-bit set in their PrefixOptions field should be ignored by the inter-area route calculation.
O接頭辞は、そのPrefixOptionsフィールドに設定NU-ビットエリア間経路計算によって無視されるべき有します。
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.
境界ルータ（ASBR）と転送アドレス選択が同じ進めるAS O RFC1583Compatibilityが無効になっているかのように。さらに、RFC1583Compatibilityは、OSPF、IPv6の設定パラメータではありません。付録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の外部の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が割り当てられます。ルータは、自動的に複数のインタフェースを検出するHelloパケットを受信インタフェースのインタフェースID以外のソースアドレス及びインタフェースIDなどのルータのリンクローカルアドレスのいずれかで受信される同一のリンクに接続されています。
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ルータはリンクに接続されたインターフェイスのいずれかが、すべてのHelloパケット以外のOSPFパケットを無視します。これは、単一のインターフェイス上で（Helloパケットを含む）のOSPF制御パケットを送信します。このインタフェースは、アクティブインターフェースと同じリンクに取り付けられ、他のインターフェイスがスタンバイインターフェイスを指定する指定されています。アクティブインターフェースの選択は実装依存です。例えば、最高のインタフェースIDとのインターフェースを選択することができます。ルータが指定ルータに選出された場合、それは、ネットワーク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である場合、例えば、アクティブインターフェースのプレフィックスは、アクティブインターフェースのネットワークLSAに関連付けられているエリア内プレフィックス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、新しいアクティブインターフェースが引き継ぐ必要があります。新しいアクティブインターフェースは、リンク上のルータとのすべての新しい隣人との隣接関係を形成すべきです。この失敗は、アクティブインターフェースの状態を監視し、例えば、ルータのhelloを聞くためにアクティブなインターフェイスのリンク停止する場合、ルータの他のインターフェイスを検出または内部機構を介してすることができます。
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.
この状態では、インタフェースは、リンクの複数のインターフェイスの一つであり、このインタフェースは、スタンバイを指定され、制御パケットを送信または受信していません。インターフェイスはアクティブインターフェースにより送信されたHelloパケットを受信し続けます。インタフェースはRouterDeadIntervalと同じ間隔で、タイマー、アクティブインターフェースタイマーを維持します。 OSPF Helloパケットをリンクにアクティブインターフェースから受信されるたびに、このタイマーはリセットされます。
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とActiveInterfaceDead：二つの新しいイベントは、インタフェース状態の変化を引き起こす事象のリストに追加されます。次のようにこれらのイベントの説明は、次のとおりです。
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.
ルータのMultipleInterfacesToLinkアンインターフェイスが同じルータ上の別のインターフェイスからのHelloパケットを受信しました。インターフェースの一つは、アクティブインターフェイスとして指定され、他のインターフェイスは、スタンバイインターフェイスとして指定されています。待機インタフェースは、スタンバイ状態に移行します。
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スタンバイインターフェイスがアクティブインターフェイスとのリンクの上にもはやである旨の表示がなされてきました。それはスタンバイインターフェイスがRouterDeadInterval用アクティブインターフェースからOSPF Helloパケットを受信していないことを示しているとアクティブインターフェースタイマーの焼成は、このイベントの一つの指標です。他の適応症には、このような構成の変更によって無効にされているアクティブインターフェイスとして内部通知、から来るかもしれません。ルータへの内部の任意の表示は、ルータがアクティブインターフェイスがリンク上でもはやアクティブであることを知っていないような、スタンバイインターフェイスのActiveInterfaceDeadイベントをトリガすることができます。
Interface state machine additions include:
インターフェイスのステートマシンの追加は、次のとおりです。
State(s): Waiting, DR Other, Backup, or DR
状態（S）：待つ、DRの他、バックアップ、またはDR
Event: MultipleInterfacesToLink
イベント：MultipleInterfacesToLink
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を発生させることにより行われます。アクティブインターフェースタイマーが開始され、インターフェイスがリンクのアクティブインターフェースからOSPF Helloパケットをリッスンします。
State(s): Standby
状態（S）：スタンバイ
Event: ActiveInterfaceDead
イベント：ActiveInterfaceDead
New state: Down
新しい状態：ダウン
Action: The Active Interface Timer is first disabled. Then the InterfaceUp event is invoked.
処置：アクティブインターフェースタイマーが最初に無効になっています。そして、InterfaceUpイベントが呼び出されます。
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カプセル化セキュリティペイロード（[IPESP]を参照）に依存しています。これは、[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のパケットを保護するために使用された場合、実装は、OSPFパケットを確実にするためにIPsecセキュリティアソシエーション（SA）とローカルSAデータベースをチェックすることが重要であるOSPFv3のために信頼されているソースから発信。これは、パケットが同じシステム上で実行されている別のプロトコルに対して定義された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]でメカニズムが損なわれ、誤動作、または誤って設定ルータに対する保護を提供しません。このようなルータは、いずれかの偶然または故意に、全体のルーティングドメインに影響を及ぼし、誤動作を引き起こす可能性があります。読者は、ルーティングプロトコルに対する脅威のより包括的な説明については、[GENERIC-脅威]を相談することが奨励されます。
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.
ほとんどのOSPFのIPv6 IANAのための考慮事項は、[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-IANA]で定義された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-IANA]で定義されたOSPFv3のプレフィックスオプションレジストリに0x08の値でprefixオプション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-IANA]で定義されたOSPFv3のプレフィックスオプションレジストリに0x10の値を有するプレフィックスオプションDNビットを追加します。 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-IANA]を参照。このドキュメント：
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.
非難するグループメンバーシップLSAのOSPFv3 LSA機能コードレジストリの値6とO。
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テキストは、マーシャルローズの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.
OSPFv3のNSSAのサポートのために明確にするために必要なプロトコルの詳細の彼の説明のためのハロルド・ラビーO。
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.
彼は、データベース記述パケットの処理に取り扱い、未知のLSAタイプの変更があることが必要なことを指摘用のNIC Neate O。
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ヤツェクKwiatkowski V6-及びRビットがOSPFv3のイントラ領域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を参照）と現在のプロトコルメカニズムの説明を提供しました。アブヘイロイは見直しとメカニズムの改善を示唆しました。
o Alan Davey reviewed and commented on document revisions.
Oアラン・デイヴィーを見直し、文書の改訂についてコメントしました。
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さんは、リンクのLSAがLinkLSASuppressionインターフェイスコンフィギュレーションパラメータの導入を強制する必要があることについて十分に訴えました。
o Manoj Goyal for pointing out that the next-hop calculation for intra-area-prefix-LSAs corresponding to network vertices was unclear.
ネットワークの頂点に対応するエリア内プレフィックスのLSAのネクストホップ計算は不明であったことを指摘するためのManojさんGoyal氏O。
o Ramana Koppula reviewed and commented on document revisions.
Oラマナ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ダウ・ストリートとウェイン・ウィーラーはOSPFv3のにDN-ビットの付加についてコメントしました。
o Mitchell Erblichs provided numerous editorial comments.
OミッチェルErblichsは、多くの社説のコメントを提供しました。
o Russ White provided numerous editorial comments.
Oラス・ホワイトは、多くの社説のコメントを提供しました。
o Kashima Hiroaki provided editorial comments.
お かしま ひろあき ｐろゔぃでｄ えぢとりあｌ こっめんｔｓ。
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シーナ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クリスチャン・フォークトは、一般的なエリアレビューチーム（ジェン・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デイブ・ワード、ダンRomascanu、ティムポーク、ロンBonica、パシEronen、およびラースエッゲルトはIESGレビューの間、コメントを提供しました。また、ルーティングの脅威に関連する第5節内のテキストのパシのおかげ。
[DEMAND] Moy, J., "Extending OSPF to Support Demand Circuits", RFC 1793, April 1995.
[DEMAND]モイ、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]ニコルズ、K.、ブレイク、S.、ベイカー、F.、およびD.ブラック、RFC 2474、 "IPv4とIPv6ヘッダーの差別化されたサービス分野（DSフィールド）の定義"、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]ローゼン、E.、ピーター、P.、およびP. Pillay-Esnault、 "BGP / MPLS IP仮想プライベートネットワーク（VPN）でループを防止するためにリンクステートアドバタイズメント（LSA）オプションビットを使用する"、RFC 4576、2006年6月。
[INTFMIB] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000.
[INTFMIB] McCloghrie、K.およびF. Kastenholzと、 "インターフェイスグループMIB"、RFC 2863、2000年6月。
[IP6ADDR] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[IP6ADDR] HindenとR.とS.デアリング、 "IPバージョン6アドレッシング体系"、RFC 4291、2006年2月。
[IPAUTH] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[IPAUTH]ケント、S.、 "IP認証ヘッダー"、RFC 4302、2005年12月。
[IPESP] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[IPESP]ケント、S.、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 4303、2005年12月。
[IPV4] Postal, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[IPV4]郵便、J.、 "インターネットプロトコル"、STD 5、RFC 791、1981年9月。
[IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[IPV6]デアリング、S.とR. Hindenと、 "インターネットプロトコルバージョン6（IPv6）の仕様"、RFC 2460、1998年12月。
[NSSA] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option", RFC 3101, January 2003.
[NSSA]マーフィー、P.、 "OSPFない準スタブエリア（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.フェナー、 "OSPFのためのIANAは考慮事項"、BCP 130、RFC 4940、2007年7月。
[OSPFV2] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
【のOSPFv2]モイ、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]グプタ、M.およびN.メラム、 "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-キーワード]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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-脅威] Barbir、A.、マーフィー、S.、およびY.ヤン、 "ルーティングプロトコルへの一般的な脅威"、RFC 4593、2006年10月。
[MOSPF] Moy, J., "Multicast Extensions to OSPF", RFC 1584, March 1994.
[MOSPF]モイ、J.、 "OSPFへのマルチキャスト拡張機能"、RFC 1584、1994年3月。
[MTUDISC] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[MTUDISC]ムガール人、J.とS.デアリング、 "パスMTUディスカバリ"、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.、ファーガソン、D.、およびJ.モイ、 "IPv6のためのOSPF"、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.
[SERV-CLASS] Babiarz、J.、チャン、K.、およびF.ベイカー、 "DiffServのサービスの構成のガイドラインクラス"、RFC 4594、2006年8月。
Appendix A. OSPF Data Formats
付録A. OSPFデータ形式
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 Helloパケット、データベース記述パケット、および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タイプごとにフォーマットを提供します。
A.1. Encapsulation of OSPF Packets
A.1。 OSPFパケットのカプセル化
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は、そのプロトコルパケットを断片化する方法を定義し、リンクMTUよりも大きいパケットを送信する場合のIPv6断片化に依存しません。必要な場合は、OSPFパケットの長さが65,535バイトまで可能です。大（データベース記述、リンク状態要求、リンクステートアップデート、およびリンクステート確認応答パケット）である可能性が高いOSPFパケットタイプは、通常、機能を損なうことなく、複数のプロトコルのパケットに分割することができます。これが推奨されます。 IPv6断片化は可能な限り避けるべきです。この推論を使用して、試みは、パスMTU探索が[MTUDISC]実行されない限り、1280バイトまでの仮想リンクを介して送信されるOSPFパケットのサイズを制限するようになされるべきです。
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
IPv6のマルチキャストのOを使用。ブロードキャストネットワークを介して送信される場合、一部のOSPFメッセージは、マルチキャストです。二つの異なるIPマルチキャストアドレスが使用されています。これらのマルチキャストアドレスに送信されたパケットを転送すべきではありません。彼らは、単一のホップを移動するためのものです。そのため、マルチキャストアドレスは、これらのアドレスに送信されたリンクローカルスコープおよびパケットで選ばれている彼らのIPv6ホップ制限が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.
AllSPFRoutersは、このマルチキャストアドレスは、値FF02 :: 5が割り当てられています。 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は、この数は、カプセル化IPv6ヘッダの次ヘッダフィールドに挿入されるべきIPプロトコル89です。
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の仕様（付録A.1 [OSPFv2は】）OSPFプロトコルパケットがインターネットワークコントロール（B'110' ）に設定されたIP優先順位[IPV4]で送信されることを示しています。 OSPFルーティングドメイン内のルータは、[DIFF-SERV]で指定された差別化サービスコードポイント（DSCP）に自分のIPv6トラフィッククラスオクテットをマップする場合は、OSPFv3のパケットはCS6に設定し、そのDSCP（B'110000' ）で送ってください、 [SERV-CLASS]で指定されるように。このマッピングをサポートしているネットワークでは、OSPFパケットは、IPv6データトラフィックよりも優先されます。
A.2. The Options Field
A.2。オプションフィールド
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パケット、Database記述パケット、および特定のLSA（ルータのLSA、ネットワークLSAを、インターエリアルータのLSA、およびリンクの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-ビット以下）を形成するから、隣接関係を防ぎます。これらのミスマッチは、送信とHelloパケットの送受信によって発見されています。いくつかのオプションの不一致は、隣接間で浸水されることから、特定のLSAタイプのを防ぎます。これらは、送信およびデータベース記述パケットの送受信によって発見されています。いくつかのオプションの不一致は、その機能低下のさまざまなルーティング計算の一つ以上に含まれているからルータを防ぎます。これらの不一致は、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ビットは、このビットは、セクション3.6、9.5、10.8に記載されているようにAS-外部のLSAは、フラッディングされる方法を説明し、そして[OSPFv2の]の12.1.2。
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ビットこのビットは、以前のOSPFv3のために推奨されたMOSPF（[MOSPF]を参照）によって使用されました。ビットが0に設定し、受信時に無視されなければなりません。これは、将来的に再割り当てすることができます。
N-bit This bit indicates whether or not the router is attached to an NSSA as specified in [NSSA].
Nビットは、このビットは[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-ビットこのビットは、[DEMAND]で指定され、需要回路のルータの取り扱いを説明しています。
*-bit These bits are reserved for migration of OSPFv2 protocol extensions.
*ビットこれらのビットはOSPFv2のプロトコル拡張のマイグレーションのために予約されています。
A.3. OSPF Packet Formats
A.3。 OSPFパケット形式
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 Helloパケットを除く）すべてのOSPFパケットタイプは、LSAのリストを扱います。たとえば、リンクステートアップデートパケットは、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で説明されています。
A.3.1. The OSPF Packet Header
A.3.1。 OSPFパケットヘッダ
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.6を通じて、付録A.3.2を参照してください。
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 Aの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パケットヘッダから始まる、パケットの全内容の1の補数和の16ビットの1の補数、およびIPv6ヘッダフィールドの「疑似ヘッダ」を先頭に追加：チェックサムOSPFは、IPv6アプリケーションのための標準的なチェックサム計算を使用します[IPV6]のセクション8.1で指定されるように。疑似ヘッダにおける「上位層パケットの長さは」OSPFパケットヘッダの長さフィールドの値に設定されています。パケットの長さは、パケットがチェックサムの前にゼロのバイトでパディングされ、16ビット・ワードの整数倍でない場合、擬似ヘッダで使用される次ヘッダ値は89です。チェックサムを計算する前に、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は1つのリンクを介して実行されるように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に設定する必要があり、プロトコルパケットを受信したときに無視しなければなりません。
A.3.2. The Hello Packet
A.3.2。 helloパケット
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のとRouterDeadInterval）に同意しなければなりません。これらのパラメータは、違いはネイバー関係の形成を阻害することができHelloパケットに含まれています。 Helloパケットは、（ルータ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 helloパケット
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とこのルータのHelloパケットの間の秒数。
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ザ・を指定します。バックアップ指定ルーターは、そのIPルータIDによって識別されます。ルータの指定バックアップがない場合には、0.0.0.0に設定されています。
Neighbor ID The Router IDs of each router on the network with neighbor state 1-Way or greater.
隣人は隣人状態1ウェイ以上で、ネットワーク上の各ルータのルータIDがあります。
A.3.3. The Database Description Packet
A.3.3。データベース説明パケット
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つは、マスターであると指定され、他方がスレーブです。マスタはスレーブ（レスポンス）により送信されたデータベース記述パケットによって確認されているデータベース記述パケット（ポーリング）を送信します。応答は、パケットの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.
初期化ビットを、私はビット。 1に設定すると、このパケットは、Database記述パケットのシーケンスの最初です。
M-bit The More bit. When set to 1, it indicates that more Database Description packets are to follow.
Mビット以上のビット。 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の現在のインスタンスの両方を識別するために必要なすべての情報が含まれています。
A.3.4. The Link State Request Packet
A.3.4。リンク状態要求パケット
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.ある、ルータはリンクステートデータベースの一部が古くなっていることがあります。リンク状態要求パケットは、より最新されている隣人のデータベースの部分を要求するために使用されます。複数のリンク状態要求パケットを使用する必要があるかもしれません。
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に記載されています。リンク状態要求パケットの受信は、[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の最新のインスタンスに対する要求であると理解されています。
A.3.5. The Link State Update Packet
A.3.5。リンクステートアップデートパケット
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.
リンクステートアップデートパケットは、これらのパケットは、LSAの氾濫を実装OSPFパケットタイプ4です。各リンクステートアップデートパケットは1つが自分の原点からさらにホップLSAのコレクションを運びます。いくつかの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はリンクステート確認応答パケットに認めています。特定の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.
＃LSAのこの更新プログラムに含ま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に記載されています。
A.3.6. The Link State Acknowledgment Packet
A.3.6。リンクステート確認応答パケット
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の信頼性、浸水のLSAのフラッディングを行うにはOSPFパケットタイプ5.明示的または暗黙的に承認されています。明示的な承認は、送信およびリンクステート確認応答パケットの受信を介して行われます。リンクステート確認応答パケットの送信[OSPFv2の]のセクション13.5に記載されています。リンク状態確認応答パケットの受信が[の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は、単一のリンクステート確認応答パケットに承認されるかもしれません。送信インターフェイスおよび対応するリンクステートアップデートパケットの送信元の状態に応じて、リンクステート確認応答パケットはマルチキャストアドレスAllSPFRouters、マルチキャストアドレスAllDRoutersに、または隣人のユニキャストアドレスに送信されます（[OSPFv2のの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の現在のインスタンスの両方を識別するために必要なすべての情報が含まれています。
A.4. LSA Formats
A.4。 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.
この文書では、LSAの8の異なるタイプを定義します。各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は、その指定ルータによって各リンクのためにアドバタイズされます。ルータのリンクローカルアドレスは、リンクのLSAにその隣にアドバタイズされています。 IPv6プレフィックスがエリア内プレフィックス-のLSAでアドバタイズされ、エリア間プレフィックス-LSAを、AS-外部LSA、およびNSSA-LSAを。特定のルータの場所はエリア間ルータ - LSAの領域の境界を越えて宣伝することができます。すべてのLSAはその後、OSPFルーティングドメイン全体にフラッディングされます。フラッディングアルゴリズムは、氾濫範囲に共通するすべてのルータは、そのフラッディングスコープに関連付けられたLSAの同じコレクションを持っていることを保証する、信頼性があります。 （フラッディングアルゴリズムに関する詳細については、セクション4.5を参照してください。）LSAのこのコレクションは、リンクステートデータベースと呼ばれています。
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節を参照してください。
A.4.1. IPv6 Prefix Representation
A.4.1。 IPv6のプレフィックス表現
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アドレスは、IPv6アドレスプレフィックスを広告する、ビット長のストリング128のIPv6ルーティングプロトコル、特に、IPv6のOSPFです。 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アドレスのプレフィックスは常に三つのフィールドの組み合わせで表現されていますPrefixLength、PrefixOptions、およびプレフィックスアドレス。 PrefixLengthは、プリフィックスのビット単位の長さです。 PrefixOptions（付録A.4.1.1参照）プレフィックスに関連する様々な機能を説明する8ビットのフィールドです。アドレスプレフィックスは、必要に応じてゼロビットでも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に見出すことができます。
A.4.1.1. Prefix Options
A.4.1.1。プレフィックスオプション
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ビットのフィールドと一緒に広告を出しています。これらはさまざまなルーティング計算への入力として働きます。例えば、彼らは接頭辞がいくつかのケースでは無視されるか、他の人でreadvertisableないとしてマークされることを示すことができます。
0 1 2 3 4 5 6 7
+--+--+--+--+--+-+--+--+
| | | |DN| P|x|LA|NU|
+--+--+--+--+--+-+--+--+
The PrefixOptions Field
PrefixOptionsフィールド
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ビットの「ノーユニキャスト」機能ビット。設定した場合、接頭辞は、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に記載されています。実装は、ホストPrefixLength（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ビットこのビットは、以前は「マルチキャスト」機能ビットと定義しました。しかし、使用が適切に指定されていませんでしたし、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ビットこのビットは、[DN-BIT]で指定されたVPN環境で相互領域プレフィックスのLSAまたはAS-外部のLSA再広告を制御します。
A.4.2. The LSA Header
A.4.2。 LSAヘッダー
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によって実行される機能を示して入力します。 LSAのLS型エンコード一般的な性質の上位3ビット、（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タイプ、および広告ルータの組み合わせは一意にリンクステートデータベースの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。例えば、ネットワークのLSAは、このフィールドは、ネットワークの代表ルータのルータ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.
LSAのLSシーケンス番号連続したインスタンスは、連続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ヘッダを含みます。
A.4.2.1. LSA Type
A.4.2.1。 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によって実行される機能を示しています。 LSAのLS型エンコード一般的な性質の上位3ビット、（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機能コードの発信及び処理を先にMOSPFによって使用されたNSSA-LSA（参照[NSSA]）と0x2006を除き、本文書の他の場所で定義されている（[MOSPF]参照）。 MOSPFは、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機能コード
A.4.3. Router-LSAs
A.4.3。ルータの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は0x2001に等しいLSタイプがあります。エリア内の各ルータには、一つ以上のルータ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
ルータ - 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によって区別一つ以上のルータLSAを、生じてもよいです。オプションフィールドとV、E、およびBビットは、単一の発信元からのすべてのルータのLSAに同じであるべきです。しかし、不一致の場合には、最低のリンクステートIDを持つ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は、ルータはトランジットエリアとして説明面積（Vは、仮想リンクのエンドポイントのためのものである）を有する一つまたはそれ以上の完全隣接する仮想リンクの終点です。
Bit E When set, the router is an AS boundary router (E is for external).
設定した場合、ビットE、ルータがAS境界ルータ（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のセット、ルータは無条件AS-外部のLSA（NtがNSSA翻訳の略）にNSSA-LSAを翻訳されたNSSA境界ルータです。ルーターは、そのNSSATranslatorRoleエリアの設定パラメータがAlwaysに設定されていることに注意してください。 （[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フィールドに依存します。
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.
隣人のHelloパケットでアドバタイズとして隣人インタフェース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.
添付のリンクがリンクステートデータベースに見出されるためトランジット（タイプ2）リンク、隣接インタフェースIDおよび近隣ルータIDの組み合わせに対してネットワークLSAを可能にします。
A.4.4. Network-LSAs
A.4.4。ネットワークの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は0x2002に等しいLSタイプがあります。ネットワークLSAは、2つ以上の隣接ルータを含む領域内の各放送とNBMAリンクに発信されます。ネットワークLSAは、リンクの指定ルータによって発信されます。 LSAは、指定ルータ自体を含むリンクに接続されているすべてのルーターを記述します。 LSAのリンクステートIDフィールドは、指定ルータがリンク上のHelloパケットでアドバタイズされたインターフェイスの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ヘッダの長さフィールドから推論することができます。
A.4.5. Inter-Area-Prefix-LSAs
A.4.5。エリア間プレフィクス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.
インターエリア・プレフィックスLSAは0x2003に等しいLSタイプがあります。これらのLSAは、IPv4のタイプ3要約LSA（[のOSPFv2]のセクション12.4.3を参照）のためのOSPFのIPv6の等価物です。エリア境界ルータが発信し、彼らは他の地域に属しているIPv6アドレスのプレフィックスへのルートを記述します。別間領域プレフィックスLSA各IPv6アドレスプレフィックスのために発信されます。エリア間プレフィックス-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はまた、（ペルエリア）デフォルトルートを記述するために使用することができます。デフォルトサマリールートではなく、外部ルートの完全なセットを洪水のスタブエリアで使用されています。デフォルトサマリールートを説明するとき、エリア間プレフィックス-LSAのPrefixLengthは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
エリア間プレフィクス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.
PrefixLength、PrefixOptions、および付録A.4.1で説明したように、IPv6アドレスプレフィックスのプレフィックス表現アドレス。
A.4.6. Inter-Area-Router-LSAs
A.4.6。エリア間-ルータ - LSAを
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は0x2004に等しいLSタイプがあります。これらのLSAは、IPv4のタイプ4要約LSA（[のOSPFv2]のセクション12.4.3を参照）のためのOSPFのIPv6の等価物です。エリア境界ルータが発信し、彼らは他の分野でAS境界ルータへのルートを記述します。各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.
LSAによって記述されているルータの宛先ルータIDザ・ルータID。
A.4.7. AS-External-LSAs
A.4.7。 ASの外部のLSAを
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の外部のLSAは0x4005に等しいLSタイプがあります。これらのLSAはAS境界ルータによって発信およびASの外部の宛先を記述しています。各LSAは、単一のIPv6アドレスプレフィックスへのルートを記述します。 ASの外部の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の外部のLSAは、デフォルトルートを記述するために使用することができます。特別なルートが先に存在しない場合、デフォルトルートが使用されています。デフォルトルートを説明するとき、ASの外部のLSAのPrefixLengthは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の外部の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外部メトリックです。これは、メトリックは、任意の内ASパスより大きいと考えられていることを意味します。ビットEがゼロの場合は、指定されたメトリックがタイプ1外部メトリックです。これは、それが他のLSA（ルータのLSAのインターフェイスコストとして、すなわち、同じ単位）と同じ単位で表されることを意味します。
bit F If set, a Forwarding Address has been included in the LSA.
設定した場合、ビットFは、転送先アドレスは、LSAに含まれています。
bit T If set, an External Route Tag has been included in the LSA.
ビットTセットした場合、外部ルートタグは、LSAに含まれています。
Metric The cost of this route. Interpretation depends on the external type indication (bit E above).
このルートのメトリックコスト。解釈は、外部のタイプ指示（上記ビットE）に依存します。
PrefixLength, PrefixOptions, and Address Prefix Representation of the IPv6 address prefix, as described in Appendix A.4.1.
PrefixLength、PrefixOptions、および付録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ビット）を転送します。ビットFが設定されている場合にだけLSAに含まれています。含まれている場合、宣伝目的地のためのデータトラフィックは、このアドレスに転送されます。これは、IPv6未指定アドレスに設定することはできません（：0：0：0 0：0：0：0：0）、またはIPv6リンクローカルアドレス（プレフィックスFE80 / 10）。 OSPFv3のルートが正常にリンクローカルアドレスと一緒にインストールされている一方で、転送アドレスを広告する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.
外部ルートは、AS境界ルータとの間に追加の情報を通信するために用いることができる32ビットのフィールドタグを付けます。ビット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タイプ」に等しいLSAたLSタイプで見つけることができる場合は、「参照先リンクステートID」に等しいリンクステートID、および広告ルータASで指定したものと同じ-external-LSAのリンク状態ヘッダー。この追加情報は、OSPFプロトコル自体では使用されません。 AS境界ルータ間で情報を通信するために使用されてもよいです。そのような情報の正確な性質は、本明細書の範囲外です。
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の外部のLSAに存在してもよい（ビットFの設定によって示されるように、それぞれT、および参照先LSタイプビットません）。存在する場合、転送先アドレスは、常に外部ルートの次のタグ、そして最後に参照リンクステートID、最初に来ます。
A.4.8. NSSA-LSAs
A.4.8。 NSSA-のLSA
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は0x2007に等しいLSタイプがあります。これらのLSAはNSSA内のAS境界ルータによって発信され、またはNSSA（[NSSA]を参照）の外側に伝播してもしなくてもよいAS外部の宛先を記述しています。 LSタイプ以外に、そのフォーマットは、付録A.4.7で説明したようにAS-外部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.
グローバルIPv6アドレスは、NSSAエリア境界ルータによって伝播されるNSSA-のLSAの転送アドレスとして選択する必要があります。選択は、IPv6リンクローカルアドレスが選択されていないことを確認するために追加のチェックをして[NSSA]のOSPFv2 NSSAのサポートと同じように進めるべき。
A.4.9. Link-LSAs
A.4.9。リンクのLSA
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:
リンクLSAは0x0008にに等しいLSタイプがあります。ルータは、各接続されている物理リンクのための別個のリンクLSAを発信します。これらのLSAは、リンクローカルフラッディングスコープを持っています。彼らは、関連するリンクを超えてあふれされることはありません。リンク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.
リンク-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.
リンク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
リンク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リンク上のDesignated Routerによって発信されるネットワーク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.
PrefixLength、PrefixOptions、および付録A.4.1で説明したように、IPv6アドレスプレフィックスのプレフィックス表現アドレス。
A.4.10. Intra-Area-Prefix-LSAs
A.4.10。エリア内プレフィクスLSAを
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.
エリア内プレフィックス-LSAは0x2009に等しいLSタイプがあります。ルータは、ローカルルータのアドレス、添付のスタブネットワークセグメント、または添付のトランジットネットワークセグメントに関連する1つの以上のIPv6アドレスプレフィックスを広告するエリア内プレフィックスLSAを使用します。 IPv4では、最初の二つは、ネットワークLSAを経由してルータのルータ - LSAと最後を介して行われました。 IPv6のためのOSPFでは、ルータのLSAとネットワークLSAの中で宣伝されたすべてのアドレス情報が削除されており、現在エリア内プレフィックス-のLSAでアドバタイズされます。エリア内プレフィックス-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
エリア内プレフィックス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.
エリア内プレフィックス-LSAの残りの部分は、ルータまたはトランジットリンクだけでなく、それに関連するコストに関連付けられるIPv6プレフィックスのリストが含まれています。
PrefixLength, PrefixOptions, and Address Prefix Representation of an IPv6 address prefix, as described in Appendix A.4.1.
PrefixLength、PrefixOptions、および付録A.4.1で説明したように、IPv6アドレスプレフィックスのプレフィックス表現アドレス。
Metric The cost of this prefix. Expressed in the same units as the interface costs in router-LSAs.
このプレフィックスのメトリックコスト。ルータのLSAのインターフェイスコストと同じ単位で表されます。
Appendix B. Architectural Constants
付録B.建築定数
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のための唯一の違いは、DefaultDestinationは、長さが0（付録A.4.1を参照）との接頭語として符号化されることです。
Appendix C. Configurable Constants
付録C.設定可能な定数
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.
いくつかのパラメータ設定は、ルータのグループ間で一貫している必要があります。例えば、エリア内のすべてのルータは、そのエリアのパラメータに同意しなければなりません。同様に、ネットワークに接続されているすべてのルータは、そのネットワークのHelloIntervalのと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.
一部のパラメータは、本明細書の外ルータアルゴリズムによって決定することができる（例えば、SLIP回線を介してルータに接続されたホストのアドレス）。ビューのOSPFの観点から、これらのアイテムは、まだ設定可能です。
C.1. Global Parameters
C.1。グローバルパラメータ
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を参照してください）。そうでなければ、彼らはMaxAgeの秒まで持続します。
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アドレスよりも小さいので（一般的にIPv4のために行われているように）、それはルータのIPv6アドレスのいずれかに設定することはできません。 IPv6のための可能なルータIDの割り当て手順は、a）ルータのIPv4アドレスの一つとして、IPv6ルーターIDを割り当てるまたはb）製品のシリアル番号を割り当てるために製造業者によって使用される手順と同様のいくつかのローカル管理手順（）を介してIPv6ルーターIDを割り当てます。
The Router ID of 0.0.0.0 is reserved and SHOULD NOT be used.
0.0.0.0のルータIDが予約されているため、使用しないでください。
C.2. Area Parameters
C.2。エリアパラメータ
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].
ExternalRoutingCapabilityかどうかASの外部のLSAは、エリア全体/にフラッディングされます。 AS-外部の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].
NSSATranslatorRoleとTranslatorStabilityIntervalこれらの領域パラメータは、[NSSA]の付録Dに記載されています。また、NSSAエリア境界ルータ（ABR）もNSSAのデフォルトルートをNSSA-LSAでアドバタイズされているかどうかの設定をできるようにするために必要です。宣伝した場合、そのメトリックとメトリックタイプは設定可能です。これらの要件はまた、[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.
有効に設定すると、エリア外の接頭辞ImportSummariesは、エリア間プレフィックス-LSAの広告を経由してエリアにインポートされます。無効に設定すると、エリア間のルートは、エリアにインポートされません。デフォルトの設定が有効になっています。このパラメータは、スタブまたはNSSAエリアにのみ有効です。
C.3. Router Interface Parameters
C.3。ルータのインターフェイスパラメータ
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、HelloIntervalの、及びRouterDeadIntervalとして）設定ルータインターフェイスパラメータのいくつかは、実際に取り付けられたリンクの特性を意味します。したがって、これらのパラメータは、そのリンクに接続されたすべてのルータで一致している必要があります。ルータインターフェイスに設定する必要がありますパラメータは次のとおりです。
IPv6 link-local address The IPv6 link-local address associated with this interface. May be learned through auto-configuration.
IPv6リンクローカルアドレスをこのインターフェイスに関連付けられた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プレフィックスのリストを接頭辞。これらは、エリア内プレフィックス-のLSAにアドバタイズされます。
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.
インターフェイス出力コスト（S）インターフェイス上でパケットを送信するコストは、リンクステートメトリックで表さ。これは、ルータのルータ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.
このインターフェイスに属する隣接関係のLSA再送信間の秒数RxmtInterval。データベース記述およびリンク状態要求パケットを再送する際にも使用。これがうまく接続リンク上の任意の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は、自分の年齢が送信前にこの量によって増分持っている必要があります。この値は、アカウントにインターフェイスの伝送および伝播遅延を取る必要があります。 1秒：これは、ローカル・エリア・ネットワークのための0のサンプル値よりも大きくなければなりません。
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つのルータにネットワークに代表ルータになるために、両方の試みを添付すると、最高のルータプライオリティを持つ1が優先されます。タイがまだある場合は、最も高いルータ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と、ルータがインターフェイス上で送信するhelloパケット間の秒単位の時間の長さ、、。この値は、ルータのHelloパケットでアドバタイズされます。それは、共通のリンクに接続されているすべてのルーターで同じでなければなりません。 HelloIntervalと小さく、より高速なトポロジの変更が検出されます。しかし、より多くのOSPFルーティングプロトコルのトラフィックが続いて起こります。 X.25 PDNのサンプル値：30秒。 10秒：ローカルエリアネットワーク（LAN）のサンプル値。
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.
そのネイバーがルータのダウンを宣言するまでの秒数を、ルータのHelloパケットを聞くために中止した後RouterDeadInterval。これはまた、彼らのRouterDeadIntervalフィールドにルータのHelloパケットでアドバタイズされます。これは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.
LinkLSASuppressionは、リンクLSAの発信が抑制されているかどうかを示します。 「有効」に設定した場合とのインターフェイスタイプが放送されていないか、またはNBMAは、ルータがリンクのためのリンクLSAを発信しません。これは、リンク上の他のルータはリンクLSA（セクション4.8.2を参照）以外のメカニズムを使用してルータのネクストホップアドレスを確認することを意味します。デフォルト値は、本明細書に記載されたインターフェイスタイプについて「無効」です。インタフェースタイプがブロードキャストまたはNBMAされている場合には、暗黙的に「無効」です。将来のインターフェイスタイプが異なるデフォルトを指定するかもしれません。
C.4. Virtual Link Parameters
C.4。仮想リンクのパラメータ
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を参照してください）。仮想リンクは、リンクローカルアドレスを持っているが、その代わりに、それは仮想リンク上で送信OSPFプロトコルパケットでIPソースとしてルータのグローバルスコープのIPv6アドレスのいずれかを使用しないでください。ルータの優先順位は、仮想リンク上で使用されていません。インターフェイス出力コストは、仮想リンクで構成されていないが、動的に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).
仮想リンクトラバース（仮想リンクの通過エリアと呼ぶ）は、仮想リンクの他のエンドポイントとの（非バックボーン）領域のルータID：仮想リンクは、次の2つの設定可能なパラメータにより定義されます。仮想リンクはスタブまたはNSSAエリアを使用して設定することができません。また、インスタンスIDは、（多重分離するための別のルータIDを必要とせずに）同じ通過面積を利用するために異なるプロトコルインスタンスから仮想リンクのために構成されてもよいです。
C.5. NBMA Network Parameters
C.5。 NBMAネットワークパラメータ
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ネットワークへのインタフェースが最初に起動すると、ルータは指定ルータが選出されるような時間まで、指定ルータになる資格それらの隣人にHelloパケットを送信します。
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.
ポーリング間隔隣接ルータが（ハローパケットがRouterDeadInterval秒間見られていない）非アクティブになった場合、まだ死んで隣人にHelloパケットを送信する必要があるかもしれません。これらのHelloパケットがHelloIntervalのよりもはるかに大きくする必要があります減少率ポーリング間隔、で送信されます。 PDNのX.25ネットワークのサンプル値：2分。
C.6. Point-to-Multipoint Network Parameters
C.6。ポイントツーマルチポイントネットワークパラメータ
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のリンクローカルアドレスが設定されています。指定ルータは、ポイント・ツー・マルチポイントネットワークで選出されていない、そのように構成さネイバーの指定ルータの適格性が定義されていません。
C.7. Host Route Parameters
C.7。ルートパラメーターをホスト
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:
ホストプレフィックスがエリア内プレフィックス-のLSAでアドバタイズされています。彼らは、ルータインターフェイス、または直接ルータ（例えば、PPP接続を介して）に接続されたIPv6ホストのループ、ポイントツーポイントネットワークをローカルルータアドレス、ルータインターフェイスのいずれかを示します。ルータに直接接続された各ホストについて、次の項目を設定する必要があります。
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
ロブColtun Acoustraプロダクション3204ブルックテラスチェビーチェイス、MD 20815 USA
Dennis Ferguson Juniper Networks 1194 N. Mathilda Avenue Sunnyvale, CA 94089 USA
デニスファーガソンジュニパーネットワークスの1194 N.マチルダアベニューサニーベール、CA 94089 USA
EMail: dennis@juniper.net
メールアドレス：dennis@juniper.net
John Moy Sycamore Networks, Inc 10 Elizabeth Drive Chelmsford, MA 01824 USA
ジョン・モイシカモアネットワークス、株式会社10エリザベス・ドライブチェルムズフォード、MA 01824 USA
EMail: jmoy@sycamorenet.com
メールアドレス：jmoy@sycamorenet.com
Acee Lindem (editor) Redback Networks 102 Carric Bend Court Cary, NC 27519 USA
ACEE Lindem（編集者）レッドバック・ネットワーク102 Carricベンド裁判所カリー、NC 27519 USA
EMail: acee@redback.com
メールアドレス：acee@redback.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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に情報を記述してください。