[要約] RFC 2740は、IPv6におけるOSPF（Open Shortest Path First）のプロトコルに関する仕様を定めたものであり、IPv6ネットワークにおける経路選択とルーティングを改善することを目的としています。
Network Working Group R. Coltun
Requests for Comments: 2740 Siara Systems
Category: Standards Track D. Ferguson
Juniper Networks
J. Moy
Sycamore Networks
December 1999
OSPF for IPv6
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）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（C）The Internet Society（1999）。全著作権所有。
Abstract
概要
This document describes the modifications to OSPF to support version 6 of the Internet Protocol (IPv6). The fundamental mechanisms of OSPF (flooding, DR election, area support, 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.
このドキュメントでは、インターネットプロトコル（IPv6）のバージョン6をサポートするためのOSPFの変更について説明します。 OSPFの基本的なメカニズム（フラッディング、DR選定、エリアサポート、SPF計算など）は変更されていません。ただし、IPv4とIPv6の間のプロトコルセマンティクスの変更のため、または単にIPv6の増加したアドレスサイズを処理するために、いくつかの変更が必要でした。
Changes between OSPF for IPv4 and this document include the following. Addressing semantics have been removed from OSPF packets and the basic LSAs. New LSAs have been created to carry IPv6 addresses and prefixes. OSPF now runs on a per-link basis, instead of on a per-IP-subnet basis. Flooding scope for LSAs has been generalized. Authentication has been removed from the OSPF protocol itself, instead relying on IPv6's Authentication Header and Encapsulating Security Payload.
OSPF for IPv4とこのドキュメントの変更点は次のとおりです。 OSPFパケットと基本的なLSAからアドレッシングセマンティクスが削除されました。 IPv6アドレスとプレフィックスを伝送する新しいLSAが作成されました。 OSPFは、IPサブネットごとではなく、リンクごとに実行されるようになりました。 LSAのフラッディングスコープが一般化されました。認証はOSPFプロトコル自体から削除され、代わりにIPv6の認証ヘッダーとカプセル化セキュリティペイロードに依存しています。
Most packets in OSPF for IPv6 are almost as compact as those in OSPF for IPv4, even with the larger IPv6 addresses. Most field-XSand packet-size limitations present in OSPF for IPv4 have been relaxed. In addition, option handling has been made more flexible.
OSPF for IPv6のほとんどのパケットは、IPv6アドレスが大きい場合でも、IPv4のOSPFのパケットとほとんど同じくらいコンパクトです。 OSPF for IPv4に存在するほとんどのフィールドXSandパケットサイズの制限が緩和されました。さらに、オプションの処理がより柔軟になりました。
All of OSPF for IPv4's optional capabilities, including on-demand circuit support, NSSA areas, and the multicast extensions to OSPF (MOSPF) are also supported in OSPF for IPv6.
OSPF for IPv4のオプション機能はすべて、オンデマンド回線サポート、NSSAエリア、OSPFへのマルチキャスト拡張（MOSPF）など、IPv6のOSPFでもサポートされています。
Table of Contents
目次
1 Introduction ........................................... 4
1.1 Terminology ............................................ 4
2 Differences from OSPF for IPv4 ......................... 4
2.1 Protocol processing per-link, not per-subnet ........... 5
2.2 Removal of addressing semantics ........................ 5
2.3 Addition of Flooding scope ............................. 5
2.4 Explicit support for multiple instances per link ....... 6
2.5 Use of link-local addresses ............................ 6
2.6 Authentication changes ................................. 7
2.7 Packet format changes .................................. 7
2.8 LSA format changes ..................................... 8
2.9 Handling unknown LSA types ............................ 10
2.10 Stub area support ..................................... 10
2.11 Identifying neighbors by Router ID .................... 11
3 Implementation details ................................ 11
3.1 Protocol data structures .............................. 12
3.1.1 The Area Data structure ............................... 13
3.1.2 The Interface Data structure .......................... 13
3.1.3 The Neighbor Data Structure ........................... 14
3.2 Protocol Packet Processing ............................ 15
3.2.1 Sending protocol packets .............................. 15
3.2.1.1 Sending Hello packets ................................. 16
3.2.1.2 Sending Database Description Packets .................. 17
3.2.2 Receiving protocol packets ............................ 17
3.2.2.1 Receiving Hello Packets ............................... 19
3.3 The Routing table Structure ........................... 19
3.3.1 Routing table lookup .................................. 20
3.4 Link State Advertisements ............................. 20
3.4.1 The LSA Header ........................................ 21
3.4.2 The link-state database ............................... 22
3.4.3 Originating LSAs ...................................... 22
3.4.3.1 Router-LSAs ........................................... 25
3.4.3.2 Network-LSAs .......................................... 27
3.4.3.3 Inter-Area-Prefix-LSAs ................................ 28
3.4.3.4 Inter-Area-Router-LSAs ................................ 29
3.4.3.5 AS-external-LSAs ...................................... 29
3.4.3.6 Link-LSAs ............................................. 31
3.4.3.7 Intra-Area-Prefix-LSAs ................................ 32
3.5 Flooding .............................................. 35
3.5.1 Receiving Link State Update packets ................... 36
3.5.2 Sending Link State Update packets ..................... 36
3.5.3 Installing LSAs in the database ....................... 38
3.6 Definition of self-originated LSAs .................... 39
3.7 Virtual links ......................................... 39
3.8 Routing table calculation ............................. 39
3.8.1 Calculating the shortest path tree for an area ........ 40
3.8.1.1 The next hop calculation .............................. 41
3.8.2 Calculating the inter-area routes ..................... 42
3.8.3 Examining transit areas' summary-LSAs ................. 42
3.8.4 Calculating AS external routes ........................ 42
3.9 Multiple interfaces to a single link .................. 43
References ............................................ 44
A OSPF data formats ..................................... 46
A.1 Encapsulation of OSPF packets ......................... 46
A.2 The Options field ..................................... 47
A.3 OSPF Packet Formats ................................... 48
A.3.1 The OSPF packet header ................................ 49
A.3.2 The Hello packet ...................................... 50
A.3.3 The Database Description packet ....................... 52
A.3.4 The Link State Request packet ......................... 54
A.3.5 The Link State Update packet .......................... 55
A.3.6 The Link State Acknowledgment packet .................. 56
A.4 LSA formats ........................................... 57
A.4.1 IPv6 Prefix Representation ............................ 58
A.4.1.1 Prefix Options ........................................ 58
A.4.2 The LSA header ........................................ 59
A.4.2.1 LS type ............................................... 60
A.4.3 Router-LSAs ........................................... 61
A.4.4 Network-LSAs .......................................... 64
A.4.5 Inter-Area-Prefix-LSAs ................................ 65
A.4.6 Inter-Area-Router-LSAs ................................ 66
A.4.7 AS-external-LSAs ...................................... 67
A.4.8 Link-LSAs ............................................. 69
A.4.9 Intra-Area-Prefix-LSAs ................................ 71
B Architectural Constants ............................... 73
C Configurable Constants ................................ 73
C.1 Global parameters ..................................... 73
C.2 Area parameters ....................................... 74
C.3 Router interface parameters ........................... 75
C.4 Virtual link parameters ............................... 77
C.5 NBMA network parameters ............................... 77
C.6 Point-to-MultiPoint network parameters ................ 78
C.7 Host route parameters ................................. 78
Security Considerations ............................... 79
Authors' Addresses .................................... 79
Full Copyright Statement .............................. 80
This document describes the modifications to OSPF to support version 6 of the Internet Protocol (IPv6). The fundamental mechanisms of OSPF (flooding, DR election, area support, 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.
このドキュメントでは、インターネットプロトコル（IPv6）のバージョン6をサポートするためのOSPFの変更について説明します。 OSPFの基本的なメカニズム（フラッディング、DR選定、エリアサポート、SPF計算など）は変更されていません。ただし、IPv4とIPv6の間のプロトコルセマンティクスの変更のため、または単にIPv6の増加したアドレスサイズを処理するために、いくつかの変更が必要でした。
This document is organized as follows. Section 2 describes the differences between OSPF for IPv4 and OSPF for IPv6 in detail. Section 3 provides implementation details for the changes. Appendix A gives the OSPF for IPv6 packet and LSA formats. Appendix B lists the OSPF architectural constants. Appendix C describes configuration parameters.
このドキュメントは次のように構成されています。セクション2では、OSPF for IPv4とOSPF for IPv6の違いについて詳しく説明します。セクション3では、変更の実装の詳細について説明します。付録Aは、OSPF for IPv6パケットとLSAフォーマットを示しています。付録Bは、OSPFアーキテクチャの定数を示しています。付録Cでは、構成パラメータについて説明します。
This document attempts to use terms from both the OSPF for IPv4 specification ([Ref1]) and the IPv6 protocol specifications ([Ref14]). 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).
このドキュメントでは、OSPF for IPv4仕様（[Ref1]）とIPv6プロトコル仕様（[Ref14]）の両方の用語を使用しようとしています。これにより、さまざまな結果が生じました。 OSPFとIPv6の両方で使用されるほとんどの用語は、ほぼ同じ意味です（例：インターフェース）。ただし、いくつかの競合があります。 IPv6は、IPv4 OSPFの「サブネット」または「ネットワーク」と同様に「リンク」を使用します。この場合、IPv6の「リンク」用語を使用することを選択しました。 「リンク」は、OSPFの「サブネット」および「ネットワーク」に代わって、このドキュメントのほとんどの場所で使用されていますが、OSPFのネットワークLSAは変更されていません（残念ながら、新しいリンクLSAも作成されています）。
The names of some of the OSPF LSAs have also changed. See Section 2.8 for details.
一部のOSPF LSAの名前も変更されました。詳細については、セクション2.8を参照してください。
Most of the algorithms from OSPF for IPv4 [Ref1] have 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.
OSPF for IPv4 [参照1]のアルゴリズムのほとんどは、OSPF for IPv6で維持されています。ただし、IPv4とIPv6の間のプロトコルセマンティクスの変更のため、または単にIPv6の増加したアドレスサイズを処理するために、いくつかの変更が必要でした。
The following subsections describe the differences between this document and [Ref1].
以下のサブセクションでは、このドキュメントと[Ref1]の違いについて説明します。
IPv6 uses the term "link" to indicate "a communication facility or medium over which nodes can communicate at the link layer" ([Ref14]). "Interfaces" connect to links. Multiple IP 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 IP subnet (IPv6 prefix).
IPv6では、「リンク」という用語を使用して、「ノードがリンク層で通信できる通信設備または媒体」を示します（[Ref14]）。 「インターフェース」はリンクに接続します。 1つのリンクに複数のIPサブネットを割り当てることができ、2つのノードは、共通のIPサブネット（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 ([Ref1]) should generally be relaced by link. Likewise, an OSPF interface now connects to a link instead of an IP subnet, etc.
このため、IPv6のOSPFは、IPサブネットごとのIPv4動作ではなく、リンクごとに実行されます。 IPv4 OSPF仕様（[Ref1]）で使用されている「ネットワーク」および「サブネット」という用語は、通常、リンクで置き換える必要があります。同様に、OSPFインターフェースはIPサブネットなどではなくリンクに接続するようになりました。
This change affects the receiving of OSPF protocol packets, and the contents of Hello Packets and 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:
OSPF for IPv6では、アドレス指定のセマンティクスがOSPFプロトコルパケットと主要なLSAタイプから削除され、ネットワークプロトコルに依存しないコアが残っています。特に：
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.
o IPv6アドレスは、リンク状態更新パケットによって運ばれる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, where previously they had been identified by IP address on broadcast and NBMA "networks".
o 隣接するルーターは常にルーターIDで識別されるようになりました。以前は、ブロードキャストとNBMAの「ネットワーク」でIPアドレスによって識別されていました。
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: o Link-local scope. LSA is flooded only on the local link, and no further. Used for the new Link-LSA (see Section A.4.8).
LSAのフラッディングスコープが一般化され、LSAのLSタイプフィールドで明示的にコーディングされるようになりました。 LSAには3つの個別のフラッディングスコープがあります。oリンクローカルスコープ。 LSAはローカルリンクでのみフラッディングされ、それ以上はフラッディングされません。新しいLink-LSAに使用されます（セクションA.4.8を参照）。
o Area scope. LSA is flooded throughout a single OSPF area only. 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.
o ASスコープ。 LSAはルーティングドメイン全体にフラッディングされます。 AS外部LSAに使用されます。
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 running separate OSPF routing domains that want 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ルーティングドメインを実行している可能性があります。 OSPF for IPv4では、これはOSPF for 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インスタンスを実行するもう1つの用途は、何らかの理由で、1つのリンクを2つ以上のOSPFエリアに所属させたい場合です。
Support for multiple protocol instances on a link is accomplished via an "Instance ID" contained in the OSPF packet header and OSPF interface structures. Instance ID solely affects the reception of OSPF packets.
リンク上の複数のプロトコルインスタンスのサポートは、OSPFパケットヘッダーとOSPFインターフェイス構造に含まれる「インスタンスID」を介して行われます。インスタンスIDは、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 [Ref15]. Link-local unicast addresses are assigned from the IPv6 address range FF80/10.
IPv6リンクローカルアドレスは、近隣探索、自動構成などの目的で、単一リンクで使用するためのものです。IPv6ルーターは、リンクローカルソースアドレスを持つIPv6データグラムを転送しません[参照15]。リンクローカルユニキャストアドレスは、IPv6アドレス範囲FF80 / 10から割り当てられます。
OSPF for IPv6 assumes that each router has been assigned link-local unicast addresses on each of the router's attached physical segments. On all OSPF interfaces except virtual links, OSPF packets are sent using the interface's associated link-local unicast address as source. 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.
OSPF for IPv6は、各ルーターに接続された各物理セグメントでリンクローカルユニキャストアドレスが割り当てられていることを前提としています。仮想リンクを除くすべてのOSPFインターフェイスでは、OSPFパケットは、インターフェイスに関連付けられたリンクローカルユニキャストアドレスをソースとして使用して送信されます。ルーターは、リンクに接続されている他のすべてのルーターのリンクローカルアドレスを学習し、パケット転送中にこれらのアドレスをネクストホップ情報として使用します。
On virtual links, global scope or site-local IP addresses must be used as the source for OSPF protocol packets.
仮想リンクでは、グローバルスコープまたはサイトローカルIPアドレスをOSPFプロトコルパケットのソースとして使用する必要があります。
Link-local addresses appear in OSPF Link-LSAs (see Section 3.4.3.6). 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 3.4.3.3), AS-external-LSAs (Section 3.4.3.5) or intra-area-prefix-LSAs (Section 3.4.3.7).
リンクローカルアドレスは、OSPFリンクLSAに表示されます（セクション3.4.3.6を参照）。ただし、リンクローカルアドレスは、他のOSPF LSAタイプでは使用できません。特に、リンクローカルアドレスは、inter-area-prefix-LSA（セクション3.4.3.3）、AS-external-LSA（セクション3.4.3.5）、またはintra-area-prefix-LSA（セクション3.4.3.7）でアドバタイズしてはなりません。 ）。
In OSPF for IPv6, authentication has been removed from OSPF itself. 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 structures.
OSPF for IPv6では、認証はOSPF自体から削除されています。 「AuType」および「Authentication」フィールドがOSPFパケットヘッダーから削除され、認証関連のすべてのフィールドがOSPFエリアおよびインターフェイス構造から削除されました。
When running over IPv6, OSPF relies on the IP Authentication Header (see [Ref19]) and the IP Encapsulating Security Payload (see [Ref20]) to ensure integrity and authentication/confidentiality of routing exchanges.
IPv6で実行する場合、OSPFはIP認証ヘッダー（[Ref19]を参照）およびIPカプセル化セキュリティペイロード（[Ref20]を参照）に依存して、ルーティング交換の整合性と認証/機密性を保証します。
Protection of OSPF packet exchanges against accidental data corruption is provided by the standard IPv6 16-bit one's complement checksum, covering the entire OSPF packet and prepended IPv6 pseudo-header (see Section A.3.1).
OSPFパケット交換の偶発的なデータ破損に対する保護は、標準のIPv6 16ビットの1の補数チェックサムによって提供され、OSPFパケット全体と付加されたIPv6疑似ヘッダーをカバーします（セクションA.3.1を参照）。
OSPF for IPv6 runs directly over IPv6. Aside from this, all addressing semantics have been removed from the OSPF packet headers, making it essentially "network-protocol-independent". All addressing information is now contained in the various LSA types only.
OSPF for IPv6は、IPv6上で直接実行されます。これとは別に、すべてのアドレッシングセマンティクスはOSPFパケットヘッダーから削除され、本質的に「ネットワークプロトコルに依存しない」ものになっています。すべてのアドレス指定情報は、さまざまなLSAタイプのみに含まれるようになりました。
In detail, changes in OSPF packet format consist of the following:
詳細には、OSPFパケット形式の変更は、次のもので構成されています。
o The OSPF version number has been increased from 2 to 3.
o OSPFバージョン番号が2から3に増えました。
o The Options field in Hello Packets and Database description Packet 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).
o AuthenticationおよびAuTypeフィールドは、OSPFパケットヘッダーから削除されました（セクション2.6を参照）。
o The Hello packet now contains no address information at all, and includes an Interface ID which the originating router has assigned to uniquely identify (among its own interfaces) its interface to the link. This Interface ID becomes the Netowrk-LSA's Link State ID, should the router become Designated-Router on the link.
o Helloパケットにはアドレス情報がまったく含まれておらず、リンクへのインターフェースを（自身のインターフェースの中で）一意に識別するために発信元ルーターが割り当てたインターフェースIDが含まれています。このインターフェイスIDは、ルーターがリンク上のDesignated-Routerになると、Netowrk-LSAのリンク状態IDになります。
o Two option bits, the "R-bit" and the "V6-bit", have been added to the Options field for processing Router-LSAs during the SPF calculation (see Section 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 diagrams belonging to another protocol family may be forwarded.
o SPF計算中にルーターLSAを処理するために、「Rビット」と「V6ビット」の2つのオプションビットがオプションフィールドに追加されました（セクションA.2を参照）。 「Rビット」がクリアな場合、OSPFスピーカーは通過トラフィックの転送に使用されなくてもOSPFトポロジー配布に参加できます。これは、ルーティングプロトコルに参加するマルチホームホストで使用できます。 V6ビットはRビットに特化しています。 V6ビットがクリアな場合、OSPFスピーカーはIPv6データグラムの転送に使用されなくてもOSPFトポロジー配布に参加できます。 Rビットが設定されていて、V6ビットがクリアされている場合、IPv6データグラムは転送されませんが、別のプロトコルファミリに属しているダイアグラムが転送される可能性があります。
o TheOSPF packet header now includes an "Instance ID" which allows multiple OSPF protocol instances to be run on a single link (see Section 2.4).
o OSPFパケットヘッダーに「インスタンスID」が含まれるようになりました。これにより、複数のOSPFプロトコルインスタンスを単一のリンクで実行できます（セクション2.4を参照）。
All addressing semantics have been removed from the LSA header, and from Router-LSAs and Network-LSAs. These two LSAs now describe the routing domain's topology in a network-protocol-independent manner. New LSAs have been added to distribute IPv6 address information, and data required for next hop resolution. The names of some of IPv4's LSAs have been changed to be more consistent with each other.
LSAヘッダーから、およびルーターLSAとネットワークLSAからすべてのアドレッシングセマンティクスが削除されました。これらの2つのLSAは、ルーティングドメインのトポロジをネットワークプロトコルに依存しない方法で記述します。 IPv6アドレス情報、およびネクストホップ解決に必要なデータを配布するために、新しいLSAが追加されました。 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 Section A.2 for details.
o オプションフィールドはLSAヘッダーから削除され、24ビットに拡張され、ルーター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タイプフィールドは（以前のオプションスペースに）16ビットに拡張され、上位3ビットのエンコードフラッディングスコープと不明なLSAタイプの処理が含まれています（セクション2.9を参照）。
o Addresses in LSAs are now expressed as [prefix, prefix length] instead of [address, mask] (see Section A.4.1). The default route is expressed as a prefix with length 0.
o LSAのアドレスは、[address、mask]ではなく[prefix、prefix length]として表現されるようになりました（セクションA.4.1を参照）。デフォルトルートは、長さが0のプレフィックスとして表されます。
o The Router and Network LSAs now have no address information, and are network-protocol-independent.
o ルーターおよびネットワーク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. The LSAs have local-link flooding scope; they are never flooded beyond the link that they are associated with. 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 assert a collection of Options bits to associate with the Network-LSA that will be originated for the link. See Section A.4.8 for details.
o Link-LSAと呼ばれる新しいLSAが導入されました。 LSAにはローカルリンクフラッディングスコープがあります。それらが関連付けられているリンクを超えてフラッディングされることはありません。リンクLSAには3つの目的があります。1）リンクに接続されている他のすべてのルーターにルーターのリンクローカルアドレスを提供する、2）リンクに接続されている他のルーターに、リンクに関連付けるIPv6プレフィックスのリストを通知する、3）これにより、ルーターはオプションビットのコレクションをアサートして、リンクに対して発信されるネットワークLSAに関連付けることができます。詳細については、セクションA.4.8を参照してください。
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 [Ref1]), 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, but rather learn of each other's existence by way of the Designated Router.
IPv4では、ルーターLSAはルーターのIPv4インターフェースアドレス（リンクローカルアドレスに相当するIPv4）を伝送します。これらは、OSPFルーティング計算中にネクストホップを計算するときにのみ使用されるため（[Ref1]のセクション16.1.1を参照）、ローカルリンクを越えてフラッディングする必要はありません。したがって、リンクLSAを使用してこれらのアドレスを配布する方が効率的です。すべての場合において、Helloの受信を通じてリンクローカルアドレスを学習することはできないことに注意してください。NBMAリンクでは、ネクストホップルーターは必ずしもhelloを交換するのではなく、指定ルーターを介して互いの存在を学習します。
o The Options field in the Network LSA is set to the logical OR of the Options that each router on the link advertises in its Link-LSA.
o ネットワークLSAのオプションフィールドは、リンク上の各ルーターがリンクLSAでアドバタイズするオプションの論理ORに設定されます。
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は「Inter-Area-Prefix-LSA」に名前が変更されました。タイプ4サマリーLSAは「Inter-Area-Router-LSA」に名前が変更されました。
o The Link State ID in Inter-Area-Prefix-LSAs, Inter-Area-Router-LSAs and AS-external-LSAs has lost its addressing semantics, and now serves solely to identify individual pieces of the Link State Database. All addresses or Router IDs that were formerly expressed by the Link State ID are now carried in the LSA bodies.
o Inter-Area-Prefix-LSA、Inter-Area-Router-LSA、およびAS-external-LSAのリンク状態IDは、アドレス指定のセマンティクスを失い、リンク状態データベースの個々の部分を識別するためだけに機能するようになりました。以前はリンクステートIDで表現されていたすべてのアドレスまたはルーターIDが、LSA本体で伝送されるようになりました。
o Network-LSAs and Link-LSAs are the only LSAs whose Link State ID carries additional meaning. For these LSAs, the Link State ID is always the Interface ID of the originating router on the link being described. For this reason, Network-LSAs and Link-LSAs are now the only LSAs whose size cannot be limited: a Network-LSA must list all routers connected to the link, and a Link-LSA must list all of a router's addresses on the link.
o ネットワークLSAとリンクLSAは、リンク状態IDが追加の意味を持つ唯一のLSAです。これらのLSAの場合、リンク状態IDは常に、記述されているリンク上の発信元ルーターのインターフェイスIDです。このため、ネットワークLSAおよびリンクLSAは、サイズを制限できない唯一のLSAです。ネットワークLSAは、リンクに接続されているすべてのルーターをリストし、リンクLSAは、リンク上のルーターのすべてのアドレスをリストする必要があります。 。
o A new LSA called the Intra-Area-Prefix-LSA has been introduced. This LSA carries all IPv6 prefix information that in IPv4 is included in Router-LSAs and Network-LSAs. See Section A.4.9 for details.
o Intra-Area-Prefix-LSAと呼ばれる新しいLSAが導入されました。このLSAは、IPv4ではルーターLSAおよびネットワークLSAに含まれるすべてのIPv6プレフィックス情報を伝達します。詳細については、セクションA.4.9を参照してください。
o Inclusion of a forwarding address in AS-external-LSAs is now optional, as is the inclusion of an external route tag (see [Ref5]). 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 itself. For example, this can be used to attach BGP path attributes to external routes as proposed in [Ref10].
o AS-external-LSAに転送アドレスを含めること、および外部ルートタグを含めることはオプションになりました（[Ref5]を参照）。さらに、AS-external-LSAは、OSPFプロトコル自体のスコープ外にある追加のルート属性を含めるために、別のLSAを参照できるようになりました。たとえば、[Ref10]で提案されているように、これを使用してBGPパス属性を外部ルートにアタッチできます。
Handling of unknown LSA types has been made more flexible so that, based on LS type, unknown LSA types are either treated as having link-local flooding scope, or are stored and flooded as if they were understood (desirable for things like the proposed External-Attributes-LSA in [Ref10]). This behavior is explicitly coded in the LSA Handling bit of the link state header's LS type field (see Section A.4.2.1).
不明なLSAタイプの処理がより柔軟になり、LSタイプに基づいて、不明なLSAタイプはリンクローカルフラッディングスコープを持つものとして扱われるか、または理解されたかのように格納およびフラッディングされます（提案された外部のようなものに望ましい） [属性10]の[LSA] [Ref10]）。この動作は、リンク状態ヘッダーのLSタイプフィールドのLSA処理ビットで明示的にコード化されています（セクションA.4.2.1を参照）。
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 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.
OSPF for IPv4では、スタブエリアは、エリアの内部ルーターのリンク状態データベースとルーティングテーブルのサイズを最小限に抑えるように設計されています。これにより、最小限のリソースを持つルーターが、非常に大規模なOSPFルーティングドメインにも参加できるようになります。
In OSPF for IPv6, the concept of stub 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. This is the IPv6 equivalent of the LSA types carried in IPv4 stub areas: router-LSAs, network-LSAs and type 3 summary-LSAs.
OSPF for IPv6では、スタブエリアの概念が維持されています。 IPv6では、必須のLSAタイプの中で、スタブエリアはルーターLSA、ネットワークLSA、インターエリアプレフィックスLSA、リンクLSA、およびイントラエリアプレフィックスLSAのみを伝送します。これは、IPv4スタブエリアで運ばれるLSAタイプと同等のIPv6です。ルーターLSA、ネットワークLSA、タイプ3サマリーLSA。
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 Section A.4.2.1). Uncontrolled introduction of such LSAs could cause a stub area's link-state database to grow larger than its component routers' capacities.
ただし、IPv4とは異なり、IPv6では、認識されないLSタイプのLSAに「タイプが理解されているかのようにLSAを格納およびフラッディングする」というラベルを付けることができます（セクションA.4.2.1のUビットを参照）。このようなLSAの制御されていない導入により、スタブエリアのリンク状態データベースが、コンポーネントルーターの容量よりも大きくなる可能性があります。
To guard against this, the following rule regarding stub areas has been established: an LSA whose LS type is unrecognized may only be flooded into/throughout a stub area if both a) the LSA has area or link-local flooding scope and b) the LSA has U-bit set to 0. See Section 3.5 for details.
これを防ぐために、スタブエリアに関する次のルールが確立されています。LSタイプが認識されないLSAは、a）LSAにエリアまたはリンクローカルフラッディングスコープがあり、かつb） LSAのUビットは0に設定されています。詳細については、セクション3.5を参照してください。
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, and neighbors on broadcast, NBMA and Point-to-MultiPoint links are identified by their IPv4 interface addresses.
OSPF for IPv6では、特定のリンク上の隣接ルーターは常にOSPFルーターIDによって識別されます。これは、ポイントツーポイントネットワークおよび仮想リンク上のネイバーがルーターIDによって識別され、ブロードキャスト、NBMAおよびポイントツーマルチポイントリンク上のネイバーがIPv4インターフェースアドレスによって識別されるIPv4の動作とは対照的です。
This change affects the reception of OSPF packets (see Section 8.2 of [Ref1]), the lookup of neighbors (Section 10 of [Ref1]) and the reception of Hello Packets (Section 10.5 of [Ref1]).
この変更は、OSPFパケットの受信（[Ref1]のセクション8.2を参照）、ネイバーの検索（[Ref1]のセクション10）、およびHelloパケットの受信（[Ref1]のセクション10.5）に影響します。
The Router ID of 0.0.0.0 is reserved, and should not be used.
ルーターID 0.0.0.0は予約されているため、使用しないでください。
When going from IPv4 to IPv6, the basic OSPF mechanisms remain unchanged from those documented in [Ref1]. These mechanisms are briefly outlined in Section 4 of [Ref1]. 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, through 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, and to elect Designated Routers and Backup Designated Routers on broadcast and NBMA links. The decision as to which neighbor relationships become adjacencies, along with 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メカニズムは[Ref1]に記載されているものから変更されていません。これらのメカニズムは、[Ref1]のセクション4で簡単に概説されています。 IPv6とIPv4の両方に、LSAで構成され、隣接するルーター間で同期されるリンク状態データベースがあります。最初の同期は、データベース交換プロセス、データベース記述、リンク状態要求、リンク状態更新パケットの交換を通じて実行されます。その後、リンク状態更新パケットとリンク状態確認パケットを利用して、フラッディングによってデータベースの同期が維持されます。 IPv6とIPv4はどちらもOSPF Helloパケットを使用して、ネイバー関係を検出および維持し、ブロードキャストおよびNBMAリンクで指定ルーターとバックアップ指定ルーターを選出します。エリア間のルーティングの背後にある基本的な考え方、外部情報をAS-external-LSAにインポートすること、およびさまざまなルーティング計算も、隣接関係になる隣接関係の決定は同じです。
In particular, the following IPv4 OSPF functionality described in [Ref1] remains completely unchanged for IPv6:
特に、[Ref1]で説明されている次のIPv4 OSPF機能は、IPv6でもまったく変更されていません。
o Both IPv4 and IPv6 use OSPF packet types described in Section 4.3 of [Ref1], 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 remains the same.
o IPv4とIPv6はどちらも、[Ref1]のセクション4.3で説明されているOSPFパケットタイプを使用しています。つまり、Hello、データベースの説明、リンク状態要求、リンク状態更新、リンク状態確認パケットです。一部のケース（Helloパケットなど）では形式が多少変更されていますが、さまざまなパケットタイプの機能は同じです。
o The system requirements for an OSPF implementation remain unchanged, although OSPF for IPv6 requires an IPv6 protocol stack (from the network layer on down) since it runs directly over the IPv6 network layer.
o OSPF実装のシステム要件は変更されていませんが、IPv6のOSPFはIPv6ネットワークレイヤー上で直接実行されるため、IPv6プロトコルスタック（ネットワークレイヤーから下）が必要です。
o The discovery and maintenance of neighbor relationships, and the selection and establishment of adjacencies remain the same. This includes election of the Designated Router and Backup Designated Router on broadcast and NBMA links. These mechanisms are described in Sections 7, 7.1, 7.2, 7.3, 7.4 and 7.5 of [Ref1].
o ネイバー関係の検出と維持、および隣接関係の選択と確立は同じままです。これには、ブロードキャストおよびNBMAリンクでの代表ルーターとバックアップ代表ルーターの選択が含まれます。これらのメカニズムについては、[Ref1]のセクション7、7.1、7.2、7.3、7.4、および7.5で説明されています。
o The link types (or equivalently, interface types) supported by OSPF remain unchanged, namely: point-to-point, broadcast, NBMA, Point-to-MultiPoint and virtual links.
o OSPFでサポートされているリンクタイプ（または同等のインターフェースタイプ）は変更されていません。つまり、ポイントツーポイント、ブロードキャスト、NBMA、ポイントツーマルチポイント、および仮想リンクです。
o The interface state machine, including the list of OSPF interface states and events, and the Designated Router and Backup Designated Router election algorithm, remain unchanged. These are described in Sections 9.1, 9.2, 9.3 and 9.4 of [Ref1].
o OSPFインターフェイスの状態とイベントのリストを含むインターフェイスステートマシン、および代表ルータとバックアップ代表ルータの選択アルゴリズムは変更されていません。これらについては、[Ref1]のセクション9.1、9.2、9.3、および9.4で説明されています。
o The neighbor state machine, including the list of OSPF neighbor states and events, remain unchanged. These are described in Sections 10.1, 10.2, 10.3 and 10.4 of [Ref1].
o OSPFネイバーの状態とイベントのリストを含むネイバーステートマシンは変更されません。これらについては、[Ref1]のセクション10.1、10.2、10.3、10.4で説明されています。
o Aging of the link-state database, as well as flushing LSAs from the routing domain through the premature aging process, remains unchanged from the description in Sections 14 and 14.1 of [Ref1].
o リンクステートデータベースのエージング、およびルーティングドメインからの早期エージングプロセスによるLSAのフラッシュは、[Ref1]のセクション14および14.1の説明から変更されていません。
However, some OSPF protocol mechanisms have changed, as outlined in Section 2 above. These changes are explained in detail in the following subsections, making references to the appropriate sections of [Ref1].
ただし、上記のセクション2で概説したように、一部のOSPFプロトコルメカニズムは変更されています。これらの変更は、[Ref1]の適切なセクションを参照して、以下のサブセクションで詳細に説明されています。
The following subsections provide a recipe for turning an IPv4 OSPF implementation into an IPv6 OSPF implementation.
次のサブセクションでは、IPv4 OSPF実装をIPv6 OSPF実装に変換するためのレシピを提供します。
The major OSPF data structures are the same for both IPv4 and IPv6: areas, interfaces, neighbors, the link-state database and the routing table. The top-level data structures for IPv6 remain those listed in Section 5 of [Ref1], with the following modifications:
主要なOSPFデータ構造は、IPv4とIPv6の両方で同じです：エリア、インターフェイス、ネイバー、リンク状態データベース、ルーティングテーブル。 IPv6のトップレベルのデータ構造は、[Ref1]のセクション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 which have AS flooding scope. LSAs with unknown LS type, U-bit set to 1 (flood even when unrecognized) and AS flooding scope also appear in the top-level data structure.
o LSタイプとASフラッディングスコープが既知のすべてのLSAは、特定のエリアまたはリンクに属するのではなく、トップレベルのデータ構造に表示されます。 AS外部LSAは、ASフラッディングスコープを持つ、この仕様で定義されている唯一のLSAです。不明なLSタイプ、1に設定されたUビット（認識されない場合でもフラッディング）、およびASフラッディングスコープのLSAもトップレベルのデータ構造に表示されます。
The IPv6 area data structure contains all elements defined for IPv4 areas in Section 6 of [Ref1]. In addition, all LSAs of known type which 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. IPv6 routers implementing MOSPF add group-membership-LSAs to the area data structure. Type-7-LSAs belong to an NSSA area's data structure.
IPv6エリアのデータ構造には、[Ref1]のセクション6でIPv4エリア用に定義されたすべての要素が含まれています。さらに、エリアフラッディングスコープを持つ既知のタイプのすべてのLSAは、IPv6エリアデータ構造に含まれています。これには常に次のLSAタイプが含まれます：ルーターLSA、ネットワークLSA、インターエリアプレフィックスLSA、インターエリアルーターLSA、イントラエリアプレフィックスLSA。不明なLSタイプ、1に設定されたUビット（認識されない場合でもフラッド）、およびエリアスコープのLSAもエリアデータ構造に表示されます。 MOSPFを実装するIPv6ルーターは、グループメンバーシップLSAをエリアデータ構造に追加します。 Type-7-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 [Ref1]) as follows:
OSPF for IPv6では、インターフェースはルーターをリンクに接続します。 IPv6インターフェイス構造は、IPv4インターフェイス構造（[Ref1]のセクション9で定義）を次のように変更します。
Interface ID Every interface is assigned an Interface ID, which uniquely identifies the interface with the router. For example, some implementations may be able to use the MIB-II IfIndex ([Ref3]) as Interface ID. The Interface ID appears in Hello packets sent out the interface, the link-local-LSA originated by 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.
インターフェースIDすべてのインターフェースには、ルーターとのインターフェースを一意に識別するインターフェースIDが割り当てられています。たとえば、一部の実装では、MIB-II IfIndex（[Ref3]）をインターフェイスIDとして使用できる場合があります。インターフェイスIDは、インターフェイスから送信されるHelloパケット、接続されたリンクのルーターによって発信されたリンクローカルLSA、および関連するエリアのルーターLSAによって発信されたルーターLSAに表示されます。また、ルーターが代表ルーターとして選出された場合に、ルーターがリンクに対して発信するネットワークLSAのリンク状態IDとしても機能します。
Instance ID Every interface is assigned an Instance ID. This should default to 0, and is only necessary to assign differently 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.
インスタンスIDすべてのインターフェースにはインスタンスIDが割り当てられています。これはデフォルトで0になり、OSPFルーターの複数の個別のコミュニティを含むリンクに異なる方法で割り当てる場合にのみ必要です。たとえば、特定のイーサネットセグメント上に、別々に保持したい2つのルーターコミュニティがあるとします。
The first community is given an Instance ID of 0, by assigning 0 as the Instance ID of all its routers' interfaces to the ethernet. An Instance ID of 1 is assigned to the other routers' interfaces to the ethernet. The OSPF transmit and receive processing (see Section 3.2) will then keep the two communities separate.
最初のコミュニティには、イーサネットへのすべてのルーターのインターフェースのインスタンスIDとして0を割り当てることにより、インスタンスIDとして0が付与されます。 1のインスタンスIDは、イーサネットへの他のルーターのインターフェースに割り当てられます。 OSPFの送受信処理（セクション3.2を参照）は、2つのコミュニティを分離したままにします。
List of LSAs with link-local scope All LSAs with link-local scope and which were originated/flooded on the link belong to the interface structure which connects to the link. This includes the collection of the link's link-LSAs.
リンクローカルスコープを持つLSAのリストリンクローカルスコープを持つすべてのLSAは、リンクで発信/フラッディングされ、リンクに接続するインターフェイス構造に属します。これには、リンクのリンクLSAのコレクションが含まれます。
List of LSAs with unknown LS type All LSAs with unknown LS type and U-bit set to 0 (if unrecognized, treat the LSA as if it had link-local flooding scope) are kept in the data structure for the interface that received the LSA.
LSタイプが不明なLSAのリストLSタイプが不明でUビットが0に設定されたすべてのLSA（認識されない場合は、LSAをリンクローカルフラッディングスコープと同様に扱います）は、LSAを受信したインターフェイスのデータ構造に保持されます。
IP interface address For IPv6, the IPv6 address appearing in the source of OSPF packets sent out the interface is almost always a link-local address. The one exception is for virtual links, which must use one of the router's own site-local or global IPv6 addresses as IP interface address.
IPインターフェースアドレスIPv6の場合、インターフェースから送信されるOSPFパケットのソースに表示されるIPv6アドレスは、ほとんどの場合、リンクローカルアドレスです。 1つの例外は仮想リンクです。仮想リンクは、ルーター自体のサイトローカルまたはグローバルIPv6アドレスのいずれかをIPインターフェイスアドレスとして使用する必要があります。
List of link prefixes A list of IPv6 prefixes can be configured for the attached link. These will be advertised by the router in link-LSAs, so that they can be advertised by the link's Designated Router in intra-area-prefix-LSAs.
リンクプレフィックスのリスト接続されたリンクにIPv6プレフィックスのリストを構成できます。これらはリンクLSA内のルーターによってアドバタイズされるため、リンクの指定ルーターによってintra-area-prefix-LSA内でアドバタイズできます。
In OSPF for IPv6, each router interface has a single metric, representing the cost of sending packets out the interface. In addition, OSPF for IPv6 relies on the IP Authentication Header (see [Ref19]) and the IP Encapsulating Security Payload (see [Ref20]) to ensure integrity and authentication/confidentiality of routing exchanges. For that reason, AuType and Authentication key are not associated with IPv6 OSPF interfaces.
OSPF for IPv6では、各ルーターインターフェイスに単一のメトリックがあり、インターフェイスからパケットを送信するコストを表します。さらに、OSPF for IPv6はIP認証ヘッダー（[Ref19]を参照）およびIPカプセル化セキュリティペイロード（[Ref20]を参照）に依存して、ルーティング交換の整合性と認証/機密性を保証します。そのため、AuTypeおよび認証キーはIPv6 OSPFインターフェースに関連付けられていません。
Interface states, events, and the interface state machine remain unchanged from IPv4, and are documented in Sections 9.1, 9.2 and 9.3 of [Ref1] respectively. The Designated Router and Backup Designated Router election algorithm also remains unchanged from the IPv4 election in Section 9.4 of [Ref1].
インターフェイスの状態、イベント、インターフェイスの状態マシンはIPv4から変更されていません。それぞれ[Ref1]のセクション9.1、9.2、9.3に記載されています。指定ルーターとバックアップ指定ルーターの選定アルゴリズムも、[Ref1]のセクション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, if 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 [Ref1] are:
ネイバー構造は、IPv6とIPv4の両方で同じ機能を実行します。つまり、隣接関係が必要になった場合に、2つのルーター間の隣接関係を形成するために必要なすべての情報を収集します。各ネイバー構造は、単一のOSPFインターフェースにバインドされています。 IPv6ネイバー構造と、[Ref1]のセクション10でIPv4用に定義されたネイバー構造の違いは次のとおりです。
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 link to the neighbor or b) advertising a link to a network where the neighbor has become Designated Router.
ネイバーのインターフェイスIDネイバーがHelloパケットでアドバタイズするインターフェイスIDは、ネイバー構造に記録する必要があります。 a）ネイバーへのポイントツーポイントリンクをアドバタイズするか、またはb）ネイバーが指定ルーターになったネットワークへのリンクをアドバタイズする場合、ルーターはルーターのルーターLSAにネイバーのインターフェイスIDを含めます。
Neighbor IP address Except on virtual links, the neighbor's IP address will be an IPv6 link-local address.
ネイバーIPアドレス仮想リンクを除き、ネイバーのIPアドレスはIPv6リンクローカルアドレスになります。
Neighbor's Designated Router The neighbor's choice of Designated Router is now encoded as a Router ID, instead of as an IP address.
ネイバーの指定ルーターネイバーが選択した指定ルーターは、IPアドレスではなくルーターIDとしてエンコードされるようになりました。
Neighbor's Backup Designated Router The neighbor's choice of Designated Router is now encoded as a Router ID, instead of as an IP address.
ネイバーのバックアップ指定ルーターネイバーが選択した指定ルーターは、IPアドレスではなくルーターIDとしてエンコードされるようになりました。
Neighbor states, events, and the neighbor state machine remain unchanged from IPv4, and are documented in Sections 10.1, 10.2 and 10.3 of [Ref1] respectively. The decision as to which adjacencies to form also remains unchanged from the IPv4 logic documented in Section 10.4 of [Ref1].
ネイバーステート、イベント、ネイバーステートマシンはIPv4から変更されていません。[Ref1]のセクション10.1、10.2、10.3にそれぞれ記載されています。形成する隣接関係の決定も、[Ref1]のセクション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.
OSPF for IPv6は、IPv6のネットワークレイヤー上で直接実行されます。そのため、1つ以上のIPv6ヘッダーにカプセル化され、すぐにカプセル化するIPv6ヘッダーの次のヘッダーフィールドが値89に設定されます。
As for IPv4, in 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 IPv4, encoded by the
IPv4については、IPv6のOSPFルーティングプロトコルパケットは隣接のみを介して送信されます（隣接を検出するために使用されるHelloパケットを除く）。 OSPFパケットのタイプと機能はIPv4とIPv4の両方で同じであり、
Type field of the standard OSPF packet header.
標準OSPFパケットヘッダーのタイプフィールド。
When an IPv6 router sends an OSPF routing protocol packet, it fills in the fields of the standard OSPF for IPv6 packet header (see Section A.3.1) as follows:
IPv6ルーターがOSPFルーティングプロトコルパケットを送信すると、標準のOSPF for IPv6パケットヘッダー（セクションA.3.1を参照）のフィールドに次のように入力されます。
Version # Set to 3, the version number of the protocol as documented in this specification.
バージョン＃3に設定。この仕様に記載されているプロトコルのバージョン番号。
Type The type of OSPF packet, such as Link state Update or Hello Packet.
タイプリンク状態更新や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（パケットを発信している）ルーター自体のID。
Area ID The OSPF area that the packet is being sent into.
Area OFパケットの送信先のOSPFエリア。
Instance ID The OSPF Instance ID associated with the interface that the packet is being sent out of.
インスタンスIDパケットが送信されるインターフェイスに関連付けられているOSPFインスタンスID。
Checksum The standard IPv6 16-bit one's complement checksum, covering the entire OSPF packet and prepended IPv6 pseudo-header (see Section A.3.1).
チェックサム標準のIPv6 16ビットの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 [Ref1]. 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送信元および宛先アドレスの選択は、[Ref1]のセクション8.1のIPv4ロジックと同じように実行されます。 IPv6宛先アドレスは、AllSPFRouters、AllDRouters、および隣接のもう一方の端に関連付けられたネイバーIPアドレス（IPv6では、仮想リンクを除くすべてのリンクの場合、IPv6リンクローカルアドレスです）から選択されます。
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 [Ref1] respectively. Sending Hello Packets is documented in Section 3.2.1.1, and the sending of Database Description Packets in Section 3.2.1.2. The sending of Link State Update Packets is documented in Section 3.5.2.
リンク状態要求パケットとリンク状態確認パケットの送信は、[Ref1]のセクション10.9と13.5にそれぞれ記載されているIPv4手順から変更されていません。 Helloパケットの送信についてはセクション3.2.1.1で説明されており、データベース記述パケットの送信についてはセクション3.2.1.2で説明されています。リンク状態更新パケットの送信については、セクション3.5.2で説明されています。
IPv6 changes the way OSPF Hello packets are sent in the following ways (compare to Section 9.5 of [Ref1]):
IPv6は、OSPF Helloパケットの送信方法を次のように変更します（[Ref1]のセクション9.5と比較してください）。
o Before the Hello Packet is sent out an interface, the interface's Interface ID must be copied into the Hello Packet.
o Helloパケットがインターフェイスに送信される前に、インターフェイスのインターフェイスIDをHelloパケットにコピーする必要があります。
o The Hello Packet no longer contains an IP network mask, as OSPF for IPv6 runs per-link instead of per-subnet.
o OSPFのIPv6はサブネットごとではなくリンクごとに実行されるため、HelloパケットにはIPネットワークマスクが含まれなくなりました。
o The choice of Designated Router and Backup Designated Router are now indicated within Hellos by their Router IDs, instead of by their IP interface addresses. Advertising the Designated Router (or Backup Designated Router) as 0.0.0.0 indicates that the Designated Router (or Backup Designated Router) has not yet been chosen.
o 指定ルーターとバックアップ指定ルーターの選択は、IPインターフェイスアドレスではなく、ルーターIDによってHello内に示されるようになりました。指定ルーター（またはバックアップ指定ルーター）を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: The E-bit is set if and only if the interface attaches to a non-stub area, the N-bit is set if and only if the interface attaches to an NSSA area (see [Ref9]), and the DC- bit is set if and only if the router wishes to suppress the sending of future Hellos over the interface (see [Ref11]). Unrecognized bits in the Hello Packet's Options field should be cleared.
o Helloパケット内のオプションフィールドが移動し、プロセスが大きくなりました。より多くのオプションビットが可能になりました。 Helloパケットで正しく設定する必要のあるものは次のとおりです。インターフェイスが非スタブエリアに接続している場合にのみEビットが設定され、インターフェイスがNSSAエリアに接続している場合にのみNビットが設定されます（を参照）。 [Ref9]）、およびルーターがインターフェイスを介した今後のHelloの送信を抑制したい場合にのみ、DCビットが設定されます（[Ref11]を参照）。 Helloパケットのオプションフィールドの認識されないビットはクリアする必要があります。
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 [Ref1].
[Ref1]のセクション9.5.1に記載されているように、NBMAネットワークでのHelloパケットの送信は、IPv4の場合とまったく同じ方法でIPv6に進みます。
The sending of Database Description packets differs from Section 10.8 of [Ref1] in the following ways:
データベース記述パケットの送信は、[Ref1]のセクション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: The MC-bit is set if and only if the router is forwarding multicast datagrams according to the MOSPF specification in [Ref7], and the DC-bit is set if and only if the router wishes to suppress the sending of Hellos over the interface (see [Ref11]). Unrecognized bits in the Database Description Packet's Options field should be cleared.
o Database Descriptionパケット内のOptionsフィールドが移動し、その過程で大きくなりました。より多くのオプションビットが可能になりました。データベース記述パケットで正しく設定する必要のあるものは、次のとおりです。MCビットは、ルーターが[Ref7]のMOSPF仕様に従ってマルチキャストデータグラムを転送している場合にのみ設定され、DCビットは、ルーターは、インターフェイスを介したHelloの送信を抑制したい（[Ref11]を参照）。データベース記述パケットのオプションフィールドの認識されないビットはクリアする必要があります。
Whenever an OSPF protocol packet is received by the router it is marked with the interface it was received on. For routers that have virtual links configured, it may not be immediately obvious which interface to associate the packet with. For example, consider the Router RT11 depicted in Figure 6 of [Ref1]. 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プロトコルパケットがルーターによって受信されるときはいつでも、それはそれが受信されたインターフェースでマークされます。仮想リンクが構成されているルーターの場合、どのインターフェイスにパケットを関連付けるかがすぐに分からない場合があります。たとえば、[Ref1]の図6に示されているルーターRT11を考えてみます。 RT11がネットワークN8へのインターフェースでOSPFプロトコルパケットを受信した場合、そのパケットをエリア2へのインターフェースまたはルーターRT10（バックボーンの一部）への仮想リンクに関連付けることができます。以下では、パケットは最初は非仮想リンクに関連付けられていると想定しています。
In order for the packet to be passed to OSPF for processing, the following tests must be performed on the encapsulating IPv6 headers:
パケットがOSPFに渡されて処理されるようにするには、カプセル化するIPv6ヘッダーに対して次のテストを実行する必要があります。
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), or one of the IP multicast addresses AllSPFRouters or AllDRouters.
o パケットのIP宛先アドレスは、受信インターフェイスに関連付けられたIPv6ユニキャストアドレスの1つ（リンクローカルアドレスを含む）、またはIPマルチキャストアドレスAllSPFRoutersまたはAllDRoutersのいずれかである必要があります。
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 [Ref19]) and the IP Encapsulating Security Payloads (see [Ref20]) must be processed and/or verified to ensure integrity and authentication/confidentiality of OSPF routing exchanges.
o カプセル化IP認証ヘッダー（[Ref19]を参照）およびIPカプセル化セキュリティペイロード（[Ref20]を参照）は、OSPFルーティング交換の整合性と認証/機密性を保証するために処理または検証する必要があります。
o Locally originated packets should not be passed on to OSPF. That is, the source IPv6 address should be examined to make sure this is not a multicast packet that the router itself generated.
o ローカルで発信されたパケットはOSPFに渡すべきではありません。つまり、ソースIPv6アドレスを調べて、これがルーター自体が生成したマルチキャストパケットでないことを確認する必要があります。
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 interface. If they do not, the packet should be discarded:
カプセル化IPv6ヘッダーを処理した後、OSPFパケットヘッダーが処理されます。ヘッダーで指定されたフィールドは、受信インターフェイス用に構成されたフィールドと一致する必要があります。そうでない場合は、パケットを破棄する必要があります。
o The version number field must specify protocol version 3.
o バージョン番号フィールドには、プロトコルバージョン3を指定する必要があります。
o The standard IPv6 16-bit one's complement checksum, covering the entire OSPF packet and prepended IPv6 pseudo-header, must be verified (see Section A.3.1).
o OSPFパケット全体と付加されたIPv6疑似ヘッダーをカバーする標準IPv6 16ビットの1の補数チェックサムを検証する必要があります（セクションA.3.1を参照）。
o The Area ID found in the OSPF header must be verified. If both of the following cases fail, the packet should be discarded. The Area ID specified in the header must either:
o OSPFヘッダーにあるエリアIDを確認する必要があります。次の両方のケースが失敗した場合、パケットは破棄されます。ヘッダーで指定されたエリアIDは、次のいずれかである必要があります。
(1) Match the Area ID of the receiving interface. In this case, unlike for IPv4, the IPv6 source address is not restricted to lie on the same IP subnet as the receiving interface. IPv6 OSPF runs per-link, instead of per-IP-subnet.
（1）受信インターフェイスのエリアIDを一致させます。この場合、IPv4とは異なり、IPv6送信元アドレスは、受信インターフェイスと同じIPサブネット上にあることに制限されません。 IPv6 OSPFは、IPサブネットごとではなく、リンクごとに実行されます。
(2) Indicate the backbone. In this case, the packet has been sent over a virtual link. The receiving router must be an area border router, and the Router ID specified in the packet (the source router) must be the other end of a configured virtual link. The receiving interface must also attach to the virtual link's configured Transit area. If all of these checks succeed, the packet is accepted and is from now on associated with the virtual link (and the backbone area).
（2）バックボーンを示します。この場合、パケットは仮想リンクを介して送信されています。受信ルーターはエリア境界ルーターである必要があり、パケットで指定されたルーターID（ソースルーター）は、構成された仮想リンクのもう一方の端である必要があります。受信インターフェイスは、仮想リンクの設定されたトランジットエリアにも接続する必要があります。これらすべてのチェックが成功した場合、パケットは受け入れられ、今後は仮想リンク（およびバックボーンエリア）に関連付けられます。
o The Instance ID specified in the OSPF header must match the receiving interface's Instance ID.
o OSPFヘッダーで指定されたインスタンスIDは、受信インターフェイスのインスタンスIDと一致する必要があります。
o Packets whose IP destination is AllDRouters should only be accepted if the state of the receiving interface is DR or Backup (see Section 9.1).
o IP宛先がAllDRoutersであるパケットは、受信インターフェースの状態がDRまたはバックアップの場合にのみ受け入れられる必要があります（セクション9.1を参照）。
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 Protocol. 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 the the received packet's OSPF header. Packets not matching any active neighbor are discarded.
パケットタイプがHelloの場合は、Helloプロトコルでさらに処理する必要があります。他のすべてのパケットタイプは、隣接でのみ送受信されます。つまり、パケットはルーターのアクティブなネイバーのいずれかから送信されたものでなければなりません。ネイバーは、受信したパケットのOSPFヘッダーに表示されるルーターIDによって識別されます。アクティブなネイバーに一致しないパケットは破棄されます。
The receive processing of Database Description Packets, Link State Request Packets and Link State Acknowledgment Packets remains unchanged from the IPv4 procedures documented in Sections 10.6, 10.7 and 13.7 of [Ref1] respectively. The receiving of Hello Packets is documented in Section 3.2.2.1, and the receiving of Link State Update Packets is documented in Section 3.5.1.
データベース記述パケット、リンク状態要求パケット、リンク状態確認パケットの受信処理は、それぞれ[Ref1]のセクション10.6、10.7、13.7に記載されているIPv4手順から変更されていません。 Helloパケットの受信はセクション3.2.2.1に記載されており、リンク状態更新パケットの受信はセクション3.5.1に記載されています。
The receive processing of Hello Packets differs from Section 10.5 of [Ref1] in the following ways:
Helloパケットの受信処理は、[Ref1]のセクション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 ネイバーが選択した代表ルータとバックアップ代表ルータは、IPインターフェイスアドレスではなく、OSPFルータIDとしてエンコードされるようになりました。
The routing table used by OSPF for IPv4 is defined in Section 11 of [Ref1]. 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 3.8).
OSPF for IPv4が使用するルーティングテーブルは、[Ref1]のセクション11で定義されています。 IPv6には類似のルーティングテーブルエントリがあります。IPv6アドレスプレフィックスとAS境界ルーターのルーティングテーブルエントリがあります。後者のルーティングテーブルエントリは、ルーティングテーブルのビルドプロセス中に中間結果を保持するためにのみ使用されます（セクション3.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の組み合わせによって識別されます。これらのルーティングテーブルエントリにより、intra-area-prefix-LSAのトランジットリンクにアドバタイズされるIPプレフィックスへのパスを後で計算できます。
The fields in the IPv4 OSPF routing table (see Section 11 of [Ref1]) 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 router.
IPv4 OSPFルーティングテーブル（[Ref1]のセクション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 Section A.4.9).
IPv6の場合、ルーティングテーブルエントリのリンク状態起点フィールドは、直接または間接的にルーティングテーブルエントリを生成したrouter-LSAまたはnetwork-LSAです。たとえば、ルーティングテーブルエントリがIPv6プレフィックスへのルートを記述している場合、リンク状態の起点は、ルートを生成したintra-area-prefix-LSAの本文にリストされているrouter-LSAまたはnetwork-LSAです（セクションA.4.9を参照してください）。
Routing table lookup (i.e., determining the best matching routing table entry during IP forwarding) is the same for IPv6 as for IPv4.
ルーティングテーブルの検索（つまり、IP転送中に最も一致するルーティングテーブルエントリを決定すること）は、IPv6の場合とIPv4の場合とで同じです。
For IPv6, the OSPF LSA header has changed slightly, with the LS type field expanding and the Options field being moved into the body of appropriate LSAs. Also, the formats of some LSAs have changed somewhat (namely router-LSAs, network-LSAs and AS-external-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 [Ref1], and is not encoded within OSPF for IPv6's LSAs.
IPv6の場合、OSPF LSAヘッダーが少し変更され、LSタイプフィールドが拡張され、オプションフィールドが適切なLSAの本文に移動されました。また、一部のLSAの形式は多少変更され（つまり、ルーターLSA、ネットワークLSA、AS外部LSA）、他のLSAの名前は変更されました（タイプ3と4のサマリーLSAがエリア間LSAになりました） prefix-LSAおよびinter-area-router- LSA）および追加のLSA（Link-LSAおよびIntra-Area-Prefix-LSA）が追加されました。 Type of Service（TOS）はOSPFv2仕様[Ref1]から削除され、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 [Ref1] respectively. However, the following fields have changed for IPv6:
IPv4とIPv6の両方で、すべてのOSPF LSAは標準の20バイトLSAヘッダーで始まります。ただし、この20バイトのヘッダーの内容はIPv6で変更されています。 [Ref1]のセクション12.1.1、12.1.5、12.1.6、12.1.7およびA.4.1に記載されているように、LSAヘッダー内のLSエージ、広告ルーター、LSシーケンス番号、LSチェックサムおよび長さフィールドは変更されません。それぞれ。ただし、IPv6では次のフィールドが変更されました。
Options The Options field has been removed from the standard 20 byte LSA header, and 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 Section A.2). In addition 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の本文に含まれています。オプションフィールドのサイズが8ビットから24ビットに増加し、一部のビット定義が変更されました（セクションA.2を参照）。さらに、LSAの本体内でアドバタイズされる各プレフィックスには、長さが8ビットの個別のPrefixOptionsフィールドが付加されます。
LS type The size of the LS type field has increased from 8 to 16 bits, with the top two bits encoding flooding scope and the next bit encoding the handling of unknown LS types. See Section A.4.2.1 for the current coding of the LS type field.
LSタイプLSタイプフィールドのサイズが8ビットから16ビットに増え、上位2ビットはフラッディングスコープをエンコードし、次のビットは不明なLSタイプの処理をエンコードします。 LSタイプフィールドの現在のコーディングについては、セクションA.4.2.1を参照してください。
Link State ID Link State ID remains at 32 bits in length, but except for network-LSAs and link-LSAs, 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.
リンク状態IDリンク状態IDの長さは32ビットのままですが、ネットワークLSAとリンクLSAを除いて、リンク状態IDはアドレッシングセマンティクスを排除しています。たとえば、複数のAS外部LSAを発信するIPv6ルーターは、最初に0.0.0.1のリンク状態IDを割り当て、2番目に0.0.0.2のリンク状態IDを割り当てることから開始できます。 AS-external-LSAのリンク状態ID内でネットワーク番号をエンコードするIPv4の動作の代わりに、IPv6リンク状態IDは、同じルーターから発信された複数のLSAを区別する方法として機能します。
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.
ネットワーク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 [Ref1]).
IPv6では、IPv4と同様に、個々のLSAは、LSタイプ、リンク状態ID、およびアドバタイジングルーターフィールドの組み合わせによって識別されます。 LSAの2つのインスタンスが与えられた場合、LSチェックサムとLSエージをタイブレーカーとして使用して、LSAのLSシーケンス番号を調べることにより、最新のインスタンスが決定されます（[Ref1]のセクション13.1を参照）。
In IPv6, the link-state database is split across three separate data structures. LSAs with AS flooding scope are contained within the top-level OSPF data structure (see Section 3.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 3.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, and intra-area-prefix-LSAs. LSAs with unknown LS type and U-bit set to 0 and/or link-local flooding scope are contained within the appropriate interface structure (see Section 3.1.2); this includes link-LSAs.
IPv6では、リンクステートデータベースは3つの個別のデータ構造に分割されています。 ASフラッディングスコープを持つLSAは、LSタイプが既知であるか、Uビットが1（認識されない場合でもフラッディング）である限り、最上位のOSPFデータ構造（セクション3.1を参照）に含まれます。これには、AS外部LSAが含まれます。エリアフラッディングスコープのLSAは、LSタイプが既知であるか、Uビットが1（認識されない場合でもフラッディング）である限り、適切なエリア構造（セクション3.1.1を参照）に含まれます。これには、ルーターLSA、ネットワークLSA、インターエリアプレフィックスLSA、インターエリアルーターLSA、イントラエリアプレフィックスLSAが含まれます。 LSタイプが不明でUビットが0に設定されているLSA、またはリンクローカルフラッディングスコープが適切なインターフェース構造内に含まれている（セクション3.1.2を参照）。これにはリンクLSAが含まれます。
To lookup or install an LSA in the database, you first examine the LS type and the LSA's context (i.e., to which area or link does the LSA belong). This information allows you to find the correct list of LSAs, all of the same LS type, where you then search based on the LSA's Link State ID and Advertising Router.
データベースでLSAを検索またはインストールするには、まずLSタイプとLSAのコンテキスト（つまり、LSAがどのエリアまたはリンクに属しているか）を調べます。この情報により、LSAの正しいリストを見つけることができます。すべて同じLSタイプで、LSAのリンク状態IDとアドバタイジングルーターに基づいて検索します。
The process of reoriginating an LSA in IPv6 is the same as in IPv4: the LSA's LS sequence number is incremented, its LS age is set to 0, its LS checksum is calculated, and the LSA is added to the link state database and flooded out the appropriate interfaces.
IPv6でLSAを再生成するプロセスはIPv4の場合と同じです。LSAのLSシーケンス番号がインクリメントされ、LSエージが0に設定され、LSチェックサムが計算され、LSAがリンク状態データベースに追加されてフラッディングされます適切なインターフェース。
To the list of events causing LSAs to be reoriginated, which for IPv4 is given in Section 12.4 of [Ref1], the following events and/or actions are added for IPv6:
LSAが再生成される原因となるイベントのリストには、IPv4の場合は[Ref1]のセクション12.4で示され、IPv6の場合は次のイベントやアクションが追加されます。
o The state 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.
o ルーターのインターフェースの1つの状態が変化します。ルーターは、リンクLSA、1つ以上のルーター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 リンクの指定ルーターのIDが変更されます。ルーターは、リンクのネットワーク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, and the reorigination of one or more intra-area-prefix-LSAs.
o ネイバーのインターフェイスIDが変更されます。これにより、ルーターLSAの新しいインスタンスが関連付けられたエリアに対して発信され、1つ以上のエリア内プレフィックス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を再発信するか、リンクに接続されている唯一のルーターである場合は、ルーターがエリア内プレフィックスLSAを再発信します。
o A new link-LSA is received, causing the link's collection of prefixes to change. If the router is Designated Router for the link, it originates a new intra-area-prefix-LSA.
o 新しいリンクLSAが受信され、リンクのプレフィックスのコレクションが変更されます。ルーターがリンクの指定ルーターである場合、ルーターは新しいintra-area-prefix-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 [Ref1] has been reworked to show IPv6 addressing, resulting in Figure 1. The OSPF cost of each interface is has been 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 5f00:0000: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の例を表示するために、[Ref1]の図15のネットワークマップは、IPv6アドレッシングを表示するように再加工され、図1になります。各インターフェイスのOSPFコストは、図1に表示されています。IPv6プレフィックスの割り当てネットワークリンクを表1に示します。エリア1には単一のエリアアドレス範囲が構成されているため、エリア1の外では、すべてのプレフィックスが5f00：0000：c001 :: / 48への単一のルートでカバーされます。図1のルーターインターフェイスのOSPFインターフェイスIDとリンクローカルアドレスを表2に示します。
..........................................
. Area 1.
. + .
. | .
. | 3+---+1 .
. N1 |--|RT1|-----+ .
. | +---+ \ .
. | \ ______ .
. + \/ \ 1+---+
. * N3 *------|RT4|------
. + /\_______/ +---+
. | / | .
. | 3+---+1 / | .
. N2 |--|RT2|-----+ 1| .
. | +---+ +---+ .
. | |RT3|----------------
. + +---+ .
. |2 .
. | .
. +------------+ .
. N4 .
..........................................
Figure 1: Area 1 with IP addresses shown
図1：IPアドレスが表示されたエリア1
Network IPv6 prefix
-----------------------------------
N1 5f00:0000:c001:0200::/56
N2 5f00:0000:c001:0300::/56
N3 5f00:0000:c001:0100::/56
N4 5f00:0000: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とリンクローカルアドレス
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 to the area. When multiple router-LSAs are used, they are distinguished by their Link State ID fields.
router-LSAのLSタイプは、値0x2001に設定されています。ルーターLSAにはエリアフラッディングスコープがあります。ルーターは、特定のエリアに対して1つ以上のルーターLSAを発信できます。各ルーターLSAには、整数個のインターフェース記述が含まれています。まとめると、エリアのルーターによって発信されたルーターLSAのコレクションは、エリアへのすべてのルーターのインターフェイスの収集された状態を記述します。複数のルーターLSAを使用する場合、それらはリンク状態IDフィールドによって区別されます。
The Options field in the router-LSA should be coded as follows. The V6-bit should be set. The E-bit should be clear if and only if the attached area is an OSPF stub area. The MC-bit should be set if and only if the router is running MOSPF (see [Ref8]). The N-bit should be set if and only if the attached area is an OSPF NSSA area. The R-bit should be set. 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 [Ref11]). All unrecognized bits in the Options field should be cleared
router-LSAのオプションフィールドは、次のようにコーディングする必要があります。 V6ビットを設定する必要があります。接続されたエリアがOSPFスタブエリアである場合に限り、Eビットはクリアされている必要があります。 MCビットは、ルーターがMOSPFを実行している場合にのみ設定する必要があります（[Ref8]を参照）。接続されたエリアがOSPF NSSAエリアである場合にのみ、Nビットを設定する必要があります。 Rビットを設定する必要があります。 DCビットは、LSAのLSエージフィールドに表示されたときにDoNotAgeビットをルーターが正しく処理できる場合にのみ設定する必要があります（[Ref11]を参照）。 [オプション]フィールドのすべての認識されないビットをクリアする必要があります
To the left of the Options field, the router capability bits V, E and B should be coded according to Section 12.4.1 of [Ref1]. Bit W should be coded according to [Ref8].
[オプション]フィールドの左側にあるルーター機能ビットV、E、Bは、[Ref1]のセクション12.4.1に従ってコーディングする必要があります。ビットWは、[Ref8]に従ってコーディングする必要があります。
Each of the router's interfaces to the area are then described by appending "link descriptions" to the router-LSA. Each link description is 16 bytes long, consisting of 5 fields: (link) Type, Metric, Interface ID, Neighbor Interface ID and Neighbor Router ID (see Section A.4.3). Interfaces in 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. All other interfaces to the area add zero, one or more link descriptions, the number and content of which depend on the interface type. Within each link description, the Metric field is always set the interface's output cost and the Interface ID field is set to the interface's OSPF Interface ID.
エリアへのルーターの各インターフェースは、ルーターLSAに「リンクの説明」を追加することで説明されます。各リンクの説明は16バイトの長さで、（リンク）タイプ、メトリック、インターフェースID、隣接インターフェースID、および隣接ルーターIDの5つのフィールドで構成されています（セクションA.4.3を参照）。 「ダウン」または「ループバック」状態のインターフェースは記述されていません（ただし、ループバックされたインターフェースはIntra-Area-Prefix-LSAのプレフィックスに寄与する可能性があります）。完全な隣接関係のないインターフェイスも説明されていません。エリアへの他のすべてのインターフェースはゼロ、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 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リンクの説明（中継ネットワーク）を追加します。 Neighbor Interface IDフィールドは、HelloパケットでDesignated RouterによってアドバタイズされたInterface IDに設定され、Neighbor Router IDフィールドはDesignated Routerのルーター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 3.7).
仮想リンク隣接ルーターが完全に隣接している場合は、タイプ4リンクの説明（仮想）を追加します。ネイバーインターフェイスIDフィールドは、HelloパケットでネイバーによってアドバタイズされたインターフェイスIDに設定され、ネイバールータIDフィールドはネイバーのルータIDに設定されます。仮想リンクの出力コストは、ルーティングテーブルの計算中に計算されることに注意してください（セクション3.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 Neighbor Interface ID field set to the Interface ID advertised by the neighbor in its Hello packets, and Neighbor Router ID field set to the neighbor's Router ID.
ポイントツーマルチポイントインターフェイスインターフェイスに関連付けられた完全に隣接するネイバーごとに、個別のタイプ1リンクの説明（ポイントツーポイント）を追加します。ネイバーインターフェイスIDフィールドを、HelloパケットでネイバーがアドバタイズするインターフェイスIDに設定します。ネイバーのルーター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 Designated Router of Network N3.
例として、ルーターRT3が図1のエリア1に対して発信するルーターLSAを考えます。単一のインターフェース、つまり中継ネットワークN3に接続するインターフェースのみを説明する必要があります。 RT4がネットワークN3の指定ルーターに選出されたと想定しています。
; RT3's router-LSA for Area 1
;エリア1のRT3のルーターLSA
LS age = 0 ;newly (re)originated
LS type = 0x2001 ;router-LSA
Link State ID = 0 ;first fragment
Advertising Router = 192.1.1.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.1.1.4 ; RT4's Router ID
If for example another router was added to Network N4, RT3 would have to advertise a second link description for its connection to (the now transit) network N4. This could be accomplished by reoriginating the above router-LSA, this time with two link descriptions. Or, a separate router-LSA could be originated with a separate Link State ID (e.g., using a Link State ID of 1) to describe the connection to N4.
たとえば、別のルーターがネットワークN4に追加された場合、RT3は（現在は通過している）ネットワークN4への接続のために2番目のリンクの説明を通知する必要があります。これは、上記のルーターLSAを再発信することで実現できますが、今回は2つのリンク記述を使用します。または、別のルーターLSAを別のリンク状態IDで発信して（たとえば、リンク状態IDを1にして）、N4への接続を記述できます。
Host routes no longer appear in the router-LSA, but are instead included in intra-area-prefix-LSAs.
ホストルートはrouter-LSAに表示されなくなりましたが、代わりにintra-area-prefix-LSAに含まれています。
The LS type of a network-LSA is set to the value 0x2002. Network-LSAs have area flooding scope. A network-LSA is originated for every broadcast or NBMA link having two or more attached routers, by the link's Designated Router. The network-LSA lists all routers attached to the link.
ネットワークLSAのLSタイプは、値0x2002に設定されています。ネットワークLSAにはエリアフラッディングスコープがあります。ネットワークLSAは、リンクの指定ルーターによって、2つ以上のルーターが接続されているブロードキャストまたはNBMAリンクごとに作成されます。 network-LSAは、リンクに接続されているすべてのルーターをリストします。
The procedure for originating network-LSAs in IPv6 is the same as the IPv4 procedure documented in Section 12.4.2 of [Ref1], with the following exceptions:
IPv6でネットワークLSAを発信する手順は、[Ref1]のセクション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.
o IPv6ネットワークLSAにはネットワークマスクが含まれていません。以前はIPv4 network-LSAに含まれていたすべてのアドレス指定情報が、intra-Area-Prefix-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. In this way, the network link exhibits a capability when at least one of the link's routers requests that the capability be asserted.
o ネットワークLSAのオプションフィールドは、リンクに関連付けられたリンクLSA内に含まれるオプションフィールドの論理ORに設定されます。このようにして、リンクのルーターの少なくとも1つが機能のアサートを要求すると、ネットワークリンクは機能を発揮します。
As an example, assuming that Router RT4 has been elected 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.1.1.4 ;RT4's Router ID
Options = (V6-bit|E-bit|R-bit)
Attached Router = 192.1.1.4 ;Router ID
Attached Router = 192.1.1.1 ;Router ID
Attached Router = 192.1.1.2 ;Router ID
Attached Router = 192.1.1.3 ;Router ID
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.
inter-area-prefix-LSAのLSタイプは、値0x2003に設定されます。 Inter-area-prefix-LSAにはエリアフラッディングスコープがあります。 IPv4では、inter-area-prefix-LSAはタイプ3サマリーLSAと呼ばれていました。各inter-area-prefix-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 [Ref1], with the following exceptions:
IPv6でinter-area-prefix-LSAを開始する手順は、[Ref1]のセクション12.4.3および12.4.3.1で説明されているIPv4の手順と同じですが、次の例外があります。
o The Link State ID of an inter-area-prefix-LSA has lost all of its addressing semantics, and instead simply serves to distinguish multiple inter-area-prefix-LSAs that are originated by the same router.
o inter-area-prefix-LSAのリンク状態IDは、すべてのアドレッシングセマンティクスを失っており、代わりに、同じルーターから発信された複数のinter-area-prefix-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、およびAddress Prefixフィールドで記述されます。ネットワークマスクは指定されなくなりました。
o The NU-bit in the PrefixOptions field should be clear. The coding of the MC-bit depends upon whether, and if so how, MOSPF is operating in the routing domain (see [Ref8]).
o PrefixOptionsフィールドのNUビットはクリアする必要があります。 MCビットのコーディングは、MOSPFがルーティングドメインで動作しているかどうか、動作している場合はどのように動作しているかによって異なります（[Ref8]を参照）。
o Link-local addresses must never be advertised in inter-area-prefix-LSAs.
o リンクローカルアドレスは、inter-area-prefix-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 5f00:0000:c001::/48. The cost is set to 4, which is the maximum cost to all of the prefix' individual components. The prefix is padded out to an even number of 32-bit words, so that it consumes 64-bits of space instead of 48 bits.
例として、以下は、ルーターRT4がOSPFバックボーンエリアに発信し、エリア1のすべてのプレフィックスを単一のプレフィックス5f00：0000：c001 :: / 48に集約するinter-area-prefix-LSAを示しています。コストは4に設定されます。これは、すべてのプレフィックスの個々のコンポーネントに対する最大コストです。プレフィックスは、32ビットワードの偶数に埋め込まれるため、48ビットではなく64ビットのスペースを消費します。
; Inter-area-prefix-LSA for Area 1 addresses ; originated by Router RT4 into the backbone
;エリア1アドレスのInter-area-prefix-LSA。ルーターRT4からバックボーンに発信
LS age = 0 ;newly (re)originated
LS type = 0x2003 ;inter-area-prefix-LSA
Advertising Router = 192.1.1.4 ;RT4's ID
Metric = 4 ;maximum to components
PrefixLength = 48
PrefixOptions = 0
Address Prefix = 5f00:0000:c001 ;padded to 64-bits
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 (an ASBR) that is external to the area, yet internal to the Autonomous System.
inter-area-router-LSAのLSタイプは、値0x2004に設定されています。エリアルーター間LSAにはエリアフラッディングスコープがあります。 IPv4では、エリア間ルーターLSAはタイプ4サマリーLSAと呼ばれていました。各エリアルーターLSAは、エリアの外部にあり、自律システムの内部にある宛先OSPFルーター（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 [Ref1], with the following exceptions:
IPv6でinter-area-router-LSAを開始する手順は、[Ref1]のセクション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, but instead 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 inter-area-router-LSAのOptionsフィールドは、宛先ルーター自身のrouter-LSAに含まれるOptionsフィールドと同じに設定する必要があります。したがって、「オプション」フィールドは、宛先ルーターがサポートする機能を記述します。
As an example, consider the OSPF Autonomous System depicted in Figure 6 of [Ref1]. Router RT4 would originate into Area 1 the following inter-area-router-LSA for destination router RT7.
例として、[Ref1]の図6に示されているOSPF自律システムを考えます。ルーターRT4は、宛先ルーターRT7の次のエリア間ルーターLSAをエリア1に発信します。
; inter-area-router-LSA for AS boundary router RT7 ; originated by Router RT4 into Area 1
; AS境界ルーターRT7のエリア間ルーターLSA。ルーターRT4からエリア1に発信
LS age = 0 ;newly (re)originated
LS type = 0x2004 ;inter-area-router-LSA
Advertising Router = 192.1.1.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
The LS type of an AS-external-LSA is set to the value 0x4005. AS-external-LSAs have AS flooding scope. Each AS-external-LSA describes a path to a prefix external to the Autonomous System.
AS-external-LSAのLSタイプは、値0x4005に設定されています。 AS外部LSAにはASフラッディングスコープがあります。各AS-external-LSAは、自律システムの外部のプレフィックスへのパスを記述します。
The procedure for originating AS-external-LSAs in IPv6 is the same as the IPv4 procedure documented in Section 12.4.4 of [Ref1], with the following exceptions: o The Link State ID of an AS-external-LSA has lost all of its addressing semantics, and instead simply serves to distinguish multiple AS-external-LSAs that are originated by the same router.
IPv6でAS-external-LSAを発信する手順は、[Ref1]のセクション12.4.4で説明されているIPv4の手順と同じですが、次の例外があります。o AS-external-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、およびAddress Prefixフィールドで記述されます。ネットワークマスクは指定されなくなりました。
o The NU-bit in the PrefixOptions field should be clear. The coding of the MC-bit depends upon whether, and if so how, MOSPF is operating in the routing domain (see [Ref8]).
o PrefixOptionsフィールドのNUビットはクリアする必要があります。 MCビットのコーディングは、MOSPFがルーティングドメインで動作しているかどうか、動作している場合はどのように動作しているかによって異なります（[Ref8]を参照）。
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.
o AS-external-LSAのビットFが設定されている場合に限り、転送アドレスはAS-external-LSAに存在します。
o The external route tag is present in the AS-external-LSA if and only if the AS-external-LSA's bit T is set.
o AS-external-LSAのビットTが設定されている場合にのみ、外部ルートタグがAS-external-LSAに存在します。
o The capability for an AS-external-LSA to reference another LSA has been included, by inclusion of the Referenced LS Type field and the optional Referenced Link State ID field (the latter present if and only if Referenced LS Type is non-zero). This capability is for future use; for now Referenced LS Type should be set to 0 and received non-zero values for this field should be ignored.
o AS-external-LSAが別のLSAを参照する機能は、Referenced LS TypeフィールドとオプションのReferenced Link State IDフィールド（Referenced LS Typeがゼロでない場合にのみ存在する）を含めることで含まれています。この機能は将来使用するためのものです。現時点では、参照されるLSタイプを0に設定し、このフィールドで受け取ったゼロ以外の値は無視する必要があります。
As an example, consider the OSPF Autonomous System depicted in Figure 6 of [Ref1]. Assume that RT7 has learned its route to N12 via BGP, and that it wishes to advertise a Type 2 metric into the AS. Further assume the the IPv6 prefix for N12 is the value 5f00:0000: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, to maintain 32-bit alignment.
例として、[Ref1]の図6に示されているOSPF自律システムを考えます。 RT7がBGPを介してN12へのルートを学習し、タイプ2メトリックをASにアドバタイズしたいとします。さらに、N12のIPv6プレフィックスが値5f00：0000：0a00 :: / 40であると仮定します。 RT7は、外部ネットワークN12に対して次のAS-external-LSAを発信します。 AS-external-LSA内では、N12のプレフィックスは64ビットのスペースを占め、32ビットのアライメントを維持します。
; AS-external-LSA for Network N12, ; originated by Router RT7
; AS-external-LSA for Network N12、ルーターRT7から発信
LS age = 0 ;newly (re)originated
LS type = 0x4005 ;AS-external-LSA
Link State ID = 123 ;or something else
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 = 5f00:0000:0a00 ;padded to 64-bits
External Route Tag = as per BGP/OSPF interaction
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 2 or more (including the originating router itself) routers.
Link-LSAのLSタイプは、値0x0008に設定されています。リンクLSAにはリンクローカルフラッディングスコープがあります。ルーターは、2つ以上のルーター（元のルーター自体を含む）をサポートする接続されたリンクごとに個別のLink-LSAを作成します。
Link-LSAs have three purposes: 1) they provide the router's link-local address to all other routers attached to the link and 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 assert a collection of Options bits in the Network-LSA that will be originated for the link.
リンクLSAには3つの目的があります。1）リンクに接続されている他のすべてのルーターにルーターのリンクローカルアドレスを提供し、2）リンクに接続されている他のルーターに、リンクに関連付けるIPv6プレフィックスのリストを通知し、3）これにより、ルーターは、リンクに対して発信されるネットワークLSAのオプションビットのコレクションをアサートできます。
A Link-LSA for a given Link L is built in the following fashion:
特定のリンクLのリンクLSAは、次の方法で構築されます。
o The Link State ID is set to the router's Interface ID on Link L.
o リンク状態IDは、リンクLのルーターのインターフェースIDに設定されます。
o The Router Priority of the router's interface to Link L is inserted into the Link-LSA.
o リンクLへのルーターのインターフェースのルーター優先度がリンクLSAに挿入されます。
o The Link-LSA's Options field is set to those bits that the router wishes set in Link L's Network LSA.
o リンクLSAのオプションフィールドは、ルーターがリンクLのネットワーク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 3.8.1.1).
o ルータは、リンクLのリンクローカルアドレスをリンクLSAに挿入します。この情報は、リンクLの他のルーターがネクストホップの計算を行うときに使用されます（セクション3.8.1.1を参照）。
o Each IPv6 address prefix that has been configured into the router for Link L is added to the Link-LSA, by specifying values for PrefixLength, PrefixOptions, and Address Prefix fields.
o リンクLのルーターに構成されている各IPv6アドレスプレフィックスは、PrefixLength、PrefixOptions、およびAddress Prefixフィールドの値を指定することにより、Link-LSAに追加されます。
After building a Link-LSA for a given link, the router installs the link-LSA into the associate interface data structure and floods the Link-LSA onto the link. All other routers on the link will receive the Link-LSA, but it will go no further.
特定のリンクのリンクLSAを構築した後、ルーターはリンクLSAを関連するインターフェイスデータ構造にインストールし、リンクLSAをリンクにフラッディングします。リンク上の他のすべてのルーターはLink-LSAを受け取りますが、それ以上は進みません。
As an example, consider the Link-LSA that RT3 will build for N3 in Figure 1. Suppose that the prefix 5f00:0000:c001:0100::/56 has been configured within RT3 for N3. This will give rise to the following Link-LSA, which RT3 will flood onto N3, but nowhere else. 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.
例として、RT1が図1のN3用に構築するLink-LSAを考えます。接頭辞5f00：0000：c001：0100 :: / 56がN3のRT3内に構成されていると仮定します。これにより、RT3がN3にフラッディングする次のLink-LSAが生成されますが、それ以外の場所にはありません。 N3のすべてのルーターにプレフィックスを設定する必要があるわけではないことに注意してください。構成されていないものは、RT3のLink-LSAを受信するときにプレフィックスを学習します。
; RT3's Link-LSA for N3
; N3用のRT3のLink-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.1.1.3 ;RT3's Router ID
Rtr Pri = 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 = 5f00:0000:c001:0100 ;pad to 64-bits
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 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.
intra-area-prefix-LSAのLSタイプは、値0x2009に設定されています。エリア内プレフィックスLSAにはエリアフラッディングスコープがあります。エリア内プレフィックスLSAには、2つの機能のうちの1つがあります。ネットワークLSAを参照してIPv6アドレスプレフィックスのリストをトランジットネットワークリンクに関連付けるか、ルーターLSAを参照してIPv6アドレスプレフィックスのリストをルーターに関連付けます。スタブリンクのプレフィックスは、接続されているルーターに関連付けられています。
A router may originate multiple intra-area-prefix-LSAs for a given area, distinguished by their Link State ID fields. Each intra-area-prefix-LSA contains an integral number of prefix descriptions.
ルーターは、リンク状態IDフィールドで区別される、特定のエリアの複数のエリア内プレフィックスLSAを発信する場合があります。各intra-area-prefix-LSAには、整数個の接頭辞の説明が含まれています。
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の指定ルーターは、次の方法でエリア内プレフィックス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
o プレフィックスがリンクLに関連付けられることを示すために、フィールドReferenced LS type、Referenced Link State ID、および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 Referenced LS Type is set to 0x2002, Referenced Link State ID is set to the Designated Router's Interface ID on Link L, and Referenced Advertising Router is set to the Designated Router's Router 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 Router, 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 Prefix Options fields should be merged by logically OR'ing the fields together, and a single resulting prefix should be copied into the intra-area-prefix-LSA. The Metric field for all prefixes is set to 0.
o リンクLに関連付けられた各リンクLSAが検査されます（これらはリンクLの指定ルーターのインターフェース構造にあります）。 Link-LSAのアドバタイジングルーターが指定ルーターに完全に隣接している場合、Link-LSA内のプレフィックスのリストは、構築されているintra-area-prefix-LSAにコピーされます。 [オプション]フィールドにNUビットやLAビットが設定されているプレフィックスはコピーしないでください。また、リンクローカルアドレスもコピーしないでください。各プレフィックスは、PrefixLength、PrefixOptions、およびAddress Prefixフィールドで記述されます。同じPrefixLengthおよびアドレスプレフィックスを持つ複数のプレフィックスは重複と見なされます。この場合、それらのプレフィックスオプションフィールドは、フィールドを論理ORすることによってマージする必要があり、単一の結果のプレフィックスをintra-area-prefix-LSAにコピーする必要があります。すべてのプレフィックスの[メトリック]フィールドは0に設定されています。
o The "# prefixes" field is set to the number of prefixes that the router has copied into the LSA. If necessary, the list of prefixes can be spread across multiple intra-area-prefix-LSAs in order to keep the LSA size small.
o 「＃prefixes」フィールドは、ルーターがLSAにコピーしたプレフィックスの数に設定されます。必要に応じて、LSAサイズを小さく保つために、プレフィックスのリストを複数のintra-area-prefix-LSAに分散させることができます。
A router builds an intra-area-prefix-LSA to advertise its own prefixes, and those of its attached stub links. A Router RTX would build its intra-area-prefix-LSA in the following fashion:
ルータは、intra-area-prefix-LSAを作成して、自身のプレフィックスと、接続されているスタブリンクのプレフィックスをアドバタイズします。ルータRTXは、次の方法でそのintra-area-prefix-LSAを構築します。
o In order to indicate that the prefixes are to be associated with the Router RTX itself, RTX sets Referenced LS type to 0x2001, Referenced Link State ID to 0, and Referenced Advertising Router to RTX's own Router ID.
o プレフィックスがルーターRTX自体に関連付けられることを示すために、RTXは参照LSタイプを0x2001に、参照リンク状態IDを0に、参照広告ルーターをRTX自身のルーターIDに設定します。
o Router RTX examines its list of interfaces to the area. If the interface is in 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), its prefixes are not included (they will be included in the intra-area-prefix-LSA for the link instead). If the interface type is Point-to-MultiPoint, or the interface is in state Loopback, or the interface connects to a point-to-point link which has not been assigned a prefix, then the site-local and global scope IPv6 addresses associated with the interface (if any) are copied into the intra-area-prefix-LSA, setting the LA-bit in the PrefixOptions field, and setting the PrefixLength to 128 and the Metric to 0. Otherwise, the list of site-local and 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で報告されている場合、そのプレフィックスは含まれていません（リンクのintra-area-prefix-LSAに含まれています）。インターフェイスタイプがポイントツーマルチポイントであるか、インターフェイスがループバック状態であるか、またはインターフェイスがプレフィックスが割り当てられていないポイントツーポイントリンクに接続している場合、サイトローカルおよびグローバルスコープのIPv6アドレスが関連付けられますインターフェース（存在する場合）がintra-area-prefix-LSAにコピーされ、PrefixOptionsフィールドでLAビットが設定され、PrefixLengthが128に、Metricが0に設定されます。それ以外の場合、サイトローカルおよびRTXでリンク用に構成されたグローバルプレフィックスは、PrefixLength、PrefixOptions、およびAddress Prefixフィールドを指定することにより、intra-area-prefix-LSAにコピーされます。これらの各プレフィックスのメトリックフィールドは、インターフェイスの出力コストに設定されます。
o RTX adds the IPv6 prefixes for any directly attached hosts belonging to the area (see Section C.7) to the intra-area-prefix-LSA.
o RTXは、エリアに属する直接接続されたホストのIPv6プレフィックス（セクションC.7を参照）をintra-area-prefix-LSAに追加します。
o If RTX has one or more virtual links configured through the area, it includes one of its site-local or global scope IPv6 interface addresses in the LSA (if it hasn't already), setting the LA-bit in the PrefixOptions field, and setting the PrefixLength to 128 and the Metric to 0. This information will be used later in the routing calculation so that the two ends of the virtual link can discover each other's IPv6 addresses.
o RTXに、エリアを介して構成された1つ以上の仮想リンクがある場合、サイトローカルまたはグローバルスコープのIPv6インターフェースアドレスの1つがLSAに含まれ（まだ設定されていない場合）、PrefixOptionsフィールドでLAビットを設定します。 PrefixLengthを128に、Metricを0に設定します。この情報は後でルーティング計算で使用され、仮想リンクの両端が互いのIPv6アドレスを検出できるようになります。
o The "# prefixes" field is set to the number of prefixes that the router has copied into the LSA. If necessary, the list of prefixes can be spread across multiple intra-area-prefix-LSAs in order to keep the LSA size small.
o 「＃prefixes」フィールドは、ルーターがLSAにコピーしたプレフィックスの数に設定されます。必要に応じて、LSAサイズを小さく保つために、プレフィックスのリストを複数のintra-area-prefix-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.
たとえば、RT4によってネットワークN3に発信されたintra-area-prefix-LSA（RT4がN3の指定ルーターであると想定）、および独自のプレフィックスに対してルーターRT3によりエリア1に発信されたintra-area-prefix-LSAが描かれています。未満。
; Intra-area-prefix-LSA ; for network link N3
; Intra-area-prefix-LSA;ネットワークリンクN3用
LS age = 0 ;newly (re)originated
LS type = 0x2009 ;Intra-area-prefix-LSA
Link State ID = 5 ;or something
Advertising Router = 192.1.1.4 ;RT4's Router ID
# prefixes = 1
Referenced LS type = 0x2002 ;network-LSA reference
Referenced Link State ID = 1
Referenced Advertising Router = 192.1.1.4
PrefixLength = 56 ;N3's prefix
PrefixOptions = 0
Metric = 0
Address Prefix = 5f00:0000:c001:0100 ;pad
; RT3's Intra-area-prefix-LSA ; for its own prefixes
; RT3のIntra-area-prefix-LSA;独自の接頭辞
LS age = 0 ;newly (re)originated
LS type = 0x2009 ;Intra-area-prefix-LSA
Link State ID = 177 ;or something
Advertising Router = 192.1.1.3 ;RT3's Router ID
# prefixes = 1
Referenced LS type = 0x2001 ;router-LSA reference
Referenced Link State ID = 0
Referenced Advertising Router = 192.1.1.3
PrefixLength = 56 ;N4's prefix PrefixOptions = 0
Metric = 2 ;N4 interface cost
Address Prefix = 5f00:0000:c001:0400 ;pad
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 Designated Router for a link but the link has no other attached routers, the link's prefixes are advertised in an intra-area-prefix-LSA referring to the Designated Router's router-LSA. When additional routers appear on the link, a network-LSA is originated for the link and the link's prefixes are moved to an intra-area-prefix-LSA referring to the network-LSA.
ネットワークの状態が変化すると、ルーターがプレフィックスを1つのエリア内プレフィックスLSAから別のエリア内プレフィックスLSAに移動することが必要になる場合があります。たとえば、ルーターがリンクの指定ルーターであるが、リンクに他のルーターが接続されていない場合、リンクのプレフィックスは、指定ルーターのルーターLSAを参照するintra-area-prefix-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 that 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 that event, the Designated Router may not be running the other protocol suite, and so another of the link's routers may need to send out the prefix-LSA. In that case, "Referenced Advertising Router" and "Advertising Router" would be different.
intra-area-prefix-LSAでは、「参照先アドバタイジングルーター」は常に、intra-area-prefix-LSAを発信しているルーター（LSAのアドバタイジングルーター）と等しいことに注意してください。 Referenced Advertising Routerフィールドが表示される理由は、現在は冗長であるにもかかわらず、将来的にはなくなる可能性があるためです。同じLSA形式を使用して、他のプロトコルスイートのアドレスプレフィックスをアドバタイズしたい場合があります。その場合、指定ルーターは他のプロトコルスイートを実行していない可能性があるため、リンクの別のルーターがプレフィックスLSAを送信する必要がある場合があります。その場合、「参照広告ルーター」と「広告ルーター」は異なります。
Most of the flooding algorithm remains unchanged from the IPv4 flooding mechanisms described in Section 13 of [Ref1]. In particular, the processes for determining which LSA instance is newer (Section 13.1 of [Ref1]), responding to updates of self-originated LSAs (Section 13.4 of [Ref1]), sending Link State Acknowledgment packets (Section 13.5 of [Ref1]), retransmitting LSAs (Section 13.6 of [Ref1]) and receiving Link State Acknowledgment packets (Section 13.7 of [Ref1]) are exactly the same for IPv6 and IPv4.
フラッディングアルゴリズムのほとんどは、[Ref1]のセクション13で説明されているIPv4フラッディングメカニズムから変更されていません。特に、どのLSAインスタンスが新しいかを判断するプロセス（[Ref1]のセクション13.1）、自己発信LSAの更新への応答（[Ref1]のセクション13.4）、リンク状態確認パケットの送信（[Ref1]のセクション13.5） ）、LSAの再送信（[Ref1]のセクション13.6）とリンク状態確認パケットの受信（[Ref1]のセクション13.7）は、IPv6とIPv4でまったく同じです。
However, the addition of flooding scope and handling options for unrecognized LSA types (see Section A.4.2.1) has caused some changes in the OSPF flooding algorithm: the reception of Link State Updates (Section 13 in [Ref1]) and the sending of Link State Updates (Section 13.3 of [Ref1]) must take into account the LSA's scope and U-bit setting. Also, installation of LSAs into the OSPF database (Section 13.2 of [Ref1]) causes different events in IPv6, due to the reorganization of LSA types and contents in IPv6. These changes are described in detail below.
ただし、認識されないLSAタイプ（セクションA.4.2.1を参照）のフラッディングスコープと処理オプションの追加により、OSPFフラッディングアルゴリズムにいくつかの変更が生じました。リンク状態更新の受信（[Ref1]のセクション13）と送信リンク状態の更新（[Ref1]のセクション13.3）では、LSAのスコープとUビット設定を考慮する必要があります。また、LSAをOSPFデータベースにインストールすると（[Ref1]のセクション13.2）、IPv6でLSAタイプとコンテンツが再編成されるため、IPv6で異なるイベントが発生します。これらの変更については、以下で詳しく説明します。
The encoding of flooding scope in the LS type and the need to process unknown LS types causes modifications to the processing of received Link State Update packets. As in IPv4, each LSA in a received Link State Update packet is examined. In IPv4, eight steps are executed for each LSA, as described in Section 13 of [Ref1]. For IPv6, all the steps are the same, except that Steps 2 and 3 are modified as follows:
LSタイプのフラッディングスコープのエンコードと不明なLSタイプを処理する必要性により、受信したリンク状態更新パケットの処理が変更されます。 IPv4と同様に、受信したリンク状態更新パケットの各LSAが検査されます。 IPv4では、[Ref1]のセクション13で説明されているように、LSAごとに8つのステップが実行されます。 IPv6の場合、ステップ2と3が次のように変更されていることを除いて、すべてのステップは同じです。
(2) Examine the LSA's LS type. If the LS type is unknown, the area has been configured as a stub area, and either the LSA's flooding scope is set to "AS flooding scope" or the U-bit of the LS type is set to 1 (flood even when unrecognized), then discard the LSA and get the next one from the Link State Update Packet. This generalizes the IPv4 behavior where AS-external-LSAs are not flooded into/throughout stub areas.
（2）LSAのLSタイプを調べます。 LSタイプが不明の場合、エリアはスタブエリアとして設定されており、LSAのフラッディングスコープが「ASフラッディングスコープ」に設定されているか、LSタイプのUビットが1に設定されています（認識されない場合でもフラッディング）次に、LSAを破棄し、リンク状態更新パケットから次のLSAを取得します。これにより、AS外部LSAがスタブエリアにフラッディング/スルーされないIPv4動作が一般化されます。
(3) Else if the flooding scope of the LSA is set to "reserved", discard the LSA and get the next one from the Link State Update Packet.
（3）LSAのフラッディングスコープが「予約済み」に設定されている場合は、LSAを破棄し、リンク状態更新パケットから次のLSAを取得します。
Steps 5b (sending Link State Update packets) and 5d (installing LSAs in the link state database) in Section 13 of [Ref1] are also somewhat different for IPv6, as described in Sections 3.5.2 and 3.5.3 below.
[Ref1]のセクション13のステップ5b（リンク状態更新パケットの送信）と5d（リンク状態データベースへのLSAのインストール）も、以下のセクション3.5.2および3.5.3で説明されているように、IPv6では多少異なります。
The sending of Link State Update packets is described in Section 13.3 of [Ref1]. 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 [Ref1]). However, the list of eligible interfaces out which to flood the LSA is different. For IPv6, the eligible interfaces are selected based on the following factors:
リンク状態更新パケットの送信については、[Ref1]のセクション13.3で説明されています。 IPv4とIPv6の場合、リンク状態更新パケットを送信する手順は同じです（[Ref1]のセクション13.3の手順1〜5）。ただし、LSAをフラッディングする適格なインターフェースのリストは異なります。 IPv6の場合、適格なインターフェースは以下の要因に基づいて選択されます。
o The LSA's flooding scope.
o LSAのフラッディングスコープ。
o For LSAs with area or link-local flooding scoping, the particular area or interface that the LSA is associated with.
o エリアまたはリンクローカルフラッディングスコープを持つLSAの場合、LSAが関連付けられている特定のエリアまたはインターフェイス。
o Whether the LSA has a recognized LS type.
o LSAに認識されたLSタイプがあるかどうか。
o The setting of the U-bit in the LS type. If the U-bit is set to 0, unrecognized LS types are treated as having link-local scope. If set to 1, unrecognized LS types are stored and flooded as if they were recognized.
o LSタイプのUビットの設定。 Uビットが0に設定されている場合、認識されないLSタイプはリンクローカルスコープを持つものとして扱われます。 1に設定すると、認識されないLSタイプが格納され、認識されたかのようにフラッディングされます。
Choosing the set of eligible interfaces then breaks into the following cases:
適格なインターフェースのセットを選択すると、次のケースに分類されます。
Case 1 The LSA's LS type is recognized. In this case, the set of eligible interfaces is set depending on the flooding scope encoded in the LS type. If the flooding scope is "AS flooding scope", the eligible interfaces are all router interfaces excepting virtual links. In addition, AS-external-LSAs are not flooded out interfaces connecting to stub areas. If the flooding scope is "area flooding scope", the set of 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, when the LSA is received in a Link State Update packet, is also the interface the LSA was received on).
ケース1 LSAのLSタイプが認識されます。この場合、適格なインターフェースのセットは、LSタイプでエンコードされたフラッディングスコープに応じて設定されます。フラッディングスコープが「ASフラッディングスコープ」の場合、適格なインターフェースは、仮想リンクを除くすべてのルーターインターフェースです。さらに、AS外部LSAは、スタブエリアに接続するインターフェースでフラッディングされません。フラッディングスコープが「エリアフラッディングスコープ」の場合、適格なインターフェースのセットは、LSAの関連エリアに接続するインターフェースです。フラッディングスコープが「リンクローカルフラッディングスコープ」の場合、適格なインターフェイスが1つあり、LSAの関連リンクに接続されているインターフェイス（LSAがリンク状態更新パケットで受信されると、LSAのインターフェイスでもあります）受け取った）。
Case 2 The LS type is unrecognized, and the U-bit in the LS Type is set to 0 (treat the LSA as if it had link-local flooding scope). In this case there is a single eligible interface, namely, the interface on which the LSA was received.
ケース2 LSタイプが認識されず、LSタイプのUビットが0に設定されている（LSAにリンクローカルフラッディングスコープがあるかのように扱う）。この場合、単一の適格なインターフェース、つまり、LSAが受信されたインターフェースがあります。
Case 3 The LS type is unrecognized, and the U-bit in the LS Type is set to 1 (store and flood the LSA, as if type understood). In this case, select the eligible interfaces based on the encoded flooding scope as in Case 1 above. However, in this case interfaces attached to stub areas are always excluded.
ケース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 [Ref1]). 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 memo, namely router-LSAs (LS type 0x2001), network-LSAs (0x2002), Inter-Area-Prefix-LSAs (0x2003), Inter-Area-Router-LSAs (0x2004), AS-External-LSAs (0x4005), Link-LSAs (0x0008) and Intra-Area-Prefix-LSAs (0x2009) are assumed to be understood by all routers. However, as an example the group-membership-LSA (0x2006) is understood only by MOSPF routers and since it has its U-bit set to 0, it should only be forwarded to a non-MOSPF neighbor (determined by examining the MC-bit in the neighbor's Database Description packets' Options field) when the neighbor is Designated Router or Backup Designated Router for the attached link.
LSAを特定のネイバーのリンクステート再送信リストに追加する前に、さらに決定が必要になる場合があります（[Ref1]のセクション13.3のステップ1d）。 LSタイプがルーターによって認識され、ネイバーでは認識されない場合（ネイバーがデータベース記述パケットでアドバタイズしたオプションフィールドを調べることで判断できる）、LSAのUビットが0に設定されている場合、LSAはネイバーが接続リンクの指定ルーターまたはバックアップ指定ルーターである場合にのみ、ネイバーのリンク状態再送信リストに追加されます。このメモで詳細に説明されているLSタイプ、つまりルーターLSA（LSタイプ0x2001）、ネットワークLSA（0x2002）、インターエリアプレフィックスLSA（0x2003）、インターエリアルーターLSA（0x2004）、AS -External-LSA（0x4005）、Link-LSA（0x0008）、およびIntra-Area-Prefix-LSA（0x2009）は、すべてのルーターによって理解されると想定されています。ただし、例として、group-membership-LSA（0x2006）はMOSPFルーターによってのみ理解され、Uビットが0に設定されているため、非MOSPFネイバーにのみ転送される必要があります（MC-接続されたリンクのネイバーが指定ルーターまたはバックアップ指定ルーターである場合、ネイバーのデータベース記述パケットのオプションフィールドのビット）。
The previous paragraph solves a problem in IPv4 OSPF extensions such as MOSPF, which require that the Designated Router support the extension in order to have the new LSA types flooded across broadcast and NBMA networks (see Section 10.2 of [Ref8]).
前の段落は、MOSPFなどのIPv4 OSPF拡張機能の問題を解決します。ブロードキャストとNBMAネットワーク全体に新しいLSAタイプをフラッディングするには、指定ルーターが拡張機能をサポートする必要があります（[Ref8]のセクション10.2を参照）。
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 3.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 3.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 structure.
フラッディングスコープに応じて、LSAを格納する場所は3つあります。 ASフラッディングスコープを持つLSAは、LSタイプが既知であるか、Uビットが1である限り、グローバルOSPFデータ構造に格納されます（セクション3.1を参照）。エリアフラッディングスコープを持つLSAは、適切なエリアデータ構造に格納されます（セクションを参照） 3.1.1）LSタイプが既知であるか、Uビットが1である限り、リンクローカルフラッディングスコープのLSA、およびLSタイプが不明でUビットが0に設定された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 [Ref1]. 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の内容が変更されたかどうかを確認する必要があります。内容の変更は、[Ref1]のセクション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 3.8).
ルーターLSA、ネットワークLSA、エリア内プレフィックスLSA、リンクLSAルーティングテーブル全体が再計算され、各エリアの最短パス計算から始めます（セクション3.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 [Ref1]). If this destination is an AS boundary router, it may also be necessary to re-examine all the AS-external-LSAs.
Inter-Area-Prefix-LSAおよびInter-Area-Router-LSA LSAによって記述された宛先への最適なルートを再計算する必要があります（[Ref1]のセクション16.5を参照）。この宛先がAS境界ルーターである場合は、すべてのAS外部LSAを再調査する必要がある場合もあります。
AS-external-LSAs The best route to the destination described by the AS-external-LSA must be recalculated (see Section 16.6 in [Ref1]).
AS-external-LSA AS-external-LSAによって記述された宛先への最適なルートを再計算する必要があります（[Ref1]のセクション16.6を参照）。
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 [Ref1]. For IPv6, self-originated LSAs are those LSAs whose Advertising Router is equal to the router's own Router ID.
IPv6では、自己生成LSAの定義は、[Ref1]のセクション13.4および14.1にあるIPv4定義から簡略化されています。 IPv6の場合、自己発信LSAは、アドバタイジングルーターがルーター自身のルーターIDと等しいLSAです。
OSPF virtual links for IPv4 are described in Section 15 of [Ref1]. Virtual links are the same in IPv6, with the following exceptions:
IPv4のOSPF仮想リンクは、[Ref1]のセクション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 ASフラッディングスコープを持つLSAが仮想隣接にフラッディングされることはなく、ASフラッディングスコープを持つLSAがデータベース交換プロセス中に仮想隣接に要約されることもありません。これは、AS外部LSAのIPv4処理の一般化です。
o The IPv6 interface address of a virtual link must be an IPv6 address having site-local or 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.
o 仮想リンクのIPv6インターフェイスアドレスは、他のインターフェイスタイプで使用されるリンクローカルアドレスではなく、サイトローカルまたはグローバルスコープを持つIPv6アドレスである必要があります。このアドレスは、仮想リンクを介して送信されるOSPFプロトコルパケットのIPv6ソースとして使用されます。
o Likewise, the virtual neighbor's IPv6 address is an IPv6 address with site-local or 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 Sections 3.4.3.7 and 3.8.1).
o 同様に、仮想ネイバーのIPv6アドレスは、サイトローカルまたはグローバルスコープのIPv6アドレスです。ルーティング計算中に仮想ネイバーのIPv6アドレスの検出を有効にするために、ネイバーは、仮想リンクのトランジットエリア用に作成されたIntra-Area-Prefix-LSAで仮想リンクのIPv6インターフェイスアドレスをアドバタイズします（セクション3.4.3.7および3.8.1を参照）。 ）。
o Like all other IPv6 OSPF interfaces, virtual links are assigned unique (within the router) Interface IDs. These are advertised in Hellos sent over the virtual link, and in the router's router-LSAs.
o 他のすべてのIPv6 OSPFインターフェースと同様に、仮想リンクには（ルーター内で）固有のインターフェースIDが割り当てられます。これらは、仮想リンクを介して送信されるHello、およびルーターのルーター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 [Ref1]. High level differences between the IPv6 and IPv4 calculations include:
IPv6 OSPFルーティングの計算は、[Ref1]のセクション16で指定された5つのステップに従って、IPv4 OSPFルーティングの計算と同じように行われます。 IPv6とIPv4の計算の高レベルの違いは次のとおりです。
o Prefix information has been removed from router-LSAs, and now is advertised in intra-area-prefix-LSAs. Whenever [Ref1] specifies that stub networks within router-LSAs be examined, IPv6 will instead examine prefixes within intra-area-prefix-LSAs.
o プレフィックス情報がルーターLSAから削除され、intra-area-prefix-LSAでアドバタイズされるようになりました。 [Ref1]がルーターLSA内のスタブネットワークを検査するように指定している場合、IPv6は代わりに、intra-area-prefix-LSA内のプレフィックスを検査します。
o Type 3 and 4 summary-LSAs have been renamed inter-area-prefix-LSAs and inter-area-router-LSAs (respectively).
o タイプ3および4のサマリーLSAは、inter-area-prefix-LSAおよびinter-area-router-LSAにそれぞれ名前が変更されました。
o Addressing information is no longer encoded in Link State IDs, and must instead be found within the body of LSAs.
o アドレッシング情報はリンクステートIDでエンコードされなくなり、代わりにLSAの本体内で見つける必要があります。
o In IPv6, a router can originate multiple router-LSAs within a single area, distinguished by Link State ID. These router-LSAs must be treated as a single aggregate by the area's shortest path calculation (see Section 3.8.1).
o IPv6では、ルーターは1つのエリア内で複数のルーターLSAを発信でき、リンク状態IDで区別されます。これらのルーターLSAは、エリアの最短経路計算によって単一の集合体として扱われる必要があります（セクション3.8.1を参照）。
For each area, routing table entries have been created for the area's routers and transit links, in order to store the results of the area's shortest-path tree calculation (see Section 3.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 3.8.2.
エリアごとに、エリアの最短パスツリー計算の結果を保存するために、エリアのルーターとトランジットリンクのルーティングテーブルエントリが作成されています（セクション3.8.1を参照）。これらのエントリは、セクション3.8.2で説明されているように、intra-area-prefix-LSA、inter-area-prefix-LSA、inter-area-router-LSAを処理するときに使用されます。
Events generated as a result of routing table changes (Section 16.7 of [Ref1]), and the equal-cost multipath logic (Section 16.8 of [Ref1]) are identical for both IPv4 and IPv6.
ルーティングテーブルの変更の結果として生成されたイベント（[Ref1]のセクション16.7）および等コストマルチパスロジック（[Ref1]のセクション16.8）は、IPv4とIPv6の両方で同一です。
The IPv4 shortest path calculation is contained in Section 16.1 of [Ref1]. 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 3.3).
IPv4最短パス計算は、[Ref1]のセクション16.1に含まれています。最短経路ツリー計算で使用されるグラフは、IPv4とIPv6の両方で同一です。グラフの頂点はルーターと中継リンクであり、それぞれルーターLSAとネットワークLSAで表されます。ルーターはOSPFルーターIDで識別されますが、中継リンクは指定ルーターのインターフェイスIDとOSPFルーターIDで識別されます。ルーターと中継リンクの両方に、エリア内に関連するルーティングテーブルエントリがあります（セクション3.3を参照）。
Section 16.1 of [Ref1] 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.
[Ref1]のセクション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 [Ref1]):
IPv6のダイクストラ計算は、IPv4に指定されたものと同じですが、次の例外があります（[Ref1]のセクション16.1で説明されているダイクストラ計算の手順を参照）。
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 Advertising Router set to V's OSPF Router ID must processed as an aggregate, treating them as fragments of a single large router-LSA. The Options field and the router type bits (bits W, V, E and B) should always be taken from "fragment" with the smallest Link State ID.
o ステップ2で、ルーターVertex Vが最短パスツリーに追加された直後に、ルーターに関連付けられた複数のLSAが存在する場合があります。アドバタイジングルーターがVのOSPFルーターIDに設定されているすべてのルーターLSAは、1つの大きなルーターLSAのフラグメントとして扱い、集約として処理する必要があります。オプションフィールドとルータータイプビット（ビットW、V、E、B）は、常に最小のリンク状態IDを持つ「フラグメント」から取得する必要があります。
o Step 2a is not needed in IPv6, as there are no longer stub network links in router-LSAs.
o ルータLSAにはスタブネットワークリンクが存在しないため、IPv6ではステップ2aは必要ありません。
o In Step 2b, if W is a router, there may again be multiple LSAs associated with the router. All Router-LSAs with Advertising Router set to W's OSPF Router ID must processed as an aggregate, treating them as fragments of a single large router-LSA.
o ステップ2bで、Wがルーターの場合、ルーターに関連付けられた複数のLSAが再び存在する可能性があります。アドバタイジングルーターがWのOSPFルーターIDに設定されたすべてのルーターLSAは、1つの大きなルーターLSAのフラグメントとして扱い、集約として処理する必要があります。
o In Step 4, there are now per-area routing table entries for each of an area's routers, instead of 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 having the "LA-bit" set.
o ステップ4では、エリア境界ルーターだけでなく、エリアのルーターごとに、エリアごとのルーティングテーブルエントリがあります。これらのエントリは、仮想リンクのメンテナンスを含む、IPv4のエリア境界ルーターのルーティングテーブルエントリのすべての機能を備えています。この手順でエリアルーティングテーブルに追加されたルーターが仮想リンクのもう一方の端である場合、仮想ネイバーのIPアドレスは次のように設定されます。 「LAビット」が設定されている、最初に検出されたプレフィックスに設定される仮想ネイバーのIPアドレス。
o Routing table entries for transit networks, which are no longer associated with IP networks, are also modified in Step 4.
o IPネットワークに関連付けられなくなったトランジットネットワークのルーティングテーブルエントリも、手順4で変更されます。
The next stage of the shortest path calculation proceeds similarly to the two steps of the second stage of Section 16.1 in [Ref1]. 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' 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' routing table entry for the area.
最短経路計算の次の段階は、[Ref1]のセクション16.1の2番目の段階の2つのステップと同様に進行します。ただし、ルータLSA内のスタブリンクを調べる代わりに、エリアのエリア内プレフィックスLSAのリストを調べます。 「NUビット」が設定されているプレフィックスアドバタイズメントは、ルーティング計算に含めないでください。アドバタイズされたプレフィックスのコストは、プレフィックスのアドバタイズされたメトリックと、intra-area-prefix-LSAの参照されたLSタイプ、参照されたリンク状態ID、および参照された広告ルーターによって識別される通過頂点（ルーターまたはトランジットネットワーク）までのコストの合計です。田畑。この後者のコストは、エリアの通過頂点のルーティングテーブルエントリに格納されます。
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 [Ref1]). The only difference is in calculating the next hop IPv6 address for a router (call it Router X) which shares a link with the calculating router. In this case the calculating router assigns the next hop IPv6 address to be the link-local interface address contained in Router X's Link-LSA (see Section A.4.8) for the link. This procedure is necessary since on some links, such as NBMA links, the two routers need not be neighbors, and therefore might not be exchanging OSPF Hellos.
IPv6では、ネクストホップのIPv6アドレス（リンクローカルアドレスになります）の計算は、IPv4ネクストホップの計算と同じように行われます（[Ref1]のセクション16.1.1を参照）。唯一の違いは、計算ルーターとリンクを共有するルーター（ルーターXと呼びます）のネクストホップIPv6アドレスを計算することです。この場合、計算ルーターはネクストホップIPv6アドレスを、リンクのルーターXのLink-LSA（セクションA.4.8を参照）に含まれるリンクローカルインターフェイスアドレスに割り当てます。 NBMAリンクなどの一部のリンクでは、2つのルーターがネイバーである必要はなく、したがってOSPF Helloを交換していない可能性があるため、この手順が必要です。
Calculation of inter-area routes for IPv6 proceeds along the same lines as the IPv4 calculation in Section 16.2 of [Ref1], with the following modifications:
IPv6のエリア間ルートの計算は、[Ref1]のセクション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の名前は、それぞれinter-area-prefix-LSAおよびinter-area-router-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 a described router's OSPF Router ID is carried in the body of an inter-area- router-LSA.
o 上記のLSAタイプのリンク状態IDは、LSAによって記述されたネットワークまたはルーターをエンコードしなくなりました。代わりに、アドレスプレフィックスは、inter-area-prefix-LSAの本体に含まれ、説明されているルーターのOSPFルーターIDは、inter-area-router-LSAの本体に含まれています。
o Prefixes having the "NU-bit" set in their Prefix Options field should be ignored by the inter-area route calculation.
o プレフィックスオプションフィールドに「NUビット」が設定されているプレフィックスは、エリア間ルート計算で無視する必要があります。
When a single inter-area-prefix-LSA or inter-area-router-LSA has changed, the incremental calculations outlined in Section 16.5 of [Ref1] can be performed instead of recalculating the entire routing table.
単一のinter-area-prefix-LSAまたはinter-area-router-LSAが変更された場合、ルーティングテーブル全体を再計算する代わりに、[Ref1]のセクション16.5で概説されている増分計算を実行できます。
Examination of transit areas' summary-LSAs in IPv6 proceeds along the same lines as the IPv4 calculation in Section 16.3 of [Ref1], modified in the same way as the IPv6 inter-area route calculation in Section 3.8.2.
通過エリアのサマリーLSAの検査（IPv6のLSA）は、[Ref1]のセクション16.3のIPv4計算と同じように行われ、セクション3.8.2のIPv6エリア間ルート計算と同じ方法で変更されます。
The IPv6 AS external route calculation proceeds along the same lines as the IPv4 calculation in Section 16.4 of [Ref1], with the following exceptions:
IPv6 AS外部ルートの計算は、[Ref1]のセクション16.4のIPv4計算と同じように行われますが、次の例外があります。
o The Link State ID of the AS-external-LSA types no longer encodes the network described by the LSA. Instead, an address prefix is contained in the body of an AS- external-LSA.
o AS外部LSAタイプのリンク状態IDは、LSAによって記述されたネットワークをエンコードしなくなりました。代わりに、アドレスプレフィックスはAS-external-LSAの本体に含まれています。
o The default route is described by AS-external-LSAs which advertise zero length prefixes.
o デフォルトルートは、長さゼロのプレフィックスをアドバタイズするAS-external-LSAによって記述されます。
o Instead of comparing the AS-external-LSA's Forwarding address field to 0.0.0.0 to see whether a forwarding address has been used, bit F of the external-LSA is examined. A forwarding address is in use if and only if bit F is set.
o AS-external-LSAのForwarding addressフィールドを0.0.0.0と比較して転送アドレスが使用されているかどうかを確認する代わりに、external-LSAのビットFが検査されます。転送アドレスは、ビットFが設定されている場合にのみ使用されます。
o Prefixes having the "NU-bit" set in their Prefix Options field should be ignored by the inter-area route calculation.
o プレフィックスオプションフィールドに「NUビット」が設定されているプレフィックスは、エリア間ルート計算で無視する必要があります。
When a single AS-external-LSA has changed, the incremental calculations outlined in Section 16.6 of [Ref1] can be performed instead of recalculating the entire routing table.
単一のAS-external-LSAが変更された場合、ルーティングテーブル全体を再計算する代わりに、[Ref1]のセクション16.6で概説されている増分計算を実行できます。
In OSPF for IPv6, a router may have multiple interfaces to a single link. All interfaces are involved in the reception and transmission of data traffic, however only a single interface sends and receives OSPF control traffic. In more detail:
OSPF for IPv6では、ルーターに単一のリンクへの複数のインターフェースがある場合があります。すべてのインターフェイスがデータトラフィックの受信と送信に関与しますが、単一のインターフェイスのみがOSPF制御トラフィックを送受信します。さらに詳細に：
o Each of the multiple interfaces are assigned different Interface IDs. In this way the router can automatically detect when multiple interfaces attach to the same link, when receiving Hellos from its own Router ID but with an Interface ID other than the receiving interface's.
o 複数のインターフェースのそれぞれに、異なるインターフェースIDが割り当てられます。このようにして、ルーターは、独自のルーターIDからHellosを受信したときに、受信インターフェース以外のインターフェースIDを使用して、複数のインターフェースが同じリンクに接続したことを自動的に検出できます。
o The router turns off the sending and receiving of OSPF packets (that is, control traffic) on all but one of the interfaces to the link. The choice of interface to send and receive control traffic is implementation dependent; as one example, the interface with the highest Interface ID could be chosen. If the router is elected DR, it will be this interface's Interface ID that will be used as the network-LSA's Link State ID.
o ルーターは、リンクへの1つを除くすべてのインターフェイスで、OSPFパケット（制御トラフィック）の送受信をオフにします。制御トラフィックを送受信するインターフェースの選択は実装に依存します。一例として、最高のインターフェースIDを持つインターフェースを選択できます。ルーターがDRとして選出された場合、ネットワークLSAのリンク状態IDとして使用されるのは、このインターフェースのインターフェースIDです。
o All the multiple interfaces to the link will however appear in the router-LSA. In addition, a Link-LSA will be generated for each of the multiple interfaces. In this way, all interfaces will be included in OSPF's routing calculations.
o ただし、リンクへの複数のインターフェースはすべてルーターLSAに表示されます。さらに、Link-LSAが複数のインターフェースのそれぞれに対して生成されます。このようにして、すべてのインターフェースがOSPFのルーティング計算に含まれます。
o If the interface which is responsible for sending and receiving control traffic fails, another will have to take over, reforming all neighbor adjacencies from scratch. This failure can be detected by the router itself, when the other interfaces to the same link cease to hear the router's own Hellos.
o 制御トラフィックの送受信を担当するインターフェイスに障害が発生した場合、別のインターフェイスが引き継ぎ、すべての隣接関係をゼロから再構成する必要があります。この障害は、同じリンクへの他のインターフェイスがルータ自身のHelloを受信しなくなったときに、ルータ自体によって検出できます。
References
参考文献
[Ref1] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[参照1] Moy、J。、「OSPFバージョン2」、STD 54、RFC 2328、1998年4月。
[Ref2] McKenzie, A., "ISO Transport Protocol specification ISO DP 8073", RFC 905, April 1984.
[参照2]マッケンジーA。、「ISOトランスポートプロトコル仕様ISO DP 8073」、RFC 905、1984年4月。
[Ref3] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB using SMIv2", RFC 2233, November 1997.
[参照3] McCloghrie、K。およびF. Kastenholz、「The Interfaces Group MIB using SMIv2」、RFC 2233、1997年11月。
[Ref4] Fuller, V., Li, T, Yu, J. and K. Varadhan, "Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", RFC 1519, September 1993.
[参照4] Fuller、V.、Li、T、Yu、J。、およびK. Varadhan、「Classless Inter-Domain Routing（CIDR）：a Address Assignment and Aggregation Strategy」、RFC 1519、1993年9月。
[Ref5] Varadhan, K., Hares, S. and Y. Rekhter, "BGP4/IDRP for IP---
OSPF Interaction", RFC 1745, December 1994
[Ref6] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.
[参照6] Reynolds、J。およびJ. Postel、「Assigned Numbers」、STD 2、RFC 1700、1994年10月。
[Ref7] deSouza, O. and M. Rodrigues, "Guidelines for Running OSPF Over Frame Relay Networks", RFC 1586, March 1994.
[参照7] deSouza、O。およびM. Rodrigues、「フレームリレーネットワーク上でOSPFを実行するためのガイドライン」、RFC 1586、1994年3月。
[Ref8] Moy, J., "Multicast Extensions to OSPF", RFC 1584, March 1994.
[参照8] Moy、J。、「OSPFへのマルチキャスト拡張」、RFC 1584、1994年3月。
[Ref9] Coltun, R. and V. Fuller, "The OSPF NSSA Option", RFC 1587, March 1994.
[Ref9] Coltun、R。およびV. Fuller、「OSPF NSSAオプション」、RFC 1587、1994年3月。
[Ref10] Ferguson, D., "The OSPF External Attributes LSA", unpublished.
[参照10]ファーガソンD。、「OSPF外部属性LSA」、未公開。
[Ref11] Moy, J., "Extending OSPF to Support Demand Circuits", RFC 1793, April 1995.
[参照11] Moy、J。、「Extending OSPF to Support Demand Circuits」、RFC 1793、1995年4月。
[Ref12] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191, November 1990.
[参照12] Mogul、J。およびS. Deering、「Path MTU Discovery」、RFC 1191、1990年11月。
[Ref13] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.
[参照13] Rekhter、Y。およびT. Li、「A Border Gateway Protocol 4（BGP-4）」、RFC 1771、1995年3月。
[Ref14] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[参照14] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、1998年12月。
[Ref15] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[参照15] Hinden、R。およびS. Deering、「IPバージョン6アドレッシングアーキテクチャ」、RFC 2373、1998年7月。
[Ref16] Conta, A. and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification" RFC 2463, December 1998.
[Ref16] Conta、A。およびS. Deering、「インターネット制御メッセージプロトコル（ICMPv6）、インターネットプロトコルバージョン6（IPv6）仕様」RFC 2463、1998年12月。
[Ref17] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[Ref17] Narten、T.、Nordmark、E。およびW. Simpson、「Neighbor Discovery for IP Version 6（IPv6）」、RFC 2461、1998年12月。
[Ref18] McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[参照18] McCann、J.、Deering、S。およびJ. Mogul、「IPバージョン6のパスMTUディスカバリ」、RFC 1981、1996年8月。
[Ref19] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[参照19]ケント、S。、およびR.アトキンソン、「IP認証ヘッダー」、RFC 2402、1998年11月。
[Ref20] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[参照20]ケント、S、Rアトキンソン、「IPカプセル化セキュリティペイロード（ESP）」、RFC 2406、1998年11月。
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 in 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タイプごとにフォーマットを提供します。
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 Packets, Link State Request, Link State Update, and Link State Acknowledgment packets) can usually be split into several separate 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 sizes of OSPF packets sent over virtual links to 1280 bytes unless Path MTU Discovery is being performed [Ref14].
OSPFは、プロトコルパケットをフラグメント化する方法を定義せず、リンクMTUよりも大きいパケットを送信するときのIPv6フラグメント化に依存します。必要に応じて、OSPFパケットの長さは最大65,535バイトにすることができます。大きくなる可能性が高いOSPFパケットタイプ（データベース記述パケット、リンク状態要求、リンク状態更新、およびリンク状態確認パケット）は、通常、機能を失うことなく、いくつかの個別のプロトコルパケットに分割できます。これが推奨されます。 IPv6フラグメンテーションは、可能な限り回避する必要があります。この推論を使用して、Path MTU Discoveryが実行されていない限り、仮想リンクを介して送信されるOSPFパケットのサイズを1280バイトに制限する試みを行う必要があります[参照14]。
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.
o IPv6マルチキャストの使用。一部のOSPFメッセージは、ブロードキャストネットワーク経由で送信されるとマルチキャストされます。 2つの異なるIPマルチキャストアドレスが使用されます。これらのマルチキャストアドレスに送信されたパケットは転送しないでください。彼らはシングルホップだけを旅行することを意図しています。そのため、マルチキャストローカルアドレスはリンクローカルスコープで選択されており、これらのアドレスに送信されるパケットのIPv6ホップ制限は1に設定されている必要があります。
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を実行しているすべてのルーターは、このアドレスに送信されたパケットを受信できるように準備する必要があります。 Helloパケットは常にこの宛先に送信されます。また、フラッディング手順中に、特定のOSPFプロトコルパケットがこのアドレスに送信されます。
AllDRouters This multicast address has been assigned the value FF02::6. Both the Designated Router and Backup Designated Router must be prepared to receive packets destined to this address. Certain OSPF protocol packets are sent to this address during the flooding procedure.
AllDRoutersこのマルチキャストアドレスには、値FF02 :: 6が割り当てられています。指定ルーターとバックアップ指定ルーターの両方で、このアドレス宛のパケットを受信できるように準備する必要があります。フラッディング手順中に、特定のOSPFプロトコルパケットがこのアドレスに送信されます。
o OSPF is IP protocol 89. This number should be inserted in the Next Header field of the encapsulating IPv6 header.
o OSPFはIPプロトコル89です。この番号は、カプセル化するIPv6ヘッダーの次のヘッダーフィールドに挿入する必要があります。
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パケット、データベース記述パケット、および特定の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 (e.g., the MC-bit below); 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 (again the MC-bit is an example); these mismatches are discovered by examining LSAs.
ルーター間のオプションの不一致は、特定のオプションに応じて、さまざまな動作を引き起こす可能性があります。一部のオプションの不一致により、近隣関係の形成が妨げられます（たとえば、以下のEビット）。これらの不一致は、Helloパケットの送受信を通じて発見されます。一部のオプションの不一致により、特定のLSAタイプが隣接間でフラッディングされるのを防ぎます（たとえば、以下のMCビット）。これらは、データベース記述パケットの送受信を通じて発見されます。一部のオプションの不一致により、機能が低下しているため（MCビットは一例です）、ルーターがさまざまなルーティング計算の1つ以上に含まれません。これらの不一致は、LSAを調べることによって発見されます。
Six 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 Option bits in received Hello Packets, Database Description packets or LSAs should ignore the capability and process the packet/LSA normally.
OSPFオプションフィールドの6ビットが割り当てられています。以下に、各ビットについて簡単に説明します。ルータは、Helloパケットまたはデータベース記述パケットを送信するとき、およびLSAを発信するときに、オプションフィールドの認識されないビットをリセット（つまり、クリア）する必要があります。逆に、受信したHelloパケット、データベース記述パケット、または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|MC| E|V6|
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+--+--+--+--+--+
The Options field
オプションフィールド
V6-bit If this bit is clear, the router/link should be excluded from IPv6 routing calculations. See Section 3.8 of this memo.
V6-bitこのビットがクリアされている場合、ルーター/リンクをIPv6ルーティング計算から除外する必要があります。このメモのセクション3.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 [Ref1].
Eビットこのビットは、[Ref1]のセクション3.6、9.5、10.8および12.1.2で説明されているように、AS外部LSAがフラッディングされる方法を説明します。
MC-bit This bit describes whether IP multicast datagrams are forwarded according to the specifications in [Ref7].
MCビットこのビットは、[Ref7]の仕様に従ってIPマルチキャストデータグラムを転送するかどうかを示します。
N-bit This bit describes the handling of Type-7 LSAs, as specified in [Ref8].
Nビットこのビットは、[Ref8]で指定されているType-7 LSAの処理を記述します。
R-bit This bit (the `Router' bit) indicates whether the originator is an active router. If the router bit is clear routes which 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 [Ref10].
DCビットこのビットは、[Ref10]で指定されている、ルーターによるデマンド回線の処理を記述します。
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 division into fields is displayed, and then the field definitions are enumerated.
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 3.2.2. The sending of OSPF packets is explained in Section 3.2.1.
OSPFパケットの受信処理については、セクション3.2.2で詳しく説明しています。 OSPFパケットの送信については、セクション3.2.1で説明します。
Every OSPF packet starts with a standard 16 byte header. Together with the encapsulating IPv6 headers, the OSPF header contains all the information necessary to determine whether the packet should be accepted for further processing. This determination is described in Section 3.2.2 of this memo.
すべてのOSPFパケットは、標準の16バイトのヘッダーで始まります。カプセル化IPv6ヘッダーとともに、OSPFヘッダーには、パケットをさらに処理するために受け入れる必要があるかどうかを判断するために必要なすべての情報が含まれています。この決定は、このメモのセクション3.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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 Sections A.3.2 through A.3.6 for details.
タイプOSPFパケットのタイプは次のとおりです。詳細については、セクションA.3.2からA.3.6を参照してください。
Type Description
---------------------------------
1 Hello
2 Database Description
3 Link State Request
4 Link State Update
5 Link State Acknowledgment
Packet length The length of the OSPF protocol packet in bytes. This length includes the standard OSPF header.
パケット長OSPFプロトコルパケットの長さ（バイト単位）。この長さには、標準のOSPFヘッダーが含まれます。
Router ID The Router ID of the packet's source.
ルーターIDパケットの送信元のルーターID。
Area ID A 32 bit number identifying the area that this packet belongs to. All OSPF packets are associated with a single area. Most travel a single hop only. Packets travelling over a virtual link are labelled with the backbone Area ID of 0.
Area IDこのパケットが属するエリアを識別する32ビットの番号。すべてのOSPFパケットは単一のエリアに関連付けられています。ほとんどの場合、1つのホップのみを移動します。仮想リンク上を移動するパケットには、バックボーンエリアID 0のラベルが付けられます。
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 [Ref14, section 8.1]. The "Upper-Layer Packet Length" in the pseudo-header is set to value of the OSPF packet header's length field. The Next Header value used in the pseudo-header is 89. If the packet's length is not an integral number of 16-bit words, the packet is padded with a byte of zero before checksumming. Before computing the checksum, the checksum field in the OSPF packet header is set to 0.
チェックサムOSPFは、IPv6アプリケーションの標準チェックサム計算を使用します。OSPFパケットヘッダーから始まり、IPv6ヘッダーフィールドの「疑似ヘッダー」を付加して、パケットの内容全体の1の補数の合計の16ビットの補数、 [Ref14、セクション8.1]で指定されているとおり。疑似ヘッダーの「上位パケット長」は、OSPFパケットヘッダーの長さフィールドの値に設定されます。疑似ヘッダーで使用される次のヘッダー値は89です。パケットの長さが16ビットワードの整数でない場合、チェックサムの前にパケットにゼロのバイトが埋め込まれます。チェックサムを計算する前に、OSPFパケットヘッダーのチェックサムフィールドは0に設定されています。
Instance ID Enables multiple instances of OSPF to be run over a single link. Each protocol instance would be assigned a separate Instance ID; the Instance ID has local link significance only. Received packets whose Instance ID is not equal to the receiving interface's Instance ID are discarded.
インスタンスID OSPFの複数のインスタンスを単一のリンク上で実行できるようにします。各プロトコルインスタンスには、個別のインスタンスIDが割り当てられます。インスタンスIDにはローカルリンクの意味のみがあります。インスタンスIDが受信インターフェイスのインスタンスIDと等しくない受信パケットは破棄されます。
0 These fields are reserved. They must be 0.
0これらのフィールドは予約されています。それらは0でなければなりません。
Hello packets are OSPF packet type 1. These packets are sent periodically on all interfaces (including virtual links) in order to establish and maintain neighbor relationships. In addition, Hello Packets are multicast on those links having a multicast or broadcast capability, enabling dynamic discovery of neighboring routers.
HelloパケットはOSPFパケットタイプ1です。これらのパケットは、ネイバー関係を確立および維持するために、すべてのインターフェイス（仮想リンクを含む）で定期的に送信されます。さらに、Helloパケットは、マルチキャストまたはブロードキャスト機能を備えたリンク上でマルチキャストされるため、隣接ルーターの動的な検出が可能になります。
All routers connected to a common link must agree on certain parameters (HelloInterval and RouterDeadInterval). These parameters are included in Hello packets, so that differences can 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 bi-directionality (the Router IDs of all neighbors whose Hellos have been recently received).
共通リンクに接続されているすべてのルーターは、特定のパラメーター（HelloIntervalおよびRouterDeadInterval）について合意する必要があります。これらのパラメータはhelloパケットに含まれているため、違いが近隣関係の形成を阻害する可能性があります。 Helloパケットには、指定ルーターの選択に使用されるフィールド（指定ルーターIDとバックアップ指定ルーターID）と、双方向性（Helloが最近受信されたすべてのネイバーのルーター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 Pri | Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HelloInterval | RouterDeadInterval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Designated Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Backup Designated Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
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 ([Ref3]).
インターフェイスIDこのルーターのインターフェイスのコレクションの中でこのインターフェイスを一意に識別する32ビットの番号。たとえば、実装によっては、MIB-II IfIndex（[Ref3]）を使用できる場合があります。
Rtr Pri 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 Priこのルーターのルーター優先度。 （バックアップ）指定ルーターの選択で使用されます。 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 identity of the Designated Router for this network, in the view of the sending router. The Designated Router is identified by its Router ID. Set to 0.0.0.0 if there is no Designated Router.
代表ルーターID送信ルーターから見た、このネットワークの代表ルーターのID。指定ルーターは、ルーターIDによって識別されます。指定ルーターがない場合は、0.0.0.0に設定します。
Backup Designated Router ID The identity of the Backup Designated Router for this network, in the view of the sending router. The Backup Designated Router is identified by its IP Router ID. Set to 0.0.0.0 if there is no Backup Designated Router.
バックアップ指定ルーターID送信ルーターから見た、このネットワークのバックアップ指定ルーターのID。バックアップ指定ルーターは、IPルーターIDによって識別されます。バックアップ指定ルーターがない場合は、0.0.0.0に設定します。
Neighbor ID The Router IDs of each router from whom valid Hello packets have been seen recently on the network. Recently means in the last RouterDeadInterval seconds.
ネイバーIDネットワーク上で最近有効なHelloパケットが確認された各ルーターのルーターID。最近の最後のRouterDeadInterval秒を意味します。
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, the other the slave. The master sends Database Description packets (polls) which are acknowledged by Database Description packets sent by the slave (responses). The responses are linked to the polls via the packets' DD sequence numbers.
データベース記述パケットはOSPFパケットタイプ2です。これらのパケットは、隣接が初期化されているときに交換されます。リンクステートデータベースの内容を記述します。データベースを記述するために複数のパケットが使用される場合があります。この目的のために、ポーリング応答手順が使用されます。ルーターの1つはマスターに指定され、もう1つはスレーブに指定されます。マスターは、スレーブによって送信されたデータベース記述パケット（応答）によって確認応答されるデータベース記述パケット（ポーリング）を送信します。応答は、パケットの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 format of the Database Description packet is very similar to both the Link State Request and Link State Acknowledgment packets. 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 [Ref1]. The reception of Database Description packets is documented in Section 10.6 of [Ref1].
データベース記述パケットのフォーマットは、リンク状態要求パケットとリンク状態確認パケットの両方に非常に似ています。 3つすべての主要部分はアイテムのリストであり、各アイテムはリンク状態データベースの一部を記述しています。データベース記述パケットの送信については、[Ref1]のセクション10.8に記載されています。データベース記述パケットの受信は、[Ref1]のセクション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 [Ref12]. Interface MTU should be set to 0 in Database Description packets sent over virtual links.
インターフェイスMTU断片化せずに、関連するインターフェイスから送信できる最大のIPv6データグラムのバイト単位のサイズ。一般的なインターネットリンクタイプのMTUは、[Ref12]の表7-1にあります。仮想リンクを介して送信されるデータベース記述パケットでは、インターフェースMTUを0に設定する必要があります。
I-bit The Init bit. When set to 1, this packet is the first in the sequence of Database Description Packets.
IビットInitビット。 1に設定すると、このパケットは一連のデータベース記述パケットの最初になります。
M-bit The More bit. When set to 1, it indicates that more Database Description Packets are to follow.
MビットThe Moreビット。 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-bitマスター/スレーブビット。 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 description has been sent.
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 Section A.4.1. It contains all the information required to uniquely identify both the LSA and the LSA's current instance.
パケットの残りの部分は、リンク状態データベースの断片の（おそらく部分的な）リストで構成されています。データベース内の各LSAは、そのLSAヘッダーによって記述されます。 LSAヘッダーについては、セクションA.4.1で説明しています。 LSAとLSAの現在のインスタンスの両方を一意に識別するために必要なすべての情報が含まれています。
Link State Request packets are OSPF packet type 3. After exchanging Database Description packets with a neighboring router, a router may find that parts of its link-state database are out-of-date. The Link State Request packet is used to request the pieces of the neighbor's database that are more up-to-date. Multiple Link State Request packets may need to be used.
リンク状態要求パケットはOSPFパケットタイプ3です。隣接ルーターとデータベース記述パケットを交換した後、ルーターはリンク状態データベースの一部が古くなっていることに気付く場合があります。 Link State Requestパケットは、ネイバーのデータベースの中でより最新の部分を要求するために使用されます。複数のリンク状態要求パケットを使用する必要がある場合があります。
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 instances in response.
リンク状態要求パケットを送信するルーターは、要求しているデータベース部分の正確なインスタンスを念頭に置いています。各インスタンスは、LSシーケンス番号、LSチェックサム、およびLS経過時間によって定義されますが、これらのフィールドはリンク状態要求パケット自体では指定されていません。ルーターは、応答としてさらに最近のインスタンスを受信する場合があります。
The sending of Link State Request packets is documented in Section 10.9 of [Ref1]. The reception of Link State Request packets is documented in Section 10.7 of [Ref1].
Link State Requestパケットの送信については、[Ref1]のセクション10.9に記載されています。 Link State Requestパケットの受信については、[Ref1]のセクション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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
Each LSA requested is specified by its LS type, Link State ID, and Advertising Router. This uniquely identifies the LSA, but not its instance. Link State Request packets are understood to be requests for the most recent instance (whatever that might be).
要求される各LSAは、そのLSタイプ、リンク状態ID、およびアドバタイジングルーターによって指定されます。これはLSAを一意に識別しますが、そのインスタンスは識別しません。リンク状態要求パケットは、最新のインスタンス（それが何であれ）の要求であると理解されます。
Link State Update packets are OSPF packet type 4. These packets implement the flooding of LSAs. Each Link State Update packet carries a collection of LSAs one hop further from their origin. Several LSAs may be included in a single packet.
リンク状態更新パケットは、OSPFパケットタイプ4です。これらのパケットは、LSAのフラッディングを実装しています。各リンク状態更新パケットは、発信元から1ホップ離れたLSAのコレクションを伝送します。 1つのパケットに複数の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 3.5.
リンク状態更新パケットは、マルチキャスト/ブロードキャストをサポートする物理ネットワーク上でマルチキャストされます。フラッディング手順を信頼できるものにするために、フラッディングされたLSAは、リンク状態確認パケットで確認されます。特定のLSAの再送信が必要な場合、再送信されたLSAは常にユニキャストリンク状態更新パケットによって伝送されます。 LSAの信頼できるフラッディングの詳細については、セクション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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | 4 | Packet length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Instance ID | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # LSAs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- +-+
| LSAs |
+- +-+
| ... |
# LSAs The number of LSAs included in this update.
＃LSAsこのアップデートに含まれるLSAの数。
The body of the Link State Update packet consists of a list of LSAs. Each LSA begins with a common 20 byte header, described in Section A.4.2. Detailed formats of the different types of LSAs are described in Section A.4.
リンク状態更新パケットの本体は、LSAのリストで構成されています。各LSAは、セクションA.4.2で説明されている共通の20バイトのヘッダーで始まります。さまざまなタイプのLSAの詳細なフォーマットについては、セクションA.4で説明します。
Link State Acknowledgment Packets are OSPF packet type 5. To make the flooding of LSAs reliable, flooded LSAs are explicitly acknowledged. This acknowledgment is accomplished through the sending and receiving of Link State Acknowledgment packets. The sending of Link State Acknowledgement packets is documented in Section 13.5 of [Ref1]. The reception of Link State Acknowledgement packets is documented in Section 13.7 of [Ref1].
リンク状態確認パケットはOSPFパケットタイプ5です。LSAのフラッディングを信頼できるものにするために、フラッディングLSAは明示的に確認されます。この確認応答は、リンク状態確認応答パケットの送受信を通じて行われます。 Link State Acknowledgementパケットの送信については、[Ref1]のセクション13.5に記載されています。リンク状態確認パケットの受信については、[Ref1]のセクション13.7に記載されています。
Multiple LSAs can 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 either to the multicast address AllSPFRouters, to the multicast address AllDRouters, or as a unicast (see Section 13.5 of [Ref1] for details).
複数のLSAは、単一のリンク状態確認パケットで確認できます。送信インターフェイスの状態と、対応するリンク状態更新パケットの送信者に応じて、リンク状態確認パケットはマルチキャストアドレスAllSPFRouters、マルチキャストアドレスAllDRouters、またはユニキャストとして送信されます（[Ref1 ] 詳細については）。
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 -+
| |
+- -+
| |
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
Each acknowledged LSA is described by its LSA header. The LSA header is documented in Section A.4.2. It contains all the information required to uniquely identify both the LSA and the LSA's current instance.
確認済みの各LSAは、そのLSAヘッダーによって記述されます。 LSAヘッダーについては、セクションA.4.2で説明されています。 LSAとLSAの現在のインスタンスの両方を一意に識別するために必要なすべての情報が含まれています。
This memo defines seven distinct types of LSAs. Each LSA begins with a standard 20 byte LSA header. This header is explained in Section A.4.2. Succeeding sections then diagram the separate LSA types.
このメモは、7つの異なるタイプのLSAを定義しています。各LSAは、標準の20バイトのLSAヘッダーで始まります。このヘッダーについては、セクションA.4.2で説明します。その後のセクションでは、個別のLSAタイプを図で示します。
Each LSA describes a piece of the OSPF routing domain. Every router originates a router-LSA. A network-LSA is advertised for each link by its Designated Router. A router's link-local addresses are advertised to its neighbors in link-LSAs. IPv6 prefixes are advertised in intra-area-prefix-LSAs, inter-area-prefix-LSAs and AS-external-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 have the same collection of LSAs. (See Section 3.5 for more information concerning the flooding algorithm). This collection of LSAs is called the link-state database.
各LSAは、OSPFルーティングドメインの一部を記述します。すべてのルーターはルーターLSAを発信します。ネットワークLSAは、指定ルーターによってリンクごとにアドバタイズされます。ルータのリンクローカルアドレスは、リンクLSAでネイバーにアドバタイズされます。 IPv6プレフィックスは、intra-area-prefix-LSA、inter-area-prefix-LSAおよびAS-external-LSAでアドバタイズされます。特定のルーターの場所は、エリアルーター間LSAのエリア境界を越えてアドバタイズできます。その後、すべてのLSAがOSPFルーティングドメイン全体にフラッディングされます。フラッディングアルゴリズムは信頼性が高く、すべてのルーターが同じLSAのコレクションを持っていることが保証されます。 （フラッディングアルゴリズムの詳細については、セクション3.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 [Ref1]). For the details of the routing table build process, see Section 3.8.
リンク状態データベースから、各ルーターは自身をルートとして最短パスツリーを構築します。これによりルーティングテーブルが生成されます（[Ref1]のセクション11を参照）。ルーティングテーブル作成プロセスの詳細については、3.8項を参照してください。
IPv6 addresses are bit strings of length 128. IPv6 routing algorithms, and OSPF for IPv6 in particular, advertise IPv6 address prefixes. IPv6 address prefixes are bit strings whose length ranges between 0 and 128 bits (inclusive).
IPv6アドレスは、長さ128のビット文字列です。IPv6ルーティングアルゴリズム、特にIPv6のOSPFは、IPv6アドレスプレフィックスをアドバタイズします。 IPv6アドレスプレフィックスは、長さが0〜128ビットの範囲のビット文字列です。
Within OSPF, IPv6 address prefixes are always represented by a combination of three fields: PrefixLength, PrefixOptions, and Address Prefix. PrefixLength is the length in bits of the prefix. PrefixOptions is an 8-bit field describing various capabilities associated with the prefix (see Section A.4.2). Address Prefix is an encoding of the prefix itself as an even multiple of 32-bit words, padding with zero bits as necessary; this encoding consumes (PrefixLength + 31) / 32) 32-bit words.
OSPF内では、IPv6アドレスプレフィックスは常に3つのフィールドの組み合わせで表されます：PrefixLength、PrefixOptions、およびアドレスプレフィックス。 PrefixLengthは、プレフィックスの長さ（ビット単位）です。 PrefixOptionsは、プレフィックスに関連するさまざまな機能を説明する8ビットのフィールドです（セクションA.4.2を参照）。アドレスプレフィックスは、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 Sections A.4.5, A.4.7, A.4.8 and A.4.9.
OSPFでのIPv6プレフィックス表現の例は、セクションA.4.5、A.4.7、A.4.8、およびA.4.9にあります。
Each prefix is advertised along with an 8-bit field of capabilities. These serve as input to the various routing calculations, allowing, for example, certain prefixes to be ignored in some cases, or to be marked as not readvertisable in others.
各プレフィックスは、8ビットの機能フィールドとともにアドバタイズされます。これらは、さまざまなルーティング計算の入力として機能し、たとえば、特定のプレフィックスを無視したり、他のプレフィックスを読み取り不可としてマークしたりできるようにします。
0 1 2 3 4 5 6 7
+--+--+--+--+--+--+--+--+
| | | | | P|MC|LA|NU|
+--+--+--+--+--+--+--+--+
The Prefix Options field
プレフィックスオプションフィールド
NU-bit The "no unicast" capability bit. If set, the prefix should be excluded from IPv6 unicast calculations, otherwise 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.
LAビット「ローカルアドレス」機能ビット。設定されている場合、プレフィックスは実際にはアドバタイズルータのIPv6インターフェイスアドレスです。
MC-bit The "multicast" capability bit. If set, the prefix should be included in IPv6 multicast routing calculations, otherwise it should be excluded.
MC-bit「マルチキャスト」機能ビット。設定されている場合、プレフィックスはIPv6マルチキャストルーティング計算に含まれる必要があります。それ以外の場合は除外されます。
P-bit The "propagate" bit. Set on NSSA area prefixes that should be readvertised at the NSSA area border.
Pビット「伝播」ビット。 NSSAエリアの境界で再アドバタイズする必要があるNSSAエリアプレフィックスに設定します。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 Section A.4.2.1 for a detailed description of LS type.
LSタイプLSタイプフィールドは、LSAによって実行される機能を示します。 LSタイプの上位3ビットはLSAの一般的なプロパティをエンコードし、残り（LSA関数コードと呼ばれる）はLSAの特定の機能を示します。 LSタイプの詳細については、セクションA.4.2.1を参照してください。
Link State ID Together with LS type and Advertising Router, uniquely identifies the LSA in the link-state database.
リンク状態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 Detects old or duplicate LSAs. Successive instances of an LSA are given successive LS sequence numbers. See Section 12.1.6 in [Ref1] for more details.
LSシーケンス番号古いまたは重複したLSAを検出します。 LSAの連続するインスタンスには、連続したLSシーケンス番号が与えられます。詳細については、[Ref1]のセクション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 [Ref1] for more details.
LSチェックサムLSAヘッダーを含み、LSエージフィールドを除いた、LSAの完全な内容のフレッチャーチェックサム。詳細については、[Ref1]のセクション12.1.7を参照してください。
length The length in bytes of the LSA. This includes the 20 byte LSA header.
LSAのバイト単位の長さ。これには、20バイトのLSAヘッダーが含まれます。
The LS type field indicates the function performed by the LSA. The high-order three bits of LS type encode generic properties of the LSA, while the remainder (called LSA function code) indicate the LSA's specific functionality. The format of the LS type is as follows:
LSタイプフィールドは、LSAによって実行される機能を示します。 LSタイプの上位3ビットはLSAの一般的なプロパティをエンコードし、残り（LSA関数コードと呼ばれる）はLSAの特定の機能を示します。 LSタイプの形式は次のとおりです。
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|U |S2|S1| LSA Function Code |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
The U bit indicates how the LSA should be handled by a router which 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 type understood
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 link it is originated on.
0 1 Area Scoping. Flooded to all routers in the originating area
1 0 AS Scoping. Flooded to all routers in the AS
1 1 Reserved
The LSA function codes are defined as follows. The origination and processing of these LSA function codes are defined elsewhere in this memo, except for the group-membership-LSA (see [Ref7]) and the Type-7-LSA (see [Ref8]). Each LSA function code also implies a specific setting for the U, S1 and S2 bits, as shown below.
LSA機能コードは次のように定義されています。これらのLSA機能コードの生成と処理は、このメモの他の場所で定義されています。ただし、グループメンバーシップLSA（[Ref7]を参照）とType-7-LSA（[Ref8]を参照）を除きます。各LSA機能コードは、次に示すように、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 Group-membership-LSA
7 0x2007 Type-7-LSA
8 0x0008 Link-LSA
9 0x2009 Intra-Area-Prefix-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 3.4.3.1. Router-LSAs are flooded throughout a single area only.
ルーターLSAのLSタイプは0x2001です。エリア内の各ルーターは、1つ以上のルーターLSAを発信します。ルーターが発信したルーターLSAの完全なコレクションは、エリアへのルーターのインターフェイスの状態とコストを示します。ルータLSAの構築の詳細については、3.4.3.1項を参照してください。ルーター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 |W|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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
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.
単一のルーターが1つ以上のルーターLSAを発信し、それらのリンク状態ID（発信元ルーターによって任意に選択される）によって区別されます。オプションフィールドとV、E、Bビットは、単一の発信元からのすべてのルーターLSAで同じでなければなりません。ただし、不一致の場合は、リンク状態IDが最も小さいLSAの値が優先されます。 1つのルーターから複数のルーターLSAを受信すると、リンクは1つのLSAに連結されているかのように処理されます。
bit V When set, the router is an endpoint of one or more fully adjacent virtual links having the described area as Transit area (V is for virtual link endpoint).
ビットVが設定されている場合、ルーターは1つ以上の完全に隣接する仮想リンクのエンドポイントであり、記述されたエリアは通過エリアです（Vは仮想リンクのエンドポイントを示します）。
bit E When set, the router is an AS boundary router (E is for external).
ビットEセットされている場合、ルーターはAS境界ルーターです（Eは外部用）。
bit B When set, the router is an area border router (B is for border).
ビットBセットされている場合、ルーターはエリア境界ルーターです（Bは境界用です）。
bit W When set, the router is a wild-card multicast receiver. When running MOSPF, these routers receive all multicast datagrams, regardless of destination. See Sections 3, 4 and A.2 of [Ref8] for details.
ビットWセットされている場合、ルーターはワイルドカードマルチキャストレシーバーです。 MOSPFを実行すると、これらのルーターは宛先に関係なく、すべてのマルチキャストデータグラムを受信します。詳細については、[Ref8]のセクション3、4、およびA.2を参照してください。
Options The optional capabilities supported by the router, as documented in Section 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フィールドによって異なります。
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
Metric The cost of using this router interface, for outbound traffic.
メトリック送信トラフィックに対して、このルーターインターフェイスを使用するコスト。
Interface ID The Interface ID assigned to the interface being described. See Sections 3.1.2 and C.3.
インターフェースID記述されているインターフェースに割り当てられたインターフェースID。セクション3.1.2およびC.3を参照してください。
Neighbor Interface ID The Interface ID the neighbor router (or the attached link's Designated Router, for Type 2 interfaces) has been advertising in hello packets sent on the attached link.
ネイバーインターフェイスIDネイバールータ（またはタイプ2インターフェイスの場合は接続リンクの指定ルータ）が接続リンクで送信されたhelloパケットでアドバタイズしているインターフェイスID。
Neighbor Router ID The Router ID the neighbor router (or the attached link's Designated Router, for Type 2 interfaces).
隣接ルーターID隣接ルーター（またはタイプ2インターフェースの場合は、接続されたリンクの指定ルーター）のルーターID。
For 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がリンク状態データベースで検出されます。
Network-LSAs have LS type equal to 0x2002. A network-LSA is originated for each broadcast and NBMA link in the area which supports two or more routers. The network-LSA is originated by the link's Designated Router. The LSA describes all routers attached to the link, including the Designated Router itself. The LSA's Link State ID field is set to the Interface ID that the Designated Router has been advertising in Hello packets on the link.
ネットワークLSAのLSタイプは0x2002です。ネットワークLSAは、2つ以上のルーターをサポートするエリア内のブロードキャストおよびNBMAリンクごとに作成されます。ネットワークLSAは、リンクの指定ルーターによって発信されます。 LSAは、代表ルーター自体を含む、リンクに接続されたすべてのルーターを記述します。 LSAのリンク状態IDフィールドは、代表ルータがリンク上の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 3.4.3.2.
ネットワークから接続されているすべてのルーターまでの距離はゼロです。これが、ネットワークLSAでメトリックフィールドを指定する必要がない理由です。ネットワークLSAの構築の詳細については、3.4.3.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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age |0|0|1| 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attached Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
Attached Router The Router IDs of each of the routers attached to the link. Actually, only those routers that are fully adjacent to the Designated Router are listed. The Designated Router includes itself in this list. The number of routers included can be deduced from the LSA header's length field.
接続されたルーターリンクに接続された各ルーターのルーターID。実際には、指定ルーターに完全に隣接しているルーターのみが表示されます。指定ルーターはこのリストに含まれています。含まれるルーターの数は、LSAヘッダーの長さフィールドから推定できます。
Inter-Area-Prefix-LSAs have LS type equal to 0x2003. These LSAs are are the IPv6 equivalent of OSPF for IPv4's type 3 summary-LSAs (see Section 12.4.3 of [Ref1]). 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 3.4.3.3.
Inter-Area-Prefix-LSAのLSタイプは0x2003です。これらのLSAは、IPv4のタイプ3サマリーLSAのOSPFに相当するIPv6です（[Ref1]のセクション12.4.3を参照）。エリアボーダールーターによって発信され、他のエリアに属するIPv6アドレスプレフィックスへのルートを記述します。 IPv6アドレスプレフィックスごとに個別のInter-Area-Prefix-LSAが生成されます。 Inter-Area-Prefix-LSAの構築の詳細については、3.4.3.3項を参照してください。
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.
スタブエリアの場合、Inter-Area-Prefix-LSAを使用して（エリアごとの）デフォルトルートを記述することもできます。外部ルートの完全なセットをフラッディングする代わりに、デフォルトのサマリールートがスタブエリアで使用されます。デフォルトのサマリールートを記述する場合、Inter-Area-Prefix-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 |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Metric The cost of this route. Expressed in the same units as the interface costs in the router-LSAs. When the Inter-Area-Prefix-LSA is describing a route to a range of addresses (see Section C.2) the cost is set to the maximum cost to any reachable component of the address range.
メトリックこのルートのコスト。ルータLSAのインターフェイスコストと同じ単位で表されます。 Inter-Area-Prefix-LSAがアドレスの範囲へのルートを記述している場合（セクションC.2を参照）、コストは、アドレス範囲の到達可能なコンポーネントへの最大コストに設定されます。
PrefixLength, PrefixOptions and Address Prefix Representation of the IPv6 address prefix, as described in Section A.4.1.
セクションA.4.1で説明されているように、IPv6アドレスプレフィックスのPrefixLength、PrefixOptions、およびアドレスプレフィックス表現。
Inter-Area-Router-LSAs have LS type equal to 0x2004. These LSAs are are the IPv6 equivalent of OSPF for IPv4's type 4 summary-LSAs (see Section 12.4.3 of [Ref1]). Originated by area border routers, they describe routes to routers in other areas. (To see why it is necessary to advertise the location of each ASBR, consult Section 16.4 in [Ref1].) Each LSA describes a route to a single router. For details concerning the construction of Inter-Area-Router-LSAs, see Section 3.4.3.4.
Inter-Area-Router-LSAのLSタイプは0x2004です。これらのLSAは、IPv4のタイプ4サマリーLSAのOSPFに相当するIPv6です（[Ref1]のセクション12.4.3を参照）。エリア境界ルーターによって発信され、他のエリアのルーターへのルートを記述します。 （各ASBRの場所を通知する必要がある理由については、[Ref1]のセクション16.4を参照してください。）各LSAは、単一のルーターへのルートを記述します。 Inter-Area-Router-LSAの構築の詳細については、3.4.3.4項を参照してください。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age |0|0|1| 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Options The optional capabilities supported by the router, as documented in Section A.2.
オプションセクションA.2で説明されている、ルーターがサポートするオプション機能。
Metric The cost of this route. Expressed in the same units as the interface costs in the router-LSAs.
メトリックこのルートのコスト。ルータLSAのインターフェイスコストと同じ単位で表されます。
Destination Router ID The Router ID of the router being described by the LSA.
宛先ルーターID LSAによって記述されているルーターのルーターID。
AS-external-LSAs have LS type equal to 0x4005. These LSAs are originated by AS boundary routers, and describe destinations external to the AS. Each LSA describes a route to a single IPv6 address prefix. For details concerning the construction of AS-external-LSAs, see Section 3.4.3.5.
AS外部LSAのLSタイプは0x4005です。これらのLSAは、AS境界ルーターによって発信され、ASの外部の宛先を記述します。各LSAは、単一のIPv6アドレスプレフィックスへのルートを記述します。 AS-external-LSAの構築の詳細については、3.4.3.5項を参照してください。
AS-external-LSAs can be used to describe a default route. Default routes are used when no specific route exists to the destination. When describing a default route, the AS-external-LSA's PrefixLength is set to 0.
AS-external-LSAを使用して、デフォルトルートを記述できます。デフォルトルートは、宛先への特定のルートが存在しない場合に使用されます。デフォルトルートを記述する場合、AS-external-LSAの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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 the link state metric (i.e., the
same units as interface cost).
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 Section A.4.1.
セクションA.4.1で説明されているように、IPv6アドレスプレフィックスのPrefixLength、PrefixOptions、およびアドレスプレフィックス表現。
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. Must not be set to the IPv6 Unspecified Address (0:0:0:0:0:0:0:0).
転送アドレス完全修飾IPv6アドレス（128ビット）。ビットFが設定されている場合にのみ、LSAに含まれます。含まれている場合、アドバタイズされた宛先のデータトラフィックはこのアドレスに転送されます。 IPv6未指定アドレス（0：0：0：0：0：0：0：0）に設定しないでください。
External Route Tag A 32-bit field which may be used to communicate additional information between AS boundary routers; see [Ref5] for example usage. Included in the LSA if and only if bit T has been set.
外部経路タグAS境界ルーター間で追加情報を通信するために使用される32ビットのフィールド。使用例については、[参照5]を参照してください。ビットTが設定されている場合にのみ、LSAに含まれます。
Referenced Link State ID Included if and only if Reference LS Type is non-zero. If included, additional information concerning the advertised external route can be found in the LSA having LS type equal to "Referenced LS Type", Link State ID equal to "Referenced Link State ID" and Advertising Router the same as that specified in the AS-external-LSA's link state header. This additional information is not used by the OSPF protocol itself. It may be used to communicate information between AS boundary routers; the precise nature of such information is outside the scope of this specification.
参照リンク状態ID参照LSタイプがゼロ以外の場合にのみ含まれます。含まれている場合、アドバタイズされた外部ルートに関する追加情報は、LSタイプが「参照されたLSタイプ」、リンク状態IDが「参照されたリンク状態ID」、広告ルーターがASで指定されたものと同じであるLSAにあります。外部LSAのリンク状態ヘッダー。この追加情報は、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). However, when present Forwarding Address always comes first, with External Route Tag always preceding Referenced Link State ID.
AS-external-LSAには、Forwarding address、External Route Tag、およびReferenced Link State IDというラベルの付いたフィールドがすべて、またはまったく、または一部存在する場合があります（ビットF、ビットT、および参照LSタイプの設定でそれぞれ示されます）。ただし、存在する場合は常に転送アドレスが最初に来て、外部ルートタグは常に参照リンク状態IDの前にあります。
Link-LSAs have LS type equal to 0x0008. A router originates a separate Link-LSA for each link it is attached to. These LSAs have local-link flooding scope; they are never flooded beyond the link that they are associated with. Link-LSAs have three purposes: 1) they provide the router's link-local address to all other routers attached to the link and 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 assert a collection of Options bits to associate with the Network-LSA that will be originated for the link.
リンクLSAのLSタイプは0x0008です。ルーターは、接続されているリンクごとに個別のリンクLSAを発信します。これらのLSAにはローカルリンクフラッディングスコープがあります。それらが関連付けられているリンクを超えてフラッディングされることはありません。リンクLSAには3つの目的があります。1）リンクに接続されている他のすべてのルーターにルーターのリンクローカルアドレスを提供し、2）リンクに接続されている他のルーターに、リンクに関連付けるIPv6プレフィックスのリストを通知し、3）これにより、ルーターはオプションビットのコレクションをアサートして、リンクに対して発信されるネットワークLSAに関連付けることができます。
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 Pri | Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- -+
| |
+- Link-local Interface Address -+
| |
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # prefixes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PrefixLength | PrefixOptions | (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Prefix |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PrefixLength | PrefixOptions | (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Prefix |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Rtr Pri The Router Priority of the interface attaching the originating router to the link.
Rtr Pri発信ルーターをリンクに接続するインターフェースのルーター優先度。
Options The set of Options bits that the router would like set in the Network-LSA that will be originated for the link.
オプションルーターがリンクに対して発信されるNetwork-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.
＃prefixes 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 Section A.4.1.
セクションA.4.1で説明されているように、IPv6アドレスプレフィックスのPrefixLength、PrefixOptions、およびアドレスプレフィックス表現。
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) the router itself, b) an attached stub network segment or c) an attached transit network segment. In IPv4, a) and b) were accomplished via the router's router-LSA, and c) via a network-LSA. However, in OSPF for IPv6 all addressing information has been removed from router-LSAs and network-LSAs, leading to the introduction of the Intra-Area-Prefix-LSA.
Intra-Area-Prefix-LSAのLSタイプは0x2009です。ルーターはIntra-Area-Prefix-LSAを使用して、a）ルーター自体、b）接続されたスタブネットワークセグメント、またはc）接続されたトランジットネットワークセグメントに関連付けられている1つ以上のIPv6アドレスプレフィックスをアドバタイズします。 IPv4では、a）およびb）はルーターのルーターLSAを介して、c）ネットワークLSAを介して達成されました。ただし、IPv6のOSPFでは、ルーターLSAおよびネットワークLSAからすべてのアドレッシング情報が削除されているため、Intra-Area-Prefix-LSAが導入されています。
A router can originate multiple Intra-Area-Prefix-LSAs for each router or transit network; each such LSA is distinguished by its 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 |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
# prefixes The number of IPv6 address prefixes contained in the LSA.
＃prefixes LSAに含まれるIPv6アドレスプレフィックスの数。
Router Referenced LS type, Referenced Link State ID and Referenced Advertising Identifies the router-LSA or network-LSA with which the IPv6 address prefixes should be associated. If Referenced LS type is 1, 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 2, 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タイプが1の場合、プレフィックスはルーターLSAに関連付けられ、参照リンク状態IDは0であり、参照広告ルーターは発信元ルーターのルーターIDである必要があります。参照LSタイプが2の場合、プレフィックスはネットワーク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, together with the cost of each prefix.
Intra-Area-Prefix-LSAの残りの部分には、ルーターまたは中継リンクに関連付けられるIPv6プレフィックスのリストと、各プレフィックスのコストが含まれています。
PrefixLength, PrefixOptions and Address Prefix Representation of an IPv6 address prefix, as described in Section A.4.1.
セクションA.4.1で説明されているように、IPv6アドレスプレフィックスのPrefixLength、PrefixOptions、およびアドレスプレフィックス表現。
Metric The cost of this prefix. Expressed in the same units as the interface costs in the router-LSAs.
メトリックこのプレフィックスのコスト。ルータLSAのインターフェイスコストと同じ単位で表されます。
B. Architectural Constants
B.アーキテクチャの定数
Architectural constants for the OSPF protocol are defined in Appendix B of [Ref1]. The only difference for OSPF for IPv6 is that DefaultDestination is encoded as a prefix of length 0 (see Section A.4.1).
OSPFプロトコルのアーキテクチャ定数は、[Ref1]の付録Bで定義されています。 OSPF for IPv6の唯一の違いは、DefaultDestinationが長さ0のプレフィックスとしてエンコードされることです（セクションA.4.1を参照）。
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, and 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の観点からは、これらの項目は引き続き構成可能です。
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 in order to change its Router ID, the router should flush its self-originated LSAs from the routing domain (see Section 14.1 of [Ref1]), or they will persist for up to MaxAge minutes.
ルーターIDこれは、自律システム内のルーターを一意に識別する32ビットの番号です。ルーターのOSPFルーターIDが変更された場合、新しいルーターIDが有効になる前に、ルーターのOSPFソフトウェアを再起動する必要があります。ルーターIDを変更するために再起動する前に、ルーターはルーティングドメインから自己生成LSAをフラッシュする必要があります（[Ref1]のセクション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アドレスよりも小さいため、ルーターのIPv6アドレスのいずれかに設定することはできません（IPv4で一般的に行われているように）。 IPv6で可能なルーターIDの割り当て手順には、a）ルーターのIPv4アドレスの1つとしてIPv6ルーターIDを割り当てるか、b）ローカルの管理手順（製造元が製品のシリアル番号を割り当てるために使用する手順と同様）を介してIPv6ルーターIDを割り当てます。
The Router ID of 0.0.0.0 is reserved, and should not be used.
ルーターID 0.0.0.0は予約されているため、使用しないでください。
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 routing protocol 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ビットの番号です。エリアID 0はバックボーン用に予約されています。
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.
ステータスはAdvertiseまたはDoNotAdvertiseに設定されます。ルーティング情報はエリア境界で圧縮されます。エリアの外部では、アドレス範囲ごとに最大で1つのルートが（inter-area-prefix-LSAを介して）アドバタイズされます。ルートは、アドレス範囲のステータスがAdvertiseに設定されている場合にのみアドバタイズされます。アドバタイズされていない範囲により、特定のネットワークの存在を他の領域から意図的に隠すことができます。ステータスはデフォルトでAdvertiseに設定されています。
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". 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 area. Also, virtual links cannot be configured through stub areas. For more information, see Section 3.6 of [Ref1].
ExternalRoutingCapability AS外部LSAがエリアにフラッディングされるか、エリア全体にフラッディングされるかどうか。 AS-external-LSAがエリアから除外されている場合、そのエリアは「スタブ」と呼ばれます。内部からスタブエリアへ、外部宛先へのルーティングはデフォルトのエリア間ルートのみに基づいて行われます。バックボーンはスタブエリアとして設定できません。また、仮想リンクはスタブエリアを介して構成できません。詳細については、[Ref1]のセクション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 [Ref1] for more information.
StubDefaultCostエリアがスタブエリアとして設定されており、ルータ自体がエリア境界ルータである場合、StubDefaultCostは、ルータがエリアにアドバタイズする必要があるデフォルトのinter-area-prefix-LSAのコストを示します。詳細については、[Ref1]のセクション12.4.3.1を参照してください。
Some of the configurable router interface parameters (such as Area ID, HelloInterval and RouterDeadInterval) actually imply properties of the attached links, and therefore 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.
Area OF接続されたリンクが属する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 ([Ref3]).
インターフェイスIDこのルーターのインターフェイスのコレクションの中でこのインターフェイスを一意に識別する32ビットの番号。たとえば、実装によっては、MIB-II IfIndex（[Ref3]）を使用できる場合があります。
IPv6 prefixes The list of IPv6 prefixes to associate with the link. These will be advertised in intra-area-prefix-LSAs.
IPv6プレフィックスリンクに関連付けるIPv6プレフィックスのリスト。これらは、intra-area-prefix-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.
Interface output cost（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.
RxmtIntervalこのインターフェイスに属する隣接関係の、LSA再送信間の秒数。データベース記述およびリンク状態要求パケットを再送信するときにも使用されます。これは、接続されたリンク上の任意の2つのルーター間で予想される往復遅延を十分に超えるはずです。この値の設定は控えめにする必要があります。そうしないと、不必要な再送信が発生します。ローカルエリアネットワークのサンプル値：5秒。
InfTransDelay The estimated number of seconds it takes to transmit a Link State Update Packet over this interface. LSAs contained in the update packet must have their age incremented by this amount before transmission. This value should take into account the transmission and propagation delays of the interface. It must be greater than 0. Sample value for a local area network: 1 second.
InfTransDelayこのインターフェースを介してリンク状態更新パケットを送信するのにかかる推定秒数。更新パケットに含まれるLSAは、送信する前に、この期間だけエージを増加させる必要があります。この値は、インターフェースの送信および伝搬遅延を考慮に入れる必要があります。 0より大きい必要があります。ローカルエリアネットワークのサンプル値：1秒。
Router Priority An 8-bit unsigned integer. When two routers attached to a network both attempt to become 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 Designated Router on the attached link. Router Priority is only configured for interfaces to broadcast and NBMA networks.
ルーター優先順位8ビットの符号なし整数。ネットワークに接続されている2つのルーターが両方とも指定ルーターになろうとする場合、最も高いルーター優先度を持つルーターが優先されます。それでも同数の場合は、最も高いルーターIDを持つルーターが優先されます。ルーター優先度が0に設定されているルーターは、接続されたリンクで指定ルーターになる資格がありません。ルータプライオリティは、ブロードキャストおよびNBMAネットワークへのインターフェイスに対してのみ設定されます。
HelloInterval The length of time, in seconds, between the 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秒。ローカルエリアネットワーク（LAN）のサンプル値：10秒。
RouterDeadInterval After ceasing to hear a router's Hello Packets, the number of seconds before its neighbors declare the router down. This is also advertised in the router's Hello Packets in their RouterDeadInterval field. This should be some multiple of the HelloInterval (say 4). This value again must be the same for all routers attached to a common link.
RouterDeadIntervalルーターのHelloパケットが聞こえなくなった後、ネイバーがルーターのダウンを宣言するまでの秒数。これは、RouterDeadIntervalフィールドのルーターのHelloパケットでもアドバタイズされます。これは、HelloInterval（たとえば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 an unnumbered point-to-point link in the graph for the backbone. The virtual link must be configured in both of the area border routers.
仮想リンクは、バックボーンの接続を復元/増加するために使用されます。仮想リンクは、共通の（非バックボーン）エリアへのインターフェイスを持つエリアボーダールーターのペア間に構成できます。仮想リンクは、バックボーンのグラフに番号なしのポイントツーポイントリンクとして表示されます。仮想リンクは、両方のエリア境界ルーターで構成する必要があります。
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 Section C.3). Virtual links do not have link-local addresses, but instead use one of the router's global-scope or site-local IPv6 addresses as the IP source in OSPF protocol packets it sends along 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 intra-area path between the two endpoint routers. The parameter RxmtInterval must 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 large.
仮想リンクは、バックボーンへの別個のルーターインターフェイスであるかのように、ルーター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 through which the virtual link runs (referred to as the virtual link's Transit area). Virtual links cannot be configured through stub areas.
仮想リンクは、次の2つの構成可能なパラメーターによって定義されます。仮想リンクの他のエンドポイントのルーターID、および仮想リンクが実行される（非バックボーン）エリア（仮想リンクのトランジットエリアと呼ばれます）。仮想リンクはスタブエリアを介して設定できません。
OSPF treats an NBMA network much like it treats a broadcast network. Since there may be many routers attached to the network, a Designated Router is selected for the network. This Designated Router then originates a network-LSA, which lists 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 Designated Router (i.e., those router's 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 Designated Router must be defined. When an interface to a NBMA network comes up, the router sends Hello Packets only to those neighbors eligible to become Designated Router, until the identity of the Designated Router is discovered.
ただし、ブロードキャスト機能がないため、指定ルーターの選択で構成パラメーターを使用する必要がある場合があります。これらのパラメーターは、それ自体が指定ルーターになる資格のあるルーター（つまり、ネットワークのルーター優先度がゼロ以外のルーター）でのみ構成する必要があり、ネイバーを検出するための自動手順が存在しない場合のみ：他のすべての接続されたルーターNBMAネットワークに接続された他のすべてのルーターのリスト。各ルーターには、ルーターIDとネットワーク上のIPv6リンクローカルアドレスが設定されています。また、リストされた各ルーターについて、そのルーターが指定ルーターになる資格を定義する必要があります。 NBMAネットワークへのインターフェースがアップすると、ルーターは、指定ルーターのIDが検出されるまで、指定ルーターになる資格があるネイバーにのみ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.
PollInterval隣接ルーターが非アクティブになった場合（RouterDeadInterval秒の間、Helloパケットが検出されなかった場合）、引き続き、死んだ隣接ルーターにHelloパケットを送信する必要があります。これらのHelloパケットは、HelloIntervalよりも大幅に大きくなるはずのPollIntervalレートで送信されます。 PDN X.25ネットワークのサンプル値：2分。
On Point-to-MultiPoint networks, it may be necessary to configure the set of neighbors that are directly reachable over the Point-to-MultiPoint network. Each neighbor is configured with its Router ID and IPv6 link-local address on the network. Designated Routers are not elected on Point-to-MultiPoint networks, so the Designated Router eligibility of configured neighbors is undefined.
ポイントツーマルチポイントネットワークでは、ポイントツーマルチポイントネットワークを介して直接到達可能な一連のネイバーを構成する必要がある場合があります。各ネイバーは、ルーターIDとネットワーク上のIPv6リンクローカルアドレスで構成されます。指定ルーターはポイントツーマルチポイントネットワークでは選出されないため、構成されたネイバーの指定ルーターの適格性は定義されていません。
Host prefixes are advertised in intra-area-prefix-LSAs. They indicate either internal 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:
ホストプレフィックスは、intra-area-prefix-LSAでアドバタイズされます。これらは、内部ルーターアドレス、ポイントツーポイントネットワークへのルーターインターフェイス、ループルーターインターフェイス、またはルーターに直接接続されている（PPP接続などを介して）IPv6ホストのいずれかを示します。ルーターに直接接続されている各ホストに対して、次の項目を構成する必要があります。
Host IPv6 prefix The IPv6 prefix belonging to the host.
ホスト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).
ホストへのリンクのコストリンク状態メトリックの観点から、ホストにパケットを送信するコスト。ただし、ホストはおそらくインターネットへの接続が1つしかないため、実際に構成されたコストは多くの場合重要ではありません（つまり、ルーティングには影響しません）。
Area ID The OSPF area to which the host's prefix belongs.
Area OFホストのプレフィックスが属するOSPFエリア。
Security Considerations
セキュリティに関する考慮事項
When running over IPv6, OSPF relies on the IP Authentication Header (see [Ref19]) and the IP Encapsulating Security Payload (see [Ref20]) to ensure integrity and authentication/confidentiality of routing exchanges.
IPv6で実行する場合、OSPFはIP認証ヘッダー（[Ref19]を参照）およびIPカプセル化セキュリティペイロード（[Ref20]を参照）に依存して、ルーティング交換の整合性と認証/機密性を保証します。
Most OSPF implementations will be running on systems that support multiple protocols, many of them having independent security assumptions and domains. When IPSEC is used to protect OSPF packets, it is important for the implementation to check the IPSEC SA, and local SA database to make sure that the packet originates from a source THAT IS TRUSTED FOR OSPF PURPOSES.
ほとんどのOSPF実装は、複数のプロトコルをサポートするシステムで実行されます。それらのプロトコルの多くは、独立したセキュリティの前提とドメインを持っています。 OSPFパケットを保護するためにIPSECを使用する場合、実装がIPSEC SAおよびローカルSAデータベースをチェックして、パケットがOSPF目的で信頼されているソースから発信されていることを確認することが重要です。
Authors' Addresses
著者のアドレス
Rob Coltun Siara Systems 300 Ferguson Drive Mountain View, CA 94043
Rob Coltun Siara Systems 300ファーガソンドライブマウンテンビュー、CA 94043
Phone: (650) 390-9030 EMail: rcoltun@siara.com
電話：（650）390-9030メール：rcoltun@siara.com
Dennis Ferguson Juniper Networks 385 Ravendale Drive Mountain View, CA 94043
Dennis Ferguson Juniper Networks 385 Ravendale Drive Mountain View、CA 94043
Phone: +1 650 526 8004
EMail: dennis@juniper.com
John Moy Sycamore Networks, Inc. 10 Elizabeth Drive Chelmsford, MA 01824
John Moy Sycamore Networks、Inc. 10 Elizabeth Drive Chelmsford、MA 01824
Phone: (978) 367-2161 Fax: (978) 250-3350 EMail: jmoy@sycamorenet.com
電話：（978）367-2161ファックス：（978）250-3350メール：jmoy@sycamorenet.com
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（C）The Internet Society（1999）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントとその翻訳はコピーして他のユーザーに提供することができ、コメントまたはその他の方法で説明したり、その実装を支援する二次的著作物は、いかなる種類の制限なしに、全体または一部を準備、コピー、公開、および配布することができます。 、ただし、上記の著作権表示とこの段落は、そのようなすべてのコピーと派生物に含まれています。ただし、このドキュメント自体は、著作権に関する通知を削除したり、インターネットソサエティや他のインターネット組織への参照を削除したりするなど、いかなる方法でも変更できません。ただし、インターネット標準を開発する目的で必要な場合は除きます。インターネット標準のプロセスに従うか、または必要に応じて、それを英語以外の言語に翻訳する必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記で付与された制限付きのアクセス許可は永続的であり、インターネットソサエティまたはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能への資金提供は、現在Internet Societyから提供されています。