RFC2740 日本語訳
2740 OSPF for IPv6. R. Coltun, D. Ferguson, J. Moy. December 1999. (Format: TXT=189810 bytes) (Obsoleted by RFC5340) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group R. Coltun
Requests for Comments: 2740 Siara Systems
Category: Standards Track D. Ferguson
Juniper Networks
J. Moy
Sycamore Networks
December 1999
コメントを求めるワーキンググループR.Coltun要求をネットワークでつないでください: 2740年のSiaraシステムカテゴリ: J.Moyアメリカスズカケノキが1999年12月にネットワークでつなぐ標準化過程D.ファーガソン杜松ネットワーク
OSPF for IPv6
IPv6のためのOSPF
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
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.
IPv4のためのOSPFとこのドキュメントの間の変化は以下を含んでいます。 意味論を扱って、OSPFパケットと基本的なLSAsから取り除いてください、そうした。 新しいLSAsは、IPv6アドレスと接頭語を運ぶために作成されました。 OSPFは現在、aの代わりにIPサブネット単位で1リンクあたり1つの基礎で動きます。基礎。 LSAsのための氾濫範囲は一般化されました。 代わりにIPv6のAuthentication HeaderとEncapsulating Security有効搭載量を当てにして、OSPFプロトコル自体から認証を取り除きました。
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.
IPv4に、IPv6のためのOSPFのほとんどのパケットがOSPFのそれらとほとんど同じくらいコンパクトです、より大きいIPv6アドレスがあっても。 IPv4のためのOSPFの現在のほとんどの分野-XSandパケットサイズ制限が緩和されました。 さらに、オプション取り扱いをよりフレキシブルにしました。
Coltun, et al. Standards Track [Page 1] RFC 2740 OSPF for IPv6 December 1999
Coltun、他 IPv6 December 1999のための標準化過程[1ページ]RFC2740OSPF
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.
また、要求次第の回路サポート、NSSA領域を含むIPv4の任意の能力のためのOSPFと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
1つの序論… 4 1.1用語… IPv4のためのOSPFからの4 2の違い… 4 2.1 サブネットではなく、処理リンクについて議定書の中で述べてください… 5 2.2 アドレシング意味論の取り外し… 5 Flooding範囲の2.3追加… 5 2.4 複数の1リンクあたりのインスタンスの明白なサポート… 6 2.5 リンクローカルのアドレスの使用… 6 2.6 認証は変化します… 7 2.7 パケット・フォーマットは変化します… 7 2.8 LSA形式は変化します… 8 2.9 取り扱いの未知のLSAはタイプします… 10 2.10 領域サポートを引き抜いてください… 10 2.11 Router IDのそばで隣人を特定します… 11 3 実装の詳細… 11 3.1 データ構造について議定書の中で述べてください… 12 3.1 .1 Area Data構造… 13 3.1 .2 Interface Data構造… 13 3.1 .3 隣人データ構造… 14 3.2 パケット処理について議定書の中で述べてください… 15 3.2 .1 プロトコルパケットを送ります… 15 3.2 .1 .1 パケットをHelloに送ります… 16 3.2 .1 .2 データベース記述パケットを送ります… 17 3.2 .2 プロトコルパケットを受けます… 17 3.2 .2.1受信、こんにちは、パケット… 19 3.3 ルート設定テーブルStructure… 19 3.3 .1 索表を発送します… 20 3.4 州の広告をリンクしてください… 20 3.4 .1 LSAヘッダー… 21 3.4 .2 リンク州のデータベース… 22 3.4 .3 LSAsを溯源します… 22 3.4 .3 .1ルータ-LSAs… 25 3.4 .3 .2ネットワーク-LSAs… 27 3.4 .3 .3 相互領域接頭語LSAs… 28 3.4 .3 .4 相互領域ルータLSAs… 29 3.4 .3 .5 外部のLSAsとして… 29 3.4 .3 .6リンク-LSAs… 31 3.4 .3 .7 イントラ領域接頭語LSAs… 32 3.5 氾濫… 35 3.5 .1 Link州Updateパケットを受けます… 36 3.5 .2 州UpdateパケットをLinkに送ります… 36 3.5 .3 LSAsをデータベースにインストールします… 38
Coltun, et al. Standards Track [Page 2] RFC 2740 OSPF for IPv6 December 1999
Coltun、他 IPv6 December 1999のための標準化過程[2ページ]RFC2740OSPF
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
3.6 自己によって溯源されたLSAsの定義… 39 3.7 仮想のリンク… 39 3.8 経路指定テーブル計算… 39 3.8 .1 最短パス木について領域に計算します… 40 3.8 .1 .1 次のホップ計算… 41 3.8 .2 相互領域ルートを計算します… 42 3.8 .3 トランジット領域の概要-LSAsを調べます… 42 3.8 .4 計算のAS外部経路… 42 3.9 シングルへの複数のインタフェースがリンクされます… 43の参照箇所… 44 OSPFデータ形式… 46 OSPFパケットのA.1カプセル化… A.2Optionsがさばく46… 47 A.3 OSPFパケット・フォーマット… 48 OSPFパケットのヘッダーのA.3.1… 49A.3.2、Helloパケット… 50A.3.3、Database記述パケット… 52A.3.4、Link州Requestパケット… 54A.3.5、Link州Updateパケット… 55A.3.6、Link州Acknowledgmentパケット… 56 A.4 LSA形式… 57 A.4.1 IPv6は表現を前に置きます… 58 A.4.1.1はオプションを前に置きます… 58 LSAヘッダーのA.4.2… 59 A.4.2.1LSはタイプします… 60 A.4.3ルータ-LSAs… 61 A.4.4ネットワーク-LSAs… 64 A.4.5相互領域接頭語LSAs… 65 A.4.6相互領域ルータLSAs… 66A.4.7、外部のLSAsとして… 67 A.4.8リンク-LSAs… 69 A.4.9イントラ領域接頭語LSAs… 71 B建築定数… 73 Cの構成可能な定数… 73 C.1のグローバルなパラメタ… 73 C.2領域パラメタ… 74 C.3ルータインタフェース・パラメータ… 75 C.4の仮想のリンクパラメータ… 77 C.5 NBMAはパラメタをネットワークでつなぎます… 77 C.6のポイントからMultiPointはパラメタをネットワークでつなぎます… 78 C.7はルートパラメタをホスティングします… 78 セキュリティ問題… 79人の作者のアドレス… 79 完全な著作権宣言文… 80
Coltun, et al. Standards Track [Page 3] RFC 2740 OSPF for IPv6 December 1999
Coltun、他 IPv6 December 1999のための標準化過程[3ページ]RFC2740OSPF
1. Introduction
1. 序論
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は詳細にIPv4のためのOSPFとIPv6のためのOSPFの違いについて説明します。 セクション3は変化のための実装詳細を明らかにします。 付録AはIPv6パケットとLSA形式のためにOSPFに与えます。 付録BはOSPFの建築定数を記載します。 付録Cは設定パラメータについて説明します。
1.1. Terminology
1.1. 用語
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).
このドキュメントは、IPv4仕様のためのOSPF([Ref1])とIPv6プロトコル仕様([Ref14])の両方からの用語を使用するのを試みます。 これは複雑な結果を生みました。 OSPFとIPv6によって使用された用語の大部分には、およそ同じ意味(例えば、インタフェース)があります。 しかしながら、いくつかの闘争があります。 IPv6用途は同様にIPv4 OSPFの「サブネット」か「ネットワーク」に「リンクされます」。 この場合、私たちは、IPv6の「リンク」用語を使用するのを選びました。 「リンク」はほとんどの場所で本書ではOSPFの「サブネット」と「ネットワーク」を取り替えます、OSPFのNetwork-LSAは変わりがありませんが(また、ことによると残念ながら、新しいLink-LSAは作成されました)。
The names of some of the OSPF LSAs have also changed. See Section 2.8 for details.
また、いくつかのOSPF LSAsという名前は変化しました。 詳細に関してセクション2.8を見てください。
2. Differences from OSPF for IPv4
2. IPv4のためのOSPFからの違い
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.
IPv4[Ref1]のためのOSPFからのアルゴリズムの大部分はIPv6のためにOSPFに保存しました。 しかしながら、いくつかの変化が必要です、IPv4とIPv6の間のプロトコル意味論における変化か単にのどちらかIPv6の増強されたアドレスサイズのハンドルに。
The following subsections describe the differences between this document and [Ref1].
以下の小区分はこのドキュメントと[Ref1]の違いについて説明します。
Coltun, et al. Standards Track [Page 4] RFC 2740 OSPF for IPv6 December 1999
Coltun、他 IPv6 December 1999のための標準化過程[4ページ]RFC2740OSPF
2.1. Protocol processing per-link, not per-subnet
2.1. サブネットではなく、プロトコル処理リンク
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])を示すのに「リンク」という用語を使用します。 「インタフェース」はリンクに接続します。 複数のIPサブネットを単一のリンクに割り当てることができます、そして、2つのノードが直接単一のリンクについて論議できます、一般的なIPサブネット(IPv6接頭語)を共有しないでも。
For this reason, OSPF for IPv6 runs per-link instead of the IPv4 behavior of per-IP-subnet. The terms "network" and "subnet" used in the IPv4 OSPF specification ([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 PacketsとNetwork-LSAsのコンテンツに影響します。
2.2. Removal of addressing semantics
2.2. アドレシング意味論の取り外し
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:
IPv6のためのOSPFでは、意味論を扱って、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 Link州Update Packetsによって運ばれたLSAペイロード以外に、IPv6 Addressesは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 ルータ-LSAsとNetwork-LSAsはもうネットワーク・アドレスを含んでいるのではなく、単に速達のトポロジー情報を含んでいます。 詳細に関してセクション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 Router ID、Area ID、およびLSA Link州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 隣接しているルータは現在、いつもRouter IDによって特定されます。以前に、そこでは、それらが放送に関するIPアドレスとNBMA「ネットワーク」によって特定されていました。
2.3. Addition of Flooding scope
2.3. Flooding範囲の追加
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:
LSAsのための氾濫範囲は、一般化されて、現在、LSAのLSタイプ分野で明らかにコード化されます。 現在、別々の氾濫がLSAsに関して見る3があります:
Coltun, et al. Standards Track [Page 5] RFC 2740 OSPF for IPv6 December 1999
Coltun、他 IPv6 December 1999のための標準化過程[5ページ]RFC2740OSPF
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).
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領域だけ中で水につかっています。 ルータ-LSAs、ネットワーク-LSAs、相互領域接頭語-LSAs、相互領域ルータLSAs、およびイントラ領域接頭語LSAsにおいて、使用されています。
o AS scope. LSA is flooded throughout the routing domain. Used
for AS-external-LSAs.
o AS範囲。 LSAは経路ドメイン中で水につかっています。 外部のLSAsとして、使用されています。
2.4. Explicit support for multiple instances per link
2.4. 複数の1リンクあたりのインスタンスの明白なサポート
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経路ドメインであるかもしれません。 IPv4のためのOSPFでは、これは、IPv4ヘッダーにOSPFの認証分野を使用しながら、行き当たりばったりのやり方でサポートされました。
Another use for running multiple OSPF instances is if you want, for one reason or another, to have a single link belong to two or more OSPF areas.
複数の実行しているOSPFインスタンスの別の使用はあなたが単一のリンクに何らかの理由のために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インタフェース構造に含まれた「Instance ID」を通して実行されます。 インスタンスIDは唯一OSPFパケットのレセプションに影響します。
2.5. Use of link-local addresses
2.5. リンクローカルのアドレスの使用
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ルータはリンク地元筋アドレス[Ref15]を持っているデータグラムをIPv6に送りません。 リンクローカルのユニキャストアドレスは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.
IPv6のためのOSPFは、各ルータはそれぞれのルータの付属物理的なセグメントにリンクローカルのユニキャストアドレスを割り当ててあると仮定します。 仮想のリンク以外のすべてのOSPFインタフェースに、ソースとしてインタフェースの関連リンクローカルのユニキャストアドレスをOSPFパケットを使用させます。 ルータは、リンクに付けられた他のすべてのルータのリンクローカルのアドレスを学んで、パケット推進の間、次のホップ情報としてこれらのアドレスを使用します。
On virtual links, global scope or site-local IP addresses must be used as the source for OSPF protocol packets.
仮想のリンクの上では、OSPFプロトコルパケットにソースとしてグローバルな範囲かサイトローカルアイピーアドレスを使用しなければなりません。
Coltun, et al. Standards Track [Page 6] RFC 2740 OSPF for IPv6 December 1999
Coltun、他 IPv6 December 1999のための標準化過程[6ページ]RFC2740OSPF
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).
セクション3.4を見てください。リンクローカルのアドレスがOSPF Link-LSAsに現れる、(.3 .6)。 しかしながら、リンクローカルのアドレスは他のOSPF LSAタイプで許容されていません。 特に、相互領域がLSAsを前に置いた状態で中にリンクローカルのアドレスの広告を出してはいけない、(セクション3.4.3、.3、)ASの外部のLSAs、(セクション3.4.3、.5)、イントラ領域がLSAsを前に置く、(セクション3.4 .3 .7)。
2.6. Authentication changes
2.6. 認証変化
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.
IPv6のためのOSPFでは、OSPF自身から認証を取り除きました。 OSPFパケットのヘッダーから"AuType"と「認証」野原を取り除きました、そして、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 Authentication Header([Ref19]を見る)とIP Encapsulating Security有効搭載量([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).
標準のIPv6 16ビットの1の補数チェックサムで偶然のデータの汚染に対するOSPFパケット交換の保護を提供します、全体のOSPFパケットとprepended IPv6疑似ヘッダーをカバーしていて(セクションA.3.1を見てください)。
2.7. Packet format changes
2.7. パケット・フォーマット変化
OSPF for IPv6 runs directly over IPv6. Aside from this, all addressing semantics have been removed from the OSPF packet headers, making it essentially "network-protocol-independent". All addressing information is now contained in the various LSA types only.
IPv6のためのOSPFは直接IPv6をひきます。 これは別として、意味論をすべて扱って、それを本質的には「ネットワークプロトコル独立者」にして、OSPFパケットのヘッダーから取り除いてください、そうした。 すべてのアドレス指定情報が現在、様々なLSAタイプだけで含まれています。
In detail, changes in OSPF packet format consist of the following:
詳細に、OSPFパケット・フォーマットにおける変化は以下から成ります:
o The OSPF version number has been 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 PacketsのOptions分野とDatabase記述Packetは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パケットは、唯一インタフェースをリンクまで特定する(それ自身のインタフェースの中で)ために、現在アドレス情報を全く含まないで、起因するルータが割り当てたInterface IDを含んでいます。 ルータがリンクでDesignated-ルータになるなら、このInterface IDはNetowrk-LSAのLink州IDになります。
Coltun, et al. Standards Track [Page 7] RFC 2740 OSPF for IPv6 December 1999
Coltun、他 IPv6 December 1999のための標準化過程[7ページ]RFC2740OSPF
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 「R-ビット」と「V6-ビット」という2オプションビットは、処理Router-LSAsのためにSPF計算の間、Options分野に加えられます(セクションA.2を見てください)。 「R-ビット」が明確であるなら、トランジットトラフィックを進めるのに使用されないで、OSPFスピーカーはOSPFトポロジー分配に参加できます。 これを使用できる、マルチ、家へ帰り、ルーティングに参加したがっているホストが議定書を作ります。 V6-ビットはR-ビットを専門にします。 V6-ビットが明確であるなら、データグラムをIPv6に送るのに使用されないで、OSPFスピーカーは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 TheOSPFパケットのヘッダーは現在、複数のOSPFプロトコルインスタンスが単一のリンクに実行されるのを許容する「Instance ID」を入れます(セクション2.4を見てください)。
2.8. LSA format changes
2.8. LSA形式変化
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ヘッダーと、Router-LSAsとNetwork-LSAsからすべてのアドレシング意味論を取り除きました。 これらの2LSAsが現在、ネットワークプロトコル独立者方法で経路ドメインのトポロジーについて説明します。 新しいLSAsはIPv6アドレス情報を分配するために付記されました、そして、データが次のホップ解決に必要です。 互いと、より一致しているように、IPv4のいくつかのLSAsという名前を変えました。
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 Options野原は、LSAヘッダーから移されて、24ビットに膨張して、Router-LSAs、Network-LSAs、Inter領域ルータLSAs、およびLink-LSAsのボディーに動かされました。 詳細に関してセクション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 Type分野を16ビットに広げてあります(前のOptionsスペースに)、上側の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 LSAsのアドレスは現在、[アドレス、マスク]の代わりに[接頭語、接頭語の長さ]として表されます(セクションA.4.1を見てください)。 デフォルトルートは接頭語として長さ0で急送されます。
o The Router and Network LSAs now have no address information, and
are network-protocol-independent.
o RouterとNetwork LSAsは現在アドレス情報を全く持たないで、ネットワークプロトコル独立者です。
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 ルータインターフェース情報は複数のRouter LSAsの向こう側に広げられるかもしれません。 受信機はSPF計算を実行するとき与えられたルータによって溯源されたすべてのRouter-LSAsを連結しなければなりません。
Coltun, et al. Standards Track [Page 8] RFC 2740 OSPF for IPv6 December 1999
Coltun、他 IPv6 December 1999のための標準化過程[8ページ]RFC2740OSPF
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を導入しました。 LSAsには、地方のリンク氾濫範囲があります。 それらはそれらが関連しているリンクを超えて決して水につかっていません。 リンク-LSAsには、3つの目的があります: 1) 彼らはリンクに付けられた他のすべてのルータ、リンクに溯源されるNetwork-LSAと交際するためにOptionsビットの収集について断言できる彼らがリンクと3に関連づけるIPv6接頭語のリストのリンクに付けられた他のルータ) それらにルータを知らせる2に)ルータのリンクローカルアドレスを提供します。 詳細に関してセクション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ルーティング計算の間次のホップについて計算するときだけ、これらが使用されるので(.1セクション16.1[Ref1]を見てください)、地方のリンクで水につかる必要はありません。 したがって、これらのアドレスを配布するのにリンク-LSAsを使用するのは、より効率的です。 すべての場合における、ハローズの受付でリンクローカルのアドレスについて学習できないことに注意してください: NBMAリンクには、次のホップルータは必ずこんにちはの挨拶を交わすというわけではありませんが、Designated Routerを通してむしろ互いの存在を知ってください。
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 Network LSAのOptions分野はリンクの上の各ルータがLink- LSAに広告を出すOptionsの論理的な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概要-LSAsが「相互領域接頭語LSAs」に改名されました。 タイプ-4概要LSAsは「相互領域ルータLSAs」に改名されました。
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領域接頭語LSAs、Inter-領域ルータ-LSAs、およびASの外部のLSAsのLink州IDは、意味論を扱うのを失って、現在、唯一Link州Databaseの個体を特定するのに役立ちます。 以前Link州IDによって表されたすべてのアドレスかRouter 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 ネットワーク-LSAsとLink-LSAsはLink州IDが追加意味を運ぶ唯一のLSAsです。 これらのLSAsに関しては、いつもLink州IDは説明されるリンクの上の起因するルータのInterface IDです。 この理由で、現在、Network-LSAsとLink-LSAsはサイズを制限できない唯一のLSAsです: Network-LSAはリンクに接続されたすべてのルータを記載しなければなりません、そして、Link-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領域接頭語LSAと呼ばれる新しいLSAを導入しました。 このLSAはRouter-LSAsとNetwork-LSAsにIPv4に含まれているすべてのIPv6接頭語情報を運びます。 詳細に関してセクションA.4.9を見てください。
Coltun, et al. Standards Track [Page 9] RFC 2740 OSPF for IPv6 December 1999
Coltun、他 IPv6 December 1999のための標準化過程[9ページ]RFC2740OSPF
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の外部のLSAsでのフォーワーディング・アドレスの包含は現在任意です、外部経路タグの包含のように([Ref5]を見てください)。 さらに、ASの外部のLSAsは現在別のLSAに参照をつけることができます、OSPFプロトコル自体の範囲の外にある追加ルート属性の包含のために。 例えば、[Ref10]で提案されるようにBGP経路属性を外部経路に付けるのにこれを使用できます。
2.9. Handling unknown LSA types
2.9. 取り扱いの未知のLSAはタイプします。
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タイプに基づいてリンク地方の氾濫範囲を持っているとして扱われるか、保存されて、またはあふれる([Ref10]の提案されたExternal属性-LSAのようなものに、望ましい)ように、未知のLSAタイプの取り扱いをよりフレキシブルにしました。 この振舞いはリンク州のヘッダーのLSタイプ分野のLSA Handlingビットで明らかにコード化されます(セクション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の振舞いはルータ能力を単一のリンクに混ぜる願望のためにサポートされないです。 Designated Routerがリンクの上に他のルータより少ないオプションをサポートすると、未知のタイプを捨てるのは問題を起こします。
2.10. Stub area support
2.10. スタッブ領域サポート
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.
IPv4のためのOSPFでは、スタッブ領域は、領域の内部のルータのためにリンク州のデータベースと経路指定テーブルサイズを最小にするように設計されました。 これで、最小量のリソースがあるルータは非常に大きい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.
IPv6のためのOSPFでは、スタッブ領域の概念は保有されます。 IPv6では、義務的なLSAタイプでは、スタッブ領域はルータ-LSAs、ネットワークLSAs、Inter領域接頭語LSAs、Link-LSAs、およびIntra領域接頭語LSAsだけを運びます。 これはIPv4スタッブ領域で運ばれたLSAタイプのIPv6同等物です: ルータ-LSAs、ネットワーク-LSAs、およびタイプ3概要-LSAs。
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タイプがあるLSAsがラベルされるのをどのように許容しても「まるでタイプが分かるかのように、LSAを保存して、あふれさせてください。」(セクションA.4.2.1のU-ビットを見てください) そのようなLSAsの非制御の導入によって、スタッブ領域のリンク州のデータベースはコンポーネントルータの能力より大きくなることができました。
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.
これに用心するために、スタッブ領域に関する以下の規則は確立されました: 範囲をあふれさせるLSAが領域かリンク地方にするa)とbの両方) LSAがU-ビットを0に設定させる場合にだけ、LSタイプが認識されていないLSAはスタッブ領域中に/へあふれるかもしれません。 詳細に関してセクション3.5を見てください。
Coltun, et al. Standards Track [Page 10] RFC 2740 OSPF for IPv6 December 1999
Coltun、他 IPv6 December 1999のための標準化過程[10ページ]RFC2740OSPF
2.11. Identifying neighbors by Router ID
2.11. Router IDのそばで隣人を特定します。
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.
IPv6のためのOSPFでは、与えられたリンクの上の隣接しているルータはいつもそれらのOSPF Router IDによって特定されます。 二地点間ネットワークと仮想のリンクの上の隣人がそれらのRouter IDによって特定されるところでこれはIPv4の振舞いとひどく違います、そして、放送での隣人、NBMA、およびPointからMultiPointへのリンクはそれらの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 Packetsのレセプション([Ref1]のセクション10.5)に影響します。
The Router ID of 0.0.0.0 is reserved, and should not be used.
Router ID、0.0 .0 .0を予約されていて、使用するべきではありません。
3. Implementation details
3. 実装の詳細
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の両方が、リンク州のデータベースがLSAsで構成されて、隣接しているルータの間で同期するのをさせます。 初並列はDatabase Exchangeプロセス、Database記述、Link州Request、およびLink州Updateパケットの交換を通して実行されます。 その後、Link州UpdateとLink州Acknowledgmentパケットを利用して、データベース同期は氾濫を通して維持されます。 IPv6とIPv4の両方が、隣人関係を発見して、維持して、放送でのDesignated RoutersとBackup Designated RoutersとNBMAをリンクに選出するのにOSPF Hello Packetsを使用します。 関係は隣接番組になります、相互領域ルーティングの後ろの基本的な考え方と共にどの隣人に関して決定、また、ASの外部のLSAsの外部の情報をインポートして、様々なルーティング計算も同じであるか。
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とOSPFパケットタイプが[Ref1]のセクション4.3で説明したIPv6使用の両方、: こんにちは、Database記述、Link州Request、Link州Update、およびLink州Acknowledgmentパケット。 いくつかにある間、それらの形式がいくらか変えたケース(例えば、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ネットワーク層をひくので、IPv6のためのOSPFはIPv6プロトコル・スタック(ネットワーク層以下の)を必要としますが。
Coltun, et al. Standards Track [Page 11] RFC 2740 OSPF for IPv6 December 1999
Coltun、他 IPv6 December 1999のための標準化過程[11ページ]RFC2740OSPF
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リンクにおけるDesignated RouterとBackup Designated Routerの選挙を含んでいます。 これらのメカニズムは[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、PointからMultiPoint、および仮想のリンク。
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界面準位とイベントのリスト、Designated Router、およびBackup Designated Router選挙アルゴリズムを含む界面準位マシンは変わりがありません。 これらは[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 経路ドメインから時期尚早な古いプロセスまでLSAsを洗い流すことと同様に、リンク州のデータベースの年をとることは[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].
しかしながら、いくつかのOSPFプロトコルメカニズムが上のセクション2に概説されているように変化しました。 [Ref1]の相当区について言及して、これらの変化は以下の小区分で詳細に説明されます。
The following subsections provide a recipe for turning an IPv4 OSPF implementation into an IPv6 OSPF implementation.
以下の小区分はIPv4 OSPF実装をIPv6 OSPF実装に変えるためのレシピを提供します。
3.1. Protocol data structures
3.1. プロトコルデータ構造
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:
IPv4とIPv6の両方に、主要なOSPFデータ構造は同じです: 領域、インタフェース、隣人、リンク州のデータベース、および経路指定テーブル。 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氾濫範囲があるすべてのLSAsがトップレベルデータ構造に現れます、特定の領域かリンクに属すことの代わりに。 ASの外部のLSAsはこの仕様で定義された唯一のLSAsです(AS氾濫範囲を持っています)。 未知のLSとLSAsはタイプします、また、1(認識されていないときにさえ、浸水する)に設定されたU-ビットとAS氾濫範囲はトップレベルデータ構造に現れます。
Coltun, et al. Standards Track [Page 12] RFC 2740 OSPF for IPv6 December 1999
Coltun、他 IPv6 December 1999のための標準化過程[12ページ]RFC2740OSPF
3.1.1. The Area Data structure
3.1.1. Area Data構造
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領域と定義されたすべての要素を含んでいます。 さらに、領域の氾濫範囲を持っている知られているタイプのすべてのLSAsがIPv6領域データ構造に含まれています。 これはいつも以下のLSAタイプを含んでいます: ルータ-LSAs、ネットワーク-LSAs、相互領域がLSAsを前に置く、相互領域ルータLSAs、そして、イントラ領域はLSAsを前に置きます。 未知のLSとLSAsはタイプします、また、1(認識されていないときにさえ、浸水する)に設定されたU-ビットと領域の範囲は領域データ構造に現れます。 MOSPFを実装するIPv6ルータがグループ会員資格-LSAsを領域データ構造に追加します。 タイプ-7-LSAsはNSSA領域のデータ構造に属します。
3.1.2. The Interface Data structure
3.1.2. Interface Data構造
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:
IPv6のためのOSPFでは、インタフェースはルータをリンクに接続します。 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.
Interface IDはインタフェースID Everyインタフェースに割り当てられます。(唯一、それは、インタフェースをルータと同一視します)。 例えば、いくつかの実装がInterface IDとしてMIB-II IfIndex([Ref3])を使用できるかもしれません。 Interface IDはインタフェースから送られたHelloパケットに現れました、そして、地方のLSAをリンクしているのはルータで付属リンクに起因しました、そして、ルータ-LSAはルータ-LSAで関連領域に起因しました。 また、それはルータが選出されるならルータがリンクに溯源するネットワーク-LSA Designated RouterのためのLink州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.
Instance IDはインスタンスID Everyインタフェースに割り当てられます。 これが、0をデフォルトとするべきであり、単にOSPF Routersの複数の別々の共同体を含むそれらのリンクに異なって割り当てるのに必要です。 例えば、ルータの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.
0のInstance IDを最初の共同体に与えます、ルータのインタフェースのInstance IDとして0をイーサネットに割り当てることによって。 1のInstance 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.
どれがリンクの上にリンク地方の範囲があるリンク地方の範囲All LSAsとLSAsのリスト、溯源されたか、またはあふれたかがリンクに接続するインタフェース構造に属します。 これはリンクのリンク-LSAsの収集を含んでいます。
Coltun, et al. Standards Track [Page 13] RFC 2740 OSPF for IPv6 December 1999
Coltun、他 IPv6 December 1999のための標準化過程[13ページ]RFC2740OSPF
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とAll LSAsがタイプして、U-ビットが0(認識されていないなら、まるでリンク地方の氾濫範囲を持っているかのようにLSAを扱う)に設定した未知のLSタイプがあるLSAsのリストはデータ構造で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インターフェース・アドレスFor IPv6、ほとんどいつもインタフェースから送られたOSPFパケットの源に載っているIPv6アドレスはリンクローカルアドレスです。 仮想のリンクには1つの例外があります。(リンクはIPインターフェース・アドレスとしてルータの自己のサイト地方の、または、グローバルなIPv6アドレスの1つを使用しなければなりません)。
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.
接頭語Aが記載するIPv6接頭語のリンクのリストを付属リンクに構成できます。 リンク-LSAsにルータでこれらの広告を出すでしょう、リンクのDesignated Routerがイントラ領域接頭語-LSAsの彼らを広告に掲載できるように。
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.
IPv6のためのOSPFでは、それぞれのルータインタフェースで、インタフェースから送付パケットの費用を表して、シングルはメートル法になります。 さらに、IPv6のためのOSPFは、ルーティング交換の保全と認証/秘密性を確実にするために、IP Authentication Header([Ref19]を見る)とIP Encapsulating Security有効搭載量([Ref20]を見る)を当てにします。 その理由で、AuTypeとAuthenticationキーは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にそれぞれ記録されます。 また選挙アルゴリズムはセクション9.4でIPv4選挙から変わりがないDesignated RouterとBackup Designated Router[Ref1]。
3.1.3. The Neighbor Data Structure
3.1.3. 隣人データ構造
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インタフェースに縛られます。 構造がIPv4のために[Ref1]のセクション10で定義したIPv6隣人構造と隣人の違いは以下の通りです。
Neighbor's Interface ID
The Interface ID that the neighbor advertises in its Hello Packets
must be recorded in the neighbor structure. The router will
include the neighbor's Interface ID in the router's router-LSA
when either a) advertising a point-to-point link to the neighbor
or b) advertising a link to a network where the neighbor has
become Designated Router.
隣人がHello Packetsに広告を出す隣人のInterface ID Interface IDを隣人構造に記録しなければなりません。 a) 隣人にポイントツーポイント接続の広告を出すか、b)のどちらかであるときに、ルータは、隣人がDesignated Routerになったネットワークへのリンクの広告を出しながら、ルータのルータ-LSAに隣人のInterface IDを含むでしょう。
Coltun, et al. Standards Track [Page 14] RFC 2740 OSPF for IPv6 December 1999
Coltun、他 IPv6 December 1999のための標準化過程[14ページ]RFC2740OSPF
Neighbor IP address
Except on virtual links, the neighbor's IP address will be an IPv6
link-local address.
隣人IPは仮想のリンクの上のExceptを扱って、隣人の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.
隣人のDesignated Router、隣人のDesignated Routerの選択は現在Router IDとしてコード化されます、IPアドレスの代わりに。
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.
隣人のBackup Designated Router、隣人のDesignated Routerの選択は現在Router IDとしてコード化されます、IPアドレスの代わりに。
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論理から変わりがありません。
3.2. Protocol Packet Processing
3.2. プロトコルパケット処理
OSPF for IPv6 runs directly over IPv6's network layer. As such, it is encapsulated in one or more IPv6 headers, with the Next Header field of the immediately encapsulating IPv6 header set to the value 89.
IPv6のためのOSPFは直接IPv6のネットワーク層をひきます。 そういうものとして、それは1個以上のIPv6ヘッダーでカプセル化されます、値89に用意ができているすぐに要約のIPv6ヘッダーのNext Header分野で。
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ルーティング・プロトコルでは、隣接番組だけに沿ってパケットを送ります。 OSPFパケットタイプと機能はコード化されたIPv4とIPv4の両方で同じです。
Type field of the standard OSPF packet header.
標準のOSPFパケットのヘッダーの分野をタイプしてください。
3.2.1. Sending protocol packets
3.2.1. 送付プロトコルパケット
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ルーティング・プロトコルパケットを送るとき、以下のIPv6パケットのヘッダー(セクションA.3.1を見る)のために標準のOSPFの分野に記入します:
Version #
Set to 3, the version number of the protocol as documented in this
specification.
3へのバージョン#Set、記録されるとしてのこの仕様によるプロトコルのバージョン番号。
Type
The type of OSPF packet, such as Link state Update or Hello
Packet.
Link州のUpdateかHello PacketなどのOSPFパケットのタイプをタイプしてください。
Packet length
The length of the entire OSPF packet in bytes, including the
standard OSPF packet header.
パケット長は標準のOSPFパケットのヘッダーを含むバイトで表現される全体のOSPFパケットの長さです。
Coltun, et al. Standards Track [Page 15] RFC 2740 OSPF for IPv6 December 1999
Coltun、他 IPv6 December 1999のための標準化過程[15ページ]RFC2740OSPF
Router ID
The identity of the router itself (who is originating the packet).
ルータID、ルータ(パケットを溯源している)自体のアイデンティティ。
Area ID
The OSPF area that the packet is being sent into.
領域ID、パケットが送られるOSPF領域。
Instance ID
The OSPF Instance ID associated with the interface that the packet
is being sent out of.
インスタンスID OSPF Instance 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).
チェックサム、全体のOSPFパケットとprepended IPv6疑似ヘッダー(セクションA.3.1を見る)をカバーする標準のIPv6 16ビットの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、および隣接番組(仮想のリンク以外のすべてのリンクへのIPv6のIPv6リンクローカルアドレスである)のもう一方の端に関連しているNeighbor IPアドレスから選ばれています。
The sending of Link State Request Packets and Link State Acknowledgment Packets remains unchanged from the IPv4 procedures documented in Sections 10.9 and 13.5 of [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.
Link州Request PacketsとLink州Acknowledgment Packetsの発信は[Ref1]のセクション10.9と13.5にそれぞれ記録されたIPv4手順から変わりがありません。 Hello Packetsを送って、記録されたコネセクション3.2.1は、.1と、Database記述Packetsコネセクション3.2.1.2の発信ですか? Link州Update Packetsの発信はセクション3.5.2に記録されます。
3.2.1.1. Sending Hello packets
3.2.1.1. 送付Helloパケット
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 Packetを出す前に、インタフェースであり、インタフェースのInterface IDをHello Packetにコピーしなければなりません。
o The Hello Packet no longer contains an IP network mask, as OSPF
for IPv6 runs per-link instead of per-subnet.
o IPv6のためのOSPFがサブネットの代わりにリンクを動かすとき、Hello Packetはもう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 Designated RouterとBackup Designated Routerの選択は現在ハローズの中にそれらのRouter IDによって示されます、それらのIPインターフェース・アドレスの代わりに。 Designated Router(または、Backup Designated Router)の広告を出す、0.0 .0 .0 Designated Router(または、Backup Designated Router)がまだ選ばれていないのを示します。
Coltun, et al. Standards Track [Page 16] RFC 2740 OSPF for IPv6 December 1999
Coltun、他 IPv6 December 1999のための標準化過程[16ページ]RFC2740OSPF
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パケットの中のOptions分野は動き回りました。 より多くのオプションビットが現在、可能です。 正しくHelloパケットをはめ込まなければならないそれらは以下の通りです。 そして、E-ビットが設定される、インタフェースが非スタッブ領域に付く場合にだけ、Nビットが設定される、単にインタフェースがNSSA領域に付いて([Ref9]を見てください)、DCビットが設定される、インタフェース([Ref11]を見る)の上で将来のハローズの発信を抑圧するというルータ願望である場合にだけ。 Hello PacketのOptions分野の認識されていないビットはきれいにされるべきです。
Sending Hello packets on NBMA networks proceeds for IPv6 in exactly the same way as for IPv4, as documented in Section 9.5.1 of [Ref1].
パケットはIPv6のためにIPv4のようにNBMAネットワークでまさに同じようにHelloに送られかけます、.1セクション9.5[Ref1]に記録されるように。
3.2.1.2. Sending Database Description Packets
3.2.1.2. 送付データベース記述パケット
The sending of Database Description packets differs from Section 10.8 of [Ref1] in the following ways:
Database記述パケットの発信は以下の方法で[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記述パケットの中のOptions分野は動き回りました。 より多くのオプションビットが現在、可能です。 正しくDatabase記述パケットをはめ込まなければならないそれらは以下の通りです。 そして、ビットM.C.が設定される、単にルータが[Ref7]のMOSPF仕様通りにマルチキャストデータグラムを進めていて、DC-ビットが設定される、インタフェース([Ref11]を見る)の上でハローズの発信を抑圧するというルータ願望である場合にだけ。 Database記述PacketのOptions分野の認識されていないビットはきれいにされるべきです。
3.2.2. Receiving protocol packets
3.2.2. プロトコルパケットを受けます。
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に表現されたRouter RT11を考えてください。 RT11がインタフェースでOSPFプロトコルパケットをNetwork N8に受けるなら、それはArea2へのインタフェース、またはRouter 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マルチキャストの1つがAllSPFRoutersかAllDRoutersを扱います。
Coltun, et al. Standards Track [Page 17] RFC 2740 OSPF for IPv6 December 1999
Coltun、他 IPv6 December 1999のための標準化過程[17ページ]RFC2740OSPF
o The Next Header field of the immediately encapsulating IPv6 header
must specify the OSPF protocol (89).
o すぐに要約のIPv6ヘッダーのNext Header分野は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がAuthentication Headers([Ref19]を見る)とIP Encapsulating Security有効搭載量([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パケットとprepended 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ヘッダーで見つけられたArea IDについて確かめなければなりません。 以下のケースの両方が失敗するなら、パケットは捨てられるべきです。 ヘッダーで指定されたArea 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) 受信インタフェースのArea 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) バックボーンを示してください。 この場合、仮想のリンクの上にパケットを送りました。 受信ルータは境界ルータであるに違いありません、そして、パケット(ソースルータ)で指定されたRouter IDは構成された仮想のリンクのもう一方の端であるに違いありません。 また、受信インタフェースは仮想のリンクの構成されたTransit領域に付かなければなりません。 これらのチェックのすべてが成功するなら、パケットは、受け入れられて、これから先、仮想のリンク(そして、バックボーン領域)に関連づけられます。
o The Instance ID specified in the OSPF header must match the
receiving interface's Instance ID.
o OSPFヘッダーで指定されたInstance IDは受信インタフェースのInstance IDに合わなければなりません。
Coltun, et al. Standards Track [Page 18] RFC 2740 OSPF for IPv6 December 1999
Coltun、他 IPv6 December 1999のための標準化過程[18ページ]RFC2740OSPF
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 受信インタフェースの状態がDRかBackup(セクション9.1を見る)である場合にだけIPの目的地がAllDRoutersであるパケットを受け入れるべきです。
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パケットタイプに従って、パケットはさらに処理されます。 IPv4とIPv6の両方に、OSPFパケットタイプと機能は同じです。
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ヘッダーに現れるRouter 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.
Database記述Packetsの処理を受けてください、とIPv4手順から変わりのないLink州Request PacketsとLink州Acknowledgment Packetsの残りは[Ref1]のセクション10.6、10.7、および13.7にそれぞれ記録しました。 Hello Packetsの受信、記録されたコネセクション3.2.2は.1であり、Link州Update Packetsの受信はセクション3.5に.1に記録されます。
3.2.2.1. Receiving Hello Packets
3.2.2.1. こんにちはを受ける、パケット
The receive processing of Hello Packets differs from Section 10.5 of [Ref1] in the following ways:
受信してください。Hello Packetsの処理は以下の方法で[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 Router IDによって特定されます。 仮想のリンク以外のすべてのリンク型にとって、Neighbor IPアドレスは容認されたOSPF HelloパケットのIPv6ヘッダーのIPv6ソースアドレスに設定されます。
o There is no longer a Network Mask field in the Hello Packet.
o もう、Network Mask分野がHello Packetにありません。
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 隣人のDesignated RouterとBackup Designated Routerの選択は現在、IPインターフェース・アドレスの代わりにOSPF Router IDとしてコード化されます。
3.3. The Routing table Structure
3.3. ルート設定テーブルStructure
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).
IPv4にOSPFによって使用された経路指定テーブルは[Ref1]のセクション11で定義されます。 IPv6のために、類似の経路指定テーブルエントリーがあります: 経路指定テーブルエントリーがIPv6アドレス接頭語、およびAS境界ルータのためにもあります。 後者の経路指定テーブルエントリーは経路指定テーブルの間の中間結果がプロセスを建てる保持に使用されるだけです(セクション3.8を見てください)。
Coltun, et al. Standards Track [Page 19] RFC 2740 OSPF for IPv6 December 1999
Coltun、他 IPv6 December 1999のための標準化過程[19ページ]RFC2740OSPF
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によって特定されます。 これらの経路指定テーブルエントリーは与えられた領域を通って与えられたルータに最短パスのセットを持っています。(順番に、Intra領域がLSAsを前に置いた状態で、それは、接頭語がそのルータで広告を出した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 その領域のそれぞれのトランジットリンクのためのエントリー。 トランジットリンクはネットワーク-LSAsを関連づけました。 トランジットリンクとLSAをネットワークでつなぐ両方がリンクとDesignated RouterのOSPF Router IDにおけるDesignated RouterのInterface IDの組み合わせで特定されます。 これらの経路指定テーブルエントリーはイントラ領域接頭語-LSAsのトランジットリンクに広告に掲載された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).
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).
3.3.1. Routing table lookup
3.3.1. Routing table lookup
Routing table lookup (i.e., determining the best matching routing table entry during IP forwarding) is the same for IPv6 as for IPv4.
Routing table lookup (i.e., determining the best matching routing table entry during IP forwarding) is the same for IPv6 as for IPv4.
3.4. Link State Advertisements
3.4. Link State Advertisements
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-
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-
Coltun, et al. Standards Track [Page 20] RFC 2740 OSPF for IPv6 December 1999
Coltun, et al. Standards Track [Page 20] RFC 2740 OSPF for IPv6 December 1999
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.
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.
These changes will be described in detail in the following subsections.
These changes will be described in detail in the following subsections.
3.4.1. The LSA Header
3.4.1. The LSA Header
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:
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:
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.
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.
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 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.
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.
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.
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.
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.
Coltun, et al. Standards Track [Page 21] RFC 2740 OSPF for IPv6 December 1999
Coltun, et al. Standards Track [Page 21] RFC 2740 OSPF for IPv6 December 1999
3.4.2. The link-state database
3.4.2. The link-state database
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]).
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]).
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.
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.
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.
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.
3.4.3. Originating LSAs
3.4.3. Originating LSAs
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.
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.
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:
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:
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 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 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 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.
Coltun, et al. Standards Track [Page 22] RFC 2740 OSPF for IPv6 December 1999
Coltun, et al. Standards Track [Page 22] RFC 2740 OSPF for IPv6 December 1999
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 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 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 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 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 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 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 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.
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.
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.
Coltun, et al. Standards Track [Page 23] RFC 2740 OSPF for IPv6 December 1999
Coltun, et al. Standards Track [Page 23] RFC 2740 OSPF for IPv6 December 1999
..........................................
. Area 1.
. + .
. | .
. | 3+---+1 .
. N1 |--|RT1|-----+ .
. | +---+ \ .
. | \ ______ .
. + \/ \ 1+---+
. * N3 *------|RT4|------
. + /\_______/ +---+
. | / | .
. | 3+---+1 / | .
. N2 |--|RT2|-----+ 1| .
. | +---+ +---+ .
. | |RT3|----------------
. + +---+ .
. |2 .
. | .
. +------------+ .
. N4 .
..........................................
.......................................... . 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
Figure 1: Area 1 with IP addresses shown
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
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
Table 1: IPv6 link prefixes for sample network
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
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
Table 2: OSPF Interface IDs and link-local addresses
Coltun, et al. Standards Track [Page 24] RFC 2740 OSPF for IPv6 December 1999
Coltun, et al. Standards Track [Page 24] RFC 2740 OSPF for IPv6 December 1999
3.4.3.1. Router-LSAs
3.4.3.1. Router-LSAs
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.
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.
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
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
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].
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].
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.
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.
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.
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.
Coltun, et al. Standards Track [Page 25] RFC 2740 OSPF for IPv6 December 1999
Coltun, et al. Standards Track [Page 25] RFC 2740 OSPF for IPv6 December 1999
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.
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.
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).
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).
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.
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.
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.
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's router-LSA for Area 1
; RT3's router-LSA for Area 1
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
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
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
Coltun, et al. Standards Track [Page 26] RFC 2740 OSPF for IPv6 December 1999
Coltun, et al. Standards Track [Page 26] RFC 2740 OSPF for IPv6 December 1999
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.
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.
Host routes no longer appear in the router-LSA, but are instead included in intra-area-prefix-LSAs.
Host routes no longer appear in the router-LSA, but are instead included in intra-area-prefix-LSAs.
3.4.3.2. Network-LSAs
3.4.3.2. Network-LSAs
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.
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.
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:
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:
o An IPv6 network-LSA's Link State ID is set to the Interface ID of
the Designated Router on the link.
o An IPv6 network-LSA's Link State ID is set to the Interface ID of the Designated Router on the link.
o IPv6 network-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 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 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 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.
As an example, assuming that Router RT4 has been elected Designated Router of Network N3 in Figure 1, the following network-LSA is originated:
As an example, assuming that Router RT4 has been elected Designated Router of Network N3 in Figure 1, the following network-LSA is originated:
; Network-LSA for Network N3
; Network-LSA for Network N3
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
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
Coltun, et al. Standards Track [Page 27] RFC 2740 OSPF for IPv6 December 1999
Coltun, et al. Standards Track [Page 27] RFC 2740 OSPF for IPv6 December 1999
3.4.3.3. Inter-Area-Prefix-LSAs
3.4.3.3. Inter-Area-Prefix-LSAs
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.
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.
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:
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:
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 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 The prefix is described by the PrefixLength, PrefixOptions and
Address Prefix fields embedded within the LSA body. Network Mask
is no longer specified.
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 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 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 Link-local addresses must never be advertised in inter-area-
prefix-LSAs.
o Link-local addresses must never be advertised in inter-area- prefix-LSAs.
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.
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.
; Inter-area-prefix-LSA for Area 1 addresses
; originated by Router RT4 into the backbone
; Inter-area-prefix-LSA for Area 1 addresses ; originated by Router RT4 into the backbone
LS age = 0 ;newly (re)originated
LS type = 0x2003 ;inter-area-prefix-LSA
Advertising Router = 192.1.1.4 ;RT4's ID
Metric = 4 ;maximum to components
PrefixLength = 48
PrefixOptions = 0
Address Prefix = 5f00:0000:c001 ;padded to 64-bits
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
Coltun, et al. Standards Track [Page 28] RFC 2740 OSPF for IPv6 December 1999
Coltun, et al. Standards Track [Page 28] RFC 2740 OSPF for IPv6 December 1999
3.4.3.4. Inter-Area-Router-LSAs
3.4.3.4. Inter-Area-Router-LSAs
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.
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.
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:
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:
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 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 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 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.
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.
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.
; inter-area-router-LSA for AS boundary router RT7
; originated by Router RT4 into Area 1
; inter-area-router-LSA for AS boundary router RT7 ; originated by Router RT4 into Area 1
LS age = 0 ;newly (re)originated
LS type = 0x2004 ;inter-area-router-LSA
Advertising Router = 192.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
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
3.4.3.5. AS-external-LSAs
3.4.3.5. AS-external-LSAs
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.
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.
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:
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:
Coltun, et al. Standards Track [Page 29] RFC 2740 OSPF for IPv6 December 1999
Coltun, et al. Standards Track [Page 29] RFC 2740 OSPF for IPv6 December 1999
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.
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.
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 The prefix is described by the PrefixLength, PrefixOptions and Address Prefix fields embedded within the LSA body. Network Mask is no longer specified.
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 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 Link-local addresses can never be advertised in AS-external-LSAs.
o Link-local addresses can never be advertised in AS-external-LSAs.
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 The forwarding address is present in the AS-external-LSA if and only if the AS-external-LSA's bit F is set.
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 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 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 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.
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.
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.
; AS-external-LSA for Network N12,
; originated by Router RT7
; AS-external-LSA for Network N12, ; originated by Router RT7
LS age = 0 ;newly (re)originated
LS type = 0x4005 ;AS-external-LSA
Link State ID = 123 ;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
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
Coltun, et al. Standards Track [Page 30] RFC 2740 OSPF for IPv6 December 1999
Coltun, et al. Standards Track [Page 30] RFC 2740 OSPF for IPv6 December 1999
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
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
3.4.3.6. Link-LSAs
3.4.3.6. Link-LSAs
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.
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-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.
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.
A Link-LSA for a given Link L is built in the following fashion:
A Link-LSA for a given Link L is built in the following fashion:
o The Link State ID is set to the router's Interface ID on Link L.
o The Link State ID is set to the router's Interface ID on Link L.
o The Router Priority of the router's interface to Link L is
inserted into the Link-LSA.
o The Router Priority of the router's interface to Link L is inserted into the Link-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 The Link-LSA's Options field is set to those bits that the router wishes set in Link L's Network 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 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 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 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.
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.
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.
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.
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.
Coltun, et al. Standards Track [Page 31] RFC 2740 OSPF for IPv6 December 1999
Coltun, et al. Standards Track [Page 31] RFC 2740 OSPF for IPv6 December 1999
; RT3's Link-LSA for N3
; RT3's Link-LSA for N3
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
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
3.4.3.7. Intra-Area-Prefix-LSAs
3.4.3.7. Intra-Area-Prefix-LSAs
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.
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.
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.
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.
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:
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:
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 In order to indicate that the prefixes are to be associated with the Link L, the fields Referenced LS type, Referenced Link State ID, and Referenced
Advertising Router are set to the corresponding fields in Link L's
network-LSA (namely LS type, Link State ID, and Advertising Router
respectively). This means that 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.
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.
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
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
Coltun, et al. Standards Track [Page 32] RFC 2740 OSPF for IPv6 December 1999
Coltun, et al. Standards Track [Page 32] RFC 2740 OSPF for IPv6 December 1999
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.
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 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 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.
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:
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:
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 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 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 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 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 adds the IPv6 prefixes for any directly attached hosts belonging to the area (see Section C.7) to the intra-area-prefix- LSA.
Coltun, et al. Standards Track [Page 33] RFC 2740 OSPF for IPv6 December 1999
Coltun, et al. Standards Track [Page 33] RFC 2740 OSPF for IPv6 December 1999
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 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 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 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.
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.
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.
; Intra-area-prefix-LSA
; for network link N3
; Intra-area-prefix-LSA ; for network link 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
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's Intra-area-prefix-LSA ; for its own prefixes
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
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
Coltun, et al. Standards Track [Page 34] RFC 2740 OSPF for IPv6 December 1999
Coltun, et al. Standards Track [Page 34] RFC 2740 OSPF for IPv6 December 1999
PrefixOptions = 0
Metric = 2 ;N4 interface cost
Address Prefix = 5f00:0000:c001:0400 ;pad
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.
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.
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.
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.
3.5. Flooding
3.5. Flooding
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.
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.
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.
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.
Coltun, et al. Standards Track [Page 35] RFC 2740 OSPF for IPv6 December 1999
Coltun, et al. Standards Track [Page 35] RFC 2740 OSPF for IPv6 December 1999
3.5.1. Receiving Link State Update packets
3.5.1. Receiving Link State Update packets
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:
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:
(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) 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.
(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) 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.
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.
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.
3.5.2. Sending Link State Update packets
3.5.2. Sending Link State Update packets
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:
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:
o The LSA's flooding scope.
o The LSA's flooding scope.
o For LSAs with area or link-local flooding scoping, the particular
area or interface that the LSA is associated with.
o For LSAs with area or link-local flooding scoping, the particular area or interface that the LSA is associated with.
o Whether the LSA has a recognized LS type.
o Whether the LSA has a recognized LS type.
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 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.
Coltun, et al. Standards Track [Page 36] RFC 2740 OSPF for IPv6 December 1999
Coltun, et al. Standards Track [Page 36] RFC 2740 OSPF for IPv6 December 1999
Choosing the set of eligible interfaces then breaks into the following cases:
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).
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).
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.
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.
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.
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.
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
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
Coltun, et al. Standards Track [Page 37] RFC 2740 OSPF for IPv6 December 1999
Coltun, et al. Standards Track [Page 37] RFC 2740 OSPF for IPv6 December 1999
attached link.
attached link.
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]).
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]).
3.5.3. Installing LSAs in the database
3.5.3. Installing LSAs in the database
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.
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.
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:
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:
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).
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).
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-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.
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-LSAs The best route to the destination described by the AS-external-LSA must be recalculated (see Section 16.6 in [Ref1]).
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.
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.
Coltun, et al. Standards Track [Page 38] RFC 2740 OSPF for IPv6 December 1999
Coltun, et al. Standards Track [Page 38] RFC 2740 OSPF for IPv6 December 1999
3.6. Definition of self-originated LSAs
3.6. Definition of self-originated LSAs
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.
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.
3.7. Virtual links
3.7. Virtual links
OSPF virtual links for IPv4 are described in Section 15 of [Ref1]. Virtual links are the same in IPv6, with the following exceptions:
OSPF virtual links for IPv4 are described in Section 15 of [Ref1]. Virtual links are the same in IPv6, with the following exceptions:
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 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 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 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 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 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 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 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.
3.8. Routing table calculation
3.8. Routing table calculation
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:
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:
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 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.
Coltun, et al. Standards Track [Page 39] RFC 2740 OSPF for IPv6 December 1999
Coltun, et al. Standards Track [Page 39] RFC 2740 OSPF for IPv6 December 1999
o Type 3 and 4 summary-LSAs have been renamed inter-area-prefix-LSAs
and inter-area-router-LSAs (respectively).
o Type 3 and 4 summary-LSAs have been renamed inter-area-prefix-LSAs and inter-area-router-LSAs (respectively).
o Addressing information is no longer encoded in Link State IDs, and
must instead be found within the body of LSAs.
o Addressing information is no longer encoded in Link State IDs, and must instead be found within the body of LSAs.
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 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).
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.
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.
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.
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.
3.8.1. Calculating the shortest path tree for an area
3.8.1. Calculating the shortest path tree for an area
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).
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).
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.
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.
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]):
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]):
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 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.
Coltun, et al. Standards Track [Page 40] RFC 2740 OSPF for IPv6 December 1999
Coltun, et al. Standards Track [Page 40] RFC 2740 OSPF for IPv6 December 1999
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 ルータVertex Vがちょうど最短パス木に加えられたところなとき、Step2に、ルータに関連している複数のLSAsがあるかもしれません。 V OSPF Router IDに用意ができているAdvertising RouterとRouter-LSAsがそうしなければならないすべてが集合として処理されました、独身の大きいルータ-LSAの断片として彼らを扱って。 最も小さいLink州IDと共に「断片」からOptionsグラウンドとルータタイプビット(ビットW、V、E、およびB)にいつも出るべきです。
o Step 2a is not needed in IPv6, as there are no longer stub network
links in router-LSAs.
o スタッブネットワークリンクがもうルータ-LSAsになくて、ステップ2aはIPv6で必要ではありません。
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 Step 2bに、ルータに関連している複数のLSAsがWがルータであるなら、再びあるかもしれません。 WのOSPF Router IDに用意ができているAdvertising RouterとRouter-LSAsがそうしなければならないすべてが集合として処理されました、独身の大きいルータ-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 Step4に、現在、それぞれの領域のルータのための1領域あたりの経路指定テーブルエントリーがあります、まさしく境界ルータの代わりに。 これらのエントリーは仮想のリンクのメインテナンスを含むIPv4の境界ルータ経路指定テーブルエントリーのすべての機能性を包括します。 このステップにおける領域経路指定テーブルに加えられたルータが仮想のリンクのもう一方の端であるときに、仮想の隣人のIPアドレスは以下の通り設定されます: 仮想の隣人によって溯源されたイントラ領域接頭語-LSAsの収集は調べられます、仮想の隣人のIPアドレスが「LA-ビット」を設定させながら遭遇する最初の接頭語に設定されている状態で。
o Routing table entries for transit networks, which are no longer
associated with IP networks, are also modified in Step 4.
o また、輸送網のための経路指定テーブルエントリーはStep4で変更されます。(輸送網はもうIPネットワークに関連していません)。
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]の2番目のステージのセクション16.1の2ステップに進みます。 しかしながら、審査の代わりに、イントラ領域がLSAsを前に置いた状態で、スタッブはルータ-LSAs、領域のリストの中でリンクします。調べられます。 ルーティング計算に「ν-ビット」が設定される接頭語広告を含むべきではありません。 メートル法で広告に掲載された'どんな広告を出している接頭語の費用も接頭語の合計です'とイントラ領域がLSAのものを前に置いているReferenced LSタイプ、Referenced Link州ID、およびReferenced Advertising Router分野によって特定されたトランジット頂点(ルータかトランジットネットワークのどちらか)への費用。 'この後者の費用はトランジット頂点'経路指定テーブルエントリーに領域として保存されます。
3.8.1.1. The next hop calculation
3.8.1.1. 次のホップ計算
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
IPv6では、次のホップのIPv6アドレス(リンクローカルアドレスになる)の計算は同じやり方でIPv4として次のホップ計算を続かせます(.1セクション16.1[Ref1]を見てください)。 ルータのために次のホップIPv6アドレスについて計算するのにおいて唯一の違いがあります。
Coltun, et al. Standards Track [Page 41] RFC 2740 OSPF for IPv6 December 1999
Coltun、他 IPv6 December 1999のための標準化過程[41ページ]RFC2740OSPF
(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.
(それをRouter Xと呼びます) 計算のルータとのリンクを共有する。 この場合、計算のルータは、Router XのLink- LSAにリンクに含まれた(セクションA.4.8を見ます)リンク地方のインタフェースアドレスになるように次のホップIPv6アドレスを割り当てます。 2つのルータがNBMAリンクなどのいくつかのリンクと隣人である必要はなく、したがって、OSPFハローズを交換していないことであるかもしれないので、この手順が必要です。
3.8.2. Calculating the inter-area routes
3.8.2. 相互領域ルートを計算します。
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のための相互領域ルートの計算は同じやり方でIPv4計算として[Ref1]のセクション16.2で続きます、以下の変更で:
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 そして、相互領域がLSAsを前に置いた状態でType3の要約のLSAsとType4概要-LSAsという名前に変えた、相互領域ルータLSAs、それぞれ。
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のLink州IDはもうネットワークかルータがLSAで説明したエンコードをタイプしません。 代わりに、アドレス接頭語がボディーに含まれている、相互領域はLSAを前に置いて、説明されたルータのOSPF Router IDは相互領域ルータ-LSAのボディーで運ばれます。
o Prefixes having the "NU-bit" set in their Prefix Options field
should be ignored by the inter-area route calculation.
o それらのPrefix Options分野に「ν-ビット」を設定する接頭語は相互領域ルート計算で無視されるべきです。
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.
または、シングルであるときに、相互領域がLSAを前に置く、相互領域ルータLSA、変えます、全体の経路指定テーブルについて再計算することの代わりに[Ref1]のセクション16.5に概説された増加の計算は実行できます。
3.8.3. Examining transit areas' summary-LSAs
3.8.3. トランジット領域の概要-LSAsを調べます。
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.
IPv6のトランジット領域の概要-LSAsの試験は同じやり方でIPv4計算としてセクション3.8.2におけるIPv6相互領域ルート計算と同様に、変更された[Ref1]のセクション16.3で続きます。
3.8.4. Calculating AS external routes
3.8.4. 計算のAS外部経路
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外部経路計算は同じやり方でIPv4計算として[Ref1]のセクション16.4で続きます、以下の例外で:
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タイプのLink州IDはもうLSAによって説明されたネットワークをコード化しません。 代わりに、アドレス接頭語はASの外部のLSAのボディーに含まれています。
Coltun, et al. Standards Track [Page 42] RFC 2740 OSPF for IPv6 December 1999
Coltun、他 IPv6 December 1999のための標準化過程[42ページ]RFC2740OSPF
o The default route is described by AS-external-LSAs which advertise
zero length prefixes.
o デフォルトルートはゼロ・レングス接頭語の広告を出すASの外部のLSAsによって説明されます。
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外部のLSA Forwardingを比較することの代わりに0.0に分野を扱ってください。.0 .0 フォーワーディング・アドレスが使用されたかどうか確認するために、外部の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 それらのPrefix Options分野に「ν-ビット」を設定する接頭語は相互領域ルート計算で無視されるべきです。
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外部のLSAが変化したとき、全体の経路指定テーブルについて再計算することの代わりに[Ref1]のセクション16.6に概説された増加の計算は実行できます。
3.9. Multiple interfaces to a single link
3.9. 単一のリンクへの複数のインタフェース
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:
IPv6のためのOSPFでは、ルータは単一のリンクに複数のインタフェースを持っているかもしれません。 すべてのインタフェースがデータ通信量のレセプションと送信にかかわります、単一のインタフェースが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 異なったInterface IDはそれぞれの複数のインタフェースに割り当てられます。 このように、いつそれ自身のRouter IDからハローズを受けるかとき、複数のインタフェースが同じリンクに付くかを検出しますが、受信インタフェースのものを除いて、ルータはInterface 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パケット(すなわち、コントロールトラフィック)の送受信をリンクにオフにします。 コントロールトラフィックを送って、受けるインタフェースの選択は実装に依存しています。 1つの例として、最も高いInterface IDとのインタフェースを選ぶことができました。 ルータがDRに選出されると、ネットワーク-LSA Link州IDとして使用されるのはこのインタフェースのInterface 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 送受信コントロールトラフィックに責任があるインタフェースが失敗すると、別のものは引き継がなければならないでしょう、最初からすべての隣人隣接番組を改革して。 ルータ自体でこの失敗を検出できます、同じリンクへの他のインタフェースが、ルータの自身のハローズを聞くのをやめるとき。
Coltun, et al. Standards Track [Page 43] RFC 2740 OSPF for IPv6 December 1999
Coltun、他 IPv6 December 1999のための標準化過程[43ページ]RFC2740OSPF
References
参照
[Ref1] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[Ref1]Moy、J.、「OSPF、バージョン2インチ、STD54、RFC2328、1998インチ年4月。
[Ref2] McKenzie, A., "ISO Transport Protocol specification ISO DP
8073", RFC 905, April 1984.
[Ref2] マッケンジー、A.、「ISO Transportプロトコル仕様ISO DP8073」、RFC905、1984年4月。
[Ref3] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB
using SMIv2", RFC 2233, November 1997.
[Ref3] McCloghrie、K.、およびF.Kastenholz、「インタフェースは1997年11月にSMIv2"、RFC2233を使用するMIBを分類します」。
[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.
[Ref4] フラーとV.と李とTとユーとJ.とK.Varadhan、「以下を掘る(CIDR)階級のない相互ドメイン」 「アドレス課題と集合戦略」、RFC1519、9月1993日
[Ref5] Varadhan, K., Hares, S. and Y. Rekhter, "BGP4/IDRP for IP---
OSPF Interaction", RFC 1745, December 1994
[Ref5] VaradhanとK.と野兎とS.とY.Rekhter、「IPのためのBGP4/IDRP」--- 「OSPF相互作用」、RFC1745、1994年12月
[Ref6] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC
1700, October 1994.
[Ref6] レイノルズとJ.とJ.ポステル、「規定番号」、STD2、RFC1700、1994年10月。
[Ref7] deSouza, O. and M. Rodrigues, "Guidelines for Running OSPF
Over Frame Relay Networks", RFC 1586, March 1994.
[Ref7] deSouzaとO.とM.ロドリーグ、「フレームリレーネットワークの上にOSPFを実行するためのガイドライン」、RFC1586、1994年3月。
[Ref8] Moy, J., "Multicast Extensions to OSPF", RFC 1584, March
1994.
[Ref8] Moy、J.、「OSPFへのマルチキャスト拡大」、RFC1584、1994年3月。
[Ref9] Coltun, R. and V. Fuller, "The OSPF NSSA Option", RFC 1587,
March 1994.
[Ref9] Coltun、R.、および「OSPF NSSAオプション」、RFC1587、1994年3月対フラー
[Ref10] Ferguson, D., "The OSPF External Attributes LSA",
unpublished.
[Ref10]ファーガソン、「OSPFの外部の属性LSA」の、そして、未発表のD.。
[Ref11] Moy, J., "Extending OSPF to Support Demand Circuits", RFC
1793, April 1995.
[Ref11] Moy、J.、「要求が回路であるとサポートするためにOSPFを広げています」、RFC1793、1995年4月。
[Ref12] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191,
November 1990.
[Ref12] ムガール人とJ.とS.デアリング、「経路MTU発見」、RFC1191、1990年11月。
[Ref13] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)",
RFC 1771, March 1995.
1995年の[Ref13]RekhterとY.とT.李、「ボーダ・ゲイトウェイ・プロトコル4(BGP-4)」、RFC1771行進。
[Ref14] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[Ref14]デアリング、S.とR.Hinden、「インターネットプロトコル、バージョン6(IPv6)仕様」、RFC2460、12月1998日
[Ref15] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998.
[Ref15] HindenとR.とS.デアリング、「IPバージョン6アドレッシング体系」、RFC2373、1998年7月。
Coltun, et al. Standards Track [Page 44] RFC 2740 OSPF for IPv6 December 1999
Coltun、他 IPv6 December 1999のための標準化過程[44ページ]RFC2740OSPF
[Ref16] Conta, A. and S. Deering, "Internet Control Message Protocol
(ICMPv6) for the Internet Protocol Version 6 (IPv6)
Specification" RFC 2463, December 1998.
[Ref16]コンタ、1998年12月のA.とS.デアリング、「インターネットへのインターネット・コントロール・メッセージ・プロトコル(ICMPv6)はバージョン6(IPv6)仕様を議定書の中で述べ」RFC2463。
[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.シンプソン、「IPバージョン6(IPv6)のための隣人発見」、RFC2461、1998年12月。
[Ref18] McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery for
IP version 6", RFC 1981, August 1996.
[Ref18] マッキャン、J.、デアリング、S.、およびJ.ムガール人、「IPのための経路MTUディスカバリー、バージョン6インチ、RFC1981、1996インチ年8月。
[Ref19] Kent, S. and R. Atkinson, "IP Authentication Header", RFC
2402, November 1998.
[Ref19] ケントとS.とR.アトキンソン、「IP認証ヘッダー」、RFC2402、1998年11月。
[Ref20] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
(ESP)", RFC 2406, November 1998.
[Ref20]ケントとS.とR.アトキンソン、「セキュリティが有効搭載量(超能力)であるとカプセル化するIP」、RFC2406、1998年11月。
Coltun, et al. Standards Track [Page 45] RFC 2740 OSPF for IPv6 December 1999
Coltun、他 IPv6 December 1999のための標準化過程[45ページ]RFC2740OSPF
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 LSAsの形式について説明します。 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 Options分野は説明されます。 この分野はOSPF経路ドメインの断片によってサポートされるかもしれない様々な能力について説明します。 OSPF Options分野はOSPF Helloパケット、Database記述パケット、およびOSPF LSAsに含まれています。
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 LSAsの記述はセクションA.4に現れます。 このセクションは、IPv6アドレス接頭語がLSAsの中にどう表されるかを説明して、標準のLSAヘッダーについて詳述して、次に、LSA特定のタイプ各人に形式を提供します。
A.1 Encapsulation of OSPF packets
OSPFパケットのA.1カプセル化
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パケットの長さは最大6万5535バイトであるかもしれません。 通常、大きい傾向があるOSPFパケットタイプ(データベース記述Packets、Link州Request、Link州Update、およびLink州Acknowledgmentパケット)はいくつかの別々のプロトコルパケットに分けることができます、機能性の損失なしで。 これはお勧めです。 可能であるときはいつも、IPv6断片化は避けられるべきです。 この推理を使用して、Path MTUディスカバリーが実行されていない場合1280バイトへの仮想のリンクの上に送られたOSPFパケット[Ref14]のサイズを制限するのを試みをするべきです。
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 Hop Limitを1に用意ができさせるはずです。
Coltun, et al. Standards Track [Page 46] RFC 2740 OSPF for IPv6 December 1999
Coltun、他 IPv6 December 1999のための標準化過程[46ページ]RFC2740OSPF
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.
値のFF02はAllSPFRouters Thisマルチキャストアドレスに割り当てられました:、:5. OSPFを実行するすべてのルータがこのアドレスに送られたパケットを受けるように準備されるべきです。 こんにちは、この目的地に送って、いつもパケットはそうです。 また、氾濫手順の間、あるOSPFプロトコルパケットをこのアドレスに送ります。
AllDRouters
This multicast address has been assigned the value FF02::6. Both
the Designated Router and Backup Designated Router must be
prepared to receive packets destined to this address. Certain
OSPF protocol packets are sent to this address during the flooding
procedure.
値のFF02はAllDRouters Thisマルチキャストアドレスに割り当てられました:、:6. このアドレスに運命づけられたパケットを受けるようにDesignated RouterとBackup Designated Routerの両方を準備しなければなりません。 氾濫手順の間、ある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ヘッダーのNext Header分野に挿入されるべきです。
A.2 The Options field
A.2はOptions分野です。
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 Options分野がOSPF Helloパケット、Database記述パケット、およびあるLSAsに存在している、(ルータ-LSAs、LSAsをネットワークでつないでください、相互領域ルータLSAs、リンク-LSAs) Options分野は、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パケットの送受信で発見されます。 いくつかのオプションミスマッチが水につかるのからの隣接番組(例えば、以下のビットM.C.)の向こう側の特定のLSAタイプを防ぎます。 これらはDatabase記述パケットの送受信で発見されます。 いくつかのオプションミスマッチが、ルータがそれらの減少している機能性のために様々なルーティング計算の1つ以上に含まれているのを防ぎます(再びビットM.C.は例です)。 これらのミスマッチは、LSAsを調べることによって、発見されます。
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 Options分野の6ビットを割り当ててあります。 各ビットは簡潔に以下で説明されます。 HelloパケットかDatabase記述パケットといつにLSAsを溯源させるかとき、ルータはOptions分野に(すなわち、明確)の認識されていないビットをリセットするべきです。 逆に、Database記述の容認されたHello Packetsで認識されていないOptionビットに遭遇するルータ、パケットまたはLSAsが能力を無視して、通常、パケット/LSAを処理するはずです。
Coltun, et al. Standards Track [Page 47] RFC 2740 OSPF for IPv6 December 1999
Coltun、他 IPv6 December 1999のための標準化過程[47ページ]RFC2740OSPF
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|
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+--+--+--+--+--+
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|M.C.| E|V6| -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+--+--+--+--+--+
The Options field
Options分野
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-ビットIfが明確である、ルータ/リンクは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].
電子ビットThisビットはASの外部のLSAsが.2セクション3.6、9.5、10.8、および12.1[Ref1]で説明されるように水につかっている方法を述べます。
MC-bit
This bit describes whether IP multicast datagrams are forwarded
according to the specifications in [Ref7].
ビットThisビットM.C.は、IPマルチキャストデータグラムが[Ref7]の仕様通りに進められるかどうか説明します。
N-bit
This bit describes the handling of Type-7 LSAs, as specified in
[Ref8].
N-ビットThisビットは[Ref8]で指定されるようにType-7 LSAsの取り扱いについて説明します。
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-ビットThisビット('ルータ'ビット)は、創始者がアクティブなルータであるかどうかを示します。 ルータがどのトランジットを発送するかなら、ビットが明確である広告ノードを計算できません。 aに、ルータビットをきれいにするのが適切であるだろう、マルチ、家へ帰り、ルーティングに参加したいのですが、非局所的に扱われたパケットを進めたがっていないホスト。
DC-bit
This bit describes the router's handling of demand circuits, as
specified in [Ref10].
DC-ビットThisビットは[Ref10]で指定されるように要求回路のルータの取り扱いについて説明します。
A.3 OSPF Packet Formats
A.3 OSPFパケット・フォーマット
There are five distinct OSPF packet types. All OSPF packet types begin with a standard 16 byte header. This header is described first. Each packet type is then described in a succeeding section. In these sections each packet's 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パケットタイプ(OSPF Helloパケットを除いた)がLSAsのリストに対処します。 例えば、Link州UpdateパケットはOSPF経路ドメイン中でLSAsの氾濫を実装します。 LSAsの形式はセクションA.4で説明されます。
Coltun, et al. Standards Track [Page 48] RFC 2740 OSPF for IPv6 December 1999
Coltun、他 IPv6 December 1999のための標準化過程[48ページ]RFC2740OSPF
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.
セクション3.2で.2に詳述したOSPFパケットの処理を受けてください。 OSPFパケットの発信はセクション3.2.1で説明されます。
A.3.1 The OSPF packet header
OSPFパケットのヘッダーのA.3.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ヘッダーはパケットがさらなる処理のために受け入れられるべきであるかどうか決定するのに必要なすべての情報を含んでいます。 この決断はこの.2のセクション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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version # | Type | Packet length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Instance ID | 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | バージョン#| タイプ| パケット長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ルータID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 領域ID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | チェックサム| インスタンス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
型記述--------------------------------- こんにちは、2データベース記述3リンク州が、4リンク州のアップデート5がリンクするよう要求する1は承認を述べます。
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 Router ID。
Coltun, et al. Standards Track [Page 49] RFC 2740 OSPF for IPv6 December 1999
Coltun、他 IPv6 December 1999のための標準化過程[49ページ]RFC2740OSPF
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.
領域ID A32はこのパケットが属す領域を特定する数に噛み付きました。 すべてのOSPFパケットがただ一つの領域に関連しています。 大部分は単一のホップだけを旅行します。 仮想のリンクの上に移動するパケットは0のバックボーンArea IDでラベルされます。
Checksum
OSPF uses the standard checksum calculation for IPv6
applications: The 16-bit one's complement of the one's complement
sum of the entire contents of the packet, starting with the OSPF
packet header, and prepending a "pseudo-header" of IPv6 header
fields, as specified in [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パケットのヘッダーと、[Ref14、セクション8.1]で指定されるようにIPv6ヘッダーフィールドの「疑似ヘッダー」をprependingすることをきっかけにパケットの全体のコンテンツの1の補数合計の16ビットの1の補数。 疑似ヘッダーの「上側の層のパケット長」はOSPFパケットのヘッダーの長さの分野の値に設定されます。 疑似ヘッダーで使用されるNext Header値は89です。 パケットの長さが整数の16ビットの単語でないなら、パケットはchecksummingする前に、1バイトのゼロで水増しされます。 チェックサムを計算する前に、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.
シングルの上に実行されるべきOSPFのインスタンスID Enables倍数インスタンスはリンクされます。 別々のInstance IDはそれぞれのプロトコルインスタンスに割り当てられるでしょう。 Instance IDには、ローカルのリンク意味しかありません。 Instance IDが受信インタフェースのInstance IDと等しくない容認されたパケットは捨てられます。
0 These fields are reserved. They must be 0.
0 これらの分野は予約されています。 それらは0であるに違いありません。
A.3.2 The Hello packet
A.3.2はHelloパケットです。
Hello packets are OSPF packet type 1. These packets are sent periodically on all interfaces (including virtual links) in order to establish and maintain neighbor relationships. In addition, Hello Packets are multicast on those links having a multicast or broadcast capability, enabling dynamic discovery of neighboring routers.
こんにちは、パケットはそうです。OSPFパケットは1をタイプします。 隣人関係を確立して、維持するためにすべてのインタフェース(仮想のリンクを含んでいる)で定期的にこれらのパケットを送ります。 さらに、Hello Packetsはマルチキャストを持っているそれらのリンクか放送能力(隣接しているルータの可能なダイナミックな発見)に関するマルチキャストです。
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パケットはDesignated Router選挙(Router IDとBackup Designated Router IDに指定される)に使用される分野、および両性愛者の方向性を検出するのに使用される分野(ハローズが最近受け取られたすべての隣人のRouter ID)を含んでいます。
Coltun, et al. Standards Track [Page 50] RFC 2740 OSPF for IPv6 December 1999
Coltun、他 IPv6 December 1999のための標準化過程[50ページ]RFC2740OSPF
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
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 | パケット長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ルータID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 領域ID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | チェックサム| インスタンスID| 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | インタフェースID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rtr Pri| オプション| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HelloInterval| RouterDeadInterval| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router IDに指定されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | バックアップに指定されたルータID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 隣人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 ThisルータのRouter Priority。 Router選挙に指定された(バックアップ)では、使用されています。 0に設定されると、ルータはRouterに指定された(バックアップ)になるのにおいて不適格になるでしょう。
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、静かなルータを宣言する前の秒数はダウンします。
Coltun, et al. Standards Track [Page 51] RFC 2740 OSPF for IPv6 December 1999
Coltun、他 IPv6 December 1999のための標準化過程[51ページ]RFC2740OSPF
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.
このネットワークのために送付ルータの視点でDesignated RouterのアイデンティティにRouter IDを指定しました。 Designated RouterはRouter IDによって特定されます。 0.0に.0を設定してください。.0 Designated Routerが全くなければ。
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.
これのためのBackup Designated Routerのアイデンティティが送付ルータの視点でネットワークでつなぐDesignated Router IDのバックアップをとってください。 Backup Designated RouterはIP Router IDによって特定されます。 0.0に.0を設定してください。.0 Backup Designated Routerが全くなければ。
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.
有効なHelloパケットが最近ネットワークで見られたそれぞれのルータの隣人ID Router ID。 最後のRouterDeadInterval秒に最近、意味します。
A.3.3 The Database Description packet
A.3.3はDatabase記述パケットです。
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つはマスターになるように指定されて、もう片方が奴隷です。 マスターは奴隷(応答)によって送られたDatabase記述パケットによって承認される記述パケット(投票)をDatabaseに送ります。 応答はパケットのDD一連番号で投票にリンクされます。
Coltun, et al. Standards Track [Page 52] RFC 2740 OSPF for IPv6 December 1999
Coltun、他 IPv6 December 1999のための標準化過程[52ページ]RFC2740OSPF
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 -+
| |
+- -+
| |
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
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 | パケット長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ルータID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 領域ID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | チェックサム| インスタンスID| 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | オプション| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | インタフェースMTU| 0 |0|0|0|0|0|I|M|+++++++++++++++++++++++++++++++++さん| DD一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +- -+ | | + LSAヘッダー-+| | +- -+ | | +- -+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... |
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].
Database記述パケットの形式はLink州RequestとLink州Acknowledgmentパケットの両方と非常に同様です。 すべての3の主部は項目、リンク州のデータベースの1つの断片について説明する各個条のリストです。 Database記述Packetsの発信は[Ref1]のセクション10.8に記録されます。 Database記述パケットのレセプションは[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データグラムであることができることのバイトで表現されるサイズは関連インタフェースを出しました、断片化なしで。 [Ref12]のTable7-1で一般的なインターネットリンク型のMTUsを見つけることができます。 インタフェースMTUはパケットが仮想のリンクの上に送ったDatabase記述で0に用意ができるべきです。
Coltun, et al. Standards Track [Page 53] RFC 2740 OSPF for IPv6 December 1999
Coltun、他 IPv6 December 1999のための標準化過程[53ページ]RFC2740OSPF
I-bit
The Init bit. When set to 1, this packet is the first in the
sequence of Database Description Packets.
Initが噛み付いたI-ビット。 1に設定されると、このパケットはDatabase記述Packetsの系列で1番目です。
M-bit
The More bit. When set to 1, it indicates that more Database
Description Packets are to follow.
Moreが噛み付いたM-ビット。 1に設定されると、それは、より多くのDatabase記述Packetsが続くことになっているのを示します。
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.
Master/奴隷が噛み付いたMS-ビット。 1に設定されると、それは、ルータがDatabase Exchangeプロセスの間マスターであることを示します。 さもなければ、ルータは奴隷です。
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.
Database記述Packetsの収集を配列するDD一連番号Used。 初期の値(設定される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の現在のインスタンスの両方を特定するのに必要であるすべての情報を含んでいます。
A.3.4 The Link State Request packet
A.3.4はLink州Requestパケットです。
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.
リンク州RequestパケットはOSPFパケットタイプ3です。 Database記述パケットを隣接しているルータと交換した後に、ルータによって、リンク州のデータベースの部分が時代遅れであることがわかるかもしれません。 Link州Requestパケットは、隣人のデータベースの、より最新の断片を要求するのに使用されます。 複数のLink州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.
Link州Requestパケットを送るルータはそれが要求しているデータベース片の正確なインスタンスを考えています。 各インスタンスはLS一連番号、LSチェックサム、およびLS時代までに定義されます、これらの分野はLink州Request Packet自身で指定されませんが。 ルータは応答におけるさらに最近のインスタンスを受けるかもしれません。
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州Requestパケットの発信は[Ref1]のセクション10.9に記録されます。 Link州Requestパケットのレセプションは[Ref1]のセクション10.7に記録されます。
Coltun, et al. Standards Track [Page 54] RFC 2740 OSPF for IPv6 December 1999
Coltun、他 IPv6 December 1999のための標準化過程[54ページ]RFC2740OSPF
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
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 | パケット長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ルータID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 領域ID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | チェックサム| インスタンスID| 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | LSはタイプします。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 州のIDをリンクしてください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 広告ルータ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... |
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が要求したそれぞれがLink州のLSタイプ、ID、およびAdvertising Routerによって指定されます。 これは唯一インスタンスではなく、LSAを特定します。 リンク州Requestパケットは最新のインスタンス(それはことなら何でもであるかもしれない)を求める要求であることが理解されています。
A.3.5 The Link State Update packet
A.3.5はLink州Updateパケットです。
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.
リンク州UpdateパケットはOSPFパケットタイプ4です。 これらのパケットはLSAsの氾濫を実装します。 それぞれのLink州Updateパケットはさらに彼らの発生源からのワンバウンドのLSAsの収集を運びます。 数個のLSAsが単一のパケットに含まれるかもしれません。
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.
リンク州Updateパケットはマルチキャスト/放送をサポートするそれらの物理ネットワークのマルチキャストです。 氾濫手順を信頼できるようにするように、水につかっているLSAsはLink州Acknowledgmentパケットで承認されます。 あるLSAsの「再-トランスミッション」が必要であるなら、再送されたLSAsはいつもユニキャストLink州Updateパケットによって運ばれます。 LSAsの信頼できる氾濫の詳しい情報に関しては、セクション3.5に相談してください。
Coltun, et al. Standards Track [Page 55] RFC 2740 OSPF for IPv6 December 1999
Coltun、他 IPv6 December 1999のための標準化過程[55ページ]RFC2740OSPF
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 |
+- +-+
| ... |
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 | パケット長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ルータID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 領域ID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | チェックサム| インスタンスID| 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | # LSAs| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +- +-+ | LSAs| +- +-+ | ... |
# LSAs
The number of LSAs included in this update.
# このアップデートにLSAsの数を含んでいるLSAs。
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.
Link州UpdateパケットのボディーはLSAsのリストから成ります。 各LSAはセクションA.4.2で説明された20バイトの一般的なヘッダーと共に始まります。 LSAsの異なったタイプの詳細な形式はセクションA.4で説明されます。
A.3.6 The Link State Acknowledgment packet
A.3.6はLink州Acknowledgmentパケットです。
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].
リンク州Acknowledgment PacketsはOSPFパケットタイプ5です。 LSAsの氾濫を信頼できるようにするように、水につかっているLSAsは明らかに承認されます。 この承認はLink州Acknowledgmentパケットの送受信で実行されます。 Link州Acknowledgementパケットの発信は[Ref1]のセクション13.5に記録されます。 Link州Acknowledgementパケットのレセプションは[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).
単一のLink州Acknowledgmentパケットで複数のLSAsを承認できます。 対応するLink州Updateパケットの送付インタフェースと送付者の状態によって、マルチキャストアドレスAllSPFRoutersか、マルチキャストアドレスAllDRoutersか、ユニキャストとしてLink州Acknowledgmentパケットを送ります(詳細に関して[Ref1]のセクション13.5を見てください)。
The format of this packet is similar to that of the Data Description packet. The body of both packets is simply a list of LSA headers.
このパケットの形式はData記述パケットのものと同様です。 両方のパケットのボディーは単にLSAヘッダーのリストです。
Coltun, et al. Standards Track [Page 56] RFC 2740 OSPF for IPv6 December 1999
Coltun、他 IPv6 December 1999のための標準化過程[56ページ]RFC2740OSPF
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 -+
| |
+- -+
| |
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
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 | パケット長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ルータID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 領域ID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | チェックサム| インスタンスID| 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +- -+ | | + LSAヘッダー-+| | +- -+ | | +- -+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... |
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の現在のインスタンスの両方を特定するのに必要であるすべての情報を含んでいます。
A.4 LSA formats
A.4 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.
このメモはLSAsの7つの異なったタイプを定義します。 各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経路ドメインの1つの断片について説明します。 あらゆるルータがルータ-LSAを溯源します。 ネットワーク-LSAはDesignated Routerによって各リンクに広告を出されます。 リンク-LSAsの隣人にルータのリンクローカルのアドレスの広告を出します。 イントラ領域がLSAsを前に置いて、相互領域がLSAsを前に置いた状態で、IPv6接頭語で広告を出します。そして、AS外部のLSAs。 中にエリアの境界の向こう側に特定のルータの位置の広告を出すことができる、相互領域ルータLSAs すべてのLSAsがその時、OSPF経路ドメイン中で水につかっています。 すべてのルータにはLSAsの同じ収集があるのを確実にして、氾濫アルゴリズムは信頼できます。 (詳しい情報に関して氾濫アルゴリズムに関してセクション3.5を見ます。) LSAsのこの収集はリンク州のデータベースと呼ばれます。
Coltun, et al. Standards Track [Page 57] RFC 2740 OSPF for IPv6 December 1999
Coltun、他 IPv6 December 1999のための標準化過程[57ページ]RFC2740OSPF
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を見てください。
A.4.1 IPv6 Prefix Representation
A.4.1 IPv6接頭語表現
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のためにアルゴリズム、およびOSPFを発送するIPv6が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を見る)です。 アドレスPrefixは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.
セクションのA.4.5、A.4.7、A.4.8、およびA.4.9でOSPFのIPv6 Prefix表現に関する例を見つけることができます。
A.4.1.1 Prefix Options
A.4.1.1接頭語オプション
Each prefix is advertised along with an 8-bit field of capabilities. These serve as input to the various routing calculations, 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|
+--+--+--+--+--+--+--+--+
0 1 2 3 4 5 6 7 +--+--+--+--+--+--+--+--+ | | | | | P|M.C.|LA|ν| +--+--+--+--+--+--+--+--+
The Prefix Options field
Prefix Options分野
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ユニキャスト計算から除かれるべきです。さもなければ、それは含まれるべきです。
Coltun, et al. Standards Track [Page 58] RFC 2740 OSPF for IPv6 December 1999
Coltun、他 IPv6 December 1999のための標準化過程[58ページ]RFC2740OSPF
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.
ビット「マルチキャスト」能力ビットM.C.。 設定されるなら、接頭語はIPv6マルチキャストルーティング計算に含まれるべきです。さもなければ、それは除かれるべきです。
P-bit
The "propagate" bit. Set on NSSA area prefixes that should be
readvertised at the NSSA area border.
噛み付かれた「伝播してください」にPで噛み付きました。 NSSA領域の境界に「再-広告を出」すべきであるNSSA領域接頭語にセットしてください。
A.4.2 The LSA header
LSAヘッダーのA.4.2
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.
すべてのLSAsが20バイトの一般的なヘッダーと共に始まります。 このヘッダーは唯一、LSA(Link州のLSタイプ、ID、およびAdvertising Router)を特定できるくらいの情報を含んでいます。 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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時代| LSはタイプします。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 州のIDをリンクしてください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 広告ルータ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSチェックサム| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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がタイプするのを見てください。
Coltun, et al. Standards Track [Page 59] RFC 2740 OSPF for IPv6 December 1999
Coltun、他 IPv6 December 1999のための標準化過程[59ページ]RFC2740OSPF
Link State ID
Together with LS type and Advertising Router, uniquely identifies
the LSA in the link-state database.
LSタイプとAdvertising Routerと共に州IDを結びつけて、リンク州のデータベースで唯一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を溯源したルータのRouter Router IDの広告を出します。 例えば、ネットワーク-LSAsでは、この分野はネットワークのDesignated RouterのRouter 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一連番号Detects老人か写しLSAs。 連続したLS一連番号をLSAの連続したインスタンスに与えます。 [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.
LSAにもかかわらず、LSAヘッダーを含んでいますが、LS時代を除く完全なコンテンツのフレッチャーチェックサムがさばくLSチェックサム。 [Ref1]でその他の詳細に関してセクション12.1.7を見てください。
length
The length in bytes of the LSA. This includes the 20 byte LSA
header.
長さ、LSAのバイトで表現される長さ。 これは20バイトのLSAヘッダーを含んでいます。
A.4.2.1 LS type
A.4.2.1LSはタイプします。
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 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |U|S2|S1| LSA機能コード| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
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
U-ビットLSA取り扱い------------------------------------------------------------- 0は、まるでリンク地方の氾濫範囲1ストアを持っているかのようにLSAを扱って、LSAをあふれさせます、まるでタイプが分かるかのように
Coltun, et al. Standards Track [Page 60] RFC 2740 OSPF for IPv6 December 1999
Coltun、他 IPv6 December 1999のための標準化過程[60ページ]RFC2740OSPF
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
S2 S1氾濫範囲--------------------------------------------------------------------- 0 0、リンク地方の見ること。 リンクだけでは、上それが溯源される水につかります。 0 1、領域の見ること。 起因している領域1 0AS Scopingのすべてのルータに浸水しました。 AS1 1Reservedのすべてのルータに浸水します。
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]を見ます)、Type7-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
LSA機能コードLS Type記述---------------------------------------------------- 1 0×2001ルータ-LSA2 0×2002ネットワーク-LSA3 0×2003相互領域接頭語LSA4 0×2004相互領域ルータLSA5、0×4005、外部のLSA、会員資格LSAを分類している0×2006 0×2007 0×0008リンク-LSA6 7タイプ-7-LSA8 9、0×2009イントラ領域接頭語LSA
A.4.3 Router-LSAs
A.4.3ルータ-LSAs
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.
ルータ-LSAsには、0×2001と等しいLSタイプがあります。 領域の各ルータは1ルータ-LSAsを溯源します。 ルータによって溯源されたルータ-LSAsの完全なコレクションはルータのインタフェースの状態と費用についてその領域に説明します。 ルータ-LSAsの構造に関する詳細に関しては、.1にセクション3.4.3を見てください。 ルータ-LSAsはただ一つの領域だけ中で水につかっています。
Coltun, et al. Standards Track [Page 61] RFC 2740 OSPF for IPv6 December 1999
Coltun、他 IPv6 December 1999のための標準化過程[61ページ]RFC2740OSPF
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
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時代|0|0|1| 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 州のIDをリンクしてください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 広告ルータ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSチェックサム| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 |W|V|E|B| オプション| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 0 | メートル法| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | インタフェースID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 隣人インタフェースID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 隣人Router ID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 0 | メートル法| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | インタフェースID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 隣人インタフェースID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 隣人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.
ただ一つのルータは彼らのLink-州のID(起因するルータによって任意に選ばれている)によって区別された1Router LSAsを溯源するかもしれません。 Options分野とV、E、およびBビットはすべてのRouter LSAsで独身の創始者から同じであるべきです。 しかしながら、ミスマッチの場合では、最も低いLink州IDがあるLSAの値は優先します。 ただ一つのルータから1Router LSAを受け取るとき、まるで独身のLSAに連結されるかのようにリンクを処理します。
bit V
When set, the router is an endpoint of one or more fully adjacent
virtual links having the described area as Transit area (V is for
virtual link endpoint).
Whenが設定するビットV、ルータはTransit領域として説明された領域を持っている1個以上の完全に隣接している仮想のリンクの終点(仮想のリンク終点にはVがある)です。
Coltun, et al. Standards Track [Page 62] RFC 2740 OSPF for IPv6 December 1999
Coltun、他 IPv6 December 1999のための標準化過程[62ページ]RFC2740OSPF
bit E
When set, the router is an AS boundary router (E is for external).
ビットE Whenはセットして、ルータはAS境界ルータ(外部にはEがある)です。
bit B
When set, the router is an area border router (B is for border).
ビットB Whenはセットして、ルータは境界ルータ(境界には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.
Whenが設定するビット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:
説明されるインタフェースの種類をタイプしてください。 以下の1つ:
Type Description
---------------------------------------------------
1 Point-to-point connection to another router
2 Connection to a transit network
3 Reserved
4 Virtual link
型記述--------------------------------------------------- 1 トランジットネットワーク3Reserved4Virtualリンクへの別のルータ2Connectionへの二地点間接続
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.
Interface 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.
隣人ルータ(または、Type2インタフェースへの付属リンクのDesignated Router)が広告を出している隣人Interface ID Interface ID、こんにちは、パケットは付属リンクを転送しました。
Neighbor Router ID
The Router ID the neighbor router (or the attached link's
Designated Router, for Type 2 interfaces).
Router ID Router IDを近所付き合いさせてください。隣人ルータ(Type2インタフェースへの付属リンクのDesignated Router)。
Coltun, et al. Standards Track [Page 63] RFC 2740 OSPF for IPv6 December 1999
Coltun、他 IPv6 December 1999のための標準化過程[63ページ]RFC2740OSPF
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.
Type2リンクに関しては、Neighbor Interface IDとNeighbor Router IDの組み合わせはLSAをネットワークでつながせます付属リンクがリンク州のデータベースで見つけられる。
A.4.4 Network-LSAs
A.4.4ネットワーク-LSAs
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.
ネットワーク-LSAsには、0×2002と等しいLSタイプがあります。 ネットワーク-LSAは各放送のために溯源されます、そして、NBMAは2つ以上のルータをサポートする領域でリンクします。 LSAをネットワークでつなぐのはリンクのDesignated Routerによって溯源されます。 LSAはDesignated Router自身を含むリンクに付けられたすべてのルータについて説明します。 LSAのLink州ID分野はDesignated Routerがリンクの上にHelloパケットに広告を出しているInterface 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で指定される必要はない理由です。 ネットワーク-LSAsの構造に関する詳細に関しては、.2にセクション3.4.3を見てください。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age |0|0|1| 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attached Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
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時代|0|0|1| 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 州のIDをリンクしてください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 広告ルータ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSチェックサム| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | オプション| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 付属ルータ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... |
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.
それぞれのルータの付属Router Router IDはリンクに付きました。 それは完全にそうです。実際にそれらのルータだけ、記載されたDesignated Routerに隣接して。 Designated Routerはこのリストにそれ自体を含んでいます。 LSAヘッダーの長さの分野からルータを含む数を推論できます。
Coltun, et al. Standards Track [Page 64] RFC 2740 OSPF for IPv6 December 1999
Coltun、他 IPv6 December 1999のための標準化過程[64ページ]RFC2740OSPF
A.4.5 Inter-Area-Prefix-LSAs
A.4.5相互領域接頭語LSAs
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.
相互Area接頭語LSAsには、0×2003と等しいLSタイプがあります。 これらのLSAsがそうである、IPv4のタイプ3概要-LSAs(.3セクション12.4[Ref1]を見る)のためのOSPFのIPv6同等物はそうです。 境界ルータによって溯源されて、それらは他の領域に属すIPv6アドレス接頭語にルートを説明します。 別々のInter領域接頭語LSAはそれぞれのIPv6アドレス接頭語のために溯源されます。 Inter-領域接頭語-LSAsの構造に関する詳細に関しては、.3にセクション3.4.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領域接頭語LSAsを使用できます。 デフォルト概要ルートは完全な外部経路をあふれさせることの代わりにスタッブ領域で使用されます。 デフォルト概要ルートを説明するとき、Inter領域接頭語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 |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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時代|0|0|1| 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 州のIDをリンクしてください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 広告ルータ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSチェックサム| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | メートル法| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PrefixLength| PrefixOptions| (0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | アドレス接頭語| | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
メートル法、このルートの費用。 インタフェースコストと同じユニットでは、ルータ-LSAsで言い表されます。 Inter領域接頭語LSAがさまざまなアドレスにルートを説明しているとき(セクションC.2を見てください)、費用はアドレスの範囲のどんな届いているコンポーネントへの最大の費用にも設定されます。
PrefixLength, PrefixOptions and Address Prefix
Representation of the IPv6 address prefix, as described in Section
A.4.1.
IPv6のPrefixLength、PrefixOptions、およびAddress Prefix RepresentationはセクションA.4.1で説明されるように接頭語を扱います。
Coltun, et al. Standards Track [Page 65] RFC 2740 OSPF for IPv6 December 1999
Coltun、他 IPv6 December 1999のための標準化過程[65ページ]RFC2740OSPF
A.4.6 Inter-Area-Router-LSAs
A.4.6相互領域ルータLSAs
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.
相互AreaルータLSAsには、0×2004と等しいLSタイプがあります。 これらのLSAsがそうである、IPv4のタイプ4概要-LSAs(.3セクション12.4[Ref1]を見る)のためのOSPFのIPv6同等物はそうです。 境界ルータによって溯源されて、それらは他の領域のルータにルートを説明します。 (それぞれのASBRの位置の広告を出すのがなぜ必要であるかを確認するには、[Ref1]でセクション16.4に相談してください。) 各LSAはただ一つのルータにルートを説明します。 Inter領域ルータLSAsの構造に関する詳細に関しては、.4にセクション3.4.3を見てください。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age |0|0|1| 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Router 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時代|0|0|1| 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 州のIDをリンクしてください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 広告ルータ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSチェックサム| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | オプション| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | メートル法| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 目的地のルータ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.
メートル法、このルートの費用。 インタフェースコストと同じユニットでは、ルータ-LSAsで言い表されます。
Destination Router ID
The Router ID of the router being described by the LSA.
LSAによって説明されるルータの目的地Router ID Router ID。
Coltun, et al. Standards Track [Page 66] RFC 2740 OSPF for IPv6 December 1999
Coltun、他 IPv6 December 1999のための標準化過程[66ページ]RFC2740OSPF
A.4.7 AS-external-LSAs
A.4.7、外部のLSAs
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の外部のLSAsには、0×4005と等しいLSタイプがあります。 これらのLSAsはAS境界ルータによって溯源されて、ASへの外部の目的地について説明します。 各LSAはただ一つのIPv6アドレス接頭語にルートを説明します。 ASの外部のLSAsの構造に関する詳細に関しては、.5にセクション3.4.3を見てください。
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の外部のLSAsを使用できます。 どんな特定のルートも目的地に存在しないとき、デフォルトルートは使用されています。 デフォルトルートを説明するとき、AS外部のLSA PrefixLengthは0に用意ができています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age |0|1|0| 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |E|F|T| Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PrefixLength | PrefixOptions | Referenced LS Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Prefix |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- -+
| |
+- Forwarding Address (Optional) -+
| |
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| External Route Tag (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Referenced Link State ID (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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時代|0|1|0| 5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 州のIDをリンクしてください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 広告ルータ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSチェックサム| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |E|F|T| メートル法| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PrefixLength| PrefixOptions| 参照をつけられたLSはタイプします。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | アドレス接頭語| | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +- -+ | | +フォーワーディング・アドレス(任意の)-+| | +- -+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 外部経路タグ(任意の)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 参照をつけられたリンク州のID(任意の)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Coltun, et al. Standards Track [Page 67] RFC 2740 OSPF for IPv6 December 1999
Coltun、他 IPv6 December 1999のための標準化過程[67ページ]RFC2740OSPF
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).
外部のタイプのEに噛み付いて、メートル法にしました。 ビットEが設定されるなら、指定されたメートル法はa Type2外部メートル法です。 これは、メートル法がどんなイントラ-AS経路よりも大きいと考えられることを意味します。 噛み付かれるならEがゼロである、メートル法で指定されて、Type1外部はメートル法ですか? これは、それがリンク状態と同じユニットでメートル法で(すなわち、インタフェース費用と同じユニット)言い表されることを意味します。
bit F
If set, a Forwarding Address has been included in the LSA.
ビットF Ifはセットして、Forwarding AddressはLSAに含まれています。
bit T
If set, an External Route Tag has been included in the LSA.
ビットT Ifはセットして、External Route Tagは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.
IPv6のPrefixLength、PrefixOptions、およびAddress Prefix RepresentationはセクションA.4.1で説明されるように接頭語を扱います。
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はIf非ゼロをタイプして、このLSタイプがあるLSAはこのLSAに関連させていることになっています(以下のReferenced Link州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).
フォーワーディング・アドレスAはIPv6アドレス(128ビット)に完全に資格を与えました。 そして、LSAに含まれている、噛み付かれる場合にだけ、Fは設定されました。 含んでいると、広告を出している目的地へのDataトラフィックをこのアドレスに送るでしょう。 IPv6 Unspecified Addressに設定されてはいけない、(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境界ルータの間の追加情報を伝えるのに使用されるかもしれない外部のRoute Tag A32ビットの分野。 例えば用法を見てください[Ref5]。 そして、LSAに含まれている、噛み付かれる場合にだけ、Tは設定されました。
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.
そして、参照をつけられたLink州ID Included、Reference LS Typeが非ゼロである場合にだけ。 含まれているなら、それがAS外部のLSAリンク州のヘッダーで指定したように「参照をつけられたLSはタイプすること」と等しいLSタイプ、「参照をつけられたリンク州のID」と等しいLink州ID、およびAdvertising Routerを同じにしながら、LSAで広告を出している外部経路に関する追加情報を見つけることができます。 この追加情報はOSPFプロトコル自体によって使用されません。 それはAS境界ルータの間の情報を伝えるのに使用されるかもしれません。 この仕様の範囲の外にそのような情報の正確な本質があります。
Coltun, et al. Standards Track [Page 68] RFC 2740 OSPF for IPv6 December 1999
Coltun、他 IPv6 December 1999のための標準化過程[68ページ]RFC2740OSPF
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.
Forwardingアドレス、External Route Tag、およびReferenced Link州IDとラベルされた分野のすべて、なにもまたはいくつかがASの外部のLSAに出席しているかもしれません(ビットFの設定によって示されるように、ビットTとReferenced LSはそれぞれタイプします)。 しかしながら、プレゼントであるときに、External Route TagがいつもReferenced Link州IDに先行していて、Forwarding Addressはいつも一番になります。
A.4.8 Link-LSAs
A.4.8リンク-LSAs
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.
リンク-LSAsには、0×0008と等しいLSタイプがあります。 ルータはそれが付けられている各リンクに別々のLink-LSAを溯源します。 これらのLSAsには、地方のリンク氾濫範囲があります。 それらはそれらが関連しているリンクを超えて決して水につかっていません。 リンク-LSAsには、3つの目的があります: 1) 彼らはリンクに付けられた他のすべてのルータとリンクに溯源されるNetwork-LSAと交際するためにOptionsビットの収集について断言できる彼らがリンクと3に関連づけるIPv6接頭語のリストのリンクに付けられた他のルータ) それらにルータを知らせる2に)ルータのリンクローカルアドレスを提供します。
A link-LSA's Link State ID is set equal to the originating router's Interface ID on the link.
リンク-LSAのLink州IDはリンクで起因するルータのInterface IDと等しいセットです。
Coltun, et al. Standards Track [Page 69] RFC 2740 OSPF for IPv6 December 1999
Coltun、他 IPv6 December 1999のための標準化過程[69ページ]RFC2740OSPF
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 |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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時代|0|0|0| 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 州のIDをリンクしてください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 広告ルータ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSチェックサム| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rtr Pri| オプション| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +- -+ | | + リンク地方のインタフェースアドレス-+| | +- -+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | # 接頭語| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PrefixLength| PrefixOptions| (0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | アドレス接頭語| | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PrefixLength| PrefixOptions| (0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | アドレス接頭語| | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Rtr Pri
The Router Priority of the interface attaching the originating
router to the link.
起因するルータをリンクに付けるインタフェースのRtr Pri Router Priority。
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のセットのようにそうするOptionsビットのセットにゆだねます。
Coltun, et al. Standards Track [Page 70] RFC 2740 OSPF for IPv6 December 1999
Coltun、他 IPv6 December 1999のための標準化過程[70ページ]RFC2740OSPF
Link-local Interface Address
The originating router's link-local interface address on the
link.
起因するルータのリンク地方のインタフェースがリンクの上に扱うリンク地方のInterface Address。
# prefixes
The number of IPv6 address prefixes contained in the LSA.
# IPv6アドレス接頭語の数がLSAに含んだ接頭語。
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.
IPv6のPrefixLength、PrefixOptions、およびAddress Prefix RepresentationはセクションA.4.1で説明されるように接頭語を扱います。
A.4.9 Intra-Area-Prefix-LSAs
A.4.9イントラ領域接頭語LSAs
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.
イントラ領域接頭語LSAsには、0×2009と等しいLSタイプがあります。 b) a) ルータ自体に関連している接頭語、付属スタッブネットワークセグメントまたはc)が付属トランジットネットワークセグメントであるとルータが1つの広告を出すのにIntra領域接頭語LSAsを使用するか、または、より多くのIPv6が、扱います。 IPv4では、a)とb)はネットワーク-LSAを通してルータのルータ-LSA、およびc)を通して達成されました。 しかしながら、IPv6のためのOSPFでは、ルータ-LSAsとネットワーク-LSAsからすべてのアドレス指定情報を取り除いてあります、Intra領域接頭語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.
ルータはそれぞれのルータかトランジットネットワークのために複数のIntra領域接頭語LSAsを溯源できます。 そのような各LSAはLink州IDによって区別されます。
Coltun, et al. Standards Track [Page 71] RFC 2740 OSPF for IPv6 December 1999
Coltun、他 IPv6 December 1999のための標準化過程[71ページ]RFC2740OSPF
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 |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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時代|0|0|1| 9 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 州のIDをリンクしてください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 広告ルータ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSチェックサム| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | # 接頭語| 参照をつけられたLSはタイプします。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 参照をつけられたリンク州のID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 参照をつけられた広告ルータ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PrefixLength| PrefixOptions| メートル法| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | アドレス接頭語| | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PrefixLength| PrefixOptions| メートル法| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | アドレス接頭語| | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
# prefixes
The number of IPv6 address prefixes contained in the LSA.
# IPv6アドレス接頭語の数がLSAに含んだ接頭語。
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.
IPv6と接頭語を扱うReferenced Link州のルータReferenced LSタイプ、ID、およびReferenced Advertising Identifiesのルータ-LSAかネットワーク-LSAが関連しているべきです。 Referenced LSタイプが1歳であるなら、接頭語はルータ-LSAに関連しています、そして、Referenced Link州IDは0歳であるべきです、そして、Referenced Advertising Routerは起因するルータのRouter IDであるべきです。 Referenced LSタイプが2歳であるなら、接頭語はネットワーク-LSAに関連しています、そして、Referenced Link州IDはリンクのDesignated RouterのInterface IDであるべきです、そして、Referenced Advertising RouterはDesignated RouterのRouter IDであるべきです。
Coltun, et al. Standards Track [Page 72] RFC 2740 OSPF for IPv6 December 1999
Coltun、他 IPv6 December 1999のための標準化過程[72ページ]RFC2740OSPF
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領域接頭語LSAの残りはルータかトランジットリンクに関連しているIPv6接頭語のリストを含んでいます、それぞれの接頭語の費用と共に。
PrefixLength, PrefixOptions and Address Prefix
Representation of an IPv6 address prefix, as described in Section
A.4.1.
IPv6のPrefixLength、PrefixOptions、およびAddress Prefix RepresentationはセクションA.4.1で説明されるように接頭語を扱います。
Metric
The cost of this prefix. Expressed in the same units as the
interface costs in the router-LSAs.
メートル法、この接頭語の費用。 インタフェースコストと同じユニットでは、ルータ-LSAsで言い表されます。
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]のAppendix Bで定義されます。 IPv6のためのOSPFのための唯一の違いは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の観点から、これらの項目はまだ構成可能です。
C.1 Global parameters
C.1のグローバルなパラメタ
In general, a separate copy of the OSPF protocol is run for each area. Because of this, most configuration parameters are defined on a per-area basis. The few global configuration parameters are listed below.
一般に、OSPFプロトコルの別々のコピーは各領域に動かされます。 これのために、ほとんどの設定パラメータが地域制で定義されます。 わずかなグローバルな設定パラメータが以下にリストアップされています。
Router ID
This is a 32-bit number that uniquely identifies the router in the
Autonomous System. If a router's OSPF Router ID is changed, the
router's OSPF software should be restarted before the new Router
ID takes effect. Before restarting in order to change its Router
ルータID ThisはAutonomous Systemで唯一ルータを特定する32ビットの数です。 ルータのOSPF Router IDを変えるなら、新しいRouter IDが効く前にルータのOSPFソフトウェアを再開するべきです。 Routerを変えるために再開する前に
Coltun, et al. Standards Track [Page 73] RFC 2740 OSPF for IPv6 December 1999
Coltun、他 IPv6 December 1999のための標準化過程[73ページ]RFC2740OSPF
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、ルータが経路ドメインから自己によって溯源されたLSAsを洗い流すべきですか([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).
Router IDの大きさがIPv6アドレスより小さいので、ルータのIPv6アドレスの1つにそれを設定できません(IPv4のために一般的にするように)。 IPv6に、可能なRouter ID課題手順は: a) 何らかのローカルの行政手続(製品通し番号を割り当てるのにメーカーによって用いられた手順と同様の)でルータのIPv4アドレスかb)の1つがIDをIPv6 Routerに割り当てるとき、IPv6 Router IDを割り当ててください。
The Router ID of 0.0.0.0 is reserved, and should not be used.
Router ID、0.0 .0 .0を予約されていて、使用するべきではありません。
C.2 Area parameters
C.2領域パラメタ
All routers belonging to an area must agree on that area's configuration. Disagreements between two routers will lead to an inability for adjacencies to form between them, with a resulting hindrance to the flow of 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 Thisは領域を特定する32ビットの数です。 0のArea IDはバックボーンのために予約されます。
List of address ranges
Address ranges control the advertisement of routes across
area boundaries. Each address range consists of the
following items:
Address範囲が広告を制御するアドレスの範囲のリストは領域の向こう側に境界を発送します。 それぞれのアドレスの範囲は以下の項目から成ります:
[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.
どちらかへの状態Set、広告、または、DoNotAdvertise。 ルート設定情報はエリアの境界で凝縮します。 その領域に外部であり、高々、それぞれのアドレスの範囲にただ一つのルートの広告を出します(aを通して、相互領域はLSAを前に置きます)。 範囲のStatusはアドレスである場合にだけ用意ができています。そして、ルートの広告を出す、広告。 Unadvertised範囲で、故意にあるネットワークの存在を他の領域から隠します。 状態が設定される、広告、デフォルトで。
Coltun, et al. Standards Track [Page 74] RFC 2740 OSPF for IPv6 December 1999
Coltun、他 IPv6 December 1999のための標準化過程[74ページ]RFC2740OSPF
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 Whether ASの外部のLSAsは領域中に/へあふれるでしょう。 ASの外部のLSAsが領域から除かれるなら、領域は「スタッブ」と呼ばれます。 領域を引き抜くために内部であり、外部の目的地へのルーティングは唯一デフォルト相互領域ルートに基づくでしょう。 スタッブ領域としてバックボーンを構成できません。 また、スタッブ領域を通って仮想のリンクを構成できません。 詳しくは、[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.
領域はスタッブ領域として構成されました、そして、ルータ自体が境界ルータである、次に、相互領域がLSAを前に置いた状態で、StubDefaultCostはデフォルトの費用を示します。StubDefaultCost If、ルータは領域に広告を出すべきです。 セクション12.4を見てください。.3 詳しい情報のための.1[Ref1。]
C.3 Router interface parameters
C.3ルータインタフェース・パラメータ
Some of the configurable router interface parameters (such as Area ID, HelloInterval and RouterDeadInterval) actually imply properties of the attached links, and therefore must be consistent across all the routers attached to that link. The parameters that must be configured for a router interface are:
構成可能なルータインタフェース・パラメータ(Area 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.
領域ID、付属リンクが属するOSPF領域。
Instance ID
The OSPF protocol instance associated with this OSPF interface.
Defaults to 0.
OSPFプロトコルインスタンスがこのOSPFインタフェースに関連づけたインスタンスID。 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接頭語のリストを前に置きます。 これらでは、イントラ領域がLSAsを前に置いた状態で、広告を出すでしょう。
Coltun, et al. Standards Track [Page 75] RFC 2740 OSPF for IPv6 December 1999
Coltun、他 IPv6 December 1999のための標準化過程[75ページ]RFC2740OSPF
Interface output cost(s)
The cost of sending a packet on the interface, expressed in the
link state metric. This is advertised as the link cost for this
interface in the router's router-LSA. The interface output cost
must always be greater than 0.
インタフェース出力は(s) リンク状態でメートル法で言い表されたインタフェースにパケットを送る費用かかります。 ルータのルータ-LSAのこのインタフェースへのリンク費用としてこれの広告を出します。 いつもインタフェース製作費は0以上であるに違いありません。
RxmtInterval
The number of seconds between LSA retransmissions, for adjacencies
belonging to this interface. Also used when retransmitting
Database Description and Link State Request Packets. This should
be well over the expected round-trip delay between any two routers
on the attached link. The setting of this value should be
conservative or needless retransmissions will result. Sample
value for a local area network: 5 seconds.
RxmtInterval、LSA retransmissionsの間のこのインタフェースに属す隣接番組の秒数。 また、Database記述とLink州Request Packetsを再送するとき、使用されます。 付属リンクの上のどんな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は、Link州Update Packetをこのインタフェースの上に伝えるのにそれがかかる秒に付番します。 アップデートパケットに含まれたLSAsはトランスミッションの前にこの量で彼らの時代を増加させなければなりません。 この値はインタフェースのトランスミッションと伝播遅延を考慮に入れるべきです。 それは0以上であるに違いありません。 ローカル・エリア・ネットワークのために値を抽出してください: 1 2番目に。
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.
ルータPriority An、8ビットの符号のない整数。 ネットワークに付けられた2つのルータが、Designated Routerになるのをともに試みるとき、最も高いRouter Priorityがあるものは優先します。 繋がりがまだあれば、最も高いRouter IDがあるルータは優先します。 Router Priorityが0に用意ができているルータは付属リンクの上のDesignated Routerになるのにおいて不適格です。 ルータPriorityは放送するインタフェースと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.
ルータがインタフェースで送るHello Packetsの間の秒の時間の長さのHelloInterval。 ルータのHello Packetsにこの値の広告を出します。 普通リンクに付けられたすべてのルータに、それは同じであるに違いありません。 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 Afterが、ルータのHello Packetsを聞くのをやめて、隣人がルータを宣言する前に秒数はダウンします。 また、中にルータのHello Packetsにこれの広告を出す、彼ら
Coltun, et al. Standards Track [Page 76] RFC 2740 OSPF for IPv6 December 1999
Coltun、他 IPv6 December 1999のための標準化過程[76ページ]RFC2740OSPF
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分野。 これはHelloIntervalの何らかの倍数であるべきです(4を言ってください)。 普通リンクに付けられたすべてのルータには、この値は再び同じでなければなりません。
C.4 Virtual link parameters
C.4の仮想のリンクパラメータ
Virtual links are used to restore/increase connectivity of the backbone. Virtual links may be configured between any pair of area border routers having interfaces to a common (non-backbone) area. The virtual link appears as 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.
仮想のリンクはまるでそれがバックボーンへの別々のルータインタフェースであるかのようにルータ-LSAs(バックボーンのための)に現れます。 そういうものとして、それには、ルータインタフェースに関連しているパラメタの大部分があります(セクションC.3を見てください)。 仮想のリンクには、リンクローカルのアドレスがありませんが、代わりにそれが仮想のリンクに沿って送るOSPFプロトコルパケットのIPソースとしてルータのグローバルな範囲かサイトローカルのIPv6アドレスの1つを使用してください。 ルータPriorityは仮想のリンクの上に使用されません。 インタフェース製作費は、仮想のリンクの上に構成されませんが、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つの構成可能なパラメタによって定義されます: 仮想のリンクの他の終点のRouter ID、および仮想のリンクが動く(非バックボーンの)領域(仮想のリンクのTransit領域と呼ばれます)。 スタッブ領域を通って仮想のリンクを構成できません。
C.5 NBMA network parameters
C.5 NBMA回路パラメータ
OSPF treats an NBMA network much like it treats a broadcast network. Since there may be many routers attached to the network, a Designated Router is selected for the network. This Designated Router then originates a network-LSA, which lists all routers attached to the NBMA network.
放送網を扱うようにOSPFはNBMAネットワークを扱います。 ネットワークに付けられた多くのルータがあるかもしれないので、Designated Routerはネットワークのために選択されます。 そして、このDesignated Routerはネットワーク-LSAを溯源します。(LSAはNBMAネットワークに付けられたすべてのルータを記載します)。
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:
しかしながら、放送能力の不足のために、Designated Router選択に設定パラメータを使用するのが必要であるかもしれません。 これらのパラメタは、それらのDesignated Router(すなわち、ネットワークのためのRouter Priorityが非ゼロであるルータのそれらのもの)になるのが自分たちで適任のルータで構成されるのが必要であり、隣人を発見するためのどんな自動手順も存在しない場合にだけ、そして必要があるでしょう:
Coltun, et al. Standards Track [Page 77] RFC 2740 OSPF for IPv6 December 1999
Coltun、他 IPv6 December 1999のための標準化過程[77ページ]RFC2740OSPF
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ネットワークに付けたルータを付けました。 各ルータはネットワークのそのRouter IDとIPv6リンクローカルアドレスによって構成されます。 Designated Routerになる各ルータが記載したのでそのルータのも適任を定義しなければなりません。 NBMAネットワークへのインタフェースが来るとき、ルータはDesignated Routerになるのが適任のそれらの隣人だけにHello Packetsを送ります、Designated Routerのアイデンティティが発見されるまで。
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 Ifのa隣接しているルータが不活発になった、(こんにちは、PacketsがRouterDeadInterval秒の間、見られていない、)、死んでいる隣人にHello Packetsを送るのがまだ必要であるかもしれません。 割引料金PollIntervalでこれらのHello Packetsを送るでしょう。(PollIntervalはHelloIntervalよりはるかに大きいはずです)。 PDN X.25ネットワークのために値を抽出してください: 2 書き留めます。
C.6 Point-to-MultiPoint network parameters
C.6ポイントからMultiPointへの回路パラメータ
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.
PointからMultiPointへのネットワークでは、PointからMultiPointへのネットワークの上で直接届いている隣人のセットを構成するのが必要であるかもしれません。 各隣人はネットワークのそのRouter IDとIPv6リンクローカルアドレスによって構成されます。 指定されたRoutersがPointからMultiPointへのネットワークで選出されないので、構成された隣人のDesignated Router適任は未定義です。
C.7 Host route parameters
C.7ホストルートパラメタ
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:
ホスト接頭語では、イントラ領域がLSAsを前に置いた状態で、広告を出します。 彼らは、内部のルータアドレス(二地点間ネットワークへのルータインタフェース)が直接ルータ(例えば、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).
メートル法でリンク状態に関してパケットをホストに送る費用を接待するリンクの費用。 しかしながら、ホストがたぶんインターネットに単独結合しか持っていないので、多くの場合、実際の構成された費用は重要ではありません(すなわち、ルーティングでは、効き目がないでしょう)。
Area ID
The OSPF area to which the host's prefix belongs.
領域ID、ホストの接頭語が属するOSPF領域。
Coltun, et al. Standards Track [Page 78] RFC 2740 OSPF for IPv6 December 1999
Coltun、他 IPv6 December 1999のための標準化過程[78ページ]RFC2740OSPF
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 Authentication Header([Ref19]を見る)とIP Encapsulating Security有効搭載量([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実装がそれらの多くが独立しているセキュリティ仮定とドメインを持っていることである複数のプロトコルをサポートするシステムで動くでしょう。 IPSECがOSPFパケットを保護するのに使用されるとき、実装がIPSEC SA、および確実にするローカルのSAデータベースをチェックするように、パケットがソースTHAT IS TRUSTED FOR OSPF PURPOSESから発するのは、重要です。
Authors' Addresses
作者のアドレス
Rob Coltun Siara Systems 300 Ferguson Drive Mountain View, CA 94043
ロブColtun Siara Systems300ファーガソンDriveマウンテンビュー、カリフォルニア 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
デニスファーガソン杜松ネットワーク385Ravendale Driveマウンテンビュー、カリフォルニア 94043
Phone: +1 650 526 8004 EMail: dennis@juniper.com
以下に電話をしてください。 +1 8004年の650 526メール: dennis@juniper.com
John Moy Sycamore Networks, Inc. 10 Elizabeth Drive Chelmsford, MA 01824
ジョンMoy SycamoreはInc.10エリザベス・Driveチェルムズフォード、MA 01824をネットワークでつなぎます。
Phone: (978) 367-2161 Fax: (978) 250-3350 EMail: jmoy@sycamorenet.com
以下に電話をしてください。 (978) 367-2161 Fax: (978) 250-3350 メールしてください: jmoy@sycamorenet.com
Coltun, et al. Standards Track [Page 79] RFC 2740 OSPF for IPv6 December 1999
Coltun、他 IPv6 December 1999のための標準化過程[79ページ]RFC2740OSPF
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Coltun, et al. Standards Track [Page 80]
Coltun、他 標準化過程[80ページ]
一覧
スポンサーリンク
