RFC5340 日本語訳
5340 OSPF for IPv6. R. Coltun, D. Ferguson, J. Moy, A. Lindem. July 2008. (Format: TXT=225664 bytes) (Obsoletes RFC2740) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group R. Coltun
Request for Comments: 5340 Acoustra Productions
Obsoletes: 2740 D. Ferguson
Category: Standards Track Juniper Networks
J. Moy
Sycamore Networks, Inc
A. Lindem, Ed.
Redback Networks
July 2008
Coltunがコメントのために要求するワーキンググループR.をネットワークでつないでください: 5340のAcoustra創作が以下を時代遅れにします。 2740年のD.ファーガソンカテゴリ: 規格は2008年7月にエドJ.Moyアメリカスズカケノキがネットワークでつなぐ杜松ネットワーク、Inc A.Lindem、20ドル紙幣ネットワークを追跡します。
OSPF for IPv6
IPv6のためのOSPF
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
This document describes the modifications to OSPF to support version 6 of the Internet Protocol (IPv6). The fundamental mechanisms of OSPF (flooding, Designated Router (DR) election, area support, Short Path First (SPF) calculations, etc.) remain unchanged. However, some changes have been necessary, either due to changes in protocol semantics between IPv4 and IPv6, or simply to handle the increased address size of IPv6. These modifications will necessitate incrementing the protocol version from version 2 to version 3. OSPF for IPv6 is also referred to as OSPF version 3 (OSPFv3).
このドキュメントは、インターネットプロトコル(IPv6)のバージョン6を支持するために変更をOSPFに説明します。 OSPF(氾濫、Designated Router(DR)選挙、領域サポート、Short Path First(SPF)計算など)の基本的機構は変わりがありません。 しかしながら、いくつかの変化が必要です、IPv4とIPv6の間のプロトコル意味論における変化か単にのどちらかIPv6の増加するアドレスサイズのハンドルに。 これらの変更は、バージョン3によってプロトコルバージョンを増加するのを必要とするでしょう。 また、IPv6のためのOSPFはOSPFバージョン3(OSPFv3)と呼ばれます。
Changes between OSPF for IPv4, OSPF Version 2, and OSPF for IPv6 as described herein include the following. Addressing semantics have been removed from OSPF packets and the basic Link State Advertisements (LSAs). New LSAs have been created to carry IPv6 addresses and prefixes. OSPF now runs on a per-link basis rather than on a per-IP-subnet basis. Flooding scope for LSAs has been generalized. Authentication has been removed from the OSPF protocol and instead relies on IPv6's Authentication Header and Encapsulating Security Payload (ESP).
IPv4のためのOSPFと、OSPFバージョン2と、説明されるとしてのIPv6のためのOSPFの間の変化はここに以下を含んでいます。 意味論を記述して、OSPFパケットと基本的なLink州Advertisements(LSAs)から取り除いてください、そうした。 新しいLSAsは、IPv6アドレスと接頭語を運ぶために作成されました。 OSPFは今、aに関してというよりむしろ1リンクあたり1個のベースでIPサブネット単位で基礎を走らせます。 LSAsのための氾濫範囲は一般化されました。 認証は、OSPFプロトコルから取り外されて、代わりに、IPv6のAuthentication HeaderとEncapsulating Security有効搭載量(超能力)を当てにします。
Even with larger IPv6 addresses, most packets in OSPF for IPv6 are almost as compact as those in OSPF for IPv4. Most fields and packet- size limitations present in OSPF for IPv4 have been relaxed. In addition, option handling has been made more flexible.
IPv4に、OSPFのそれらより大きいIPv6アドレスがあっても、IPv6のためのOSPFのほとんどのパケットがほとんど同じくらいコンパクトです。 IPv4のためのOSPFの現在のほとんどの分野とパケットサイズ制限が緩和されました。 さらに、オプション取り扱いをよりフレキシブルにしました。
Coltun, et al. Standards Track [Page 1] RFC 5340 OSPF for IPv6 July 2008
Coltun、他 IPv6 July 2008のための標準化過程[1ページ]RFC5340OSPF
All of OSPF for IPv4's optional capabilities, including demand circuit support and Not-So-Stubby Areas (NSSAs), are also supported in OSPF for IPv6.
また、要求サーキットサポートととても短く太いNot Areas(NSSAs)を含むIPv4の任意の能力のためのOSPFのすべてがIPv6のためにOSPFで支持されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Differences from OSPF for IPv4 . . . . . . . . . . . . . . . . 5
2.1. Protocol Processing Per-Link, Not Per-Subnet . . . . . . . 5
2.2. Removal of Addressing Semantics . . . . . . . . . . . . . 5
2.3. Addition of Flooding Scope . . . . . . . . . . . . . . . . 6
2.4. Explicit Support for Multiple Instances per Link . . . . . 6
2.5. Use of Link-Local Addresses . . . . . . . . . . . . . . . 7
2.6. Authentication Changes . . . . . . . . . . . . . . . . . . 7
2.7. Packet Format Changes . . . . . . . . . . . . . . . . . . 8
2.8. LSA Format Changes . . . . . . . . . . . . . . . . . . . . 9
2.9. Handling Unknown LSA Types . . . . . . . . . . . . . . . . 10
2.10. Stub/NSSA Area Support . . . . . . . . . . . . . . . . . . 11
2.11. Identifying Neighbors by Router ID . . . . . . . . . . . . 11
3. Differences with RFC 2740 . . . . . . . . . . . . . . . . . . 11
3.1. Support for Multiple Interfaces on the Same Link . . . . . 11
3.2. Deprecation of MOSPF for IPv6 . . . . . . . . . . . . . . 12
3.3. NSSA Specification . . . . . . . . . . . . . . . . . . . . 12
3.4. Stub Area Unknown LSA Flooding Restriction Deprecated . . 12
3.5. Link LSA Suppression . . . . . . . . . . . . . . . . . . . 12
3.6. LSA Options and Prefix Options Updates . . . . . . . . . . 13
3.7. IPv6 Site-Local Addresses . . . . . . . . . . . . . . . . 13
4. Implementation Details . . . . . . . . . . . . . . . . . . . . 13
4.1. Protocol Data Structures . . . . . . . . . . . . . . . . . 14
4.1.1. The Area Data Structure . . . . . . . . . . . . . . . 15
4.1.2. The Interface Data Structure . . . . . . . . . . . . . 15
4.1.3. The Neighbor Data Structure . . . . . . . . . . . . . 16
4.2. Protocol Packet Processing . . . . . . . . . . . . . . . . 17
4.2.1. Sending Protocol Packets . . . . . . . . . . . . . . . 17
4.2.1.1. Sending Hello Packets . . . . . . . . . . . . . . 18
4.2.1.2. Sending Database Description Packets . . . . . . . 19
4.2.2. Receiving Protocol Packets . . . . . . . . . . . . . . 19
4.2.2.1. Receiving Hello Packets . . . . . . . . . . . . . 21
4.3. The Routing table Structure . . . . . . . . . . . . . . . 22
4.3.1. Routing Table Lookup . . . . . . . . . . . . . . . . . 23
4.4. Link State Advertisements . . . . . . . . . . . . . . . . 23
4.4.1. The LSA Header . . . . . . . . . . . . . . . . . . . . 23
4.4.2. The Link-State Database . . . . . . . . . . . . . . . 24
4.4.3. Originating LSAs . . . . . . . . . . . . . . . . . . . 25
4.4.3.1. LSA Options . . . . . . . . . . . . . . . . . . . 27
4.4.3.2. Router-LSAs . . . . . . . . . . . . . . . . . . . 27
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1。 要件記法. . . . . . . . . . . . . . . . . . 4 1.2 用語. . . . . . . . . . . . . . . . . . . . . . . 4 2。 IPv4. . . . . . . . . . . . . . . . 5 2.1のためのOSPFからの違い。 サブネットではなく、リンクあたり.52.2を処理して、議定書を作ってください。 アドレシング意味論. . . . . . . . . . . . . 5 2.3の取り外し。 氾濫範囲. . . . . . . . . . . . . . . . 6 2.4の添加。 複数のリンク. . . . . 6 2.5あたりの例の明白なサポート。 リンクローカルのアドレス. . . . . . . . . . . . . . . 7 2.6の使用。 認証は.72.7を変えます。 パケット・フォーマットは.82.8を変えます。 LSAは変化. . . . . . . . . . . . . . . . . . . . 9 2.9をフォーマットします。 取り扱いの未知のLSAは.10 2.10をタイプします。 スタッブ/NSSA領域サポート. . . . . . . . . . . . . . . . . . 11 2.11。 ルータID. . . . . . . . . . . . 11 3はネイバーズを特定します。 RFC2740.113.1がある違い。 倍数のサポートは同じリンク. . . . . 11 3.2に連結します。 IPv6. . . . . . . . . . . . . . 12 3.3のためのMOSPFの不賛成。 NSSA仕様. . . . . . . . . . . . . . . . . . . . 12 3.4。 制限をあふれさせるスタッブ領域の未知のLSAが.123.5を非難しました。 LSA抑圧. . . . . . . . . . . . . . . . . . . 12 3.6をリンクしてください。 LSAオプションと接頭語オプションアップデート. . . . . . . . . . 13 3.7。 IPv6のサイトローカルのアドレス. . . . . . . . . . . . . . . . 13 4。 実現の詳細. . . . . . . . . . . . . . . . . . . . 13 4.1。 データ構造. . . . . . . . . . . . . . . . . 14 4.1.1について議定書の中で述べてください。 領域データ構造. . . . . . . . . . . . . . . 15 4.1.2。 インタフェースデータ構造. . . . . . . . . . . . . 15 4.1.3。 隣人データ構造. . . . . . . . . . . . . 16 4.2。 パケット処理. . . . . . . . . . . . . . . . 17 4.2.1について議定書の中で述べてください。 プロトコルパケット. . . . . . . . . . . . . . . 17 4.2.1.1を送ります。 発信、こんにちは、パケット、.184.2 .1 .2。 データベース記述パケット. . . . . . . 19 4.2.2を送ります。 プロトコルパケット. . . . . . . . . . . . . . 19 4.2.2.1を受け取ります。 こんにちはを受ける、パケット. . . . . . . . . . . . . 21 4.3 ルート設定テーブルStructure. . . . . . . . . . . . . . . 22 4.3.1。 索表. . . . . . . . . . . . . . . . . 23 4.4を発送します。 州の広告. . . . . . . . . . . . . . . . 23 4.4.1をリンクしてください。 LSAヘッダー. . . . . . . . . . . . . . . . . . . . 23 4.4.2。 リンク州のデータベース. . . . . . . . . . . . . . . 24 4.4.3。 .1にLSAs. . . . . . . . . . . . . . . . . . . 25 4.4.3を溯源します。 LSAオプション. . . . . . . . . . . . . . . . . . . 27 4.4.3.2。 ルータ-LSAs.27
Coltun, et al. Standards Track [Page 2] RFC 5340 OSPF for IPv6 July 2008
Coltun、他 IPv6 July 2008のための標準化過程[2ページ]RFC5340OSPF
4.4.3.3. Network-LSAs . . . . . . . . . . . . . . . . . . . 29
4.4.3.4. Inter-Area-Prefix-LSAs . . . . . . . . . . . . . . 30
4.4.3.5. Inter-Area-Router-LSAs . . . . . . . . . . . . . . 31
4.4.3.6. AS-External-LSAs . . . . . . . . . . . . . . . . . 32
4.4.3.7. NSSA-LSAs . . . . . . . . . . . . . . . . . . . . 33
4.4.3.8. Link-LSAs . . . . . . . . . . . . . . . . . . . . 34
4.4.3.9. Intra-Area-Prefix-LSAs . . . . . . . . . . . . . . 36
4.4.4. Future LSA Validation . . . . . . . . . . . . . . . . 40
4.5. Flooding . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.5.1. Receiving Link State Update Packets . . . . . . . . . 40
4.5.2. Sending Link State Update Packets . . . . . . . . . . 41
4.5.3. Installing LSAs in the Database . . . . . . . . . . . 43
4.6. Definition of Self-Originated LSAs . . . . . . . . . . . . 43
4.7. Virtual Links . . . . . . . . . . . . . . . . . . . . . . 44
4.8. Routing Table Calculation . . . . . . . . . . . . . . . . 44
4.8.1. Calculating the Shortest-Path Tree for an Area . . . . 45
4.8.2. The Next-Hop Calculation . . . . . . . . . . . . . . . 44
4.8.3. Calculating the Inter-Area Routes . . . . . . . . . . 47
4.8.4. Examining Transit Areas' Summary-LSAs . . . . . . . . 48
4.8.5. Calculating AS External and NSSA Routes . . . . . . . 48
4.9. Multiple Interfaces to a Single Link . . . . . . . . . . . 48
4.9.1. Standby Interface State . . . . . . . . . . . . . . . 50
5. Security Considerations . . . . . . . . . . . . . . . . . . . 52
6. Manageability Considerations . . . . . . . . . . . . . . . . . 52
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 52
7.1. MOSPF for OSPFv3 Deprecation IANA Considerations . . . . . 53
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 53
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 55
9.1. Normative References . . . . . . . . . . . . . . . . . . . 55
9.2. Informative References . . . . . . . . . . . . . . . . . . 56
Appendix A. OSPF Data Formats . . . . . . . . . . . . . . . . . . 57
A.1. Encapsulation of OSPF Packets . . . . . . . . . . . . . . 57
A.2. The Options Field . . . . . . . . . . . . . . . . . . . . 58
A.3. OSPF Packet Formats . . . . . . . . . . . . . . . . . . . 60
A.3.1. The OSPF Packet Header . . . . . . . . . . . . . . . . 60
A.3.2. The Hello Packet . . . . . . . . . . . . . . . . . . . 62
A.3.3. The Database Description Packet . . . . . . . . . . . 63
A.3.4. The Link State Request Packet . . . . . . . . . . . . 65
A.3.5. The Link State Update Packet . . . . . . . . . . . . . 66
A.3.6. The Link State Acknowledgment Packet . . . . . . . . . 67
A.4. LSA Formats . . . . . . . . . . . . . . . . . . . . . . . 68
A.4.1. IPv6 Prefix Representation . . . . . . . . . . . . . . 69
A.4.1.1. Prefix Options . . . . . . . . . . . . . . . . . . 69
A.4.2. The LSA Header . . . . . . . . . . . . . . . . . . . . 70
A.4.2.1. LSA Type . . . . . . . . . . . . . . . . . . . . . 72
A.4.3. Router-LSAs . . . . . . . . . . . . . . . . . . . . . 73
A.4.4. Network-LSAs . . . . . . . . . . . . . . . . . . . . . 76
A.4.5. Inter-Area-Prefix-LSAs . . . . . . . . . . . . . . . . 77
4.4.3.3. ネットワーク-LSAs.294.4、.3 .4。 相互領域はLSAsを前に置きます。.304.4 .3 .5。 相互領域ルータLSAs.314.4、.3 .6。 外部のLSAs、.324.4 .3 .7。 NSSA-LSAs、.334.4 .3 .8。 リンク-LSAs.344.4、.3 .9。 イントラ領域はLSAsを前に置きます。.364.4 .4。 今後のLSA合法化. . . . . . . . . . . . . . . . 40 4.5。 氾濫. . . . . . . . . . . . . . . . . . . . . . . . . 40 4.5.1。 リンク州のアップデートパケット. . . . . . . . . 40 4.5.2を受け取ります。 リンク州のアップデートパケット. . . . . . . . . . 41 4.5.3を送ります。 データベース. . . . . . . . . . . 43 4.6にLSAsをインストールします。 自己によって溯源されたLSAs. . . . . . . . . . . . 43 4.7の定義。 仮想のリンク. . . . . . . . . . . . . . . . . . . . . . 44 4.8。 テーブル計算. . . . . . . . . . . . . . . . 44 4.8.1を発送します。 領域. . . . 45 4.8.2のために最短パス木について計算します。 次のホップ計算. . . . . . . . . . . . . . . 44 4.8.3。 .4に相互領域ルート. . . . . . . . . . 47 4.8を計算します。 .5にトランジット領域の概要-LSAs.484.8を調べます。 外部として計算して、NSSAルート. . . . . . . 48 4.9。 倍数はただ一つのリンク. . . . . . . . . . . 48 4.9.1に連結します。 予備界面準位. . . . . . . . . . . . . . . 50 5。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 52 6。 管理可能性問題. . . . . . . . . . . . . . . . . 52 7。 IANA問題. . . . . . . . . . . . . . . . . . . . . 52 7.1。 OSPFv3不賛成IANA問題. . . . . 53 8のためのMOSPF。 承認. . . . . . . . . . . . . . . . . . . . . . . 53 9。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 55 9.1。 引用規格. . . . . . . . . . . . . . . . . . . 55 9.2。 有益な参照. . . . . . . . . . . . . . . . . . 56付録A.OSPFデータは.57A.1をフォーマットします。 OSPFパケット. . . . . . . . . . . . . . 57A.2のカプセル化。 オプションは.58A.3をさばきます。 OSPFパケット・フォーマット. . . . . . . . . . . . . . . . . . . 60A.3.1。 OSPFパケットのヘッダー.60A.3.2。 こんにちは、パケット. . . . . . . . . . . . . . . . . . . 62A.3.3。 データベース記述パケット. . . . . . . . . . . 63A.3.4。 リンク州のリクエスト・パケット. . . . . . . . . . . . 65A.3.5。 リンク州のアップデートパケット. . . . . . . . . . . . . 66A.3.6。 リンク州の確認応答パケット. . . . . . . . . 67A.4。 LSAは.68A.4.1をフォーマットします。 IPv6は表現. . . . . . . . . . . . . . 69A.4.1.1を前に置きます。 オプション. . . . . . . . . . . . . . . . . . 69A.4.2を前に置いてください。 LSAヘッダー.70A.4.2.1。 LSAは.72A.4.3をタイプします。 ルータ-LSAs.73A.4.4。 ネットワーク-LSAs.76A.4.5。 相互領域接頭語LSAs.77
Coltun, et al. Standards Track [Page 3] RFC 5340 OSPF for IPv6 July 2008
Coltun、他 IPv6 July 2008のための標準化過程[3ページ]RFC5340OSPF
A.4.6. Inter-Area-Router-LSAs . . . . . . . . . . . . . . . . 78
A.4.7. AS-External-LSAs . . . . . . . . . . . . . . . . . . . 79
A.4.8. NSSA-LSAs . . . . . . . . . . . . . . . . . . . . . . 82
A.4.9. Link-LSAs . . . . . . . . . . . . . . . . . . . . . . 82
A.4.10. Intra-Area-Prefix-LSAs . . . . . . . . . . . . . . . . 84
Appendix B. Architectural Constants . . . . . . . . . . . . . . . 86
Appendix C. Configurable Constants . . . . . . . . . . . . . . . 86
C.1. Global Parameters . . . . . . . . . . . . . . . . . . . . 86
C.2. Area Parameters . . . . . . . . . . . . . . . . . . . . . 87
C.3. Router Interface Parameters . . . . . . . . . . . . . . . 88
C.4. Virtual Link Parameters . . . . . . . . . . . . . . . . . 90
C.5. NBMA Network Parameters . . . . . . . . . . . . . . . . . 91
C.6. Point-to-Multipoint Network Parameters . . . . . . . . . . 92
C.7. Host Route Parameters . . . . . . . . . . . . . . . . . . 92
A.4.6。 相互領域ルータLSAs.78A.4.7。 外部のLSAs、.79A.4.8。 NSSA-LSAs. . . . . . . . . . . . . . . . . . . . . . 82A.4.9。 リンク-LSAs.82A.4.10。 .84のイントラ領域接頭語LSAsの付録のB.の建築定数. . . . . . . . . . . . . . . 86の付録のC.の構成可能な定数. . . . . . . . . . . . . . . 86C.1。 グローバルなパラメタ. . . . . . . . . . . . . . . . . . . . 86C.2。 領域パラメタ. . . . . . . . . . . . . . . . . . . . . 87C.3。 ルータインタフェース・パラメータ. . . . . . . . . . . . . . . 88C.4。 仮想のリンクパラメータ. . . . . . . . . . . . . . . . . 90C.5。 NBMAはパラメタ. . . . . . . . . . . . . . . . . 91C.6をネットワークでつなぎます。 ポイントツーマルチポイント回路パラメータ. . . . . . . . . . 92C.7。 ホストルートパラメタ. . . . . . . . . . . . . . . . . . 92
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, Designated Router (DR) election, area support, (Shortest Path First) SPF calculations, etc.) remain unchanged. However, some changes have been necessary, either due to changes in protocol semantics between IPv4 and IPv6, or simply to handle the increased address size of IPv6. These modifications will necessitate incrementing the protocol version from version 2 to version 3. OSPF for IPv6 is also referred to as OSPF version 3 (OSPFv3).
このドキュメントは、インターネットプロトコル(IPv6)のバージョン6を支持するために変更をOSPFに説明します。 OSPF(氾濫、Designated Router(DR)選挙、領域サポート、(最も短いPath First)SPF計算など)の基本的機構は変わりがありません。 しかしながら、いくつかの変化が必要です、IPv4とIPv6の間のプロトコル意味論における変化か単にのどちらかIPv6の増加するアドレスサイズのハンドルに。 これらの変更は、バージョン3によってプロトコルバージョンを増加するのを必要とするでしょう。 また、IPv6のためのOSPFはOSPFバージョン3(OSPFv3)と呼ばれます。
This document is organized as follows. Section 2 describes the differences between OSPF for IPv4 (OSPF version 2) and OSPF for IPv6 (OSPF version 3) in detail. Section 3 describes the difference between RFC 2740 and this document. Section 4 provides implementation details for the changes. Appendix A gives the OSPF for IPv6 packet and Link State Advertisement (LSA) formats. Appendix B lists the OSPF architectural constants. Appendix C describes configuration parameters.
このドキュメントは以下の通りまとめられます。 セクション2は詳細にIPv4のためのOSPF(OSPFバージョン2)とIPv6のためのOSPF(OSPFバージョン3)の違いについて説明します。 セクション3はRFC2740とこのドキュメントの違いについて説明します。 セクション4は変化のための実現詳細を明らかにします。 付録AはIPv6パケットとLink州Advertisement(LSA)形式のためにOSPFに与えます。 付録BはOSPFの建築定数を記載します。 付録Cは設定パラメータについて説明します。
1.1. Requirements Notation
1.1. 要件記法
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC-KEYWORDS].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC-キーワード]で説明されるように本書では解釈されることであるべきですか?
1.2. Terminology
1.2. 用語
This document attempts to use terms from both the OSPF for IPv4 specification ([OSPFV2]) and the IPv6 protocol specifications ([IPV6]). This has produced a mixed result. Most of the terms used both by OSPF and IPv6 have roughly the same meaning (e.g.,
このドキュメントは、IPv4仕様のためのOSPF([OSPFV2])とIPv6プロトコル仕様([IPV6])の両方からの用語を使用するのを試みます。 これは複雑な結果を生みました。 OSPFとIPv6によって使用された用語の大部分にはおよそ同じ意味がある、(例えば。
Coltun, et al. Standards Track [Page 4] RFC 5340 OSPF for IPv6 July 2008
Coltun、他 IPv6 July 2008のための標準化過程[4ページ]RFC5340OSPF
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).
インタフェース) しかしながら、いくつかの闘争があります。 IPv6用途は同様にIPv4 OSPFの「サブネット」か「ネットワーク」に「リンクされます」。 この場合、私たちは、IPv6の「リンク」用語を使用するのを選びました。 「リンク」はほとんどの場所で本書ではOSPFの「サブネット」と「ネットワーク」を取り替えます、OSPFのネットワーク-LSAは変わりがありませんが(また、ことによると残念ながら、新しいリンク-LSAは作成されました)。
The names of some of the OSPF LSAs have also changed. See Section 2.8 for details.
また、いくつかのOSPF LSAsという名前は変化しました。 詳細に関してセクション2.8を見てください。
In the context of this document, an OSPF instance is a separate protocol instance complete with its own protocol data structures (e.g., areas, interfaces, neighbors), link-state database, protocol state machines, and protocol processing (e.g., SPF calculation).
このドキュメントの文脈では、OSPF例はそれ自身のプロトコルデータ構造(例えば、領域、インタフェース、隣人)、リンク州のデータベース、プロトコル州のマシン、およびプロトコル処理(例えば、SPF計算)で完全な別々のプロトコル例です。
2. Differences from OSPF for IPv4
2. IPv4のためのOSPFからの違い
Most of the algorithms from OSPF for IPv4 [OSPFV2] have been preserved in OSPF for IPv6. However, some changes have been necessary, either due to changes in protocol semantics between IPv4 and IPv6, or simply to handle the increased address size of IPv6.
IPv4[OSPFV2]のためのOSPFからのアルゴリズムの大部分はIPv6のためにOSPFに保存されました。 しかしながら、いくつかの変化が必要です、IPv4とIPv6の間のプロトコル意味論における変化か単にのどちらかIPv6の増加するアドレスサイズのハンドルに。
The following subsections describe the differences between this document and [OSPFV2].
以下の小区分はこのドキュメントと[OSPFV2]の違いについて説明します。
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" ([IPV6]). "Interfaces" connect to links. Multiple IPv6 subnets can be assigned to a single link, and two nodes can talk directly over a single link, even if they do not share a common IPv6 subnet (IPv6 prefix).
IPv6は、「ノードがリンクレイヤで交信できる通信機器か媒体」([IPV6])を示すのに「リンク」という用語を使用します。 「インタフェース」はリンクに接続します。 複数のIPv6サブネットを単一のリンクに割り当てることができます、そして、2つのノードが直接単一のリンクについて論議できます、一般的なIPv6サブネット(IPv6接頭語)を共有しないでも。
For this reason, OSPF for IPv6 runs per-link instead of the IPv4 behavior of per-IP-subnet. The terms "network" and "subnet" used in the IPv4 OSPF specification ([OSPFV2]) should generally be replaced by link. Likewise, an OSPF interface now connects to a link instead of an IP subnet.
IPv6のためのOSPFは、これが推論するとIPサブネット単位でIPv4の代わりにリンク振舞いを述べます。 一般に、「ネットワーク」と「サブネット」がIPv4 OSPF仕様([OSPFV2])で使用した用語をリンクに取り替えるべきです。 同様に、OSPFインタフェースは現在、IPサブネットの代わりにリンクに接続します。
This change affects the receiving of OSPF protocol packets, the contents of Hello packets, and the contents of network-LSAs.
この変化はOSPFプロトコルパケットの受信、Helloパケットのコンテンツ、およびネットワーク-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タイプから取り除いてください、そうした、ネットワークのプロトコルから独立しているコアを残して。 特に:
Coltun, et al. Standards Track [Page 5] RFC 5340 OSPF for IPv6 July 2008
Coltun、他 IPv6 July 2008のための標準化過程[5ページ]RFC5340OSPF
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パケットによって運ばれたLSAペイロード以外に、IPv6アドレスは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とネットワーク-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.
Previously, they had been identified by an IPv4 address on
broadcast, NBMA (Non-Broadcast Multi-Access), and point-to-
multipoint links.
o 隣接しているルータは現在、いつもRouter IDによって特定されます。 以前、それらは放送、NBMA(非放送Multi-アクセス)、およびポイントから多点へのリンクに関するIPv4アドレスによって特定されていました。
2.3. Addition of Flooding Scope
2.3. 氾濫範囲の添加
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があります:
o Link-local scope. LSA is only flooded on the local link and no
further. Used for the new link-LSA. See Section 4.4.3.8 for
details.
o リンク地方の範囲。 LSAは地方のリンクにこれ以上水につかっているだけです。 新しいリンク-LSAにおいて、使用されています。 セクション4.4を見てください。.3 .8 詳細のために。
o Area scope. LSA is only flooded throughout a single OSPF area.
Used for router-LSAs, network-LSAs, inter-area-prefix-LSAs, inter-
area-router-LSAs, and intra-area-prefix-LSAs.
o 領域の範囲。 LSAはただ一つのOSPF領域中で水につかっているだけです。 ルータ-LSAs、ネットワーク-LSAsにおいて使用されていて、相互領域がLSAsを前に置く、相互領域ルータLSAs、イントラ領域はLSAsを前に置きます。
o AS scope. LSA is flooded throughout the routing domain. Used for
AS-external-LSAs. A router that originates AS scoped LSAs is
considered an AS Boundary Router (ASBR) and will set its E-bit in
router-LSAs for regular areas.
o AS範囲。 LSAは経路ドメイン中で水につかっています。 外部のLSAsとして、使用されています。 ASを溯源するルータは、LSAsがAS Boundary Router(ASBR)であると考えられるのを見て、通常の領域のためにルータ-LSAsにE-ビットをはめ込むでしょう。
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 supporting separate OSPF routing domains that wish to remain separate even though they have one or more physical network segments (i.e., links) in common. In OSPF for IPv4, this was supported in a haphazard fashion using the authentication fields in the OSPF for IPv4 header.
OSPFは現在、単一のリンクの上の複数のOSPFプロトコル例を走らせる能力を支持します。 例えば、これがいくつかのプロバイダーの間で共有されたNAPセグメントで必要であるかもしれません。 プロバイダーは一般的に1つ以上の物理ネットワークセグメント(すなわち、リンク)を持っていますが、別々のままで残りたがっている別々のOSPF経路ドメインを、支持しているかもしれません。 IPv4のためのOSPFでは、これは、IPv4ヘッダーにOSPFの認証分野を使用しながら、行き当たりばったりのやり方で支持されました。
Coltun, et al. Standards Track [Page 6] RFC 5340 OSPF for IPv6 July 2008
Coltun、他 IPv6 July 2008のための標準化過程[6ページ]RFC5340OSPF
Another use for running multiple OSPF instances is if you want, for one reason or another, to have a single link belong to two or more OSPF areas.
複数のOSPF例を走らせる別の使用はあなたが単一のリンクに何らかの理由のために2つ以上のOSPF領域に属させたがっているかどうかということです。
Support for multiple protocol instances on a link is accomplished via an "Instance ID" contained in the OSPF packet header and OSPF interface data structures. Instance ID solely affects the reception of OSPF packets and applies to normal OSPF interfaces and virtual links.
リンクの上の複数のプロトコル例のサポートはOSPFパケットのヘッダーとOSPFインタフェースデータ構造に含まれた「Instance ID」を通して実行されます。 例のIDは、唯一OSPFパケットのレセプションに影響して、正常な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 [IP6ADDR]. Link-local unicast addresses are assigned from the IPv6 address range FE80/10.
IPv6のリンクローカルのアドレスは単一のリンクにおける使用、隣人発見、自動構成などの目的のためのものです。 IPv6ルータはリンク地元筋アドレス[IP6ADDR]を持っているデータグラムをIPv6に送りません。 リンクローカルのユニキャストアドレスはIPv6アドレス範囲FE80/10から割り当てられます。
OSPF for IPv6 assumes that each router has been assigned link-local unicast addresses on each of the router's attached physical links [IP6ADDR]. On all OSPF interfaces except virtual links, OSPF packets are sent using the interface's associated link-local unicast address as the source address. A router learns the link-local addresses of all other routers attached to its links and uses these addresses as next-hop information during packet forwarding.
IPv6のためのOSPFは、各ルータはそれぞれのルータの付属物理的なリンク[IP6ADDR]にリンクローカルのユニキャストアドレスを割り当ててあると仮定します。 仮想のリンク以外のすべてのOSPFインタフェースに、ソースアドレスとしてインタフェースの関連リンクローカルのユニキャストアドレスをOSPFパケットを使用させます。 ルータは、リンクに付けられた他のすべてのルータのリンクローカルのアドレスを学んで、パケット推進の間、次のホップ情報としてこれらのアドレスを使用します。
On virtual links, a global scope IPv6 address MUST be used as the source address for OSPF protocol packets.
仮想のリンクの上では、OSPFプロトコルパケットにソースアドレスとしてグローバルな範囲IPv6アドレスを使用しなければなりません。
Link-local addresses appear in OSPF link-LSAs (see Section 4.4.3.8). However, link-local addresses are not allowed in other OSPF LSA types. In particular, link-local addresses MUST NOT be advertised in inter-area-prefix-LSAs (Section 4.4.3.4), AS-external-LSAs (Section 4.4.3.6), NSSA-LSAs (Section 4.4.3.7), or intra-area-prefix- LSAs (Section 4.4.3.9).
セクション4.4を見てください。リンクローカルのアドレスがOSPFリンク-LSAsに現れる、(.3 .8)。 しかしながら、リンクローカルのアドレスは他のOSPF LSAタイプで許容されていません。 特に、相互領域がLSAsを前に置いた状態で中にリンクローカルのアドレスの広告を出してはいけない、(セクション4.4.3、.4、)ASの外部のLSAs、(セクション4.4 .3 .6、)NSSA-LSAs、(セクション4.4.3の.7)、またはイントラ領域接頭語-LSAs、(セクション4.4 .3 .9)。
2.6. Authentication Changes
2.6. 認証変化
In OSPF for IPv6, authentication has been removed from the OSPF protocol. The "AuType" and "Authentication" fields have been removed from the OSPF packet header, and all authentication-related fields have been removed from the OSPF area and interface data structures.
IPv6のためのOSPFでは、OSPFプロトコルから認証を取り除きました。 OSPFパケットのヘッダーから"AuType"と「認証」野原を取り除きました、そして、OSPF領域とインタフェースデータ構造からすべての認証関連の野原を取り除きました。
When running over IPv6, OSPF relies on the IP Authentication Header (see [IPAUTH]) and the IP Encapsulating Security Payload (see [IPESP]) as described in [OSPFV3-AUTH] to ensure integrity and authentication/confidentiality of routing exchanges.
IPv6をひくとき、OSPFはルーティング交換の保全と認証/秘密性を確実にするために[OSPFV3-AUTH]で説明されるようにIP Authentication Header([IPAUTH]を見る)とIP Encapsulating Security有効搭載量([IPESP]を見る)を当てにします。
Coltun, et al. Standards Track [Page 7] RFC 5340 OSPF for IPv6 July 2008
Coltun、他 IPv6 July 2008のための標準化過程[7ページ]RFC5340OSPF
Protection of OSPF packet exchanges against accidental data corruption is provided by the standard IPv6 Upper-Layer checksum (as described in Section 8.1 of [IPV6]), covering the entire OSPF packet and prepended IPv6 pseudo-header (see Appendix A.3.1).
標準のIPv6 Upper-層のチェックサムで偶然のデータの汚染に対するOSPFパケット交換の保護を提供します([IPV6]のセクション8.1で説明されるように)、全体のOSPFパケットとprepended IPv6疑似ヘッダーを覆っていて(Appendix 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 incremented from 2 to 3.
o OSPFバージョン番号は2〜3まで増加されました。
o The Options field in Hello packets and Database Description
packets has been expanded to 24 bits.
o HelloパケットとDatabase記述パケットのOptions分野を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.
Rather, it now includes an Interface ID that the originating
router has assigned to uniquely identify (among its own
interfaces) its interface to the link. This Interface ID will be
used as the network-LSA's Link State ID if the router becomes the
Designated Router on the link.
o Helloパケットは現在、アドレス情報を全く含みません。 むしろ、それは現在、由来しているルータが唯一インタフェースをリンクまで特定する(それ自身のインタフェースの中で)ために割り当てたInterface IDを含んでいます。 ルータがリンクの上のDesignated Routerになると、このInterface IDはネットワーク-LSA Link州IDとして使用されるでしょう。
o Two Options bits, the "R-bit" and the "V6-bit", have been added to
the Options field for processing router-LSAs during the SPF
calculation (see Appendix A.2). If the "R-bit" is clear, an OSPF
speaker can participate in OSPF topology distribution without
being used to forward transit traffic; this can be used in multi-
homed hosts that want to participate in the routing protocol. The
V6-bit specializes the R-bit; if the V6-bit is clear, an OSPF
speaker can participate in OSPF topology distribution without
being used to forward IPv6 datagrams. If the R-bit is set and the
V6-bit is clear, IPv6 datagrams are not forwarded but datagrams
belonging to another protocol family may be forwarded.
o 「R-ビット」と「V6-ビット」という2Optionsビットは、処理ルータ-LSAsのためにSPF計算の間、Options分野に加えられます(Appendix A.2を見てください)。 「R-ビット」が明確であるなら、トランジット交通を進めるのに使用されないで、OSPFスピーカーはOSPFトポロジー分配に参加できます。 これを使用できる、マルチ、家へ帰り、ルーティングに参加したがっているホストが議定書を作ります。 V6-ビットはR-ビットを専門にします。 V6-ビットが明確であるなら、データグラムをIPv6に送るのに使用されないで、OSPFスピーカーはOSPFトポロジー分配に参加できます。R-ビットが設定されて、V6-ビットが明確であるなら、IPv6データグラムを進めませんが、もう1プロトコル家族のものであるデータグラムを進めるかもしれません。
o The OSPF packet header now includes an "Instance ID" that allows
multiple OSPF protocol instances to be run on a single link (see
Section 2.4).
o OSPFパケットのヘッダーは現在、複数のOSPFプロトコル例を単一のリンクの上に走らせる「Instance ID」を入れます(セクション2.4を見てください)。
Coltun, et al. Standards Track [Page 8] RFC 5340 OSPF for IPv6 July 2008
Coltun、他 IPv6 July 2008のための標準化過程[8ページ]RFC5340OSPF
2.8. LSA Format Changes
2.8. LSA形式変化
All addressing semantics have been removed from the LSA header, router-LSAs, and network-LSAs. These two LSAs now describe the routing domain's topology in a network-protocol-independent manner. New LSAs have been added to distribute IPv6 address information and data required for next-hop resolution. The names of some of IPv4's LSAs have been changed to be more consistent with each other.
LSAヘッダー、ルータ-LSAs、およびネットワーク-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 Appendix A.2 for
details.
o Options野原は、LSAヘッダーから移されて、24ビットに膨張して、ルータ-LSAsのボディーに動かされました、ネットワーク-LSAs、相互領域ルータLSAs、LSAsをリンクします。 詳細に関してAppendix 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 Appendix A.4.1). The default
route is expressed as a prefix with length 0.
o LSAsのアドレスは現在、[アドレス、マスク]の代わりに[接頭語、接頭語の長さ]として表されます(Appendix A.4.1を見てください)。 デフォルトルートは接頭語として長さ0で急送されます。
o Router-LSAs and network-LSAs now have no address information and
are network protocol independent.
o ルータ-LSAsとネットワーク-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 ルータインターフェース情報は複数のルータLSAsの向こう側に広げられるかもしれません。 受信機はSPF計算を走らせるとき与えられたルータによって溯源されたすべてのルータ-LSAsを連結しなければなりません。
o A new LSA called the link-LSA has been introduced. Link-LSAs have
link-local flooding scope; they are never flooded beyond the link
with which they are associated. Link-LSAs have three purposes: 1)
they provide the router's link-local address to all other routers
attached to the link, 2) they inform other routers attached to the
link of a list of IPv6 prefixes to associate with the link, and 3)
they allow the router to advertise a collection of Options bits to
associate with the network-LSA that will be originated for the
link. See Section 4.4.3.8 for details.
o LSAをリンクすると呼ばれる新しいLSAを導入しました。 リンク-LSAsには、リンク地方の氾濫範囲があります。 それらはそれらが関連しているリンクを超えて決して水につかっていません。 リンク-LSAsには、3つの目的があります: 1) 彼らはリンクに付けられた他のすべてのルータ、リンクに溯源されるネットワーク-LSAと交際するためにOptionsビットの収集の広告を出すためにルータを許容することをリンク、および3に関連づけるIPv6接頭語のリストのリンクに付けられた他のルータ) それらに知らせる2に)ルータのリンクローカルアドレスを提供します。 セクション4.4を見てください。.3 .8 詳細のために。
o In IPv4, the router-LSA carries a router's IPv4 interface
addresses, the IPv4 equivalent of link-local addresses. These are
only used when calculating next hops during the OSPF routing
calculation (see Section 16.1.1 of [OSPFV2]), so they do not need
to be flooded past the local link. Hence, using link-LSAs to
distribute these addresses is more efficient. Note that link-
local addresses cannot be learned through the reception of Hellos
o IPv4では、ルータ-LSAはルータのIPv4インターフェース・アドレス、リンクローカルのアドレスのIPv4同等物を運びます。 OSPFルーティング計算の間次のホップについて計算するときだけ、これらが使用されるので(.1セクション16.1[OSPFV2]を見てください)、それらは地方のリンクで水につかる必要はありません。 したがって、これらのアドレスを配布するのにリンク-LSAsを使用するのは、より効率的です。 ハローズの受付でリンクのローカルのアドレスについて学習できないことに注意してください。
Coltun, et al. Standards Track [Page 9] RFC 5340 OSPF for IPv6 July 2008
Coltun, et al. Standards Track [Page 9] RFC 5340 OSPF for IPv6 July 2008
in all cases. On NBMA links, next-hop routers do not necessarily
exchange Hellos. Rather, these routers learn of each other's
existence by way of the Designated Router (DR).
in all cases. On NBMA links, next-hop routers do not necessarily exchange Hellos. Rather, these routers learn of each other's existence by way of the Designated Router (DR).
o 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 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 Type-3 summary-LSAs have been renamed "inter-area-prefix-LSAs".
Type-4 summary LSAs have been renamed "inter-area-router-LSAs".
o Type-3 summary-LSAs have been renamed "inter-area-prefix-LSAs". Type-4 summary LSAs have been renamed "inter-area-router-LSAs".
o The Link State ID in inter-area-prefix-LSAs, inter-area-router-
LSAs, NSSA-LSAs, and AS-external-LSAs has lost its addressing
semantics and now serves solely to identify individual pieces of
the Link State Database. All addresses or Router IDs that were
formerly expressed by the Link State ID are now carried in the LSA
bodies.
o The Link State ID in inter-area-prefix-LSAs, inter-area-router- LSAs, NSSA-LSAs, and AS-external-LSAs has lost its addressing semantics and now serves solely to identify individual pieces of the Link State Database. All addresses or Router IDs that were formerly expressed by the Link State ID are now carried in the LSA bodies.
o 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 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 A new LSA called the intra-area-prefix-LSA has been introduced.
This LSA carries all IPv6 prefix information that in IPv4 is
included in router-LSAs and network-LSAs. See Section 4.4.3.9 for
details.
o A new LSA called the intra-area-prefix-LSA has been introduced. This LSA carries all IPv6 prefix information that in IPv4 is included in router-LSAs and network-LSAs. See Section 4.4.3.9 for details.
o Inclusion of a forwarding address or external route tag in AS-
external-LSAs is now optional. In addition, AS-external-LSAs can
now reference another LSA, for inclusion of additional route
attributes that are outside the scope of the OSPF protocol. For
example, this reference could be used to attach BGP path
attributes to external routes.
o Inclusion of a forwarding address or external route tag in AS- external-LSAs is now optional. In addition, AS-external-LSAs can now reference another LSA, for inclusion of additional route attributes that are outside the scope of the OSPF protocol. For example, this reference could be used to attach BGP path attributes to external routes.
2.9. Handling Unknown LSA Types
2.9. Handling Unknown LSA Types
Handling of unknown LSA types has been made more flexible so that, based on the LS type, unknown LSA types are either treated as having link-local flooding scope, or are stored and flooded as if they were understood. This behavior is explicitly coded in the LSA Handling bit of the link state header's LS type field (see the U-bit in Appendix A.4.2.1).
Handling of unknown LSA types has been made more flexible so that, based on the LS type, unknown LSA types are either treated as having link-local flooding scope, or are stored and flooded as if they were understood. This behavior is explicitly coded in the LSA Handling bit of the link state header's LS type field (see the U-bit in Appendix A.4.2.1).
Coltun, et al. Standards Track [Page 10] RFC 5340 OSPF for IPv6 July 2008
Coltun, et al. Standards Track [Page 10] RFC 5340 OSPF for IPv6 July 2008
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.
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.
2.10. Stub/NSSA Area Support
2.10. Stub/NSSA Area Support
In OSPF for IPv4, stub and NSSA areas were designed to minimize link- state database and routing table sizes for the areas' internal routers. This allows routers with minimal resources to participate in even very large OSPF routing domains.
In OSPF for IPv4, stub and NSSA areas were designed to minimize link- state database and routing table sizes for the areas' internal routers. This allows routers with minimal resources to participate in even very large OSPF routing domains.
In OSPF for IPv6, the concept of stub and NSSA areas is retained. In IPv6, of the mandatory LSA types, stub areas carry only router-LSAs, network-LSAs, inter-area-prefix-LSAs, link-LSAs, and intra-area- prefix-LSAs. NSSA areas are restricted to these types and, of course, NSSA-LSAs. This is the IPv6 equivalent of the LSA types carried in IPv4 stub areas: router-LSAs, network-LSAs, type 3 summary-LSAs and for NSSA areas: stub area types and NSSA-LSAs.
In OSPF for IPv6, the concept of stub and NSSA areas is retained. In IPv6, of the mandatory LSA types, stub areas carry only router-LSAs, network-LSAs, inter-area-prefix-LSAs, link-LSAs, and intra-area- prefix-LSAs. NSSA areas are restricted to these types and, of course, NSSA-LSAs. This is the IPv6 equivalent of the LSA types carried in IPv4 stub areas: router-LSAs, network-LSAs, type 3 summary-LSAs and for NSSA areas: stub area types and NSSA-LSAs.
2.11. Identifying Neighbors by Router ID
2.11. Identifying Neighbors by 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 while neighbors on broadcast, NBMA, and point-to-multipoint links are identified by their IPv4 interface addresses.
In OSPF for IPv6, neighboring routers on a given link are always identified by their OSPF Router ID. This contrasts with the IPv4 behavior where neighbors on point-to-point networks and virtual links are identified by their Router IDs while neighbors on broadcast, NBMA, and point-to-multipoint links are identified by their IPv4 interface addresses.
This change affects the reception of OSPF packets (see Section 8.2 of [OSPFV2]), the lookup of neighbors (Section 10 of [OSPFV2]), and the reception of Hello packets (Section 10.5 of [OSPFV2]).
This change affects the reception of OSPF packets (see Section 8.2 of [OSPFV2]), the lookup of neighbors (Section 10 of [OSPFV2]), and the reception of Hello packets (Section 10.5 of [OSPFV2]).
The Router ID of 0.0.0.0 is reserved and SHOULD NOT be used.
The Router ID of 0.0.0.0 is reserved and SHOULD NOT be used.
3. Differences with RFC 2740
3. Differences with RFC 2740
OSPFv3 implementations based on RFC 2740 will fully interoperate with implementations based on this specification. There are, however, some protocol additions and changes (all of which are backward compatible).
OSPFv3 implementations based on RFC 2740 will fully interoperate with implementations based on this specification. There are, however, some protocol additions and changes (all of which are backward compatible).
3.1. Support for Multiple Interfaces on the Same Link
3.1. Support for Multiple Interfaces on the Same Link
This protocol feature was only partially specified in the RFC 2740. The level of specification was insufficient to implement the feature. Section 4.9 specifies the additions and clarifications necessary for implementation. They are fully compatible with RFC 2740.
This protocol feature was only partially specified in the RFC 2740. The level of specification was insufficient to implement the feature. Section 4.9 specifies the additions and clarifications necessary for implementation. They are fully compatible with RFC 2740.
Coltun, et al. Standards Track [Page 11] RFC 5340 OSPF for IPv6 July 2008
Coltun, et al. Standards Track [Page 11] RFC 5340 OSPF for IPv6 July 2008
3.2. Deprecation of MOSPF for IPv6
3.2. Deprecation of MOSPF for IPv6
This protocol feature was only partially specified in RFC 2740. The level of specification was insufficient to implement the feature. There are no known implementations. Multicast Extensions to OSPF (MOSPF) support and its attendant protocol fields have been deprecated from OSPFv3. Refer to Section 4.4.3.2, Section 4.4.3.4, Section 4.4.3.6, Section 4.4.3.7, Appendix A.2, Appendix A.4.2.1, Appendix A.4.3, Appendix A.4.1.1, and Section 7.1.
This protocol feature was only partially specified in RFC 2740. The level of specification was insufficient to implement the feature. There are no known implementations. Multicast Extensions to OSPF (MOSPF) support and its attendant protocol fields have been deprecated from OSPFv3. Refer to Section 4.4.3.2, Section 4.4.3.4, Section 4.4.3.6, Section 4.4.3.7, Appendix A.2, Appendix A.4.2.1, Appendix A.4.3, Appendix A.4.1.1, and Section 7.1.
3.3. NSSA Specification
3.3. NSSA Specification
This protocol feature was only partially specified in RFC 2740. The level of specification was insufficient to implement the function. This document includes an NSSA specification unique to OSPFv3. This specification coupled with [NSSA] provide sufficient specification for implementation. Refer to Section 4.8.5, Appendix A.4.3, Appendix A.4.8, and [NSSA].
This protocol feature was only partially specified in RFC 2740. The level of specification was insufficient to implement the function. This document includes an NSSA specification unique to OSPFv3. This specification coupled with [NSSA] provide sufficient specification for implementation. Refer to Section 4.8.5, Appendix A.4.3, Appendix A.4.8, and [NSSA].
3.4. Stub Area Unknown LSA Flooding Restriction Deprecated
3.4. Stub Area Unknown LSA Flooding Restriction Deprecated
In RFC 2740 [OSPFV3], flooding of unknown LSA was restricted within stub and NSSA areas. The text describing this restriction is included below.
In RFC 2740 [OSPFV3], flooding of unknown LSA was restricted within stub and NSSA areas. The text describing this restriction is included below.
However, unlike in IPv4, IPv6 allows LSAs with unrecognized
LS types to be labeled "Store and flood the LSA, as if type
understood" (see the U-bit in Appendix A.4.2.1). Uncontrolled
introduction of such LSAs could cause a stub area's link-state
database to grow larger than its component routers' capacities.
However, unlike in IPv4, IPv6 allows LSAs with unrecognized LS types to be labeled "Store and flood the LSA, as if type understood" (see the U-bit in Appendix A.4.2.1). Uncontrolled introduction of such LSAs could cause a stub area's link-state database to grow larger than its component routers' capacities.
To guard against this, the following rule regarding stub areas
has been established: an LSA whose LS type is unrecognized can
only be flooded into/throughout a stub area if both a) the LSA
has area or link-local flooding scope and b) the LSA has U-bit
set to 0. See Section 3.5 for details.
To guard against this, the following rule regarding stub areas has been established: an LSA whose LS type is unrecognized can only be flooded into/throughout a stub area if both a) the LSA has area or link-local flooding scope and b) the LSA has U-bit set to 0. See Section 3.5 for details.
This restriction has been deprecated. OSPFv3 routers will flood link and area scope LSAs whose LS type is unrecognized and whose U-bit is set to 1 throughout stub and NSSA areas. There are no backward- compatibility issues other than OSPFv3 routers still supporting the restriction may not propagate newly defined LSA types.
This restriction has been deprecated. OSPFv3 routers will flood link and area scope LSAs whose LS type is unrecognized and whose U-bit is set to 1 throughout stub and NSSA areas. There are no backward- compatibility issues other than OSPFv3 routers still supporting the restriction may not propagate newly defined LSA types.
3.5. Link LSA Suppression
3.5. Link LSA Suppression
The LinkLSASuppression interface configuration parameter has been added. If LinkLSASuppression is configured for an interface and the interface type is not broadcast or NBMA, origination of the link-LSA
The LinkLSASuppression interface configuration parameter has been added. If LinkLSASuppression is configured for an interface and the interface type is not broadcast or NBMA, origination of the link-LSA
Coltun, et al. Standards Track [Page 12] RFC 5340 OSPF for IPv6 July 2008
Coltun, et al. Standards Track [Page 12] RFC 5340 OSPF for IPv6 July 2008
may be suppressed. The LinkLSASuppression interface configuration parameter is described in Appendix C.3. Section 4.8.2 and Section 4.4.3.8 were updated to reflect the parameter's usage.
may be suppressed. The LinkLSASuppression interface configuration parameter is described in Appendix C.3. Section 4.8.2 and Section 4.4.3.8 were updated to reflect the parameter's usage.
3.6. LSA Options and Prefix Options Updates
3.6. LSA Options and Prefix Options Updates
The LSA Options and Prefix Options fields have been updated to reflect recent protocol additions. Specifically, bits related to MOSPF have been deprecated, Options field bits common with OSPFv2 have been reserved, and the DN-bit has been added to the prefix- options. Refer to Appendix A.2 and Appendix A.4.1.1.
The LSA Options and Prefix Options fields have been updated to reflect recent protocol additions. Specifically, bits related to MOSPF have been deprecated, Options field bits common with OSPFv2 have been reserved, and the DN-bit has been added to the prefix- options. Refer to Appendix A.2 and Appendix A.4.1.1.
3.7. IPv6 Site-Local Addresses
3.7. IPv6 Site-Local Addresses
All references to IPv6 site-local addresses have been removed.
All references to IPv6 site-local addresses have been removed.
4. Implementation Details
4. Implementation Details
When going from IPv4 to IPv6, the basic OSPF mechanisms remain unchanged from those documented in [OSPFV2]. These mechanisms are briefly outlined in Section 4 of [OSPFV2]. Both IPv6 and IPv4 have a link-state database composed of LSAs and synchronized between adjacent routers. Initial synchronization is performed through the Database Exchange process, which includes the exchange of Database Description, Link State Request, and Link State Update packets. Thereafter, database synchronization is maintained via flooding, utilizing Link State Update and Link State Acknowledgment packets. Both IPv6 and IPv4 use OSPF Hello packets to discover and maintain neighbor relationships, as well as to elect Designated Routers and Backup Designated Routers on broadcast and NBMA links. The decision as to which neighbor relationships become adjacencies, and the basic ideas behind inter-area routing, importing external information in AS-external-LSAs, and the various routing calculations are also the same.
When going from IPv4 to IPv6, the basic OSPF mechanisms remain unchanged from those documented in [OSPFV2]. These mechanisms are briefly outlined in Section 4 of [OSPFV2]. Both IPv6 and IPv4 have a link-state database composed of LSAs and synchronized between adjacent routers. Initial synchronization is performed through the Database Exchange process, which includes the exchange of Database Description, Link State Request, and Link State Update packets. Thereafter, database synchronization is maintained via flooding, utilizing Link State Update and Link State Acknowledgment packets. Both IPv6 and IPv4 use OSPF Hello packets to discover and maintain neighbor relationships, as well as to elect Designated Routers and Backup Designated Routers on broadcast and NBMA links. The decision as to which neighbor relationships become adjacencies, and the basic ideas behind inter-area routing, importing external information in AS-external-LSAs, and the various routing calculations are also the same.
In particular, the following IPv4 OSPF functionality described in [OSPFV2] remains completely unchanged for IPv6:
In particular, the following IPv4 OSPF functionality described in [OSPFV2] remains completely unchanged for IPv6:
o Both IPv4 and IPv6 use OSPF packet types described in Section 4.3
of [OSPFV2], namely: Hello, Database Description, Link State
Request, Link State Update, and Link State Acknowledgment packets.
While in some cases (e.g., Hello packets) their format has changed
somewhat, the functions of the various packet types remain the
same.
o Both IPv4 and IPv6 use OSPF packet types described in Section 4.3 of [OSPFV2], namely: Hello, Database Description, Link State Request, Link State Update, and Link State Acknowledgment packets. While in some cases (e.g., Hello packets) their format has changed somewhat, the functions of the various packet types remain the same.
Coltun, et al. Standards Track [Page 13] RFC 5340 OSPF for IPv6 July 2008
Coltun, et al. Standards Track [Page 13] RFC 5340 OSPF for IPv6 July 2008
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 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 The discovery and maintenance of neighbor relationships, and the
selection and establishment of adjacencies, remain the same. This
includes election of the Designated Router and Backup Designated
Router on broadcast and NBMA links. These mechanisms are
described in Sections 7, 7.1, 7.2, 7.3, 7.4, and 7.5 of [OSPFV2].
o The discovery and maintenance of neighbor relationships, and the selection and establishment of adjacencies, remain the same. This includes election of the Designated Router and Backup Designated Router on broadcast and NBMA links. These mechanisms are described in Sections 7, 7.1, 7.2, 7.3, 7.4, and 7.5 of [OSPFV2].
o 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 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 The interface state machine, including the list of OSPF interface
states and events, and the Designated Router and Backup Designated
Router election algorithm remain unchanged. These are described
in Sections 9.1, 9.2, 9.3, and 9.4 of [OSPFV2].
o The interface state machine, including the list of OSPF interface states and events, and the Designated Router and Backup Designated Router election algorithm remain unchanged. These are described in Sections 9.1, 9.2, 9.3, and 9.4 of [OSPFV2].
o The neighbor state machine, including the list of OSPF neighbor
states and events, remains unchanged. The neighbor state machine
is described in Sections 10.1, 10.2, 10.3, and 10.4 of [OSPFV2].
o The neighbor state machine, including the list of OSPF neighbor states and events, remains unchanged. The neighbor state machine is described in Sections 10.1, 10.2, 10.3, and 10.4 of [OSPFV2].
o Aging of the link-state database, as well as flushing LSAs from
the routing domain through the premature aging process, remains
unchanged from the description in Sections 14 and 14.1 of
[OSPFV2].
o Aging of the link-state database, as well as flushing LSAs from the routing domain through the premature aging process, remains unchanged from the description in Sections 14 and 14.1 of [OSPFV2].
However, some OSPF protocol mechanisms have changed as previously described in Section 2 herein. These changes are explained in detail in the following subsections, making references to the appropriate sections of [OSPFV2].
However, some OSPF protocol mechanisms have changed as previously described in Section 2 herein. These changes are explained in detail in the following subsections, making references to the appropriate sections of [OSPFV2].
The following subsections provide a recipe for turning an IPv4 OSPF implementation into an IPv6 OSPF implementation.
The following subsections provide a recipe for turning an IPv4 OSPF implementation into an IPv6 OSPF implementation.
4.1. Protocol Data Structures
4.1. Protocol Data Structures
The major OSPF data structures are the same for both IPv4 and IPv6: areas, interfaces, neighbors, the link-state database, and the routing table. The top-level data structures for IPv6 remain those listed in Section 5 of [OSPFV2], with the following modifications:
The major OSPF data structures are the same for both IPv4 and IPv6: areas, interfaces, neighbors, the link-state database, and the routing table. The top-level data structures for IPv6 remain those listed in Section 5 of [OSPFV2], with the following modifications:
o All LSAs with known LS type and AS flooding scope appear in the
top-level data structure, instead of belonging to a specific area
or link. AS-external-LSAs are the only LSAs defined by this
specification that have AS flooding scope. LSAs with unknown LS
o All LSAs with known LS type and AS flooding scope appear in the top-level data structure, instead of belonging to a specific area or link. AS-external-LSAs are the only LSAs defined by this specification that have AS flooding scope. LSAs with unknown LS
Coltun, et al. Standards Track [Page 14] RFC 5340 OSPF for IPv6 July 2008
Coltun, et al. Standards Track [Page 14] RFC 5340 OSPF for IPv6 July 2008
type, U-bit set to 1 (flood even when unrecognized), and AS
flooding scope also appear in the top-level data structure.
type, U-bit set to 1 (flood even when unrecognized), and AS flooding scope also appear in the top-level data structure.
4.1.1. The Area Data Structure
4.1.1. The Area Data Structure
The IPv6 area data structure contains all elements defined for IPv4 areas in Section 6 of [OSPFV2]. In addition, all LSAs of known type that have area flooding scope are contained in the IPv6 area data structure. This always includes the following LSA types: router- LSAs, network-LSAs, inter-area-prefix-LSAs, inter-area-router-LSAs, and intra-area-prefix-LSAs. LSAs with unknown LS type, U-bit set to 1 (flood even when unrecognized), and area scope also appear in the area data structure. NSSA-LSAs are also included in an NSSA area's data structure.
The IPv6 area data structure contains all elements defined for IPv4 areas in Section 6 of [OSPFV2]. In addition, all LSAs of known type that have area flooding scope are contained in the IPv6 area data structure. This always includes the following LSA types: router- LSAs, network-LSAs, inter-area-prefix-LSAs, inter-area-router-LSAs, and intra-area-prefix-LSAs. LSAs with unknown LS type, U-bit set to 1 (flood even when unrecognized), and area scope also appear in the area data structure. NSSA-LSAs are also included in an NSSA area's data structure.
4.1.2. The Interface Data Structure
4.1.2. The Interface Data Structure
In OSPF for IPv6, an interface connects a router to a link. The IPv6 interface structure modifies the IPv4 interface structure (as defined in Section 9 of [OSPFV2]) as follows:
In OSPF for IPv6, an interface connects a router to a link. The IPv6 interface structure modifies the IPv4 interface structure (as defined in Section 9 of [OSPFV2]) as follows:
Interface ID
Every interface is assigned an Interface ID, which uniquely
identifies the interface with the router. For example, some
implementations MAY be able to use the MIB-II IfIndex ([INTFMIB])
as the Interface ID. The Interface ID appears in Hello packets
sent out the interface, the link-local-LSA originated by the
router for the attached link, and the router-LSA originated by the
router-LSA for the associated area. It will also serve as the
Link State ID for the network-LSA that the router will originate
for the link if the router is elected Designated Router.
The Interface ID for a virtual link is independent of the
Interface ID of the outgoing interface it traverses in the transit
area.
Interface ID Every interface is assigned an Interface ID, which uniquely identifies the interface with the router. For example, some implementations MAY be able to use the MIB-II IfIndex ([INTFMIB]) as the Interface ID. The Interface ID appears in Hello packets sent out the interface, the link-local-LSA originated by the router for the attached link, and the router-LSA originated by the router-LSA for the associated area. It will also serve as the Link State ID for the network-LSA that the router will originate for the link if the router is elected Designated Router. The Interface ID for a virtual link is independent of the Interface ID of the outgoing interface it traverses in the transit area.
Instance ID
Every interface is assigned an Instance ID. This should default
to 0. It is only necessary to assign a value other than 0 on
those links that will contain multiple separate communities of
OSPF routers. For example, suppose that there are two communities
of routers on a given ethernet segment that you wish to keep
separate.
The first community is assigned an Instance ID of 0 and all the
routers in the first community will be assigned 0 as the Instance
ID for interfaces connected to the ethernet segment. An Instance
ID of 1 is assigned to the other routers' interfaces connected to
the ethernet segment. The OSPF transmit and receive processing
(see Section 4.2) will then keep the two communities separate.
Instance ID Every interface is assigned an Instance ID. This should default to 0. It is only necessary to assign a value other than 0 on those links that will contain multiple separate communities of OSPF routers. For example, suppose that there are two communities of routers on a given ethernet segment that you wish to keep separate. The first community is assigned an Instance ID of 0 and all the routers in the first community will be assigned 0 as the Instance ID for interfaces connected to the ethernet segment. An Instance ID of 1 is assigned to the other routers' interfaces connected to the ethernet segment. The OSPF transmit and receive processing (see Section 4.2) will then keep the two communities separate.
Coltun, et al. Standards Track [Page 15] RFC 5340 OSPF for IPv6 July 2008
Coltun, et al. Standards Track [Page 15] RFC 5340 OSPF for IPv6 July 2008
List of LSAs with link-local scope
All LSAs with link-local scope and that were originated/flooded on
the link belong to the interface structure that connects to the
link. This includes the collection of the link's link-LSAs.
List of LSAs with link-local scope All LSAs with link-local scope and that were originated/flooded on the link belong to the interface structure that connects to the link. This includes the collection of the link's link-LSAs.
IP interface address
For IPv6, the IPv6 address appearing in the source of OSPF packets
sent on the interface is almost always a link-local address. The
one exception is for virtual links that MUST use one of the
router's own global IPv6 addresses as IP interface address.
IP interface address For IPv6, the IPv6 address appearing in the source of OSPF packets sent on the interface is almost always a link-local address. The one exception is for virtual links that MUST use one of the router's own global IPv6 addresses as IP interface address.
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.
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.
In OSPF for IPv6, each router interface has a single metric representing the cost of sending packets on the interface. In addition, OSPF for IPv6 relies on the IP Authentication Header (see [IPAUTH]) and the IP Encapsulating Security Payload (see [IPESP]) as described in [OSPFV3-AUTH] to ensure integrity and authentication/ confidentiality of routing exchanges. For this reason, AuType and Authentication key are not associated with IPv6 OSPF interfaces.
In OSPF for IPv6, each router interface has a single metric representing the cost of sending packets on the interface. In addition, OSPF for IPv6 relies on the IP Authentication Header (see [IPAUTH]) and the IP Encapsulating Security Payload (see [IPESP]) as described in [OSPFV3-AUTH] to ensure integrity and authentication/ confidentiality of routing exchanges. For this reason, AuType and Authentication key are not associated with IPv6 OSPF interfaces.
Interface states, events, and the interface state machine remain unchanged from IPv4 as documented in Sections 9.1, 9.2, and 9.3 of [OSPFV2] respectively. The Designated Router and Backup Designated Router election algorithm also remains unchanged from the IPv4 election in Section 9.4 of [OSPFV2].
Interface states, events, and the interface state machine remain unchanged from IPv4 as documented in Sections 9.1, 9.2, and 9.3 of [OSPFV2] respectively. The Designated Router and Backup Designated Router election algorithm also remains unchanged from the IPv4 election in Section 9.4 of [OSPFV2].
4.1.3. The Neighbor Data Structure
4.1.3. The Neighbor Data Structure
The neighbor structure performs the same function in both IPv6 and IPv4. Namely, it collects all information required to form an adjacency between two routers when such an adjacency becomes necessary. Each neighbor structure is bound to a single OSPF interface. The differences between the IPv6 neighbor structure and the neighbor structure defined for IPv4 in Section 10 of [OSPFV2] are:
The neighbor structure performs the same function in both IPv6 and IPv4. Namely, it collects all information required to form an adjacency between two routers when such an adjacency becomes necessary. Each neighbor structure is bound to a single OSPF interface. The differences between the IPv6 neighbor structure and the neighbor structure defined for IPv4 in Section 10 of [OSPFV2] are:
Neighbor's Interface ID
The Interface ID that the neighbor advertises in its Hello packets
must be recorded in the neighbor structure. The router will
include the neighbor's Interface ID in the router's router-LSA
when either a) advertising a point-to-point or point-to-multipoint
link to the neighbor or b) advertising a link to a network where
the neighbor has become the Designated Router.
Neighbor's Interface ID The Interface ID that the neighbor advertises in its Hello packets must be recorded in the neighbor structure. The router will include the neighbor's Interface ID in the router's router-LSA when either a) advertising a point-to-point or point-to-multipoint link to the neighbor or b) advertising a link to a network where the neighbor has become the Designated Router.
Coltun, et al. Standards Track [Page 16] RFC 5340 OSPF for IPv6 July 2008
Coltun, et al. Standards Track [Page 16] RFC 5340 OSPF for IPv6 July 2008
Neighbor IP address
The neighbor's IPv6 address contained as the source address in
OSPF for IPv6 packets. This will be an IPv6 link-local address
for all link types except virtual links.
Neighbor IP address The neighbor's IPv6 address contained as the source address in OSPF for IPv6 packets. This will be an IPv6 link-local address for all link types except virtual links.
Neighbor's Designated Router
The neighbor's choice of Designated Router is now encoded as a
Router ID instead of as an IP address.
Neighbor's Designated Router The neighbor's choice of Designated Router is now encoded as a Router ID instead of as an IP address.
Neighbor's Backup Designated Router
The neighbor's choice of Backup Designated Router is now encoded
as a Router ID instead of as an IP address.
Neighbor's Backup Designated Router The neighbor's choice of Backup Designated Router is now encoded as a Router ID instead of as an IP address.
Neighbor states, events, and the neighbor state machine remain unchanged from IPv4 as documented in Sections 10.1, 10.2, and 10.3 of [OSPFV2] respectively. The decision as to which adjacencies to form also remains unchanged from the IPv4 logic documented in Section 10.4 of [OSPFV2].
Neighbor states, events, and the neighbor state machine remain unchanged from IPv4 as documented in Sections 10.1, 10.2, and 10.3 of [OSPFV2] respectively. The decision as to which adjacencies to form also remains unchanged from the IPv4 logic documented in Section 10.4 of [OSPFV2].
4.2. Protocol Packet Processing
4.2. Protocol Packet Processing
OSPF for IPv6 runs directly over IPv6's network layer. As such, it is encapsulated in one or more IPv6 headers with the Next Header field of the immediately encapsulating IPv6 header set to the value 89.
OSPF for IPv6 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.
As for OSPF for IPv4, OSPF for IPv6 OSPF routing protocol packets are sent along adjacencies only (with the exception of Hello packets, which are used to discover the adjacencies). OSPF packet types and functions are the same in both IPv4 and IPv6, encoded by the Type field of the standard OSPF packet header.
As for OSPF for IPv4, OSPF for IPv6 OSPF routing protocol packets are sent along adjacencies only (with the exception of Hello packets, which are used to discover the adjacencies). OSPF packet types and functions are the same in both IPv4 and IPv6, encoded by the Type field of the standard OSPF packet header.
4.2.1. Sending Protocol Packets
4.2.1. Sending Protocol Packets
When an IPv6 router sends an OSPF routing protocol packet, it fills in the fields of the standard OSPF for IPv6 packet header (see Appendix A.3.1) as follows:
When an IPv6 router sends an OSPF routing protocol packet, it fills in the fields of the standard OSPF for IPv6 packet header (see Appendix A.3.1) as follows:
Version #
Set to 3, the version number of the protocol as documented in this
specification.
Version # Set to 3, the version number of the protocol as documented in this specification.
Type
The type of OSPF packet, such as Link State Update or Hello
packet.
Type The type of OSPF packet, such as Link State Update or Hello packet.
Coltun, et al. Standards Track [Page 17] RFC 5340 OSPF for IPv6 July 2008
Coltun, et al. Standards Track [Page 17] RFC 5340 OSPF for IPv6 July 2008
Packet length
The length of the entire OSPF packet in bytes, including the
standard OSPF packet header.
Packet length The length of the entire OSPF packet in bytes, including the standard OSPF packet header.
Router ID
The identity of the router itself (who is originating the packet).
Router ID The identity of the router itself (who is originating the packet).
Area ID
The OSPF area for the interface on which the packet is being sent.
Area ID The OSPF area for the interface on which the packet is being sent.
Instance ID
The OSPF Instance ID associated with the interface out of which
the packet is being sent.
Instance ID The OSPF Instance ID associated with the interface out of which the packet is being sent.
Checksum
The standard IPv6 Upper-Layer checksum (as described in Section
8.1 of [IPV6]) covering the entire OSPF packet and prepended IPv6
pseudo-header (see Appendix A.3.1).
Checksum The standard IPv6 Upper-Layer checksum (as described in Section 8.1 of [IPV6]) covering the entire OSPF packet and prepended IPv6 pseudo-header (see Appendix A.3.1).
Selection of OSPF routing protocol packets' IPv6 source and destination addresses is performed identically to the IPv4 logic in Section 8.1 of [OSPFV2]. The IPv6 destination address is chosen from among the addresses AllSPFRouters, AllDRouters, and the Neighbor IP address associated with the other end of the adjacency (which in IPv6, for all links except virtual links, is an IPv6 link-local address).
Selection of OSPF routing protocol packets' IPv6 source and destination addresses is performed identically to the IPv4 logic in Section 8.1 of [OSPFV2]. The IPv6 destination address is chosen from among the addresses AllSPFRouters, AllDRouters, and the Neighbor IP address associated with the other end of the adjacency (which in IPv6, for all links except virtual links, is an IPv6 link-local address).
The sending of Link State Request packets and Link State Acknowledgment packets remains unchanged from the IPv4 procedures documented in Sections 10.9 and 13.5 of [OSPFV2] respectively. Sending Hello packets is documented in Section 4.2.1.1, and the sending of Database Description packets in Section 4.2.1.2. The sending of Link State Update packets is documented in Section 4.5.2.
The sending of Link State Request packets and Link State Acknowledgment packets remains unchanged from the IPv4 procedures documented in Sections 10.9 and 13.5 of [OSPFV2] respectively. Sending Hello packets is documented in Section 4.2.1.1, and the sending of Database Description packets in Section 4.2.1.2. The sending of Link State Update packets is documented in Section 4.5.2.
4.2.1.1. Sending Hello Packets
4.2.1.1. Sending Hello Packets
IPv6 changes the way OSPF Hello packets are sent in the following ways (compare to Section 9.5 of [OSPFV2]):
IPv6 changes the way OSPF Hello packets are sent in the following ways (compare to Section 9.5 of [OSPFV2]):
o Before the Hello packet is sent on an interface, the interface's
Interface ID MUST be copied into the Hello packet.
o Before the Hello packet is sent on an interface, the interface's Interface ID MUST be copied into the Hello packet.
o The Hello packet no longer contains an IP network mask since OSPF
for IPv6 runs per-link instead of per-subnet.
o The Hello packet no longer contains an IP network mask since OSPF for IPv6 runs per-link instead of per-subnet.
o The choice of Designated Router and Backup Designated Router is
now indicated within Hellos by their Router IDs instead of by
their IP interface addresses. Advertising the Designated Router
o The choice of Designated Router and Backup Designated Router is now indicated within Hellos by their Router IDs instead of by their IP interface addresses. Advertising the Designated Router
Coltun, et al. Standards Track [Page 18] RFC 5340 OSPF for IPv6 July 2008
Coltun, et al. Standards Track [Page 18] RFC 5340 OSPF for IPv6 July 2008
(or Backup Designated Router) as 0.0.0.0 indicates that the
Designated Router (or Backup Designated Router) has not yet been
chosen.
(or Backup Designated Router) as 0.0.0.0 indicates that the Designated Router (or Backup Designated Router) has not yet been chosen.
o The Options field within Hello packets has moved around, getting
larger in the process. More Options bits are now possible. Those
that MUST be set correctly in Hello packets are as follows. The
E-bit is set if and only if the interface attaches to a regular
area, i.e., not a stub or NSSA area. Similarly, the N-bit is set
if and only if the interface attaches to an NSSA area (see
[NSSA]). Finally, the DC-bit is set if and only if the router
wishes to suppress the sending of future Hellos over the interface
(see [DEMAND]). Unrecognized bits in the Hello packet's Options
field should be cleared.
o The Options field within Hello packets has moved around, getting larger in the process. More Options bits are now possible. Those that MUST be set correctly in Hello packets are as follows. The E-bit is set if and only if the interface attaches to a regular area, i.e., not a stub or NSSA area. Similarly, the N-bit is set if and only if the interface attaches to an NSSA area (see [NSSA]). Finally, the DC-bit is set if and only if the router wishes to suppress the sending of future Hellos over the interface (see [DEMAND]). Unrecognized bits in the Hello packet's Options field should be cleared.
Sending Hello packets on NBMA networks proceeds for IPv6 in exactly the same way as for IPv4, as documented in Section 9.5.1 of [OSPFV2].
Sending Hello packets on NBMA networks proceeds for IPv6 in exactly the same way as for IPv4, as documented in Section 9.5.1 of [OSPFV2].
4.2.1.2. Sending Database Description Packets
4.2.1.2. Sending Database Description Packets
The sending of Database Description packets differs from Section 10.8 of [OSPFV2] in the following ways:
The sending of Database Description packets differs from Section 10.8 of [OSPFV2] in the following ways:
o The Options field within Database Description packets has moved
around, getting larger in the process. More Options bits are now
possible. Those that MUST be set correctly in Database
Description packets are as follows. The DC-bit is set if and only
if the router wishes to suppress the sending of Hellos over the
interface (see [DEMAND]). Unrecognized bits in the Database
Description packet's Options field should be cleared.
o The Options field within Database Description packets has moved around, getting larger in the process. More Options bits are now possible. Those that MUST be set correctly in Database Description packets are as follows. The DC-bit is set if and only if the router wishes to suppress the sending of Hellos over the interface (see [DEMAND]). Unrecognized bits in the Database Description packet's Options field should be cleared.
4.2.2. Receiving Protocol Packets
4.2.2. Receiving Protocol Packets
Whenever a router receives an OSPF protocol packet, it is marked with the interface on which it was received. For routers that have virtual links configured, it may not be immediately obvious with which interface to associate the packet. For example, consider the Router RT11 depicted in Figure 6 of [OSPFV2]. If RT11 receives an OSPF protocol packet on its interface to Network N8, it may want to associate the packet with the interface to Area 2, or with the virtual link to Router RT10 (which is part of the backbone). In the following, we assume that the packet is initially associated with the non-virtual link.
Whenever a router receives an OSPF protocol packet, it is marked with the interface on which it was received. For routers that have virtual links configured, it may not be immediately obvious with which interface to associate the packet. For example, consider the Router RT11 depicted in Figure 6 of [OSPFV2]. If RT11 receives an OSPF protocol packet on its interface to Network N8, it may want to associate the packet with the interface to Area 2, or with the virtual link to Router RT10 (which is part of the backbone). In the following, we assume that the packet is initially associated with the non-virtual link.
In order for the packet to be passed to OSPF for processing, the following tests must be performed on the encapsulating IPv6 headers:
In order for the packet to be passed to OSPF for processing, the following tests must be performed on the encapsulating IPv6 headers:
Coltun, et al. Standards Track [Page 19] RFC 5340 OSPF for IPv6 July 2008
Coltun, et al. Standards Track [Page 19] RFC 5340 OSPF for IPv6 July 2008
o The packet's IP destination address MUST be one of the IPv6
unicast addresses associated with the receiving interface (this
includes link-local addresses), one of the IPv6 multicast
addresses AllSPFRouters or AllDRouters, or an IPv6 global address
(for virtual links).
o パケットの受信者IPアドレスは、受信インタフェース(これはリンクローカルのアドレスを含んでいる)に関連しているIPv6ユニキャストアドレスの1つ、IPv6マルチキャストアドレスのAllSPFRoutersかAllDRoutersの1つ、またはIPv6グローバルアドレスであるに違いありません(仮想のリンクへの)。
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 [IPAUTH]) and the
IP Encapsulating Security Payloads (see [IPESP]) MUST be processed
and/or verified to ensure integrity and authentication/
confidentiality of OSPF routing exchanges. This is described in
[OSPFV3-AUTH].
o IPがAuthentication Headers([IPAUTH]を見る)とIP Encapsulating Security有効搭載量([IPESP]を見る)であるとカプセル化するのと、OSPFルーティング交換の保全と認証/秘密性を確実にするためにいくらか、処理される、そして/または、確かめなければなりません。 これは[OSPFV3-AUTH]で説明されます。
After processing the encapsulating IPv6 headers, the OSPF packet header is processed. The fields specified in the header must match those configured for the receiving OSPFv3 interface. If they do not, the packet SHOULD be discarded:
要約のIPv6ヘッダーを処理した後に、OSPFパケットのヘッダーは処理されます。 ヘッダーで指定された分野は受信OSPFv3インタフェースに構成されたものに合わなければなりません。 そうしないで、パケットはSHOULDです。捨てられてください:
o The version number field MUST specify protocol version 3.
o バージョンナンバーフィールドはプロトコルバージョン3を指定しなければなりません。
o The IPv6 Upper-Layer checksum (as described in Section 8.1 of
[IPV6]), covering the entire OSPF packet and prepended IPv6
pseudo-header, must be verified (see Appendix A.3.1).
o 全体のOSPFパケットとprepended IPv6疑似ヘッダーをカバーしていて、IPv6 Upper-層のチェックサム([IPV6]のセクション8.1で説明されるように)について確かめなければなりません(Appendix A.3.1を見てください)。
o The Area ID and Instance ID found in the OSPF header must be
verified. If both of the following cases fail, the packet should
be discarded. The Area ID and Instance ID specified in the header
must either:
o OSPFヘッダーで見つけられたArea IDとInstance IDについて確かめなければなりません。 以下のケースの両方が失敗するなら、パケットは捨てられるべきです。 ヘッダーで指定されたArea IDとInstance IDはそうしなければなりません:
1. Match one of the Area ID(s) and Interface Instance ID(s) for
the receiving link. Unlike IPv4, the IPv6 source address is
not restricted to lie within the same IPv6 subnet as the
receiving link. IPv6 OSPF runs per-link instead of per-IP-
subnet.
1. 受信のためのArea IDとInterface Instance IDのマッチ1はリンクされます。 IPv4と異なって、IPv6ソースアドレスは、受信リンクと同じIPv6サブネットに属すために制限されません。 IPv6 OSPFはIP-サブネットの代わりにリンクを動かします。
2. Match the backbone area and other criteria for a configured
virtual link. The receiving router must be an ABR (Area
Border Router) and the Router ID specified in the packet (the
source router) must be the other end of a configured virtual
link. Additionally, the receiving link must have an OSPFv3
interface that attaches to the virtual link's configured
transit area and the Instance ID must match the virtual link's
Instance ID. If all of these checks succeed, the packet is
accepted and is associated with the virtual link (and the
backbone area).
2. 構成された仮想のリンクのバックボーン領域と他の評価基準を合わせてください。 受信ルータはABRであるに違いありません(領域Border Router)、そして、パケット(ソースルータ)で指定されたRouter IDは構成された仮想のリンクのもう一方の端であるに違いありません。 さらに、受信リンクには、仮想のリンクの構成されたトランジット領域に付くOSPFv3インタフェースがなければなりません、そして、Instance IDは仮想のリンクのInstance IDに合わなければなりません。 これらのチェックのすべてが成功するなら、パケットは、受け入れられて、仮想のリンク(そして、バックボーン領域)に関連しています。
Coltun, et al. Standards Track [Page 20] RFC 5340 OSPF for IPv6 July 2008
Coltun、他 IPv6 July 2008のための標準化過程[20ページ]RFC5340OSPF
o Locally originated packets SHOULD NOT be processed by OSPF except
for support of multiple interfaces attached to the same link as
described in Section 4.9. Locally originated packets have a
source address equal to one of the router's local addresses.
o 局所的に溯源されたパケットSHOULD NOT、セクション4.9で説明されるのと同じリンクに付けられた複数のインタフェースのサポート以外のOSPFによって処理されてください。 局所的に溯源されたパケットには、ルータのローカルのアドレスの1つと等しいソースアドレスがあります。
o Packets whose IPv6 destination is AllDRouters should only be
accepted if the state of the receiving OSPFv3 interface is DR or
Backup (see Section 9.1 [OSPFV2]).
o OSPFv3が連結する受信の状態がDRかBackup(セクション9.1[OSPFV2]を見る)である場合にだけIPv6の目的地が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 packet processing as described in Section 4.2.2.1. All other packet types are sent/received only on adjacencies. This means that the packet must have been sent by one of the router's active neighbors. The neighbor is identified by the Router ID appearing in the received packet's OSPF header. Packets not matching any active neighbor are discarded.
そして、パケットタイプがHelloであるなら、それはセクション4.2.2で.1に説明されるようにHelloパケット処理でさらに処理されるべきです。 隣接番組だけに他のすべてのパケットタイプを送るか、または受け取ります。 これは、パケットがルータの活発な隣人のひとりによって送られたに違いないことを意味します。 隣人は容認されたパケットのOSPFヘッダーに現れるRouter IDによって特定されます。 どんな活発な隣人にも合っていないパケットは捨てられます。
The receive processing of Database Description packets, Link State Request packets, and Link State Acknowledgment packets is almost identical to the IPv4 procedures documented in Sections 10.6, 10.7, and 13.7 of [OSPFV2] respectively with the exceptions noted below.
Database記述パケットの処理を受けてください、Link州Requestパケット、そして、Link州Acknowledgmentパケットは例外が以下に述べられている状態で[OSPFV2]のセクション10.6、10.7、および13.7にそれぞれ記録されたIPv4手順とほとんど同じです。
o LSAs with unknown LS types in Database Description packets that
have an acceptable flooding scope are processed the same as LSAs
with known LS types. In OSPFv2 [OSPFV2], these would result in
the adjacency being brought down with a SequenceMismatch event.
o 知られているLSとLSAsがタイプするように未知のLSタイプが許容できる氾濫範囲を持っているDatabase記述パケットにあるLSAsは同じように処理されます。 OSPFv2[OSPFV2]では、これらはSequenceMismatchイベントで降ろされる隣接番組をもたらすでしょう。
The receiving of Hello packets is documented in Section 4.2.2.1 and the receiving of Link State Update packets is documented in Section 4.5.1.
Helloパケットの受信はセクション4.2.2に記録されて、.1とLink州Updateパケットの受信がセクション4.5.1に記録されるということです。
4.2.2.1. Receiving Hello Packets
4.2.2.1. こんにちはを受ける、パケット
The receive processing of Hello packets differs from Section 10.5 of [OSPFV2] in the following ways:
以下の方法で、パケットがセクション10.5と異なるHelloの処理[OSPFV2]を受けてください:
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パケットにありません。
Coltun, et al. Standards Track [Page 21] RFC 5340 OSPF for IPv6 July 2008
Coltun、他 IPv6 July 2008のための標準化過程[21ページ]RFC5340OSPF
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としてコード化されます。
4.3. The Routing table Structure
4.3. ルート設定テーブルStructure
The routing table used by OSPF for IPv4 is defined in Section 11 of [OSPFV2]. For IPv6, there are analogous routing table entries: there are routing table entries for IPv6 address prefixes and also for AS boundary routers. The latter routing table entries are only used to hold intermediate results during the routing table build process (see Section 4.8).
IPv4にOSPFによって使用された経路指定テーブルは[OSPFV2]のセクション11で定義されます。 IPv6のために、類似の経路指定テーブルエントリーがあります: IPv6アドレス接頭語とAS境界ルータのために経路指定テーブルエントリーがもあります。 後者の経路指定テーブルエントリーは経路指定テーブルの間の中間結果がプロセスを建てる保持に使用されるだけです(セクション4.8を見てください)。
Also, to hold the intermediate results during the shortest-path calculation for each area, there is a separate routing table for each area holding the following entries:
また、各領域のための最短パス計算の間、中間結果を保持するために、各領域への以下のエントリーを保持する別々の経路指定テーブルがあります:
o An entry for each router in the area. Routers are identified by
their OSPF Router ID. These routing table entries hold the set of
shortest paths through a given area to a given router, which in
turn allows calculation of paths to the IPv6 prefixes advertised
by that router in intra-area-prefix-LSAs. If the router is also
an area border router, these entries are also used to calculate
paths for inter-area address prefixes. If in addition the router
is the other endpoint of a virtual link, the routing table entry
describes the cost and viability of the virtual link.
o その領域の各ルータのためのエントリー。 ルータはそれらのOSPF Router IDによって特定されます。 これらの経路指定テーブルエントリーは与えられた領域を通って与えられたルータに最短パスのセットを持っています。(順番に、イントラ領域が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 [OSPFV2]) remain valid for IPv6: optional capabilities (routers only), path type, cost, type 2 cost, link state origin, and for each of the equal cost paths to the destination, the next-hop and advertising routers.
IPv4 OSPF経路指定テーブル([OSPFV2]のセクション11を見る)の分野はIPv6に有効なままで残っています: (ルータ専用)(経路タイプ)がかかる任意の能力、2がかかるタイプは、州の発生源をリンクしてください、そして、同輩各人に関して、目的地、次のホップ、および広告ルータに経路かかってください。
For IPv6, the link-state origin field in the routing table entry is the router-LSA or network-LSA that has directly or indirectly produced the routing table entry. For example, if the routing table entry describes a route to an IPv6 prefix, the link state origin is the router-LSA or network-LSA that is listed in the body of the intra-area-prefix-LSA that has produced the route (see Appendix A.4.10).
IPv6に関しては、経路指定テーブルエントリーにおけるリンク州の発生源分野は、直接か間接的に経路指定テーブルエントリーを起こしたルータ-LSAかネットワーク-LSAです。 経路指定テーブルエントリーがIPv6接頭語にルートを説明するなら、リンク州の発生源は、例えば、ルートを作成したイントラ領域がLSAを前に置くことのボディーに記載されているルータ-LSAかネットワーク-LSA(Appendix A.4.10を見る)です。
Coltun, et al. Standards Track [Page 22] RFC 5340 OSPF for IPv6 July 2008
Coltun、他 IPv6 July 2008のための標準化過程[22ページ]RFC5340OSPF
4.3.1. Routing Table Lookup
4.3.1. 索表を発送します。
Routing table lookup (i.e., determining the best matching routing table entry during IP forwarding) is the same for IPv6 as for IPv4.
IPv6に、索表(すなわち、IP推進の間、最も良い合っている経路指定テーブルエントリーを決定する)を発送するのはIPv4のように同じです。
4.4. Link State Advertisements
4.4. リンク州の広告
For IPv6, the OSPF LSA header has changed slightly, with the LS type field expanding and the Options field being moved into the body of appropriate LSAs. Also, the formats of some LSAs have changed somewhat (namely, router-LSAs, network-LSAs, AS-external-LSAs, and NSSA-LSAs), while the names of other LSAs have been changed (type 3 and 4 summary-LSAs are now inter-area-prefix-LSAs and inter-area- router-LSAs respectively) and additional LSAs have been added (link- LSAs and intra-area-prefix-LSAs). Type of Service (TOS) has been removed from the OSPFv2 specification [OSPFV2] and is not encoded within OSPF for IPv6's LSAs.
IPv6に関しては、OSPF LSAヘッダーはわずかに変化しました、LSタイプ分野が広がっていて、Options野原が適切なLSAsのボディーに動かされている状態で。 また、いくつかのLSAsの形式はいくらか(すなわち、ルータ-LSAs、ネットワーク-LSAs、ASの外部のLSAs、およびNSSA-LSAs)変化しました、他のLSAsという名前を変えました、そして、(タイプ3と4概要-LSAsはそれぞれ相互領域がLSAsを前に置く現在と相互領域ルータ-LSAsです)追加LSAsを加えましたが(LSAsをリンクしてください。そうすれば、イントラ領域はLSAsを前に置きます)。 Service(TOS)のタイプは、OSPFv2仕様[OSPFV2]から外されて、IPv6のLSAsのためにOSPFの中でコード化されません。
These changes will be described in detail in the following subsections.
これらの変化は以下の小区分で詳細に説明されるでしょう。
4.4.1. The LSA Header
4.4.1. LSAヘッダー
In both IPv4 and IPv6, all OSPF LSAs begin with a standard 20-byte LSA header. However, the contents of this 20-byte header have changed in IPv6. The LS age, Advertising Router, LS Sequence Number, LS checksum, and length fields within the LSA header remain unchanged, as documented in Sections 12.1.1, 12.1.5, 12.1.6, 12.1.7, and A.4.1 of [OSPFV2], respectively. However, the following fields have changed for IPv6:
IPv4とIPv6の両方では、すべてのOSPF LSAsが標準の20バイトのLSAヘッダーと共に始まります。 しかしながら、この20バイトのヘッダーの内容はIPv6で変化しました。 LSAヘッダーの中のLS時代、Advertising Router、LS Sequence Number、LSチェックサム、および長さの分野は変わりがありません、セクション12.1.1、12.1に.5、12.1を記録するので.6 12.1 .7、および[OSPFV2]のA.4.1、それぞれ。 しかしながら、以下の分野はIPv6のために変化しました:
Options
The Options field has been removed from the standard 20-byte LSA
header and moved into the body of router-LSAs, network-LSAs,
inter-area-router-LSAs, and link-LSAs. The size of the Options
field has increased from 8 to 24 bits, and some of the bit
definitions have changed (see Appendix A.2). Additionally, a
separate PrefixOptions field, 8 bits in length, is attached to
each prefix advertised within the body of an LSA.
標準の20バイトのLSAヘッダーから移されて、ルータ-LSAs、ネットワーク-LSAsのボディーに動いて、Options分野が持っているオプション、相互領域ルータLSAs、LSAsをリンクします。 Options分野のサイズは8〜24ビットまで増えました、そして、噛み付いている定義のいくつかが変化しました(Appendix A.2を見てください)。 さらに、別々のPrefixOptions分野(長さ8ビット)はLSAのボディーの中に広告に掲載された各接頭語に付けられています。
LS type
The size of the LS type field has increased from 8 to 16 bits,
with high-order bit encoding the handling of unknown types and the
next two bits encoding flooding scope. See Appendix A.4.2.1 for
the current coding of the LS type field.
LSタイプ分野のサイズのLSタイプは8〜16ビットまで増えました、高位のビットが未知のタイプの取り扱いをコード化していて、次の2ビットが氾濫範囲をコード化していて。 LSタイプ分野の現在のコード化に関してAppendix A.4.2.1を見てください。
Coltun, et al. Standards Track [Page 23] RFC 5340 OSPF for IPv6 July 2008
Coltun、他 IPv6 July 2008のための標準化過程[23ページ]RFC5340OSPF
Link State ID
The Link State ID remains at 32 bits in length. However, except
for network-LSAs and link-LSAs, the Link State ID has shed any
addressing semantics. For example, an IPv6 router originating
multiple AS-external-LSAs could start by assigning the first a
Link State ID of 0.0.0.1, the second a Link State ID of 0.0.0.2,
and so on. Instead of the IPv4 behavior of encoding the network
number within the AS-external-LSA's Link State ID, the IPv6 Link
State ID simply serves as a way to differentiate multiple LSAs
originated by the same router.
For network-LSAs, the Link State ID is set to the Designated
Router's Interface ID on the link. When a router originates a
link-LSA for a given link, its Link State ID is set equal to the
router's Interface ID on the link.
Link州IDが長さで32ビット残る州IDをリンクしてください。 しかしながら、ネットワーク-LSAsとリンク-LSAsを除いて、Link州IDはどんなアドレシング意味論もはじきました。 例えば、複数のASの外部のLSAsを溯源するIPv6ルータは、.1、0.0の第2.0a Link州IDを0.0の最初のa Link州IDに割り当てることによって、.0の.2などを始めるかもしれません。 AS外部のLSA Link州IDの中でネットワーク・ナンバーをコード化するIPv4の振舞いの代わりに、複数のLSAsを差別化する方法が同じルータで起因したので、IPv6 Link州IDは単に役立ちます。 ネットワーク-LSAsにおいて、Link州IDはリンクの上にDesignated RouterのInterface IDに設定されます。 ルータがリンク-LSAを与えられたリンクに溯源するとき、Link州IDはリンクでルータのInterface IDと等しいセットです。
4.4.2. The Link-State Database
4.4.2. リンク州のデータベース
In IPv6, as in IPv4, individual LSAs are identified by a combination of their LS type, Link State ID, and Advertising Router fields. Given two instances of an LSA, the most recent instance is determined by examining the LSAs' LS sequence number, using LS checksum and LS age as tiebreakers (see Section 13.1 of [OSPFV2]).
IPv6では、IPv4のように、個々のLSAsは彼らのLSタイプ、Link州ID、およびAdvertising Router分野の組み合わせで特定されます。 LSAの2つのインスタンスを考えて、最新のインスタンスはLSAsのLS一連番号を調べることによって、決定します、タイブレークとしてLSチェックサムとLS時代を費やして([OSPFV2]のセクション13.1を見てください)。
In IPv6, the link-state database is split across three separate data structures. LSAs with AS flooding scope are contained within the top-level OSPF data structure (see Section 4.1) as long as either their LS type is known or their U-bit is 1 (flood even when unrecognized); this includes the AS-external-LSAs. LSAs with area flooding scope are contained within the appropriate area structure (see Section 4.1.1) as long as either their LS type is known or their U-bit is 1 (flood even when unrecognized); this includes router-LSAs, network-LSAs, inter-area-prefix-LSAs, inter-area-router-LSAs, NSSA- LSAs, and intra-area-prefix-LSAs. LSAs with an unknown LS type, the U-bit set to 0, and/or link-local flooding scope are contained within the appropriate interface structure (see Section 4.1.2); this includes link-LSAs.
IPv6では、リンク州のデータベースは3つの別々のデータ構造の向こう側に分けられます。 AS氾濫範囲があるLSAsは彼らのLSタイプが知られているか、彼らのU-ビットが1(認識されていなくさえあるときには、浸水する)である限り、トップレベルOSPFデータ構造(セクション4.1を見る)の中に含まれています。 これはASの外部のLSAsを含んでいます。 領域の氾濫範囲があるLSAsは彼らのLSタイプが知られているか、彼らのU-ビットが1(認識されていなくさえあるときには、浸水する)である限り、適切な領域構造(セクション4.1.1を見る)の中に含まれています。 ネットワーク-LSAs、これがルータ-LSAsを含んで、相互領域がLSAsを前に置く、相互領域ルータLSAs、NSSA- LSAs、イントラ領域はLSAsを前に置きます。 未知のLSタイプがあるLSAs、0へのU-ビットセット、そして/または、リンク地方の氾濫範囲は適切なインタフェース構造の中に含まれています(セクション4.1.2を見てください)。 これはリンク-LSAsを含んでいます。
To look up or install an LSA in the database, you first examine the LS type and the LSA's context (i.e., the area or link to which the LSA belongs). This information allows you to find the correct database of LSAs where you then search based on the LSA's type, Link State ID, and Advertising Router.
LSAをデータベースに見上げるか、またはインストールするために、あなたは最初に、LSタイプとLSAの文脈(すなわち、LSAが属する領域かリンク)を調べます。 この情報で、あなたはあなたが次にLink州のLSAのタイプ、ID、およびAdvertising Routerに基づいて探すLSAsの正しいデータベースを見つけることができます。
Coltun, et al. Standards Track [Page 24] RFC 5340 OSPF for IPv6 July 2008
Coltun、他 IPv6 July 2008のための標準化過程[24ページ]RFC5340OSPF
4.4.3. Originating LSAs
4.4.3. 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 on the appropriate interfaces.
IPv6でLSAが再起因させるプロセスはIPv4と同じです: LSAのLS一連番号が増加されていて、LS時代が0に設定されて、LSチェックサムが計算されて、LSAはリンク州のデータベースに追加されて、適切なインタフェースにあふれます。
The list of events causing LSAs to be reoriginated for IPv4 is given in Section 12.4 of [OSPFV2]. The following events and/or actions are added for IPv6:
セクション12.4でIPv4のためにLSAsが再起因させるイベントのリストに[OSPFV2]を与えます。 以下のイベント、そして/または、動作はIPv6のために加えられます:
o The state or interface ID of one of the router's interfaces
changes. The router may need to (re)originate or flush its link-
LSA and one or more router-LSAs and/or intra-area-prefix-LSAs. If
the router is the Designated Router, the router may also need to
(re)originate and/or flush the network-LSA corresponding to the
interface.
o ルータのインタフェースの1つの状態かインタフェースIDが変化します。 ルータは、リンクLSAと1ルータ-LSAsを溯源するか、または洗い流す(re)必要があるかもしれません、そして、イントラ領域はLSAsを前に置きます。 また、ルータがDesignated Routerであるなら、ルータは、ネットワーク-LSA対応をインタフェースに溯源する、そして/または、洗い流す(re)必要があるかもしれません。
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 リンクのDesignated Routerのアイデンティティは変化します。 ルータは、リンクのネットワーク-LSAと1ルータ-LSAsを溯源するか、または洗い流す(re)必要があるかもしれません、そして、イントラ領域は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 隣人は「完全な」状態からの/に移行します。 ルータは、リンクのネットワーク-LSAと1ルータ-LSAsを溯源するか、または洗い流す(re)必要があるかもしれません、そして、イントラ領域は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.
o 隣人のInterface IDは変化します。 これで、ルータ-LSAの新しいインスタンスを関連領域に溯源するかもしれません。
o A new prefix is added to an attached link, or a prefix is deleted
(both through configuration). This causes the router to
reoriginate its link-LSA for the link or, if it is the only router
attached to the link, causes the router to reoriginate an intra-
area-prefix-LSA.
o 新しい接頭語が付属リンクに加えられるか、または接頭語は削除されます(構成を通した両方)。 これは、リンクのためにreoriginateへのリンク-LSAをルータに引き起こすか、または領域がLSAを前に置いた状態で、それがリンクに付けられた唯一のルータであるならreoriginateへのイントラをルータに引き起こします。
o A new link-LSA is received, causing the link's collection of
prefixes to change. If the router is the Designated Router for
the link, it originates a new intra-area-prefix-LSA.
o リンクの接頭語の収集が変化することを引き起こして、新しいリンク-LSAは受け取られています。 ルータがリンクへのDesignated Routerであるなら、イントラ領域がLSAを新しく前に置いた状態で、それはaを溯源します。
o A new link-LSA is received, causing the logical OR of LSA options
advertised by adjacent routers on the link to change. If the
router is the Designated Router for the link, it originates a new
network-LSA.
o 新しいリンク-LSAは受け取られています、リンクの上の隣接しているルータによって広告に掲載されたLSAオプションの論理的なORが変化することを引き起こして。 ルータがリンクへのDesignated Routerであるなら、それは新しいネットワーク-LSAを溯源します。
Detailed construction of the seven required IPv6 LSA types is supplied by the following subsections. In order to display example LSAs, the network map in Figure 15 of [OSPFV2] has been reworked to show IPv6 addressing, resulting in Figure 1. The OSPF cost of each
以下の小区分は7つの必要なIPv6 LSAタイプの詳細な工事を供給します。 例のLSAsを表示して、[OSPFV2]の図15のネットワーク地図はアドレシングをIPv6に示しているために作りなおされました、図1をもたらして。 それぞれのOSPF費用
Coltun, et al. Standards Track [Page 25] RFC 5340 OSPF for IPv6 July 2008
Coltun、他 IPv6 July 2008のための標準化過程[25ページ]RFC5340OSPF
interface is displayed in Figure 1. The assignment of IPv6 prefixes to network links is shown in Table 1. A single area address range has been configured for Area 1, so that outside of Area 1 all of its prefixes are covered by a single route to 2001:0db8:c001::/48. The OSPF interface IDs and the link-local addresses for the router interfaces in Figure 1 are given in Table 2.
図1にインタフェースを表示します。 ネットワークリンクへのIPv6接頭語の課題はTable1に示されます。 ただ一つの領域のアドレスの範囲はArea1のために構成されました、接頭語のすべてがArea1の外でただ一つのルートで2001:0db8:c001にカバーされているように:、:/48. Table2で図1のルータインタフェースへのOSPFインタフェースIDとリンクローカルのアドレスを与えます。
..........................................
. Area 1.
. + .
. | .
. | 3+---+1 .
. N1 |--|RT1|-----+ .
. | +---+ \ .
. | \ ______ .
. + \/ \ 1+---+
. * N3 *------|RT4|------
. + /\_______/ +---+
. | / | .
. | 3+---+1 / | .
. N2 |--|RT2|-----+ 1| .
. | +---+ +---+ .
. | |RT3|----------------
. + +---+ .
. |2 .
. | .
. +------------+ .
. N4 .
..........................................
.......................................... . 領域1。 . + . . | . . | 3+---+1 N1|--|RT1|-----+ . . | +---+ \ . . | \ ______ . . + \/ \ 1+---+ . *N3*------|RT4|------ . + /\_______/ +---+ . | / | . . | 3+---+1 / | . . N2|--|RT2|-----+ 1| . . | +---+ +---+ . . | |RT3|---------------- . + +---+ . . |2 . . | . . +------------+ N4。
Figure 1: Area 1 with IP Addresses Shown
図1: 示されるIPアドレスでの領域1
Network IPv6 prefix
-----------------------------------
N1 2001:0db8:c001:0200::/56
N2 2001:0db8:c001:0300::/56
N3 2001:0db8:c001:0100::/56
N4 2001:0db8:c001:0400::/56
ネットワークIPv6接頭語----------------------------------- N1 2001: 0db8:c001:0200:、:/56N2 2001: 0db8:c001:0300:、:/56N3 2001: 0db8:c001:0100:、:/56N4 2001: 0db8:c001:0400:、:/56
Table 1: IPv6 Link Prefixes for Sample Network
テーブル1: IPv6はサンプルネットワークのために接頭語をリンクします。
Coltun, et al. Standards Track [Page 26] RFC 5340 OSPF for IPv6 July 2008
Coltun、他 IPv6 July 2008のための標準化過程[26ページ]RFC5340OSPF
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
ルータInterface Interface IDリンクローカルアドレス------------------------------------------------------- N1 1 fe80へのRT1:0001:、:N3 2 fe80へのRT1:0002:、:N2 1 fe80へのRT1 RT2:0001:、:N3 2 fe80へのRT2:0002:、:N3 1 fe80へのRT2 RT3:0001:、:N4 2 fe80へのRT3:0002:、:N3 1 fe80へのRT3 RT4:0001:、:RT4
Table 2: OSPF Interface IDs and Link-Local Addresses
テーブル2: OSPFインタフェースIDとリンクローカルのアドレス
Figure 1
図1
4.4.3.1. LSA Options
4.4.3.1. LSAオプション
The Options field in LSAs should be coded as follows. The V6-bit should be set unless the router will not participate in transit IPv6 routing. The E-bit should be clear if and only if the attached area is an OSPF stub or OSPF NSSA area. The E-bit should always be set in AS scoped LSAs. The N-bit should be set if and only if the attached area is an OSPF NSSA area. The R-bit should be set unless the router will not participate in any transit routing. The DC-bit should be set if and only if the router can correctly process the DoNotAge bit when it appears in the LS age field of LSAs (see [DEMAND]). All unrecognized bits in the Options field should be cleared.
LSAsのOptions分野は以下の通りコード化されるべきです。 ルータがトランジットIPv6ルーティングに参加するなら、V6-ビットは設定されるべきです。 E-ビットが明確であるはずである、付属領域である場合にだけ、OSPFスタッブかOSPF NSSA領域がそうです。 いつもE-ビットはASに見られたLSAsを設定することであるべきです。 N-ビットが設定されるべきである、付属領域である場合にだけ、OSPF NSSA領域はそうです。 ルータがどんなトランジットルーティングにも参加するなら、R-ビットは設定されるべきです。 そして、DC-ビットが設定されるべきである、LSAsのLS時代分野に現れるとき([DEMAND]を見てください)、ルータが正しく処理されることができる場合にだけ、DoNotAgeは噛み付きました。 Options分野のすべての認識されていないビットがきれいにされるべきです。
The V6-bit and R-bit are only examined in Router-LSAs during the SPF computation. In other LSA types containing options, they are set for informational purposes only.
V6-ビットとR-ビットはSPF計算の間、Router-LSAsで調べられるだけです。 オプションを含む他のLSAタイプで、それらは情報の目的だけに設定されます。
4.4.3.2. Router-LSAs
4.4.3.2. ルータ-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 attached to the area. When multiple router-LSAs are used, they are distinguished by their Link State ID fields.
ルータ-LSAのLSタイプは値0x2001に用意ができています。 ルータ-LSAsには、領域の氾濫範囲があります。 ルータは1ルータLSAsを与えられた領域に溯源するかもしれません。 各ルータ-LSAは整数のインタフェース記述を含んでいます。 一緒に取って、ルータによって領域に溯源されたルータLSAsの収集はその領域に付けられたすべてのルータのインタフェースの集まっている州について説明します。 複数のルータ-LSAsが使用されているとき、彼らは彼らのLink州ID分野によって区別されます。
To the left of the Options field, the router capability bits V, E, and B should be set according to Section 12.4.1 of [OSPFV2].
Options分野、ルータ能力ビットVの左に、.1セクション12.4[OSPFV2]に従って、E、およびBは設定されるべきです。
Each of the router's interfaces to the area is then described by appending "link descriptions" to the router-LSA. Each link description is 16 bytes long, consisting of five fields: (link) Type,
そして、それぞれのルータのインタフェースは、「リンク記述」をルータ-LSAに追加することによって、その領域に説明されます。 5つの分野から成って、それぞれのリンク記述は長さ16バイトです: (リンク) タイプしてください。
Coltun, et al. Standards Track [Page 27] RFC 5340 OSPF for IPv6 July 2008
Coltun、他 IPv6 July 2008のための標準化過程[27ページ]RFC5340OSPF
Metric, Interface ID, Neighbor Interface ID, and Neighbor Router ID (see Appendix A.4.3). Interfaces in the state "Down" or "Loopback" are not described (although looped back interfaces can contribute prefixes to intra-area-prefix-LSAs), nor are interfaces without any full adjacencies described (except in the case of multiple Standby Interfaces as described in Section 4.9). All other interfaces to the area add zero, one, or more link descriptions. The number and content of these depend on the interface type. Within each link description, the Metric field is always set to the interface's output cost, and the Interface ID field is set to the interface's OSPF Interface ID.
メートル法であり、ID、隣人インタフェースID、および隣人Router IDを連結してください(付録A.4.3を見てください)。 州の“Down"か「ループバック」におけるインタフェースは説明されません、そして、(輪にされますが、イントラ領域がLSAsを前に置いた状態で、缶が接頭語を寄付するインタフェースを支持してください)少しも完全な隣接番組のないインタフェースは説明されません(複数のStandby Interfacesの場合では、セクション4.9で説明されるように、除きます)。 その領域への他のすべてのインタフェースがゼロ、1つ以上のリンク記述を加えます。 これらの数と内容はインターフェース型に頼っています。 それぞれのリンク記述の中では、Metric分野はいつもインタフェースの製作費に設定されます、そして、Interface ID分野はインタフェースの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.
ポイントツーポイントは隣接のIfを連結します。ルータは完全に隣接していて、Type1リンク記述(ポイントツーポイント)を加えてください。 Neighbor Interface ID分野はHelloパケットの隣人によって広告に掲載されたInterface IDに設定されます、そして、Neighbor Router ID分野は隣人のRouter IDに設定されます。
Broadcast and NBMA interfaces
If the router is fully adjacent to the link's Designated Router or
if the router itself is the Designated Router and is fully
adjacent to at least one other router, add a single Type 2 link
description (transit network). The Neighbor Interface ID field is
set to the Interface ID advertised by the Designated Router in its
Hello packets, and the Neighbor Router ID field is set to the
Designated Router's Router ID.
放送とNBMAはIfを連結します。ルータは、Designated Router、ルータ自体がリンクのDesignated Routerに隣接した完全にDesignated Routerであるなら他の少なくとも1つのルータに隣接した完全にである独身のType2が記述(トランジットネットワーク)をリンクすると言い足します。 Neighbor Interface ID分野はHelloパケットのDesignated Routerによって広告に掲載されたInterface IDに設定されます、そして、Neighbor Router ID分野はDesignated Routerの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 4.7).
仮想のリンクIf、隣接しているルータは完全に隣接していて、(仮想)でa Type4リンク記述を加えてください。 Neighbor Interface ID分野はHelloパケットの隣人によって広告に掲載されたInterface IDに設定されます、そして、Neighbor Router ID分野は隣人のRouter IDに設定されます。 仮想のリンクの製作費が経路指定テーブル計算の間計算されることに注意してください(セクション4.7を見てください)。
Point-to-Multipoint interfaces
For each fully adjacent neighbor associated with the interface,
add a separate Type 1 link description (point-to-point) with the
Neighbor Interface ID field set to the Interface ID advertised by
the neighbor in its Hello packets and the Neighbor Router ID field
set to the neighbor's Router ID.
それぞれの完全に隣接している隣人がインタフェースに関連づけたポイントから多点へのインタフェースFor、Neighbor Interface ID分野がある別々のType1リンク記述(ポイントツーポイント)がHelloパケットの隣人によって広告に掲載されたInterface IDにセットして、Neighbor Router ID分野が隣人の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 the Designated Router of Network N3.
例と、ルータRT3がArea1のために起因するルータ-LSA図1を考えてください。 単一のインタフェースだけについて説明しなければなりません、すなわち、トランジットに接続するそれはN3をネットワークでつなぎます。 それは、RT4がNetwork N3のDesignated Routerに選出されたと仮定します。
Coltun, et al. Standards Track [Page 28] RFC 5340 OSPF for IPv6 July 2008
Coltun、他 IPv6 July 2008のための標準化過程[28ページ]RFC5340OSPF
; RT3's router-LSA for Area 1
; 領域1へのRT3のルータ-LSA
LS age = 0 ;newly (re)originated
LS type = 0x2001 ;router-LSA
Link State ID = 0 ;first fragment
Advertising Router = 192.0.2.3 ;RT3's Router ID
bit E = 0 ;not an AS boundary router
bit B = 1 ;area border router
Options = (V6-bit|E-bit|R-bit)
Type = 2 ;connects to N3
Metric = 1 ;cost to N3
Interface ID = 1 ;RT3's Interface ID on N3
Neighbor Interface ID = 1 ;RT4's Interface ID on N3
Neighbor Router ID = 192.0.2.4 ; RT4's Router ID
LS age = 0 ;newly (re)originated LS type = 0x2001 ;router-LSA Link State ID = 0 ;first fragment Advertising Router = 192.0.2.3 ;RT3's Router ID bit E = 0 ;not an AS boundary router bit B = 1 ;area border router Options = (V6-bit|E-bit|R-bit) Type = 2 ;connects to N3 Metric = 1 ;cost to N3 Interface ID = 1 ;RT3's Interface ID on N3 Neighbor Interface ID = 1 ;RT4's Interface ID on N3 Neighbor Router ID = 192.0.2.4 ; RT4のRouter ID
RT3's router-LSA for Area 1
領域1へのRT3のルータ-LSA
For example, if another router was added to Network N4, RT3 would have to advertise a second link description for its connection to (the now transit) network N4. This could be accomplished by reoriginating the above router-LSA, this time with two link descriptions. Or, a separate router-LSA could be originated with a separate Link State ID (e.g., using a Link State ID of 1) to describe the connection to N4.
例えば、別のルータがNetwork N4に加えられるなら、RT3は接続のために(現在は通過します)ネットワークN4に2番目のリンク記述の広告を出さなければならないでしょうに。 2つのリンク記述で上のルータ-LSA、この時間が再起因させることによって、これを達成できるでしょう。 または、接続についてN4に説明するために別々のLink州ID(例えば、1のLink州IDを使用する)と共に別々のルータ-LSAを溯源できました。
Host routes for stub networks no longer appear in the router-LSA. Rather, they are included in intra-area-prefix-LSAs.
スタッブネットワークのためのホストルートはもうルータ-LSAに現れません。 むしろ、イントラ領域がLSAsを前に置いた状態で、それらは中に含まれています。
4.4.3.3. Network-LSAs
4.4.3.3. ネットワーク-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 with an elected Designated Router that is fully adjacent with at least one other router on the link. The network-LSA is originated by the link's Designated Router and lists all routers on the link with which it is fully adjacent.
ネットワーク-LSAのLSタイプは値0x2002に用意ができています。 ネットワークLSAsには、領域の氾濫範囲があります。 ネットワーク-LSAがあらゆる放送のために溯源されるか、またはNBMAはリンクの上に他の少なくとも1つのルータがある状態で完全に隣接している選出されたDesignated Routerにリンクします。 LSAをネットワークでつなぐのは、リンクのDesignated Routerによって溯源されて、それが完全に隣接しているリンクにすべてのルータを記載します。
The procedure for originating network-LSAs in IPv6 is the same as the IPv4 procedure documented in Section 12.4.2 of [OSPFV2], with the following exceptions:
IPv6でネットワーク-LSAsを溯源するための手順はIPv4手順が.2セクション12.4[OSPFV2]に記録したのと同じです、以下の例外で:
o An IPv6 network-LSA's Link State ID is set to the Interface ID of
the Designated Router on the link.
o IPv6ネットワーク-LSAのLink州IDはリンクの上のDesignated RouterのInterface IDに設定されます。
o IPv6 network-LSAs do not contain a Network Mask. All addressing
information formerly contained in the IPv4 network-LSA has now
been consigned to intra-Area-Prefix-LSAs originated by the link's
Designated Router.
o IPv6 network-LSAs do not contain a Network Mask. All addressing information formerly contained in the IPv4 network-LSA has now been consigned to intra-Area-Prefix-LSAs originated by the link's Designated Router.
Coltun, et al. Standards Track [Page 29] RFC 5340 OSPF for IPv6 July 2008
Coltun, et al. Standards Track [Page 29] RFC 5340 OSPF for IPv6 July 2008
o The Options field in the network-LSA is set to the logical OR of
the Options fields contained within the link's associated link-
LSAs corresponding to fully adjacent neighbors. In this way, the
network link exhibits a capability when at least one fully
adjacent neighbor on the link requests that the capability be
advertised.
o The Options field in the network-LSA is set to the logical OR of the Options fields contained within the link's associated link- LSAs corresponding to fully adjacent neighbors. In this way, the network link exhibits a capability when at least one fully adjacent neighbor on the link requests that the capability be advertised.
As an example, assuming that Router RT4 has been elected the Designated Router of Network N3 in Figure 1, the following network- LSA is originated:
As an example, assuming that Router RT4 has been elected the Designated Router of Network N3 in Figure 1, the following network- LSA is originated:
; 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.0.2.4 ;RT4's Router ID
Options = (V6-bit|E-bit|R-bit)
Attached Router = 192.0.2.4 ;Router ID
Attached Router = 192.0.2.1 ;Router ID
Attached Router = 192.0.2.2 ;Router ID
Attached Router = 192.0.2.3 ;Router ID
LS age = 0 ;newly (re)originated LS type = 0x2002 ;network-LSA Link State ID = 1 ;RT4's Interface ID on N3 Advertising Router = 192.0.2.4 ;RT4's Router ID Options = (V6-bit|E-bit|R-bit) Attached Router = 192.0.2.4 ;Router ID Attached Router = 192.0.2.1 ;Router ID Attached Router = 192.0.2.2 ;Router ID Attached Router = 192.0.2.3 ;Router ID
Network-LSA for Network N3
Network-LSA for Network N3
4.4.3.4. Inter-Area-Prefix-LSAs
4.4.3.4. 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 [OSPFV2], 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 [OSPFV2], with the following exceptions:
o The Link State ID of an inter-area-prefix-LSA has lost all of its
addressing semantics and simply serves to distinguish multiple
inter-area-prefix-LSAs that are originated by the same router.
o The Link State ID of an inter-area-prefix-LSA has lost all of its addressing semantics and simply serves to distinguish multiple inter-area-prefix-LSAs that are originated by the same router.
o 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.
o The NU-bit in the PrefixOptions field should be clear.
Coltun, et al. Standards Track [Page 30] RFC 5340 OSPF for IPv6 July 2008
Coltun, et al. Standards Track [Page 30] RFC 5340 OSPF for IPv6 July 2008
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 2001:0db8:c001::/48. The cost is set to 4, which is the maximum cost of all of the individual component prefixes. The prefix is padded out to an even number of 32-bit words, so that it consumes 64 bits of space instead of 48 bits.
As an example, the following shows the inter-area-prefix-LSA that Router RT4 originates into the OSPF backbone area, condensing all of Area 1's prefixes into the single prefix 2001:0db8:c001::/48. The cost is set to 4, which is the maximum cost of all of the individual component prefixes. The prefix is padded out to an even number of 32-bit words, so that it consumes 64 bits of space instead of 48 bits.
; 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.0.2.4 ;RT4's ID
Metric = 4 ;maximum to components
PrefixLength = 48
PrefixOptions = 0
Address Prefix = 2001:0db8:c001 ;padded to 64-bits
LS age = 0 ;newly (re)originated LS type = 0x2003 ;inter-area-prefix-LSA Advertising Router = 192.0.2.4 ;RT4's ID Metric = 4 ;maximum to components PrefixLength = 48 PrefixOptions = 0 Address Prefix = 2001:0db8:c001 ;padded to 64-bits
Inter-area-prefix-LSA for Area 1 addresses originated
by Router
RT4 into the backbone
Inter-area-prefix-LSA for Area 1 addresses originated by Router RT4 into the backbone
4.4.3.5. Inter-Area-Router-LSAs
4.4.3.5. 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 (i.e., an AS Boundary Router (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 (i.e., an AS Boundary Router (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 [OSPFV2], 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 [OSPFV2], 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 and now simply serves to
distinguish multiple inter-area-router-LSAs that are originated by
the same router. The destination router's Router ID is now found
in the body of the LSA.
o The Link State ID of an inter-area-router-LSA is no longer the destination router's OSPF Router ID and now simply serves to distinguish multiple inter-area-router-LSAs that are originated by the same router. The destination router's Router ID is now found in the body of the LSA.
Coltun, et al. Standards Track [Page 31] RFC 5340 OSPF for IPv6 July 2008
Coltun, et al. Standards Track [Page 31] RFC 5340 OSPF for IPv6 July 2008
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 [OSPFV2]. 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 [OSPFV2]. 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.0.2.4 ;RT4's ID
Options = (V6-bit|E-bit|R-bit) ;RT7's capabilities
Metric = 14 ;cost to RT7
Destination Router ID = Router RT7's ID
LS age = 0 ;newly (re)originated LS type = 0x2004 ;inter-area-router-LSA Advertising Router = 192.0.2.4 ;RT4's ID Options = (V6-bit|E-bit|R-bit) ;RT7's capabilities Metric = 14 ;cost to RT7 Destination Router ID = Router RT7's ID
Inter-area-router-LSA for AS boundary router RT7 originated by Router
RT4 into Area 1
Inter-area-router-LSA for AS boundary router RT7 originated by Router RT4 into Area 1
4.4.3.6. AS-External-LSAs
4.4.3.6. 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 [OSPFV2], 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 [OSPFV2], with the following exceptions:
o The Link State ID of an AS-external-LSA has lost all of its
addressing semantics and simply serves to distinguish multiple AS-
external-LSAs that are originated by the same router.
o The Link State ID of an AS-external-LSA has lost all of its addressing semantics and simply serves to distinguish multiple AS- external-LSAs that are originated by the same router.
o 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.
o The NU-bit in the PrefixOptions field should be clear.
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.
Coltun, et al. Standards Track [Page 32] RFC 5340 OSPF for IPv6 July 2008
Coltun, et al. Standards Track [Page 32] RFC 5340 OSPF for IPv6 July 2008
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 supported through the inclusion of the Referenced LS Type
field and the optional Referenced Link State ID field (the latter
present if and only if the Referenced LS Type is non-zero). This
capability is for future use; the Referenced LS Type should be set
to 0, and received non-zero values for this field should be
ignored until its use is defined.
o The capability for an AS-external-LSA to reference another LSA has been supported through the inclusion of the Referenced LS Type field and the optional Referenced Link State ID field (the latter present if and only if the Referenced LS Type is non-zero). This capability is for future use; the Referenced LS Type should be set to 0, and received non-zero values for this field should be ignored until its use is defined.
As an example, consider the OSPF Autonomous System depicted in Figure 6 of [OSPFV2]. Assume that RT7 has learned its route to N12 via BGP and that it wishes to advertise a Type 2 metric into the AS. Also assume that the IPv6 prefix for N12 is the value 2001:0db8:0a00::/40. RT7 would then originate the following AS-external-LSA for the external network N12. Note that within the AS-external-LSA, N12's prefix occupies 64 bits of space in order to maintain 32-bit alignment.
As an example, consider the OSPF Autonomous System depicted in Figure 6 of [OSPFV2]. Assume that RT7 has learned its route to N12 via BGP and that it wishes to advertise a Type 2 metric into the AS. Also assume that the IPv6 prefix for N12 is the value 2001:0db8:0a00::/40. RT7 would then originate the following AS-external-LSA for the external network N12. Note that within the AS-external-LSA, N12's prefix occupies 64 bits of space in order to maintain 32-bit alignment.
; 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 ;LSA type/scope unique identifier
Advertising Router = Router RT7's ID
bit E = 1 ;Type 2 metric
bit F = 0 ;no forwarding address
bit T = 1 ;external route tag included
Metric = 2
PrefixLength = 40
PrefixOptions = 0
Referenced LS Type = 0 ;no Referenced Link State ID
Address Prefix = 2001:0db8:0a00 ;padded to 64-bits
External Route Tag = as per BGP/OSPF interaction
LS age = 0 ;newly (re)originated LS type = 0x4005 ;AS-external-LSA Link State ID = 123 ;LSA type/scope unique identifier Advertising Router = Router RT7's ID bit E = 1 ;Type 2 metric bit F = 0 ;no forwarding address bit T = 1 ;external route tag included Metric = 2 PrefixLength = 40 PrefixOptions = 0 Referenced LS Type = 0 ;no Referenced Link State ID Address Prefix = 2001:0db8:0a00 ;padded to 64-bits External Route Tag = as per BGP/OSPF interaction
AS-external-LSA for Network N12, originated by Router RT7
AS-external-LSA for Network N12, originated by Router RT7
4.4.3.7. NSSA-LSAs
4.4.3.7. NSSA-LSAs
The LS type of an NSSA-LSA is set to the value 0x2007. NSSA-LSAs have area flooding scope. Each NSSA-LSA describes a path to a prefix external to the Autonomous System whose flooding scope is restricted to a single NSSA area.
The LS type of an NSSA-LSA is set to the value 0x2007. NSSA-LSAs have area flooding scope. Each NSSA-LSA describes a path to a prefix external to the Autonomous System whose flooding scope is restricted to a single NSSA area.
The procedure for originating NSSA-LSAs in IPv6 is the same as the IPv4 procedure documented in [NSSA], with the following exceptions:
The procedure for originating NSSA-LSAs in IPv6 is the same as the IPv4 procedure documented in [NSSA], with the following exceptions:
Coltun, et al. Standards Track [Page 33] RFC 5340 OSPF for IPv6 July 2008
Coltun, et al. Standards Track [Page 33] RFC 5340 OSPF for IPv6 July 2008
o The Link State ID of an NSSA-LSA has lost all of its addressing
semantics and simply serves to distinguish multiple NSSA-LSAs that
are originated by the same router in the same area.
o The Link State ID of an NSSA-LSA has lost all of its addressing semantics and simply serves to distinguish multiple NSSA-LSAs that are originated by the same router in the same area.
o 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.
o The NU-bit in the PrefixOptions field should be clear.
o Link-local addresses can never be advertised in NSSA-LSAs.
o Link-local addresses can never be advertised in NSSA-LSAs.
o The forwarding address is present in the NSSA-LSA if and only if
the NSSA-LSA's bit F is set.
o The forwarding address is present in the NSSA-LSA if and only if the NSSA-LSA's bit F is set.
o The external route tag is present in the NSSA-LSA if and only if
the NSSA-LSA's bit T is set.
o The external route tag is present in the NSSA-LSA if and only if the NSSA-LSA's bit T is set.
o The capability for an NSSA-LSA to reference another LSA has been
supported through the inclusion of the Referenced LS Type field
and the optional Referenced Link State ID field (the latter
present if and only if the Referenced LS Type is non-zero). This
capability is for future use; the Referenced LS Type should be set
to 0, and received non-zero values for this field should be
ignored until its use is defined.
o The capability for an NSSA-LSA to reference another LSA has been supported through the inclusion of the Referenced LS Type field and the optional Referenced Link State ID field (the latter present if and only if the Referenced LS Type is non-zero). This capability is for future use; the Referenced LS Type should be set to 0, and received non-zero values for this field should be ignored until its use is defined.
An example of an NSSA-LSA would only differ from an AS-external-LSA in that the LS type would be 0x2007 rather than 0x4005.
An example of an NSSA-LSA would only differ from an AS-external-LSA in that the LS type would be 0x2007 rather than 0x4005.
4.4.3.8. Link-LSAs
4.4.3.8. 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 two or more (including the originating router itself) routers. Link-LSAs SHOULD NOT be originated for virtual links.
The LS type of a link-LSA is set to the value 0x0008. Link-LSAs have link-local flooding scope. A router originates a separate link-LSA for each attached link that supports two or more (including the originating router itself) routers. Link-LSAs SHOULD NOT be originated for virtual links.
Link-LSAs have three purposes:
Link-LSAs have three purposes:
1. They provide the router's link-local address to all other routers
attached to the link.
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.
2. They inform other routers attached to the link of a list of IPv6 prefixes to associate with the link.
3. They allow the router to advertise a collection of Options bits
in the network-LSA originated by the Designated Router on a
broadcast or NBMA link.
3. They allow the router to advertise a collection of Options bits in the network-LSA originated by the Designated Router on a broadcast or NBMA link.
Coltun, et al. Standards Track [Page 34] RFC 5340 OSPF for IPv6 July 2008
Coltun, et al. Standards Track [Page 34] RFC 5340 OSPF for IPv6 July 2008
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 reflect the router's
capabilities. On multi-access links, the Designated Router will
logically OR the link-LSA Options fields for all fully adjacent
neighbors in Link L's network-LSA.
o The link-LSA's Options field is set to reflect the router's capabilities. On multi-access links, the Designated Router will logically OR the link-LSA Options fields for all fully adjacent neighbors in Link L's network-LSA.
o The router inserts its link-local address on Link L into the link-
LSA. This information will be used when the other routers on Link
L do their next-hop calculations (see Section 4.8.2).
o The router inserts its link-local address on Link L into the link- LSA. This information will be used when the other routers on Link L do their next-hop calculations (see Section 4.8.2).
o Each IPv6 address prefix that has been configured on Link L is
added to the link-LSA by specifying values for the PrefixLength,
PrefixOptions, and Address Prefix fields.
o Each IPv6 address prefix that has been configured on Link L is added to the link-LSA by specifying values for the PrefixLength, PrefixOptions, and Address Prefix fields.
After building a link-LSA for a given link, the router installs the link-LSA into the associated interface data structure and floods the link-LSA on the link. All other routers on the link will receive the link-LSA, but they will not flood the link-LSA on other links.
After building a link-LSA for a given link, the router installs the link-LSA into the associated interface data structure and floods the link-LSA on the link. All other routers on the link will receive the link-LSA, but they will not flood the link-LSA on other links.
If LinkLSASuppression is configured for the interface and the interface type is not broadcast or NBMA, origination of the link-LSA may be suppressed. This implies that other routers on the link will ascertain the router's next-hop address using a mechanism other than the link-LSA (see Section 4.8.2). Refer to Appendix C.3 for a description of the LinkLSASuppression interface configuration parameter.
If LinkLSASuppression is configured for the interface and the interface type is not broadcast or NBMA, origination of the link-LSA may be suppressed. This implies that other routers on the link will ascertain the router's next-hop address using a mechanism other than the link-LSA (see Section 4.8.2). Refer to Appendix C.3 for a description of the LinkLSASuppression interface configuration parameter.
As an example, consider the link-LSA that RT3 will build for N3 in Figure 1. Suppose that the prefix 2001:0db8:c001:0100::/56 has been configured within RT3 for N3. This will result in the following link-LSA that RT3 will flood only on N3. Note that not all routers on N3 need be configured with the prefix; those not configured will learn the prefix when receiving RT3's link-LSA.
As an example, consider the link-LSA that RT3 will build for N3 in Figure 1. Suppose that the prefix 2001:0db8:c001:0100::/56 has been configured within RT3 for N3. This will result in the following link-LSA that RT3 will flood only on N3. Note that not all routers on N3 need be configured with the prefix; those not configured will learn the prefix when receiving RT3's link-LSA.
Coltun, et al. Standards Track [Page 35] RFC 5340 OSPF for IPv6 July 2008
Coltun, et al. Standards Track [Page 35] RFC 5340 OSPF for IPv6 July 2008
; 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.0.2.3 ;RT3's Router ID
Rtr Priority = 1 ;RT3's N3 Router Priority
Options = (V6-bit|E-bit|R-bit)
Link-local Interface Address = fe80:0001::RT3
# prefixes = 1
PrefixLength = 56
PrefixOptions = 0
Address Prefix = 2001:0db8:c001:0100 ;pad to 64-bits
LS age = 0 ;newly (re)originated LS type = 0x0008 ;link-LSA Link State ID = 1 ;RT3's Interface ID on N3 Advertising Router = 192.0.2.3 ;RT3's Router ID Rtr Priority = 1 ;RT3's N3 Router Priority Options = (V6-bit|E-bit|R-bit) Link-local Interface Address = fe80:0001::RT3 # prefixes = 1 PrefixLength = 56 PrefixOptions = 0 Address Prefix = 2001:0db8:c001:0100 ;pad to 64-bits
RT3's link-LSA for N3
RT3's link-LSA for N3
4.4.3.9. Intra-Area-Prefix-LSAs
4.4.3.9. 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 either associates a list of IPv6 address prefixes with a transit network link by referencing a network-LSA, or associates a list of IPv6 address prefixes with a router by referencing a router-LSA. A stub link's prefixes are associated with its attached router.
The LS type of an intra-area-prefix-LSA is set to the value 0x2009. Intra-area-prefix-LSAs have area flooding scope. An intra-area- prefix-LSA has one of two functions. It either associates a list of IPv6 address prefixes with a transit network link by referencing a network-LSA, or associates a list of IPv6 address prefixes with a router by referencing a router-LSA. A stub link's prefixes are associated with its attached router.
A router MAY originate multiple intra-area-prefix-LSAs for a given area. Each intra-area-prefix-LSA has a unique Link State ID and contains an integral number of prefix descriptions.
A router MAY originate multiple intra-area-prefix-LSAs for a given area. Each intra-area-prefix-LSA has a unique Link State ID and contains an integral number of prefix descriptions.
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 Advertising Router are set to the corresponding
fields in Link L's network-LSA (namely, LS type, Link State ID,
and Advertising Router respectively). This means that the
Referenced LS Type is set to 0x2002, the Referenced Link State ID
is set to the Designated Router's Interface ID on Link L, and the
Referenced Advertising Router is set to the Designated Router's
Router ID.
o In order to indicate that the prefixes are to be associated with the Link L, the fields Referenced LS Type, Referenced Link State ID, and Referenced Advertising Router are set to the corresponding fields in Link L's network-LSA (namely, LS type, Link State ID, and Advertising Router respectively). This means that the Referenced LS Type is set to 0x2002, the Referenced Link State ID is set to the Designated Router's Interface ID on Link L, and the Referenced Advertising Router is set to the Designated Router's Router ID.
o Each link-LSA associated with Link L is examined (these are in the
Designated Router's interface structure for Link L). If the link-
LSA's Advertising Router is fully adjacent to the Designated
o 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
Coltun, et al. Standards Track [Page 36] RFC 5340 OSPF for IPv6 July 2008
Coltun, et al. Standards Track [Page 36] RFC 5340 OSPF for IPv6 July 2008
Router and the Link State ID matches the neighbor's interface ID,
the list of prefixes in the link-LSA is copied into the intra-
area-prefix-LSA that is being built. Prefixes having the NU-bit
and/or LA-bit set in their Options field SHOULD NOT be copied, nor
should link-local addresses be copied. Each prefix is described
by the PrefixLength, PrefixOptions, and Address Prefix fields.
Multiple prefixes having the same PrefixLength and Address Prefix
are considered to be duplicates. In this case, their
PrefixOptions fields should be logically OR'ed together, and a
single instance of the duplicate prefix should be included in the
intra-area-prefix-LSA. The Metric field for all prefixes is set
to 0.
Router and the Link State ID matches the neighbor's interface ID, the list of prefixes in the link-LSA is copied into the intra- area-prefix-LSA that is being built. Prefixes having the NU-bit and/or LA-bit set in their Options field SHOULD NOT be copied, nor should link-local addresses be copied. Each prefix is described by the PrefixLength, PrefixOptions, and Address Prefix fields. Multiple prefixes having the same PrefixLength and Address Prefix are considered to be duplicates. In this case, their PrefixOptions fields should be logically OR'ed together, and a single instance of the duplicate prefix should be included in the intra-area-prefix-LSA. The Metric field for all prefixes is set to 0.
o 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 prefixes for its attached stub links, looped-back interfaces, and hosts. A Router RTX would build its intra-area-prefix-LSA in the following fashion:
A router builds an intra-area-prefix-LSA to advertise prefixes for its attached stub links, looped-back interfaces, and hosts. A Router RTX would build its intra-area-prefix-LSA in the following fashion:
o In order to indicate that the prefixes are to be associated with
the Router RTX itself, RTX sets the Referenced LS Type to 0x2001,
the Referenced Link State ID to 0, and the Referenced Advertising
Router to RTX's own Router ID.
o In order to indicate that the prefixes are to be associated with the Router RTX itself, RTX sets the Referenced LS Type to 0x2001, the Referenced Link State ID to 0, and the Referenced Advertising Router to RTX's own Router ID.
o Router RTX examines its list of interfaces to the area. If the
interface is in the state Down, its prefixes are not included. If
the interface has been reported in RTX's router-LSA as a Type 2
link description (link to transit network), prefixes that will be
included in the intra-area-prefix-LSA for the link are skipped.
However, any prefixes that would normally have the LA-bit set
SHOULD be advertised independent of whether or not the interface
is advertised as a transit link. If the interface type is point-
to-multipoint or the interface is in the state Loopback, the
global scope IPv6 addresses associated with the interface (if any)
are copied into the intra-area-prefix-LSA with the PrefixOptions
LA-bit set, the PrefixLength set to 128, and the metric set to 0.
Otherwise, the list of global prefixes configured in RTX for the
link are copied into the intra-area-prefix-LSA by specifying the
PrefixLength, PrefixOptions, and Address Prefix fields. The
Metric field for each of these prefixes is set to the interface's
output cost.
o Router RTX examines its list of interfaces to the area. If the interface is in the state Down, its prefixes are not included. If the interface has been reported in RTX's router-LSA as a Type 2 link description (link to transit network), prefixes that will be included in the intra-area-prefix-LSA for the link are skipped. However, any prefixes that would normally have the LA-bit set SHOULD be advertised independent of whether or not the interface is advertised as a transit link. If the interface type is point- to-multipoint or the interface is in the state Loopback, the global scope IPv6 addresses associated with the interface (if any) are copied into the intra-area-prefix-LSA with the PrefixOptions LA-bit set, the PrefixLength set to 128, and the metric set to 0. Otherwise, the list of global prefixes configured in RTX for the link are copied into the intra-area-prefix-LSA by specifying the PrefixLength, PrefixOptions, and Address Prefix fields. The Metric field for each of these prefixes is set to the interface's output cost.
o RTX adds the IPv6 prefixes for any directly attached hosts
belonging to the area (see Appendix C.7) to the intra-area-prefix-
LSA.
o RTX adds the IPv6 prefixes for any directly attached hosts belonging to the area (see Appendix C.7) to the intra-area-prefix- LSA.
Coltun, et al. Standards Track [Page 37] RFC 5340 OSPF for IPv6 July 2008
Coltun, et al. Standards Track [Page 37] RFC 5340 OSPF for IPv6 July 2008
o If RTX has one or more virtual links configured through the area,
it includes one of its global scope IPv6 interface addresses in
the LSA (if it hasn't already), setting the LA-bit in the
PrefixOptions field, the PrefixLength to 128, and the Metric to 0.
This information will be used later in the routing calculation so
that the two ends of the virtual link can discover each other's
IPv6 addresses.
o If RTX has one or more virtual links configured through the area, it includes one of its global scope IPv6 interface addresses in the LSA (if it hasn't already), setting the LA-bit in the PrefixOptions field, the PrefixLength to 128, and the Metric to 0. This information will be used later in the routing calculation so that the two ends of the virtual link can discover each other's IPv6 addresses.
o 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.
Coltun, et al. Standards Track [Page 38] RFC 5340 OSPF for IPv6 July 2008
Coltun, et al. Standards Track [Page 38] RFC 5340 OSPF for IPv6 July 2008
; RT4's Intra-area-prefix-LSA for network link N3
; RT4's 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 ;LSA type/scope unique identifier
Advertising Router = 192.0.2.4 ;RT4's Router ID
# prefixes = 1
Referenced LS Type = 0x2002 ;network-LSA reference
Referenced Link State ID = 1
Referenced Advertising Router = 192.0.2.4
PrefixLength = 56 ;N3's prefix
PrefixOptions = 0
Metric = 0
Address Prefix = 2001:0db8:c001:0100 ;pad
LS age = 0 ;newly (re)originated LS type = 0x2009 ;Intra-area-prefix-LSA Link State ID = 5 ;LSA type/scope unique identifier Advertising Router = 192.0.2.4 ;RT4's Router ID # prefixes = 1 Referenced LS Type = 0x2002 ;network-LSA reference Referenced Link State ID = 1 Referenced Advertising Router = 192.0.2.4 PrefixLength = 56 ;N3's prefix PrefixOptions = 0 Metric = 0 Address Prefix = 2001:0db8:c001:0100 ;pad
; RT3's Intra-area-prefix-LSA for its own prefixes
; RT3'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 ;LSA type/scope unique identifier
Advertising Router = 192.0.2.3 ;RT3's Router ID
# prefixes = 1
Referenced LS Type = 0x2001 ;router-LSA reference
Referenced Link State ID = 0
Referenced Advertising Router = 192.0.2.3
PrefixLength = 56 ;N4's prefix
PrefixOptions = 0
Metric = 2 ;N4 interface cost
Address Prefix = 2001:0db8:c001:0400 ;pad
LS age = 0 ;newly (re)originated LS type = 0x2009 ;Intra-area-prefix-LSA Link State ID = 177 ;LSA type/scope unique identifier Advertising Router = 192.0.2.3 ;RT3's Router ID # prefixes = 1 Referenced LS Type = 0x2001 ;router-LSA reference Referenced Link State ID = 0 Referenced Advertising Router = 192.0.2.3 PrefixLength = 56 ;N4's prefix PrefixOptions = 0 Metric = 2 ;N4 interface cost Address Prefix = 2001:0db8:c001:0400 ;pad
Intra-area-prefix-LSA for Network Link N3
Intra-area-prefix-LSA for Network Link N3
When network conditions change, it may be necessary for a router to move prefixes from one intra-area-prefix-LSA to another. For example, if the router is the Designated Router for a link but the link has no other attached routers, the link's prefixes are advertised in an intra-area-prefix-LSA referring to the Designated Router's router-LSA. When additional routers appear on the link, a network-LSA is originated for the link and the link's prefixes are moved to an intra-area-prefix-LSA referring to the network-LSA.
When network conditions change, it may be necessary for a router to move prefixes from one intra-area-prefix-LSA to another. For example, if the router is the Designated Router for a link but the link has no other attached routers, the link's prefixes are advertised in an intra-area-prefix-LSA referring to the Designated Router's router-LSA. When additional routers appear on the link, a network-LSA is originated for the link and the link's prefixes are moved to an intra-area-prefix-LSA referring to the network-LSA.
Note that in the intra-area-prefix-LSA, the Referenced Advertising Router is always equal to the router that is originating the intra- area-prefix-LSA (i.e., the LSA's Advertising Router). The reason the Referenced Advertising Router field appears is that, even though it is currently redundant, it may not be in the future. We may sometime want to use the same LSA format to advertise address prefixes for other protocol suites. In this case, the Designated Router may not
Note that in the intra-area-prefix-LSA, the Referenced Advertising Router is always equal to the router that is originating the intra- area-prefix-LSA (i.e., the LSA's Advertising Router). The reason the Referenced Advertising Router field appears is that, even though it is currently redundant, it may not be in the future. We may sometime want to use the same LSA format to advertise address prefixes for other protocol suites. In this case, the Designated Router may not
Coltun, et al. Standards Track [Page 39] RFC 5340 OSPF for IPv6 July 2008
Coltun, et al. Standards Track [Page 39] RFC 5340 OSPF for IPv6 July 2008
be running the other protocol suite, and so another of the link's routers may need to originate the intra-area-prefix-LSA. In that case, the Referenced Advertising Router and Advertising Router would be different.
be running the other protocol suite, and so another of the link's routers may need to originate the intra-area-prefix-LSA. In that case, the Referenced Advertising Router and Advertising Router would be different.
4.4.4. Future LSA Validation
4.4.4. Future LSA Validation
It is expected that new LSAs will be defined that will not be processed during the Shortest Path First (SPF) calculation as described in Section 4.8, for example, OSPFv3 LSAs corresponding to information advertised in OSPFv2 using opaque LSAs [OPAQUE]. In general, the new information advertised in future LSAs should not be used unless the OSPFv3 router originating the LSA is reachable. However, depending on the application and the data advertised, this reachability validation MAY be done less frequently than every SPF calculation.
It is expected that new LSAs will be defined that will not be processed during the Shortest Path First (SPF) calculation as described in Section 4.8, for example, OSPFv3 LSAs corresponding to information advertised in OSPFv2 using opaque LSAs [OPAQUE]. In general, the new information advertised in future LSAs should not be used unless the OSPFv3 router originating the LSA is reachable. However, depending on the application and the data advertised, this reachability validation MAY be done less frequently than every SPF calculation.
To facilitate inter-area reachability validation, any OSPFv3 router originating AS scoped LSAs is considered an AS Boundary Router (ASBR).
To facilitate inter-area reachability validation, any OSPFv3 router originating AS scoped LSAs is considered an AS Boundary Router (ASBR).
4.5. Flooding
4.5. Flooding
Most of the flooding algorithm remains unchanged from the IPv4 flooding mechanisms described in Section 13 of [OSPFV2]. In particular, the protocol processes for determining which LSA instance is newer (Section 13.1 of [OSPFV2]), responding to updates of self- originated LSAs (Section 13.4 of [OSPFV2]), sending Link State Acknowledgment packets (Section 13.5 of [OSPFV2]), retransmitting LSAs (Section 13.6 of [OSPFV2]), and receiving Link State Acknowledgment packets (Section 13.7 of [OSPFV2]), are exactly the same for IPv6 and IPv4.
Most of the flooding algorithm remains unchanged from the IPv4 flooding mechanisms described in Section 13 of [OSPFV2]. In particular, the protocol processes for determining which LSA instance is newer (Section 13.1 of [OSPFV2]), responding to updates of self- originated LSAs (Section 13.4 of [OSPFV2]), sending Link State Acknowledgment packets (Section 13.5 of [OSPFV2]), retransmitting LSAs (Section 13.6 of [OSPFV2]), and receiving Link State Acknowledgment packets (Section 13.7 of [OSPFV2]), are exactly the same for IPv6 and IPv4.
However, the addition of flooding scope and unknown LSA type handling (see Appendix A.4.2.1) has caused some changes in the OSPF flooding algorithm: the reception of Link State Updates (Section 13 in [OSPFV2]) and the sending of Link State Updates (Section 13.3 of [OSPFV2]) must take into account the LSA's scope and U-bit setting. Also, installation of LSAs into the OSPF database (Section 13.2 of [OSPFV2]) causes different events in IPv6, due to the reorganization of LSA types and the IPv6 LSA contents. These changes are described in detail below.
しかしながら、氾濫範囲と未知のLSAタイプ取り扱い(Appendix A.4.2.1を見る)の追加はOSPF氾濫アルゴリズムにおけるいくつかの変化を引き起こしました: Link州Updatesのレセプション([OSPFV2]のセクション13)とLink州Updatesの発信([OSPFV2]のセクション13.3)はLSAの範囲とU-ビット設定を考慮に入れなければなりません。 また、OSPFデータベース([OSPFV2]のセクション13.2)へのLSAsのインストールはIPv6で異なったイベントを引き起こします、LSAタイプの再編成とIPv6 LSAコンテンツのため。 これらの変化は以下で詳細に説明されます。
4.5.1. Receiving Link State Update Packets
4.5.1. リンク州のアップデートパケットを受けます。
The encoding of flooding scope in the LS type and the need to process unknown LS types cause modifications to the processing of received Link State Update packets. As in IPv4, each LSA in a received Link
LSタイプと未知のLSを処理する必要性における、氾濫範囲のコード化は容認されたLink州Updateパケットの処理への原因変更をタイプします。 aの各LSAがLinkを受けたのでIPv4では
Coltun, et al. Standards Track [Page 40] RFC 5340 OSPF for IPv6 July 2008
Coltun、他 IPv6 July 2008のための標準化過程[40ページ]RFC5340OSPF
State Update packet is examined. In IPv4, eight steps are executed for each LSA, as described in Section 13 of [OSPFV2]. For IPv6, all the steps are the same, except that Steps 2 and 3 are modified as follows:
州のUpdateパケットは調べられます。 IPv4では、8ステップは各LSAのために[OSPFV2]のセクション13で説明されるように実行されます。 IPv6に関しては、Steps2と3が以下の通り変更されるのを除いて、すべてのステップが同じです:
(2) Examine the LSA's LS type. Discard the LSA and get
the next one from the Link State Update packet if the
interface area has been configured as a stub or
NSSA area and the LS type indicates "AS flooding scope".
(2) LSAのLSタイプを調べてください。 LSAを捨ててください、そして、スタッブかNSSA領域とLSタイプが「AS氾濫範囲」を示すときインタフェース領域が構成されたなら、Link州Updateパケットから次のものを得てください。
This generalizes the IPv4 behavior where AS-external-LSAs
and AS-scoped opaque LSAs [OPAQUE] are not flooded
throughout stub or NSSA areas.
ASの外部のLSAsとASによって見られた不透明なLSAs[OPAQUE]がスタッブかNSSA領域中にあふれないところでこれはIPv4の振舞いを一般化します。
(3) Else if the flooding scope in the LSA's LS type is set to
"reserved", discard the LSA and get the next one from
the Link State Update packet.
(3) LSAのLSタイプによる氾濫範囲が「予約されていた」状態で設定されるなら、ほかに、LSAを捨ててください、そして、Link州Updateパケットから次のものを得てください。
Steps 5b (sending Link State Update packets) and 5d (installing LSAs in the link-state database) in Section 13 of [OSPFV2] are also somewhat different for IPv6, as described in Sections 4.5.2 and 4.5.3 below.
また、IPv6において、[OSPFV2]のセクション13におけるステップの5b(送付Link州Updateパケット)と5d(リンク州のデータベースにLSAsをインストールする)もいくらか異なっています、セクション4.5.2と4.5で.3未満について説明するので。
4.5.2. Sending Link State Update Packets
4.5.2. 送付リンク州のアップデートパケット
The sending of Link State Update packets is described in Section 13.3 of [OSPFV2]. For IPv4 and IPv6, the steps for sending a Link State Update packet are the same (steps 1 through 5 of Section 13.3 in [OSPFV2]). However, the list of eligible interfaces on which to flood the LSA is different. For IPv6, the eligible interfaces are selected based on the following factors:
Link州Updateパケットの発信は[OSPFV2]のセクション13.3で説明されます。 IPv4とIPv6に関しては、Link州Updateパケットを送るためのステップは同じです([OSPFV2]のセクション13.3のステップ1〜5)。 しかしながら、LSAをあふれさせる適任のインタフェースのリストは異なっています。 IPv6に関しては、適任のインタフェースは以下の要素に基づいて選択されます:
o The LSA's flooding scope.
o LSAは範囲をあふれさせています。
o For LSAs with area or link-local flooding scope, the particular
area or interface with which the LSA is associated.
o LSAが関連している領域があるLSAsかリンク地方の氾濫範囲、特定の領域またはインタフェースに。
o Whether the LSA has a recognized LS type.
o LSAに認識されたLSがあるか否かに関係なく、タイプしてください。
o The setting of the U-bit in the LS type. If the U-bit is set to
0, unrecognized LS types are treated as having link-local scope.
If set to 1, unrecognized LS types are stored and flooded as if
they were recognized.
o LSタイプのU-ビットの設定。 U-ビットが0に設定されるなら、認識されていないLSタイプはリンク地方の範囲を持っているとして扱われます。 1に設定されるなら、まるで彼らが認識されるかのように、認識されていないLSタイプは、保存されて、あふれます。
Coltun, et al. Standards Track [Page 41] RFC 5340 OSPF for IPv6 July 2008
Coltun、他 IPv6 July 2008のための標準化過程[41ページ]RFC5340OSPF
Choosing the set of eligible interfaces then breaks into the following cases:
次に、適任のインタフェースのセットを選ぶと、以下のケースは侵入されます:
Case 1
The LSA's LS type is recognized. In this case, the set of
eligible interfaces is set depending on the flooding scope encoded
in the LS type. If the flooding scope is "AS flooding scope", the
eligible interfaces are all router interfaces excepting virtual
links. In addition, AS-external-LSAs are not flooded on
interfaces connecting to stub or NSSA areas. If the flooding
scope is "area flooding scope", the eligible interfaces are those
interfaces connecting to the LSA's associated area. If the
flooding scope is "link-local flooding scope", then there is a
single eligible interface, the one connecting to the LSA's
associated link (which is also the interface on which the LSA was
received in a Link State Update packet).
LSAのLSがタイプするケース1は認識されます。 この場合、適任のインタフェースのセットはLSタイプでコード化された氾濫範囲によるように設定されます。 氾濫範囲が「AS氾濫範囲」であるなら、適任のインタフェースは仮想のリンクを除いたすべてルータインタフェースです。 さらに、ASの外部のLSAsはスタッブに接続するインタフェースかNSSA領域にあふれません。 氾濫範囲が「領域の氾濫範囲」であるなら、適任のインタフェースはLSAの関連領域に接続するそれらのインタフェースです。 氾濫範囲が「リンク地方の氾濫範囲」であるなら、単一の適任のインタフェース(LSAの関連リンク(また、LSAがLink州Updateパケットに受け取られたインタフェースである)に接続するもの)があります。
Case 2
The LS type is unrecognized and the U-bit in the LS type is set to
0 (treat the LSA as if it had link-local flooding scope). In this
case, there is a single eligible interface, namely, the interface
on which the LSA was received.
LSが認識されていないのをタイプするケース2とLSタイプのU-ビットは0に設定されます(まるでリンク地方の氾濫範囲を持っているかのようにLSAを扱ってください)。 この場合、単一の適任のインタフェース、すなわち、LSAが受け取られたインタフェースがあります。
Case 3
The LS type is unrecognized, and the U-bit in the LS type is set
to 1 (store and flood the LSA as if the type is understood). In
this case, select the eligible interfaces based on the encoded
flooding scope the same as in Case 1 above.
LSがタイプするケース3は認識されていません、そして、LSタイプのU-ビットは1に設定されます(まるでタイプが理解されているかのように、LSAを保存して、あふれさせてください)。 この場合、上でCase1と同じコード化された氾濫範囲に基づいた適任のインタフェースを選択してください。
A further decision must sometimes be made before adding an LSA to a given neighbor's link-state retransmission list (Step 1d in Section 13.3 of [OSPFV2]). If the LS type is recognized by the router but not by the neighbor (as can be determined by examining the Options field that the neighbor advertised in its Database Description packet) and the LSA's U-bit is set to 0, then the LSA should be added to the neighbor's link-state retransmission list if and only if that neighbor is the Designated Router or Backup Designated Router for the attached link. The LS types described in detail by this document, namely, router-LSAs (LS type 0x2001), network-LSAs (0x2002), inter- area-prefix-LSAs (0x2003), inter-area-router-LSAs (0x2004), NSSA-LSAs (0x2007), AS-external-LSAs (0x4005), link-LSAs (0x0008), and Intra- Area-Prefix-LSAs (0x2009), are assumed to be understood by all routers. However, all LS types MAY not be understood by all routers. For example, a new LSA type with its U-bit set to 0 MAY only be understood by a subset of routers. This new LS type should only be flooded to an OSPF neighbor that understands the LS type or when the neighbor is the Designated Router or Backup Designated Router for the attached link.
与えられた隣人のリンク州の「再-トランスミッション」リスト([OSPFV2]のセクション13.3におけるステップ1d)にLSAを追加する前に、時々さらなる決定をしなければなりません。 LSタイプがルータによって認識されますが、隣人に認識されるというわけではなくて(隣人がDatabase記述パケットに広告を出したOptions分野を調べることによって決定できるように)、LSAのU-ビットが0に設定されるならLSAが隣人のリンク州の「再-トランスミッション」リストに追加されるべきである、その隣人である場合にだけ、付属リンクへのDesignated RouterかBackup Designated Routerがそうです。 すなわち、LSタイプはこのドキュメントで詳細にルータ-LSAsについて説明しました(LSは0×2001をタイプします)、ネットワーク-LSAs(0×2002)、相互領域がLSAsを前に置く、(0×2003)相互領域ルータLSAs、(0×2004)(NSSA-LSAs(0×2007)、ASの外部のLSAs(0×4005)、リンク-LSAs(0×0008)、およびIntra領域接頭語LSAs(0×2009))は、すべてのルータに解釈されると思われます。 しかしながら、すべてのLSタイプがすべてのルータに解釈されるかもしれないというわけではありません。 例えば、0に設定されたU-ビットがある新しいLSAタイプはルータの部分集合に解釈されるだけであるかもしれません。 この新しいLSタイプは付属リンクへのLSがタイプするのを理解しているOSPF隣人、いつ隣人がDesignated Routerであるか、そして、またはBackup Designated Routerへあふれるだけであるべきです。
Coltun, et al. Standards Track [Page 42] RFC 5340 OSPF for IPv6 July 2008
Coltun、他 IPv6 July 2008のための標準化過程[42ページ]RFC5340OSPF
The previous paragraph solves a problem for IPv4 OSPF extensions, which require that the Designated Router support the extension in order to have the new LSA types flooded across broadcast and NBMA networks.
前のパラグラフはIPv4 OSPF拡張子のために問題を解きます。(拡張子は、Designated Routerが放送とNBMAネットワークの向こう側に新しいLSAタイプをあふれさせるように拡大をサポートするのを必要とします)。
4.5.3. Installing LSAs in the Database
4.5.3. LSAsをデータベースにインストールします。
There are three separate places to store LSAs, depending on their flooding scope. LSAs with AS flooding scope are stored in the global OSPF data structure (see Section 4.1) as long as their LS type is known or their U-bit is 1. LSAs with area flooding scope are stored in the appropriate area data structure (see Section 4.1.1) as long as their LS type is known or their U-bit is 1. LSAs with link-local flooding scope, and those LSAs with unknown LS type and U-bit set to 0 (treat the LSA as if it had link-local flooding scope), are stored in the appropriate interface data structure.
彼らの氾濫範囲によって、LSAsを保存する3つの別々の場所があります。 彼らのLSタイプが知られているか、彼らのU-ビットが1である限り、AS氾濫範囲があるLSAsはグローバルなOSPFデータ構造(セクション4.1を見る)で保存されます。 彼らのLSタイプが知られているか、彼らのU-ビットが1である限り、領域の氾濫範囲があるLSAsは適切な領域データ構造(セクション4.1.1を見る)で保存されます。 リンク地方の氾濫範囲があるLSAs、およびタイプとU-ビットが0に設定する未知のLSとそれらのLSAs(まるでリンク地方の氾濫範囲を持っているかのようにLSAを扱う)は適切なインタフェースデータ構造で保存されます。
When storing the LSA into the link-state database, a check must be made to see whether the LSA's contents have changed. Changes in contents are indicated exactly as in Section 13.2 of [OSPFV2]. When an LSA's contents have been changed, the following parts of the routing table must be recalculated, based on the LSA's LS type:
リンク州のデータベースとしてLSAを保存するとき、LSAの内容が変化したかどうかを見るのをチェックをしなければなりません。 コンテンツにおける変化はちょうど[OSPFV2]のセクション13.2のように示されます。 LSAの内容を変えたとき、経路指定テーブルの以下の部分について再計算しなければなりません、LSAのLSタイプに基づいて:
Router-LSAs, Network-LSAs, Intra-Area-Prefix-LSAs, and Link-LSAs
The entire routing table is recalculated, starting with the
shortest-path calculation for each area (see Section 4.8).
ルータ-LSAs、Network-LSAs、Intra領域接頭語LSAs、および全体のルーティングがテーブルの上に置くLink-LSAsは再計算されます、各領域のための最短パス計算から始まって(セクション4.8を見てください)。
Inter-Area-Prefix-LSAs and Inter-Area-Router-LSAs
The best route to the destination described by the LSA must be
recalculated (see Section 16.5 in [OSPFV2]). If this destination
is an AS boundary router, it may also be necessary to re-examine
all the AS-external-LSAs.
目的地への最も良いルートがLSAで説明した相互Area接頭語LSAsとInter領域ルータLSAsについて再計算しなければなりません([OSPFV2]でセクション16.5を見てください)。 また、この目的地がAS境界ルータであるなら、すべてのASの外部のLSAsを再検討するのも必要であるかもしれません。
AS-external-LSAs and NSSA-LSAs
The best route to the destination described by the AS-external-LSA
or NSSA-LSA must be recalculated (see Section 16.6 in [OSPFV2] and
Section 2.0 in [NSSA]).
ASの外部のLSAsと目的地への最も良いルートがASの外部のLSAかNSSA-LSAで説明したNSSA-LSAsについて再計算しなければなりません([OSPFV2]のセクション16.6と[NSSA]のセクション2.0を見てください)。
As in IPv4, any old instance of the LSA must be removed from the database when the new LSA is installed. This old instance must also be removed from all neighbors' link-state retransmission lists.
新しいLSAをインストールするとき、IPv4のように、データベースからLSAのどんな古いインスタンスも取り除かなければなりません。 また、すべての隣人のリンク州の「再-トランスミッション」リストからこの古いインスタンスを取り除かなければなりません。
4.6. Definition of Self-Originated LSAs
4.6. 自己によって溯源された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 [OSPFV2]. For IPv6, self-originated LSAs are those LSAs whose Advertising Router is equal to the router's own Router ID.
IPv6では、自己によって溯源されたLSAの定義は[OSPFV2]のセクション13.4と14.1に現れるIPv4定義から簡素化されました。 IPv6に関しては、自己によって溯源されたLSAsはAdvertising Routerがルータの自己のRouter IDと等しいそれらのLSAsです。
Coltun, et al. Standards Track [Page 43] RFC 5340 OSPF for IPv6 July 2008
Coltun、他 IPv6 July 2008のための標準化過程[43ページ]RFC5340OSPF
4.7. Virtual Links
4.7. 仮想のリンク
OSPF virtual links for IPv4 are described in Section 15 of [OSPFV2]. Virtual links are the same in IPv6, with the following exceptions:
IPv4のためのOSPFの仮想のリンクは[OSPFV2]のセクション15で説明されます。 仮想のリンクは以下の例外があるIPv6で同じです:
o LSAs having AS flooding scope are never flooded over virtual
adjacencies, nor are LSAs with AS flooding scope summarized over
virtual adjacencies during the database exchange process. This is
a generalization of the IPv4 treatment of AS-external-LSAs.
o AS氾濫範囲を持っているLSAsは決して仮想の隣接番組の上で水につからないで、またAS氾濫範囲がデータベース交換プロセスの間、仮想の隣接番組の上へまとめられているLSAsではありません。 これはASの外部のLSAsのIPv4処理の一般化です。
o The IPv6 interface address of a virtual link MUST be an IPv6
address having global scope, instead of the link-local addresses
used by other interface types. This address is used as the IPv6
source for OSPF protocol packets sent over the virtual link.
Hence, a link-LSA SHOULD NOT be originated for a virtual link
since the virtual link has no link-local address or associated
prefixes.
o 仮想のリンクのIPv6インターフェース・アドレスはグローバルな範囲を持っているIPv6アドレスであるに違いありません、他のインターフェース型によって使用されたリンクローカルのアドレスの代わりに。 OSPFプロトコルパケットのためのIPv6ソースが仮想のリンクを移動したので、このアドレスは使用されています。 したがって、リンク-LSA SHOULD NOTは仮想のリンクにはリンクローカルアドレスが全くないので仮想のリンクに溯源されたか、または接頭語を関連づけました。
o Likewise, the virtual neighbor's IPv6 address is an IPv6 address
with global scope. To enable the discovery of a virtual
neighbor's IPv6 address during the routing calculation, the
neighbor advertises its virtual link's IPv6 interface address in
an intra-area-prefix-LSA originated for the virtual link's transit
area (see Section 4.4.3.9 and Section 4.8.1).
o 同様に、仮想の隣人のIPv6アドレスはグローバルな範囲があるIPv6アドレスです。 イントラ領域はLSAを前に置きます。ルーティング計算の間、仮想の隣人のIPv6アドレスの発見を可能にするために、隣人が中に仮想のリンクのIPv6インターフェース・アドレスの広告を出す、仮想のリンクのトランジット領域(セクション4.4.3の.9とセクション4.8.1を見る)に起因しました。
o Like all other IPv6 OSPF interfaces, virtual links are assigned
unique (within the router) Interface IDs. These are advertised in
Hellos sent over the virtual link and in the router's router-LSAs.
o 他のすべてのIPv6 OSPFインタフェースのように、ユニークな(ルータの中の)インタフェースIDは仮想のリンクに割り当てられます。 仮想のリンクの上に送られたハローズとルータのルータ-LSAsにこれらの広告を出します。
4.8. Routing Table Calculation
4.8. 経路指定テーブル計算
The IPv6 OSPF routing calculation proceeds along the same lines as the IPv4 OSPF routing calculation, following the five steps specified by Section 16 of [OSPFV2]. High-level differences between the IPv6 and IPv4 calculations include:
IPv6 OSPFルーティング計算は同じやり方でIPv4 OSPFルーティング計算として続きます、[OSPFV2]のセクション16によって指定された5つの方法に従って。 IPv6とIPv4計算のハイレベルの違いは:
o Prefix information has been removed from router-LSAs and network-
LSAs and is now advertised in intra-area-prefix-LSAs. Whenever
[OSPFV2] specifies that stub networks within router-LSAs be
examined, IPv6 will instead examine prefixes within intra-area-
prefix-LSAs.
o 接頭語情報では、ルータ-LSAsとネットワークLSAsから取り除いて、イントラ領域がLSAsを前に置いた状態で、現在、広告を出します。 [OSPFV2]が、ルータ-LSAsの中のスタッブネットワークが調べられると指定するときはいつも、IPv6は代わりにイントラ領域接頭語-LSAsの中で接頭語を調べるでしょう。
o Type 3 and 4 summary-LSAs have been renamed inter-area-prefix-LSAs
and inter-area-router-LSAs respectively.
o そして、相互領域がLSAsを前に置いた状態でタイプ3と4概要-LSAsが改名された、相互領域ルータLSAs、それぞれ。
Coltun, et al. Standards Track [Page 44] RFC 5340 OSPF for IPv6 July 2008
Coltun、他 IPv6 July 2008のための標準化過程[44ページ]RFC5340OSPF
o Addressing information is no longer encoded in Link State IDs and
is now only found within the body of LSAs.
o アドレス指定情報は、もうLink州IDでコード化されないで、今、LSAsのボディーの中で見つけられるだけです。
o In IPv6, a router can originate multiple router-LSAs,
distinguished by Link State ID, within a single area. These
router-LSAs MUST be treated as a single aggregate by the area's
shortest-path calculation (see Section 4.8.1).
o IPv6では、ルータはただ一つの領域の中でLink州IDによって区別された複数のルータ-LSAsを溯源できます。 領域の最短パス計算でこれらのルータ-LSAsをただ一つの集合として扱わなければなりません(セクション4.8.1を見てください)。
For each area, the shortest-path tree calculation creates routing table entries for the area's routers and transit links (see Section 4.8.1). These entries are then used when processing intra- area-prefix-LSAs, inter-area-prefix-LSAs, and inter-area-router-LSAs, as described in Section 4.8.3.
各領域に、最短パス木の計算は領域のルータとトランジットリンクのための経路指定テーブルエントリーを作成します(セクション4.8.1を見てください)。 そして、次に、イントラを処理して、領域がLSAsを前に置いて、相互領域がLSAsを前に置くこれらのエントリーが使用される、相互領域ルータLSAs、セクション4.8では、.3に説明されます。
Events generated as a result of routing table changes (Section 16.7 of [OSPFV2]) and the equal-cost multipath logic (Section 16.8 of [OSPFV2]) are identical for both IPv4 and IPv6.
IPv4とIPv6の両方に、ルーティングの結果、テーブル変化([OSPFV2]のセクション16.7)であると生成されたイベントと等価コストマルチパス論理([OSPFV2]のセクション16.8)は同じです。
4.8.1. Calculating the Shortest-Path Tree for an Area
4.8.1. 最短パス木について領域に計算します。
The IPv4 shortest-path calculation is contained in Section 16.1 of [OSPFV2]. The graph used by the shortest-path tree calculation is identical for both IPv4 and IPv6. The graph's vertices are routers and transit links, represented by router-LSAs and network-LSAs respectively. A router is identified by its OSPF Router ID, while a transit link is identified by its Designated Router's Interface ID and OSPF Router ID. Both routers and transit links have associated routing table entries within the area (see Section 4.3).
IPv4最短パス計算は[OSPFV2]のセクション16.1に含まれています。 IPv4とIPv6の両方に、最短パス木の計算で使用されるグラフは同じです。 グラフの頭頂は、ルータ-LSAsとネットワーク-LSAsによってそれぞれ表されたルータとトランジットリンクです。 ルータはOSPF Router IDによって特定されます、トランジットリンクがDesignated RouterのInterface IDとOSPF Router IDによって特定されますが。 ルータとトランジットリンクの両方が領域の中で経路指定テーブルエントリーを関連づけました(セクション4.3を見てください)。
Section 16.1 of [OSPFV2] splits up the shortest-path calculations into two stages. First, the Dijkstra calculation is performed, and then the stub links are added onto the tree as leaves. The IPv6 calculation maintains this split.
[OSPFV2]のセクション16.1は最短パス計算を2つのステージに分けます。 まず最初に、ダイクストラの計算は実行されます、そして、次に、スタッブリンクは葉として木に加えられます。 IPv6計算はこの分裂を維持します。
The Dijkstra calculation for IPv6 is identical to that specified for IPv4, with the following exceptions (referencing the steps from the Dijkstra calculation as described in Section 16.1 of [OSPFV2]):
IPv6のためのダイクストラの計算はIPv4に指定されたそれと同じです、以下の例外で([OSPFV2]のセクション16.1で説明されるようにダイクストラの計算からステップに参照をつけて):
o The Vertex ID for a router is the OSPF Router ID. The Vertex ID
for a transit network is a combination of the Interface ID and
OSPF Router ID of the network's Designated Router.
o ルータのためのVertex IDはOSPF Router IDです。 トランジットネットワークのためのVertex IDは、Interface IDの組み合わせとネットワークのDesignated RouterのOSPF Router IDです。
o In Step 2, when a router Vertex V has just been added to the
shortest-path tree, there may be multiple LSAs associated with the
router. All router-LSAs with the Advertising Router set to V's
OSPF Router ID MUST be processed as an aggregate, treating them as
fragments of a single large router-LSA. The Options field and the
o ルータVertex Vがちょうど最短パス木に加えられたところなとき、Step2に、ルータに関連している複数のLSAsがあるかもしれません。 集合としてV OSPF Router IDに用意ができているAdvertising Routerとすべてのルータ-LSAsを処理しなければなりません、独身の大きいルータ-LSAの断片として彼らを扱って。 そしてOptionsがさばく。
Coltun, et al. Standards Track [Page 45] RFC 5340 OSPF for IPv6 July 2008
Coltun、他 IPv6 July 2008のための標準化過程[45ページ]RFC5340OSPF
router type bits (bits Nt, V, E, and B) should always be taken
from the router-LSA with the smallest Link State ID.
最も小さいLink州IDと共にルータ-LSAからルータタイプビット(ビットNt、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 and the router-LSA V6-bit or R-bit is
not set in the LSA options, the transit link W is ignored and V's
next link is examined.
o Step 2bでは、Wがルータであり、ルータLSA V6ビットかR-ビットがLSAオプションで設定されないなら、トランジットリンクWは無視されます、そして、次がリンクするVは調べられます。
o In Step 2b, if W is a router, there may again be multiple LSAs
associated with the router. All router-LSAs with the Advertising
Router set to W's OSPF Router ID MUST be processed as an
aggregate, treating them as fragments of a single large router-
LSA.
o Step 2bに、ルータに関連している複数のLSAsがWがルータであるなら、再びあるかもしれません。 集合としてWのOSPF Router IDに用意ができているAdvertising Routerとすべてのルータ-LSAsを処理しなければなりません、独身の大きいルータLSAの断片として彼らを扱って。
o In Step 4, there are now per-area routing table entries for each
of an area's routers rather than just the area border routers.
These entries subsume all the functionality of IPv4's area border
router routing table entries, including the maintenance of virtual
links. When the router added to the area routing table in this
step is the other end of a virtual link, the virtual neighbor's IP
address is set as follows: The collection of intra-area-prefix-
LSAs originated by the virtual neighbor is examined, with the
virtual neighbor's IP address being set to the first prefix
encountered with the LA-bit set.
o Step4に、まさしく境界ルータよりむしろそれぞれの領域のルータのための1領域あたりの経路指定テーブルエントリーが現在、あります。 これらのエントリーは仮想のリンクのメインテナンスを含むIPv4の境界ルータ経路指定テーブルエントリーのすべての機能性を包括します。 このステップにおける領域経路指定テーブルに加えられたルータが仮想のリンクのもう一方の端であるときに、仮想の隣人のIPアドレスは以下の通り設定されます: 仮想の隣人によって溯源されたイントラ領域接頭語-LSAsの収集は調べられます、仮想の隣人のIPアドレスがLA-ビットセットで遭遇する最初の接頭語に設定されている状態で。
o Routing table entries for transit networks, which are no longer
associated with IP networks, are also calculated in Step 4 and
added to the per-area routing table.
o 輸送網のための経路指定テーブルエントリーは、また、Step4で計算されて、1領域あたりの経路指定テーブルに加えられます。(輸送網はもうIPネットワークに関連していません)。
The next stage of the shortest-path calculation proceeds similarly to the two steps of the second stage of Section 16.1 in [OSPFV2]. However, instead of examining the stub links within router-LSAs, the list of the area's intra-area-prefix-LSAs is examined. A prefix advertisement whose NU-bit is set SHOULD NOT be included in the routing calculation. The cost of any advertised prefix is the sum of the prefix's advertised metric plus the cost to the transit vertex (either router or transit network) identified by intra-area-prefix- LSA's Referenced LS Type, Referenced Link State ID, and Referenced Advertising Router fields. This latter cost is stored in the transit vertex's routing table entry for the area.
最短パス計算の次のステージは同様に[OSPFV2]の2番目のステージのセクション16.1の2ステップに進みます。 しかしながら、審査の代わりに、イントラ領域がLSAsを前に置いた状態で、スタッブはルータ-LSAs、領域のリストの中でリンクします。調べられます。 含まれていて、NU-ビットがルーティング計算でセットSHOULD NOTである接頭語広告。 どんな広告を出している接頭語の費用もトランジット頂点(ルータかトランジットネットワークのどちらか)への費用がイントラ領域接頭語-LSAのReferenced LS Type、Referenced Link州IDとReferenced Advertising Router分野で特定した接頭語の広告を出しているメートル法のプラスの合計です。 この後者の費用は領域のためのトランジット頂点の経路指定テーブルエントリーに保存されます。
This specification does not require that the above algorithm be used to calculate the intra-area shortest-path tree. However, if another algorithm or optimization is used, an identical shortest-path tree must be produced. It is also important that any alternate algorithm or optimization maintain the requirement that transit vertices must
この仕様は、上のアルゴリズムがイントラ領域最短パス木について計算するのに使用されるのを必要としません。 しかしながら、別のアルゴリズムか最適化が使用されているなら、同じ最短パス木を生産しなければなりません。 また、どんな代替のアルゴリズムや最適化もトランジット頭頂がそうしなければならないという要件を維持するのも、重要です。
Coltun, et al. Standards Track [Page 46] RFC 5340 OSPF for IPv6 July 2008
Coltun、他 IPv6 July 2008のための標準化過程[46ページ]RFC5340OSPF
be bidirectional for inclusion in the tree. Alternate algorithms and optimizations are beyond the scope of this specification.
木での包含において、双方向になってください。 代替のアルゴリズムと最適化はこの仕様の範囲を超えています。
4.8.2. The Next-Hop Calculation
4.8.2. 次のホップ計算
In IPv6, the calculation of the next-hop's IPv6 address (which will be a link-local address) proceeds along the same lines as the IPv4 next-hop calculation (see Section 16.1.1 of [OSPFV2]). However, there are some differences. When calculating the next-hop IPv6 address for a router (call it Router X) that shares a link with the calculating router, the calculating router assigns the next-hop IPv6 address to be the link-local interface address contained in Router X's link-LSA (see Appendix A.4.9) for the link. This procedure is necessary for some link types, for example NBMA, where the two routers need not be neighbors and might not be exchanging OSPF Hello packets. For other link types, the next-hop address may be determined via the IPv6 source address in the neighbor's Hello packet.
IPv6では、次のホップのIPv6アドレス(リンクローカルアドレスになる)の計算は同じやり方でIPv4次のホップ計算として続きます(.1セクション16.1[OSPFV2]を見てください)。 しかしながら、いくつかの違いがあります。 計算のルータとのリンクを共有するルータ(それをRouter Xと呼ぶ)のための次のホップIPv6アドレスについて計算するとき、計算のルータは、Router Xのリンク-LSAにリンクに含まれた(Appendix A.4.9を見ます)リンク地方のインタフェースアドレスになるように次のホップIPv6アドレスを割り当てます。 この手順が何人かのリンク型、例えば、NBMAに必要です。そこでは2つのルータは、隣人である必要はなく、OSPF Helloパケットを交換していないことであるかもしれません。 他のリンク型にとって、次のホップアドレスは隣人のHelloパケットのIPv6ソースアドレスで決定しているかもしれません。
Additionally, when calculating routes for the area's intra-area- prefix-LSAs, the parent vertex can be either a router-LSA or network- LSA. This is in contrast to the second stage of the OSPFv2 intra- area SPF (Section 16.1 in [OSPFV2]) where the parent vertex is always a router-LSA. In the case where the intra-area-prefix-LSA's referenced LSA is a directly connected network-LSA, the prefixes are also considered to be directly connected. In this case, the next hop is solely the outgoing link and no IPv6 next-hop address is selected.
領域のイントラ領域接頭語-LSAsのためのルートを計算するとき、さらに、親頂点は、ルータ-LSAかネットワークLSAのどちらかであるかもしれません。 これはいつも親頂点がルータ-LSAであるOSPFv2イントラ領域SPF([OSPFV2]のセクション16.1)の2番目の台と対照してあります。 また、イントラ領域がLSAのものを前に置いている参照をつけられたLSAが直接接続されたネットワーク-LSAである場合では、接頭語によって直接接続されると考えられます。 この場合、次のホップは唯一出発しているリンクです、そして、IPv6次のホップアドレスは全く選択されません。
4.8.3. Calculating the Inter-Area Routes
4.8.3. 相互領域ルートを計算します。
Calculation of inter-area routes for IPv6 proceeds along the same lines as the IPv4 calculation in Section 16.2 of [OSPFV2], with the following modifications:
IPv6のための相互領域ルートの計算は同じやり方でIPv4計算として[OSPFV2]のセクション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 an
advertised AS boundary router's OSPF Router ID is carried in the
body of an inter-area-router-LSA.
o 上のLSAのLink州IDはもうネットワークかルータがLSAで説明したエンコードをタイプしません。 代わりに、アドレス接頭語がボディーに含まれている、相互領域がLSAを前に置いて、広告を出しているAS境界ルータのOSPF Router IDがボディーで運ばれる、相互領域ルータLSA
o Prefixes having the NU-bit set in their PrefixOptions field should
be ignored by the inter-area route calculation.
o それらのPrefixOptions分野にNU-ビットを設定する接頭語は相互領域ルート計算で無視されるべきです。
Coltun, et al. Standards Track [Page 47] RFC 5340 OSPF for IPv6 July 2008
Coltun、他 IPv6 July 2008のための標準化過程[47ページ]RFC5340OSPF
When a single inter-area-prefix-LSA or inter-area-router-LSA has changed, the incremental calculations outlined in Section 16.5 of [OSPFV2] can be performed instead of recalculating the entire routing table.
または、シングルであるときに、相互領域がLSAを前に置く、相互領域ルータLSA、変えます、全体の経路指定テーブルについて再計算することの代わりに[OSPFV2]のセクション16.5に概説された増加の計算は実行できます。
4.8.4. Examining Transit Areas' Summary-LSAs
4.8.4. トランジット領域の概要-LSAsを調べます。
Examination of transit areas' summary-LSAs in IPv6 proceeds along the same lines as the IPv4 calculation in Section 16.3 of [OSPFV2], modified in the same way as the IPv6 inter-area route calculation in Section 4.8.3.
IPv6のトランジット領域の概要-LSAsの試験は同じやり方でIPv4計算としてセクション4.8.3におけるIPv6相互領域ルート計算と同様に、変更された[OSPFV2]のセクション16.3で続きます。
4.8.5. Calculating AS External and NSSA Routes
4.8.5. 外部として計算して、NSSAルート
The IPv6 AS external route calculation proceeds along the same lines as the IPv4 calculation in Section 16.4 of [OSPFV2] and Section 2.5 of [NSSA], with the following exceptions:
IPv6 AS外部経路計算は同じやり方でIPv4計算として[OSPFV2]のセクション16.4と[NSSA]のセクション2.5で続きます、以下の例外で:
o The Link State ID of the AS-external-LSA and NSSA-LSA types no
longer encodes the network described by the LSA. Instead, an
address prefix is contained in the body of the LSA.
o ASの外部のLSAとNSSA-LSAのLink州IDはもうネットワークがLSAで説明したエンコードをタイプしません。 代わりに、アドレス接頭語はLSAのボディーに含まれています。
o The default route in AS-external-LSAs or NSSA-LSAs is advertised
by a zero-length prefix.
o ゼロ・レングス接頭語はASの外部のLSAsかNSSA-LSAsのデフォルトルートの広告を出します。
o Instead of comparing the AS-external-LSA's or NSSA-LSA's
Forwarding Address field to 0.0.0.0 to see whether a forwarding
address has been used, the bit F in the respective LSA is
examined. A forwarding address is in use if and only if bit F is
set.
o AS外部のLSAのものかNSSA-LSAのForwarding Addressを比較することの代わりに.0を0.0としてさばいてください。.0 フォーワーディング・アドレスが使用されたかどうか確認するために、それぞれのLSAのビットFは調べられます。 そして、フォーワーディング・アドレスが使用中である、噛み付かれる場合にだけ、Fは設定されます。
o Prefixes having the NU-bit set in their PrefixOptions field should
be ignored by the inter-area route calculation.
o それらのPrefixOptions分野にNU-ビットを設定する接頭語は相互領域ルート計算で無視されるべきです。
o AS Boundary Router (ASBR) and forwarding address selection will
proceed the same as if RFC1583Compatibility is disabled.
Furthermore, RFC1583Compatibility is not an OSPF for IPv6
configuration parameter. Refer to Appendix C.1.
o まるでRFC1583Compatibilityは障害があるかのようにAS Boundary Router(ASBR)と推進アドレス選択は同じように続くでしょう。 その上、RFC1583CompatibilityはIPv6設定パラメータのためのOSPFではありません。 付録C.1を参照してください。
When a single AS-external-LSA or NSSA-LSA has changed, the incremental calculations outlined in Section 16.6 of [OSPFV2] can be performed instead of recalculating the entire routing table.
独身のAS外部のLSAかNSSA-LSAが変化したとき、全体の経路指定テーブルについて再計算することの代わりに[OSPFV2]のセクション16.6に概説された増加の計算は実行できます。
4.9. Multiple Interfaces to a Single Link
4.9. 単一のリンクへの複数のインタフェース
In OSPF for IPv6, a router may have multiple interfaces to a single link associated with the same OSPF instance and area. All interfaces
IPv6のためのOSPFでは、ルータは同じOSPFインスタンスと領域に関連している単一のリンクに複数のインタフェースを持っているかもしれません。 すべてのインタフェース
Coltun, et al. Standards Track [Page 48] RFC 5340 OSPF for IPv6 July 2008
Coltun、他 IPv6 July 2008のための標準化過程[48ページ]RFC5340OSPF
will be used for the reception and transmission of data traffic while only a single interface sends and receives OSPF control traffic. In more detail:
データ通信量のレセプションと送信のために、単一のインタフェースだけがOSPFコントロールトラフィックを送って、受けている間、使用されるでしょう。 さらに詳細に:
o Each of the multiple interfaces is assigned a different Interface
ID. A router will automatically detect that multiple interfaces
are attached to the same link when a Hello packet is received with
one of the router's link-local addresses as the source address and
an Interface ID other than the Interface ID of the receiving
interface.
o 異なったInterface IDはそれぞれの複数のインタフェースに割り当てられます。 ソースアドレスと受信インタフェースのInterface ID以外のInterface IDとしてルータのリンクローカルのアドレスの1つでHelloパケットを受け取るとき、ルータは自動的に付けられたそんなに複数のインタフェースを同じリンクに検出するでしょう。
o Each of the multiple interfaces MUST be configured with the same
Interface Instance ID to be considered on the same link. If an
interface has multiple Instance IDs, it will be grouped with other
interfaces based on matching Instance IDs. Each Instance ID will
be treated uniquely with respect to groupings of multiple
interfaces on the same link. For example, if interface A is
configured with Instance IDs 1 and 35, and interface B is
configured with Instance ID 35, interface B may be the Active
Interface for Instance ID 35 but interface A will be active for
Instance ID 1.
o 同じInterface Instance IDでそれぞれの複数のインタフェースを構成して、同じリンクの上に考えられなければなりません。 インタフェースに複数のInstance IDがあると、Instance IDを合わせることに基づいてそれは他のインタフェースで分類されるでしょう。 それぞれのInstance IDは同じリンクにおける複数のインタフェースの組分けに関して唯一扱われるでしょう。 例えば、インタフェースAがInstance ID1と35によって構成されて、インタフェースBがInstance ID35によって構成されるなら、インタフェースBはInstance ID35のためのActive Interfaceであるかもしれませんが、インタフェースAはInstance ID1にアクティブになるでしょう。
o The router will ignore OSPF packets other than Hello packets on
all but one of the interfaces attached to the link. It will only
send its OSPF control packets (including Hello packets) on a
single interface. This interface is designated the Active
Interface and other interfaces attached to the same link will be
designated Standby Interfaces. The choice of the Active Interface
is implementation dependent. For example, the interface with the
highest Interface ID could be chosen. If the router is elected
Designated Router, it will be the Active Interface's Interface ID
that will be used as the network-LSA's Link State ID.
o ルータはリンクに付けられたインタフェースの1つ以外のすべてのHelloパケット以外のOSPFパケットを無視するでしょう。 それはOSPFコントロールパケット(Helloパケットを含んでいる)を単一のインタフェースに送るだけでしょう。 このインタフェースはActive Interfaceに指定されます、そして、同じリンクに付けられた他のインタフェースはStandby Interfacesに指定されるでしょう。 Active Interfaceの選択は実装に依存しています。 例えば、最も高いInterface IDとのインタフェースを選ぶことができました。 ルータがDesignated Routerに選出されると、ネットワーク-LSA Link州IDとして使用されるのはActive InterfaceのInterface IDになるでしょう。
o All of the interfaces to the link (Active and Standby) will appear
in the router-LSA. In addition, a link-LSA will be generated for
each of the interfaces. In this way, all interfaces will be
included in OSPF's routing calculations.
o リンク(能動態とStandby)へのインタフェースのすべてがルータ-LSAに現れるでしょう。 さらに、リンク-LSAはそれぞれのインタフェースに生成されるでしょう。 このように、すべてのインタフェースがOSPFのルーティング計算に含まれるでしょう。
o Any link-local scope LSAs that are originated for a Standby
Interface will be flooded over the Active Interface.
If a Standby Interface goes down, then the link-local scope LSAs
originated for the Standby Interfaces MUST be flushed on the
Active Interface.
o Standby Interfaceのために溯源されるどんなリンク地方の範囲LSAsもActive Interfaceの上で水につかるでしょう。 Standby Interfaceが落ちるなら、Standby Interfacesのために溯源されたリンク地方の範囲LSAsをActive Interfaceに洗い流さなければなりません。
o Prefixes on Standby Interfaces will be processed the same way as
prefixes on the Active Interface. For example, if the router is
the DR for the link, the Active Interface's prefixes are included
o Standby Interfacesの上の接頭語は接頭語として同じようにActive Interfaceに処理されるでしょう。 例えば、ルータがリンクへのDRであるなら、Active Interfaceの接頭語は含まれています。
Coltun, et al. Standards Track [Page 49] RFC 5340 OSPF for IPv6 July 2008
Coltun、他 IPv6 July 2008のための標準化過程[49ページ]RFC5340OSPF
in an intra-area-prefix-LSA which is associated with the Active
Interface's network-LSA; prefixes from Standby Interfaces on the
link will also be included in that intra-area-prefix LSA.
Similarly, if the link is a stub link, then the prefixes for the
Active and Standby Interfaces will all be included in the same
intra-area-prefix-LSA that is associated with the router-LSA.
中、イントラ領域はLSAを前に置きます(Active Interfaceのネットワーク-LSAに関連しています)。 また、リンクの上のStandby Interfacesからの接頭語はそのイントラ領域接頭語LSAに含まれるでしょう。 同様に、ActiveとStandby Interfacesのための接頭語はリンクがスタッブリンクであるならすべてことになるでしょうイントラ領域がLSAを前に置いた状態で同じくらいに含まれていて、それがルータ-LSAに関連しているという。
o If the Active Interface fails, a new Active Interface will have to
take over. The new Active Interface SHOULD form all new neighbor
adjacencies with routers on the link. This failure can be
detected when the router's other interfaces to the Active
Interface's link cease to hear the router's Hellos or through
internal mechanisms, e.g., monitoring the Active Interface's
status.
o Active Interfaceが失敗すると、新しいActive Interfaceは引き継がなければならないでしょう。リンクの上にルータがある状態で、新しいActive Interface SHOULDはすべての新しい隣人隣接番組を形成します。 この失敗はルータが他ときに、検出されて、Active Interfaceのリンクへのインタフェースが、ルータのハローズか内部のメカニズムを通して聞くのをやめて、例えば、モニターがActive Interfaceの状態であるということであるかもしれません。
o If the network becomes partitioned with different local interfaces
attaching to different network partitions, multiple interfaces
will become Active Interfaces and function independently.
o 異なった局所界面が異なったネットワークパーティションに付いていてネットワークが仕切られるようになると、複数のインタフェースが、Active Interfacesになって、独自に機能するでしょう。
o During the SPF calculation when a network-LSA for a network that
is directly connected to the root vertex is being examined, all of
the multiple interfaces to the link of adjacent router-LSAs must
be used in the next-hop calculation.
This can be accomplished during the back link check (see Section
16.1, Step 2 (B), in [OSPFV2]) by examining each link of the
router-LSA and making a list of the links that point to the
network-LSA. The Interface IDs for links in this list are then
used to find the corresponding link-LSAs and the link-local
addresses used as next hops when installing equal-cost paths in
the routing table.
o 直接根の頂点に接続されるネットワークのためのネットワーク-LSAが調べられているときのSPF計算の間、次のホップ計算に隣接しているルータ-LSAsのリンクへの複数のインタフェースのすべてを使用しなければなりません。 逆リンクチェック(セクション16.1を見てください、Step2(B)、[OSPFV2]で)の間、ルータ-LSAの各リンクを調べて、LSAをネットワークでつなぐのを示すリンクのリストを作ることによって、これを達成できます。 このリストのリンクへのInterface IDはその時、経路指定テーブルで等しい費用経路をインストールするとき次のホップとして使用される対応するリンク-LSAsとリンクローカルのアドレスを見つけるのにおいて使用されています。
o The interface state machine is modified to add the state Standby.
See Section 4.9.1 for a description of the Standby state.
o 界面準位マシンは、州のStandbyを加えるように変更されます。 Standby状態の記述に関してセクション4.9.1を見てください。
4.9.1. Standby Interface State
4.9.1. 予備界面準位
In this state, the interface is one of multiple interfaces to a link and this interface is designated Standby and is not sending or receiving control packets. The interface will continue to receive the Hello packets sent by the Active Interface. The interface will maintain a timer, the Active Interface Timer, with the same interval as the RouterDeadInterval. This timer will be reset whenever an OSPF Hello packet is received from the Active Interface to the link.
インタフェースがこの状態では、リンクへの複数のインタフェースの1つであり、このインタフェースは、コントロールパケットをStandbyに指定されて、送るか、または受けていません。 インタフェースは、Active Interfaceによって送られたHelloパケットを受け続けるでしょう。 インタフェースはRouterDeadIntervalと同じ間隔でタイマ、Active Interface Timerを維持するでしょう。 Active InterfaceからリンクまでOSPF Helloパケットを受け取るときはいつも、このタイマはリセットされるでしょう。
Two new events are added to the list of events that cause interface state changes: MultipleInterfacesToLink and ActiveInterfaceDead. The descriptions of these events are as follows:
2つの新しいイベントが界面準位変化を引き起こすイベントのリストに追加されます: MultipleInterfacesToLinkとActiveInterfaceDead。 これらのイベントの記述は以下の通りです:
Coltun, et al. Standards Track [Page 50] RFC 5340 OSPF for IPv6 July 2008
Coltun、他 IPv6 July 2008のための標準化過程[50ページ]RFC5340OSPF
MultipleInterfacesToLink
An interfaces on the router has received a Hello packet from
another interface on the same router. One of the interfaces is
designated as the Active Interface and the other interface is
designated as a Standby Interface. The Standby Interface
transitions to the Standby state.
ルータのMultipleInterfacesToLink Anインタフェースは同じルータで別のインタフェースからHelloパケットを受けました。 インタフェースの1つはActive Interfaceとして指定されます、そして、もう片方のインタフェースはStandby Interfaceとして指定されます。 Standby InterfaceはStandby状態に移行します。
ActiveInterfaceDead
There has been an indication that a Standby Interface is no longer
on a link with an Active Interface. The firing of the Active
Interface Timer is one indication of this event, as it indicates
that the Standby Interface has not received an OSPF Hello packet
from the Active Interface for the RouterDeadInterval. Other
indications may come from internal notifications, such as the
Active Interface being disabled through a configuration change.
Any indication internal to the router, such that the router knows
the Active Interface is no longer active on the link, can trigger
the ActiveInterfaceDead event for a Standby Interface.
ActiveInterfaceDead ThereはもうActive Interfaceとのどんなリンクの上にもStandby Interfaceがないという指示です。 Active Interface Timerの発火はこのイベントの1回のしるしです、Standby InterfaceがRouterDeadIntervalのためにActive InterfaceからOSPF Helloパケットを受けていないのを示すとき。 他の指摘は無効にされるActive Interfaceなどの内部の通知から構成変更で来るかもしれません。 ルータへの内部のどんな指示(ルータが、Active Interfaceがもうリンクでアクティブでないことを知っているようなもの)もStandby InterfaceのためのActiveInterfaceDeadイベントの引き金となることができます。
Interface state machine additions include:
界面準位マシン追加は:
State(s): Waiting, DR Other, Backup, or DR
州: 待っていて、DR他のバックアップ、またはDR
Event: MultipleInterfacesToLink
イベント: MultipleInterfacesToLink
New state: Standby
新しい州: 予備
Action: All interface variables are reset and interface
timers disabled. Also, all neighbor connections
associated with the interface are destroyed. This
is done by generating the event KillNbr on all
associated neighbors. The Active Interface Timer is
started and the interface will listen for OSPF Hello
packets from the link's Active Interface.
動作: すべてのインタフェース変数が、リセットとインタフェースタイマ身体障害者です。 また、インタフェースに関連づけられたすべての隣人接続が滅ぼされます。 すべての関連隣人の上でイベントがKillNbrであると生成することによって、これをします。 Active Interface Timerは始動されます、そして、インタフェースはリンクのActive InterfaceからOSPF Helloパケットの聞こうとするでしょう。
State(s): Standby
州: 予備
Event: ActiveInterfaceDead
イベント: ActiveInterfaceDead
New state: Down
新しい州: 下に
Action: The Active Interface Timer is first disabled. Then
the InterfaceUp event is invoked.
動作: Active Interface Timerは最初に、無効にされます。 そして、InterfaceUpイベントは呼び出されます。
Standby Interface State Machine Additions
予備界面準位マシン追加
Coltun, et al. Standards Track [Page 51] RFC 5340 OSPF for IPv6 July 2008
Coltun、他 IPv6 July 2008のための標準化過程[51ページ]RFC5340OSPF
5. Security Considerations
5. セキュリティ問題
When running over IPv6, OSPFv3 relies on the IP Authentication Header (see [IPAUTH]) and the IP Encapsulating Security Payload (see [IPESP]) to ensure integrity and authentication/confidentiality of protocol packets. This is described in [OSPFV3-AUTH].
IPv6をひくとき、OSPFv3は、プロトコルパケットの保全と認証/秘密性を確実にするために、IP Authentication Header([IPAUTH]を見る)とIP Encapsulating Security有効搭載量([IPESP]を見る)を当てにします。 これは[OSPFV3-AUTH]で説明されます。
Most OSPFv3 implementations will be running on systems that support multiple protocols with their own independent security assumptions and domains. When IPsec is used to protect OSPFv3 packets, it is important for the implementation to check the IPsec Security Association (SA) and local SA database to ensure the OSPF packet originated from a source that is trusted for OSPFv3. This is required to eliminate the possibility that the packet was authenticated using an SA defined for another protocol running on the same system.
ほとんどのOSPFv3実装がそれら自身の独立しているセキュリティ仮定とドメインで複数のプロトコルをサポートするシステムで動くでしょう。 IPsecがOSPFv3パケットを保護するのに使用されるとき、実装がOSPFパケットがOSPFv3のために信じられるソースから発したのを保証するためにIPsec Security Association(SA)とローカルのSAデータベースをチェックするのは、重要です。 これが、パケットが同じシステムで動く別のプロトコルのために定義されたSAを使用することで認証された可能性を排除するのに必要です。
The mechanisms in [OSPFV3-AUTH] do not provide protection against compromised, malfunctioning, or misconfigured routers. Such routers can, either accidentally or deliberately, cause malfunctions affecting the whole routing domain. The reader is encouraged to consult [GENERIC-THREATS] for a more comprehensive description of threats to routing protocols.
[OSPFV3-AUTH]のメカニズムは感染しているか、誤動作しているか、misconfiguredされたルータに対する保護を提供しません。 そのようなルータは偶然か故意に全体の経路ドメインに影響する不調を引き起こす場合があります。 読者がルーティング・プロトコルへの脅威の、より包括的な記述のために[GENERIC-THREATS]に相談するよう奨励されます。
6. Manageability Considerations
6. 管理可能性問題
The Management Information Base (MIB) for OSPFv3 is defined in [OSPFV3-MIB].
OSPFv3のためのManagement Information基地(MIB)は[OSPFV3-MIB]で定義されます。
7. IANA Considerations
7. IANA問題
Most OSPF for IPv6 IANA considerations are documented in [OSPF-IANA]. IANA has updated the reference for RFC 2740 to this document.
IPv6 IANA問題のためのほとんどのOSPFが[OSPF-IANA]に記録されます。 IANAはRFC2740の参照をこのドキュメントにアップデートしました。
Additionally, this document introduces the following IANA requirements that were not present in [OSPFV3]:
さらに、このドキュメントは[OSPFV3]で以下の存在していないIANA要件を導入します:
o Reserves the options with the values 0x000040 and 0x000080 for
migrated OSPFv2 options in the OSPFv3 Options registry defined in
[OSPF-IANA]. For information on the OSPFv3 Options field, refer
to Appendix A.2.
o OSPFv3 Options登録の移行したOSPFv2オプションのための値0×000040と0x000080があるオプションが[OSPF-IANA]で定義した蓄え。 OSPFv3 Optionsフィールドの情報について、Appendix A.2を参照してください。
o Adds the prefix option P-bit with value 0x08 to the OSPFv3 Prefix
Options registry defined in [OSPF-IANA]. For information on
OSPFv3 Prefix Options, refer to Appendix A.4.1.1.
o 値0x08に従った接頭語オプションP-ビットを[OSPF-IANA]で定義されたOSPFv3 Prefix Options登録に加えます。 OSPFv3 Prefix Optionsの情報について、Appendix A.4.1.1を参照してください。
Coltun, et al. Standards Track [Page 52] RFC 5340 OSPF for IPv6 July 2008
Coltun、他 IPv6 July 2008のための標準化過程[52ページ]RFC5340OSPF
o Adds the prefix option DN-bit with value 0x10 to the OSPFv3 Prefix
Options registry defined in [OSPF-IANA]. For information on
OSPFv3 Prefix Options, refer to Appendix A.4.1.1.
o 値0x10に従った接頭語オプションDN-ビットを[OSPF-IANA]で定義されたOSPFv3 Prefix Options登録に加えます。 OSPFv3 Prefix Optionsの情報について、Appendix A.4.1.1を参照してください。
7.1. MOSPF for OSPFv3 Deprecation IANA Considerations
7.1. OSPFv3不賛成IANA問題のためのMOSPF
With the deprecation of MOSPF for OSPFv3, the following code points are available for reassignment. Refer to [OSPF-IANA] for information on the respective registries. This document:
OSPFv3のためのMOSPFの不賛成で、以下のコード・ポイントは再割当てに利用可能です。 それぞれの登録の情報について[OSPF-IANA]を参照してください。 このドキュメント:
o Deprecates the MC-bit with value 0x000004 in the OSPFv3 Options
registry.
o 値0x000004がOSPFv3 Options登録にある状態で、ビットM.C.を非難します。
o Deprecates Group-membership-LSA with value 6 in OSPFv3 LSA
Function Code registry.
o 非難、Group会員資格LSA、値6がOSPFv3 LSA Function Code登録にある状態で。
o Deprecates MC-bit with value 0x04 in the OSPFv3 Prefix Options
registry.
o 値0x04がOSPFv3 Prefix Options登録にある状態で、ビットM.C.を非難します。
The W-bit in the OSPFv3 Router Properties has also been deprecated. This requires a new registry for OSPFv3 router properties since it will diverge from the OSPFv2 Router Properties.
また、OSPFv3 Router PropertiesのW-ビットも推奨しないです。 OSPFv2 Router Propertiesからそれるので、これはOSPFv3ルータの特性のために新しい登録を必要とします。
Registry Name: OSPFv3 Router Properties Registry
Reference: RFC 5340
Registration Procedures: Standards Action
登録名: OSPFv3ルータ特性の登録参照: RFC5340登録手順: 規格動作
Registry:
Value Description Reference
------ ------------- ---------
0x01 B-bit RFC 5340
0x02 E-bit RFC 5340
0x04 V-bit RFC 5340
0x08 Deprecated RFC 5340
0x10 Nt-bit RFC 5340
登録: 値の記述参照------ ------------- --------- 0×01 B-ビットRFC5340 0×02電子ビットRFC5340 0×04V-ビットRFC5340 0×08の推奨しないRFC5340 0×10Nt-ビットRFC5340
OSPFv3 Router Properties Registry
OSPFv3ルータ特性の登録
8. Acknowledgments
8. 承認
The RFC text was produced using Marshall Rose's xml2rfc tool.
RFCテキストは、マーシャル・ローズのxml2rfcツールを使用することで製作されました。
The following individuals contributed comments that were incorporated into this document:
以下の個人はこのドキュメントに法人組織であるコメントを寄付しました:
o Harold Rabbie for his description of protocol details that needed
to be clarified for OSPFv3 NSSA support.
o 彼のプロトコルの記述のためのハロルドRabbieはOSPFv3 NSSAサポートのためにはっきりさせられるのに必要であるそれを詳しく述べます。
Coltun, et al. Standards Track [Page 53] RFC 5340 OSPF for IPv6 July 2008
Coltun、他 IPv6 July 2008のための標準化過程[53ページ]RFC5340OSPF
o Nic Neate for his pointing out that there needed to be changes for
unknown LSA types handling in the processing of Database
Description packets.
o 未知のLSAのための変化になるようにそこで必要とした彼の指示のためのNicニートはDatabase記述パケットの処理における取り扱いをタイプします。
o Jacek Kwiatkowski for being the first to point out that the V6-
and R-bits are not taken into account in the OSPFv3 intra-area SPF
calculation.
o V6とR-ビットが連れていかれないと指摘する1番目であることのためのヤセクKwiatkowskiは、OSPFv3でイントラ領域がSPF計算であることを説明します。
o Michael Barnes recognized that the support for multiple interfaces
to a single link was broken (see Section 4.9) and provided the
description of the current protocol mechanisms. Abhay Roy
reviewed and suggested improvements to the mechanisms.
o マイケル・バーンズは、単一のリンクへの複数のインタフェースのサポートが中断していると(セクション4.9を見ます)認めて、現在のプロトコルメカニズムの記述を前提としました。Abhayロイは、メカニズムへの改良を見直して、勧めました。
o Alan Davey reviewed and commented on document revisions.
o アラン・デーブは、ドキュメント改正を見直して、批評しました。
o Vivek Dubey reviewed and commented on document revisions.
o Vivek Dubeyはドキュメント改正を見直して、批評しました。
o Manoj Goyal and Vivek Dubey complained enough about link-LSAs
being unnecessary to compel introduction of the LinkLSASuppression
interface configuration parameter.
o Manoj GoyalとVivek Dubeyは、LinkLSASuppressionインタフェース設定パラメータの導入を強制するために不要であるので、リンク-LSAsの周りで十分不平を言いました。
o Manoj Goyal for pointing out that the next-hop calculation for
intra-area-prefix-LSAs corresponding to network vertices was
unclear.
o ネットワーク頭頂とのイントラ領域がLSAsを前に置いている対応のための次のホップ計算が不明瞭であったと指摘するためのManoj Goyal。
o Ramana Koppula reviewed and commented on document revisions.
o ラマナKoppulaはドキュメント改正を見直して、批評しました。
o Paul Wells reviewed and commented on document revisions.
o ポール・ウェルズは、ドキュメント改正を見直して、批評しました。
o Amir Khan reviewed and commented on document revisions.
o アミールカーンは、ドキュメント改正を見直して、批評しました。
o Dow Street and Wayne Wheeler commented on the addition of the DN-
bit to OSPFv3.
o Dow通りとウェイン・ウィーラーはDNビットの追加をOSPFv3に批評しました。
o Mitchell Erblichs provided numerous editorial comments.
o ミッチェルErblichsは頻繁な編集のコメントを提供しました。
o Russ White provided numerous editorial comments.
o ラス・ホワイトは頻繁な編集のコメントを提供しました。
o Kashima Hiroaki provided editorial comments.
o 博暁鹿島は編集のコメントを提供しました。
o Sina Mirtorabi suggested that OSPFv3 should be aligned with OSPFv2
with respect to precedence and should map it to IPv6 traffic class
as specified in RFC 2474. Steve Blake helped with the text.
o シーナMirtorabiは、OSPFv3が先行に関してOSPFv2に並べられるべきであり、RFC2474の指定されるとしてのIPv6トラフィックのクラスにそれを写像するはずであると示唆しました。 スティーブ・ブレークはテキストで助けました。
o Faraz Shamin reviewed a late version of the document and provided
editorial comments.
o Faraz社民は、ドキュメントの遅いバージョンを見直して、編集のコメントを提供しました。
Coltun, et al. Standards Track [Page 54] RFC 5340 OSPF for IPv6 July 2008
Coltun、他 IPv6 July 2008のための標準化過程[54ページ]RFC5340OSPF
o Christian Vogt performed the General Area Review Team (Gen-ART)
review and provided comments.
o クリスチャンのフォークトは、Area Review Team司令官(ARTに情報を得ている)レビューを実行して、コメントを提供しました。
o Dave Ward, Dan Romascanu, Tim Polk, Ron Bonica, Pasi Eronen, and
Lars Eggert provided comments during the IESG review. Also,
thanks to Pasi for the text in Section 5 relating to routing
threats.
o デーヴ・ウォード、ダンRomascanu、ティム・ポーク、ロンBonica、パシEronen、およびラース・エッゲルトはIESGレビューの間、コメントを提供しました。 また、テキストのためにルーティングの脅威に関連しながら、セクション5でパシをありがとうございます。
9. References
9. 参照
9.1. Normative References
9.1. 引用規格
[DEMAND] Moy, J., "Extending OSPF to Support Demand
Circuits", RFC 1793, April 1995.
[要求します] Moy、J.、「要求が回路であるとサポートするためにOSPFを広げています」、RFC1793、1995年4月。
[DIFF-SERV] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field
(DS Field) in the IPv4 and IPv6 Headers",
RFC 2474, December 1998.
[デフ-SERV] ニコルズ、K.、ブレーク、S.、ベイカー、F.、およびD.黒、「IPv4とIPv6ヘッダーとの差別化されたサービス分野(DS分野)の定義」、RFC2474(1998年12月)。
[DN-BIT] Rosen, E., Peter, P., and P. Pillay-Esnault,
"Using a Link State Advertisement (LSA) Options
Bit to Prevent Looping in BGP/MPLS IP Virtual
Private Networks (VPNs)", RFC 4576, June 2006.
[DNによって噛み付かれる]のローゼン、E.、ピーター、P.、およびP.Pillay-Esnault、「リンク州の広告(LSA)を使用して、オプションにBGP/MPLS IP仮想私設網(VPNs)で輪にするのを防ぐために噛み付きました」、RFC4576、2006年6月。
[INTFMIB] McCloghrie, K. and F. Kastenholz, "The Interfaces
Group MIB", RFC 2863, June 2000.
[INTFMIB] McCloghrieとK.とF.Kastenholz、「インタフェースはMIBを分類する」RFC2863、2000年6月。
[IP6ADDR] Hinden, R. and S. Deering, "IP Version 6
Addressing Architecture", RFC 4291, February 2006.
[IP6ADDR] HindenとR.とS.デアリング、「IPバージョン6アドレッシング体系」、RFC4291、2006年2月。
[IPAUTH] Kent, S., "IP Authentication Header", RFC 4302,
December 2005.
[IPAUTH] ケント、S.、「IP認証ヘッダー」、RFC4302、2005年12月。
[IPESP] Kent, S., "IP Encapsulating Security Payload
(ESP)", RFC 4303, December 2005.
[IPESP]ケント、S.、「セキュリティが有効搭載量(超能力)であるとカプセル化するIP」、RFC4303、2005年12月。
[IPV4] Postal, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[IPV4]郵便、J.、「インターネットプロトコル」、STD5、RFC791、9月1981日
[IPV6] Deering, S. and R. Hinden, "Internet Protocol,
Version 6 (IPv6) Specification", RFC 2460,
December 1998.
[IPV6]デアリング、S.とR.Hinden、「インターネットプロトコル、バージョン6(IPv6)仕様」、RFC2460、12月1998日
[NSSA] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA)
Option", RFC 3101, January 2003.
[NSSA] マーフィー、P.、「OSPFしたがって、短く太くない領域(NSSA)オプション」、RFC3101、2003年1月。
Coltun, et al. Standards Track [Page 55] RFC 5340 OSPF for IPv6 July 2008
Coltun、他 IPv6 July 2008のための標準化過程[55ページ]RFC5340OSPF
[OSPF-IANA] Kompella, K. and B. Fenner, "IANA Considerations
for OSPF", BCP 130, RFC 4940, July 2007.
[OSPF-IANA]Kompella、K.とB.フェナー、「OSPFのためのIANA問題」BCP130、2007年7月のRFC4940。
[OSPFV2] Moy, J., "OSPF Version 2", STD 54, RFC 2328,
April 1998.
[OSPFV2]Moy、J.、「OSPF、バージョン2インチ、STD54、RFC2328、1998インチ年4月。
[OSPFV3-AUTH] Gupta, M. and N. Melam, "Authentication/
Confidentiality for OSPFv3", RFC 4552, June 2006.
[OSPFV3-AUTH] グプタとM.とN.Melam、「OSPFv3"、RFC4552、2006年6月のための認証/秘密性。」
[RFC-KEYWORDS] Bradner, S., "Key words for use in RFCs to
Indicate Requirement Levels", BCP 14, RFC 2119,
March 1997.
[RFC-KEYWORDS]ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
9.2. Informative References
9.2. 有益な参照
[GENERIC-THREATS] Barbir, A., Murphy, S., and Y. Yang, "Generic
Threats to Routing Protocols", RFC 4593,
October 2006.
[ジェネリック脅威] 2006年10月のBarbirとA.とマーフィー、S.とY.陽、「ルーティング・プロトコルへのジェネリックの脅威」RFC4593。
[MOSPF] Moy, J., "Multicast Extensions to OSPF", RFC 1584,
March 1994.
[MOSPF] Moy、J.、「OSPFへのマルチキャスト拡大」、RFC1584、1994年3月。
[MTUDISC] Mogul, J. and S. Deering, "Path MTU discovery",
RFC 1191, November 1990.
[MTUDISC] ムガール人とJ.とS.デアリング、「経路MTU探索」、RFC1191、1990年11月。
[OPAQUE] Coltun, R., "The OSPF Opaque LSA Option",
RFC 2370, July 1998.
[不透明]のColtun、1998年7月のR.、「OSPFの不明瞭なLSAオプション」RFC2370。
[OSPFV3] Coltun, R., Ferguson, D., and J. Moy, "OSPF for
IPv6", RFC 2740, December 1999.
[OSPFV3] ColtunとR.とファーガソン、D.とJ.Moy、「IPv6"、RFC2740、1999年12月のためのOSPF。」
[OSPFV3-MIB] Joyal, D. and V. Manral, "Management Information
Base for OSPFv3", Work in Progress,
September 2007.
[OSPFV3-MIB] Joyal、D.、およびManralに対する「OSPFv3"のための管理情報ベース、処理中の作業、2007年9月。」
[SERV-CLASS] Babiarz, J., Chan, K., and F. Baker,
"Configuration Guidelines for DiffServ Service
Classes", RFC 4594, August 2006.
[SERV-クラス] 2006年8月のBabiarzとJ.とチェン、K.とF.ベイカー、「DiffServサービスのクラスのための構成ガイドライン」RFC4594。
Coltun, et al. Standards Track [Page 56] RFC 5340 OSPF for IPv6 July 2008
Coltun、他 IPv6 July 2008のための標準化過程[56ページ]RFC5340OSPF
Appendix A. OSPF Data Formats
付録A.OSPFデータ形式
This appendix describes the format of OSPF protocol packets and OSPF LSAs. The OSPF protocol runs directly over the IPv6 network layer. Before any data formats are described, the details of the OSPF encapsulation are explained.
この付録はOSPFプロトコルパケットとOSPF 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 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
A.1。 OSPFパケットのカプセル化
OSPF runs directly over the IPv6's network layer. OSPF packets are therefore encapsulated solely by IPv6 and local data-link headers.
OSPFは直接IPv6のネットワーク層をひきます。 したがって、OSPFパケットは唯一IPv6と地元のデータ・リンクヘッダーによってカプセルに入れられます。
OSPF does not define a way to fragment its protocol packets, and depends on IPv6 fragmentation when transmitting packets larger than the link MTU. If necessary, the length of OSPF packets can be up to 65,535 bytes. The OSPF packet types that are likely to be large (Database Description, Link State Request, Link State Update, and Link State Acknowledgment packets) can usually be split into multiple protocol packets without loss of functionality. This is recommended; IPv6 fragmentation should be avoided whenever possible. Using this reasoning, an attempt should be made to limit the size of OSPF packets sent over virtual links to 1280 bytes unless Path MTU Discovery is being performed [MTUDISC].
OSPFはプロトコルパケットを断片化する方法を定義しないで、リンクMTUより大きいパケットを伝えるとき、IPv6断片化によります。 必要なら、OSPFパケットの長さは最大6万5535バイトであるかもしれません。 通常、機能性の損失なしで大きい傾向があるOSPFパケットタイプ(データベース記述、Link州Request、Link州Update、およびLink州Acknowledgmentパケット)は複数のプロトコルパケットに分けることができます。 これはお勧めです。 可能であるときはいつも、IPv6断片化は避けられるべきです。 この推理を使用して、Path MTUディスカバリーが実行されていない場合1280バイトへの仮想のリンクの上に送られたOSPFパケット[MTUDISC]のサイズを制限するのを試みをするべきです。
The other important features of OSPF's IPv6 encapsulation are:
OSPFのIPv6カプセル化の他の重要な特徴は以下の通りです。
o Use of IPv6 multicast. Some OSPF messages are multicast when sent
over broadcast networks. Two distinct IP multicast addresses are
used. Packets sent to these multicast addresses should never be
forwarded; they are meant to travel a single hop only. As such,
the multicast addresses have been chosen with link-local scope and
packets sent to these addresses should have their IPv6 Hop Limit
set to 1. b
o IPv6マルチキャストの使用。 放送網の上に送ると、いくつかのOSPFメッセージがマルチキャストです。 2つの異なったIPマルチキャストアドレスが使用されています。 これらのマルチキャストアドレスに送られたパケットを決して進めるべきではありません。 彼らは単一のホップだけを旅行することになっています。 そういうものとして、マルチキャストアドレスはリンク地方の範囲で選ばれました、そして、これらのアドレスに送られたパケットで、1bにそれらのIPv6 Hop Limitを用意ができさせるはずです。
Coltun, et al. Standards Track [Page 57] RFC 5340 OSPF for IPv6 July 2008
Coltun、他 IPv6 July 2008のための標準化過程[57ページ]RFC5340OSPF
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分野であったならSHOULDに付番します。
o The OSPFv2 specification (Appendix A.1 in [OSPFV2]) indicates that
OSPF protocol packets are sent with IP precedence set to
Internetwork Control (B'110') [IPV4]. If routers in the OSPF
routing domain map their IPv6 Traffic Class octet to the
Differentiated Services Code Point (DSCP) as specified in
[DIFF-SERV], then OSPFv3 packets SHOULD be sent with their DSCP
set to CS6 (B'110000'), as specified in [SERV-CLASS]. In networks
supporting this mapping, OSPF packets will be given precedence
over IPv6 data traffic.
o OSPFv2仕様([OSPFV2]の付録A.1)は、OSPFプロトコルパケットがInternetwork Control(B'110')[IPV4]に設定されたIP先行と共に送られるのを示します。 ルータであるなら、[DIFF-SERV]、当時のOSPFv3パケットSHOULDで指定されて、経路ドメインがDifferentiated Services Code Point(DSCP)への彼らのIPv6 Traffic Class八重奏を写像するOSPFで、それらのDSCPセットでCS6(B'110000')に送ってください、[SERV-CLASS]で指定されるように。 このマッピングをサポートするネットワークで、IPv6データ通信量の上の優先権をOSPFパケットに与えるでしょう。
A.2. The Options Field
A.2。 オプション分野
The 24-bit OSPF Options field is present in OSPF Hello packets, Database Description packets, and certain LSAs (router-LSAs, network- LSAs, inter-area-router-LSAs, and link-LSAs). The Options field enables OSPF routers to support (or not support) optional capabilities, and to communicate their capability level to other OSPF routers. Through this mechanism, routers of differing capabilities can be mixed within an OSPF routing domain.
24ビットのOSPF 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; these are discovered through the sending and receiving of Database Description packets. Some option mismatches prevent routers from being included in one or more of the various routing calculations because of their reduced functionality; these mismatches are discovered by examining LSAs.
特定のオプションによって、ルータの間のオプションミスマッチはさまざまな振舞いを引き起こす場合があります。 いくつかのオプションミスマッチが、隣人関係が(例えば、以下のE-ビット)を形成するのを防ぎます。 これらのミスマッチはHelloパケットの送受信で発見されます。 いくつかのオプションミスマッチが水につかるのからの隣接番組の向こう側の特定のLSAタイプを防ぎます。 これらはDatabase記述パケットの送受信で発見されます。 いくつかのオプションミスマッチが、ルータがそれらの減少している機能性のために様々なルーティング計算の1つ以上に含まれているのを防ぎます。 これらのミスマッチは、LSAsを調べることによって、発見されます。
Coltun, et al. Standards Track [Page 58] RFC 5340 OSPF for IPv6 July 2008
Coltun、他 IPv6 July 2008のための標準化過程[58ページ]RFC5340OSPF
Seven bits of the OSPF Options field have been assigned. Each bit is described briefly below. Routers should reset (i.e., clear) unrecognized bits in the Options field when sending Hello packets or Database Description packets and when originating LSAs. Conversely, routers encountering unrecognized Options bits in received Hello packets, Database Description packets, or LSAs should ignore the unrecognized bits and process the packet or LSA normally.
OSPF Options分野の7ビットを割り当ててあります。 各ビットは簡潔に以下で説明されます。 HelloパケットかDatabase記述パケットといつにLSAsを溯源させるかとき、ルータはOptions分野に(すなわち、明確)の認識されていないビットをリセットするべきです。 逆に、Database記述の容認されたHelloパケット、パケット、またはLSAsで認識されていないOptionsビットに遭遇するルータは、認識されていないビットを無視して、通常、パケットかLSAを処理するはずです。
1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+--+--+
| | | | | | | | | | | | | | | | |*|*|DC|R|N|x| E|V6|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+--+--+
1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+--+--+ | | | | | | | | | | | | | | | | |*|*|DC|R|N|x| E|V6| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+--+--+
The Options field
Options分野
The Options field
Options分野
V6-bit
If this bit is clear, the router/link should be excluded from IPv6
routing calculations. See Section 4.8 for details.
これが噛み付いたV6-ビットIfが明確である、ルータ/リンクはIPv6ルーティング計算から除かれるべきです。 詳細に関してセクション4.8を見てください。
E-bit
This bit describes the way AS-external-LSAs are flooded, as
described in Sections 3.6, 9.5, 10.8, and 12.1.2 of [OSPFV2].
電子ビットThisビットはASの外部のLSAsが.2セクション3.6、9.5、10.8、および12.1[OSPFV2]で説明されるように水につかっている方法を述べます。
x-Bit
This bit was previously used by MOSPF (see [MOSPF]), which has
been deprecated for OSPFv3. The bit should be set to 0 and
ignored when received. It may be reassigned in the future.
x-ビットThisビットは以前に、MOSPF([MOSPF]を見る)によって使用されました。(OSPFv3に、MOSPFは推奨しないです)。 受け取ると、ビットを0に設定して、無視するべきです。 それは将来、再選任されるかもしれません。
N-bit
This bit indicates whether or not the router is attached to an
NSSA as specified in [NSSA].
N-ビットThisビットは、ルータが[NSSA]の指定されるとしてのNSSAに付けられているかどうかを示します。
R-bit
This bit (the `Router' bit) indicates whether the originator is an
active router. If the router bit is clear, then routes that
transit the advertising node cannot be computed. Clearing the
router bit would be appropriate for a multi-homed host that wants
to participate in routing, but does not want to forward non-
locally addressed packets.
R-ビットThisビット('ルータ'ビット)は、創始者がアクティブなルータであるかどうかを示します。 ルータビットが明確であり、次に、そのトランジットを発送するなら、広告ノードを計算できません。 aに、ルータビットをきれいにするのが適切であるだろう、マルチ、家へ帰り、ルーティングに参加したいのですが、非局所的に扱われたパケットを進めたがっていないホスト。
DC-bit
This bit describes the router's handling of demand circuits, as
specified in [DEMAND].
DC-ビットThisビットは[DEMAND]で指定されるように要求回路のルータの取り扱いについて説明します。
Coltun, et al. Standards Track [Page 59] RFC 5340 OSPF for IPv6 July 2008
Coltun、他 IPv6 July 2008のための標準化過程[59ページ]RFC5340OSPF
*-bit
These bits are reserved for migration of OSPFv2 protocol
extensions.
*-噛み付いているTheseビットはOSPFv2プロトコル拡張子の移行のために予約されます。
A.3. OSPF Packet Formats
A.3。 OSPFパケット・フォーマット
There are five distinct OSPF packet types. All OSPF packet types begin with a standard 16-byte header. This header is described first. Each packet type is then described in a succeeding section. In these sections, each packet's format is displayed and the packet's component fields are defined.
5つの異なったOSPFパケットタイプがあります。 すべてのOSPFパケットタイプが標準の16バイトのヘッダーと共に始まります。 このヘッダーは最初に、説明されます。 そして、それぞれのパケットタイプは続くセクションで説明されます。 これらのセクションで、各パケットの書式を表示します、そして、パケットのコンポーネント分野を定義します。
All OSPF packet types (other than the OSPF Hello packets) deal with lists of LSAs. For example, Link State Update packets implement the flooding of LSAs throughout the OSPF routing domain. The format of LSAs is described in Section A.4.
すべてのOSPFパケットタイプ(OSPF Helloパケットを除いた)がLSAsのリストに対処します。 例えば、Link州UpdateパケットはOSPF経路ドメイン中でLSAsの氾濫を実装します。 LSAsの形式はセクションA.4で説明されます。
The receive processing of OSPF packets is detailed in Section 4.2.2. The sending of OSPF packets is explained in Section 4.2.1.
セクション4.2で.2に詳述したOSPFパケットの処理を受けてください。 OSPFパケットの発信はセクション4.2.1で説明されます。
A.3.1. The OSPF Packet Header
A.3.1。 OSPFパケットのヘッダー
Every OSPF packet starts with a standard 16-byte header. Together with the encapsulating IPv6 headers, the OSPF header contains all the information necessary to determine whether the packet should be accepted for further processing. This determination is described in Section 4.2.2.
あらゆるOSPFパケットが標準の16バイトのヘッダーから始めます。 要約のIPv6ヘッダーと共に、OSPFヘッダーはパケットがさらなる処理のために受け入れられるべきであるかどうか決定するのに必要なすべての情報を含んでいます。 この決断はセクション4.2.2で説明されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version # | Type | Packet length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Instance ID | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The OSPF Packet Header
OSPFパケットのヘッダー
Version #
The OSPF version number. This specification documents version 3
of the OSPF protocol.
OSPFバージョンが付番するバージョン#。 この仕様はOSPFプロトコルのバージョン3を記録します。
Coltun, et al. Standards Track [Page 60] RFC 5340 OSPF for IPv6 July 2008
Coltun、他 IPv6 July 2008のための標準化過程[60ページ]RFC5340OSPF
Type
The OSPF packet types are as follows. See Appendix A.3.2 through
Appendix A.3.6 for details.
OSPFパケットがタイプするタイプは以下の通りです。 詳細のためにAppendix A.3.6でAppendix A.3.2を見てください。
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。
Area ID
A 32-bit number identifying the area to which this packet belongs.
All OSPF packets are associated with a single area. Most travel a
single hop only. Packets traversing a virtual link are labeled
with the backbone Area ID of 0.
このパケットが属する領域を特定する領域のIDの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 Section 8.1 of [IPV6]. The "Upper-Layer Packet
Length" in the pseudo-header is set to the value of the OSPF
packet header's length field. The Next Header value used in the
pseudo-header is 89. If the packet's length is not an integral
number of 16-bit words, the packet is padded with a byte of zero
before checksumming. Before computing the checksum, the checksum
field in the OSPF packet header is set to 0.
チェックサムOSPFはIPv6アプリケーションに標準のチェックサム計算を使用します: OSPFパケットのヘッダーと、[IPV6]のセクション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 link-local 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と等しくない容認されたパケットは捨てられます。
Coltun, et al. Standards Track [Page 61] RFC 5340 OSPF for IPv6 July 2008
Coltun、他 IPv6 July 2008のための標準化過程[61ページ]RFC5340OSPF
0
0
These fields are reserved. They SHOULD be set to 0 when sending
protocol packets and MUST be ignored when receiving protocol
packets.
これらの分野は予約されています。 それら、SHOULDはプロトコルパケットを送るとき、0に用意ができて、プロトコルパケットを受けるとき、無視しなければなりません。
A.3.2. The Hello Packet
A.3.2。 こんにちは、パケット
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パケットはマルチキャストを持っているそれらのリンクか放送能力(隣接しているルータの可能なダイナミックな発見)に関するマルチキャストです。
All routers connected to a common link must agree on certain parameters (HelloInterval and RouterDeadInterval). These parameters are included in Hello packets allowing differences to inhibit the forming of neighbor relationships. The Hello packet also contains fields used in Designated Router election (Designated Router ID and Backup Designated Router ID), and fields used to detect bidirectional communication (the Router IDs of all neighbors whose Hellos have been recently received).
普通リンクに接続されたすべてのルータが、あるパラメタ(HelloIntervalとRouterDeadInterval)に同意しなければなりません。 これらのパラメタは違いが隣人関係の形成を禁止できるHelloパケットに含まれています。 また、HelloパケットはDesignated Router選挙(Router IDとBackup Designated Router IDに指定される)に使用される分野、および双方向のコミュニケーションを検出するのに使用される分野(ハローズが最近受け取られたすべての隣人の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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | 1 | Packet Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Instance ID | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rtr Priority | Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HelloInterval | RouterDeadInterval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Designated Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Backup Designated Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
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優先権| オプション| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HelloInterval| RouterDeadInterval| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router IDに指定されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | バックアップに指定されたルータID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 隣人ID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... |
The OSPF Hello Packet
OSPF、こんにちは、パケット
Coltun, et al. Standards Track [Page 62] RFC 5340 OSPF for IPv6 July 2008
Coltun、他 IPv6 July 2008のための標準化過程[62ページ]RFC5340OSPF
Interface ID
32-bit number uniquely identifying this interface among the
collection of this router's interfaces. For example, in some
implementations it may be possible to use the MIB-II IfIndex
([INTFMIB]).
このルータのインタフェースの収集の中で唯一このインタフェースを特定するIDの32ビットの番号を連結してください。 例えば、いくつかの実装では、MIB-II IfIndex([INTFMIB])を使用するのは可能であるかもしれません。
Rtr Priority
This router's Router Priority. Used in (Backup) Designated Router
election. If set to 0, the router will be ineligible to become
(Backup) Designated Router.
Rtr Priority 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、静かなルータを宣言する前の秒数はダウンします。
Designated Router ID
The sending router's view of the identity of the Designated Router
for this network. The Designated Router is identified by its
Router ID. It is set to 0.0.0.0 if there is no Designated Router.
このネットワークのために送付ルータのDesignated Routerのアイデンティティの視点にRouter IDを指定しました。 Designated RouterはRouter IDによって特定されます。 それは設定されます。0.0 .0 .0 Designated Routerが全くなければ。
Backup Designated Router ID
The sending router's view of the identity of the Backup Designated
Router for this network. The Backup Designated Router is
identified by its IP Router ID. It is set to 0.0.0.0 if there is
no Backup Designated Router.
このネットワークのために送付ルータのものが見る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 on the network with neighbor state
1-Way or greater.
隣人状態が1方法か、より大きいネットワークのそれぞれのルータの隣人ID Router ID。
A.3.3. The Database Description Packet
A.3.3。 データベース記述パケット
Database Description packets are OSPF packet type 2. These packets are exchanged when an adjacency is being initialized. They describe the contents of the link-state database. Multiple packets may be used to describe the database. For this purpose, a poll-response procedure is used. One of the routers is designated to be the master and the other is the slave. The master sends Database Description packets (polls) that are acknowledged by Database Description packets sent by the slave (responses). The responses are linked to the polls via the packets' DD sequence numbers.
データベース記述パケットはOSPFパケットタイプ2です。 隣接番組を初期化しているとき、これらのパケットを交換します。 彼らはリンク州のデータベースのコンテンツについて説明します。 複数のパケットが、データベースについて説明するのに使用されるかもしれません。 このために、投票応答手順は使用されています。 ルータの1つはマスターになるように指定されます、そして、もう片方が奴隷です。 マスターは奴隷(応答)によって送られたDatabase記述パケットによって承認される記述パケット(投票)をDatabaseに送ります。 応答はパケットのDD一連番号で投票にリンクされます。
Coltun, et al. Standards Track [Page 63] RFC 5340 OSPF for IPv6 July 2008
Coltun、他 IPv6 July 2008のための標準化過程[63ページ]RFC5340OSPF
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 OSPF Database Description Packet
OSPFデータベース記述パケット
The format of the Database Description packet is very similar to both the Link State Request packet and the Link State Acknowledgment packet. The main part of all three is a list of items, each item describing a piece of the link-state database. The sending of Database Description packets is documented in Section 10.8 of [OSPFV2]. The reception of Database Description packets is documented in Section 10.6 of [OSPFV2].
Database記述パケットの形式はLink州RequestパケットとLink州Acknowledgmentパケットの両方と非常に同様です。 すべての3の主部は項目、リンク州のデータベースの1つの断片について説明する各個条のリストです。 Database記述パケットの発信は[OSPFV2]のセクション10.8に記録されます。 Database記述パケットのレセプションは[OSPFV2]のセクション10.6に記録されます。
Options
The optional capabilities supported by the router, as documented
in Section A.2.
任意の能力がセクションA.2に記録されるようにルータでサポートしたオプション。
Interface MTU
The size in bytes of the largest IPv6 datagram that can be sent
out the associated interface without fragmentation. The MTUs of
common Internet link types can be found in Table 7-1 of [MTUDISC].
MTUを連結してください。それが最も大きいIPv6データグラムであることができることのバイトで表現されるサイズは断片化なしで関連インタフェースを出しました。 [MTUDISC]のTable7-1で一般的なインターネットリンク型のMTUsを見つけることができます。
Coltun, et al. Standards Track [Page 64] RFC 5340 OSPF for IPv6 July 2008
Coltun、他 IPv6 July 2008のための標準化過程[64ページ]RFC5340OSPF
Interface MTU should be set to 0 in Database Description packets
sent over virtual links.
インタフェースMTUはパケットが仮想のリンクの上に送ったDatabase記述で0に用意ができるべきです。
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記述パケットの系列で1番目です。
M-bit
The More bit. When set to 1, it indicates that more Database
Description packets are to follow.
Moreが噛み付いたM-ビット。 1に設定されると、それは、より多くのDatabase記述パケットが続くことになっているのを示します。
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 for both the master and slave routers have been
exchanged.
Database記述パケットの収集を配列する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 Appendix A.4.2. It contains all the information required to uniquely identify both the LSA and the LSA's current instance.
パケットの残りはリンク州のデータベースの片の(ことによると部分的)のリストから成ります。 データベースの各LSAはLSAヘッダーによって説明されます。 LSAヘッダーはAppendix A.4.2に記録されます。 それは唯一LSAとLSAの現在のインスタンスの両方を特定するのに必要であるすべての情報を含んでいます。
A.3.4. The Link State Request Packet
A.3.4。 リンク州のリクエスト・パケット
Link State Request packets are OSPF packet type 3. After exchanging Database Description packets with a neighboring router, a router may find that parts of its link-state database are out-of-date. The Link State Request packet is used to request the pieces of the neighbor's database that are more up-to-date. Multiple Link State Request packets may need to be used.
リンク州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 LSA instances in response.
Link州Requestパケットを送るルータはそれが要求しているデータベース片の正確なインスタンスを考えています。 各インスタンスはLS一連番号、LSチェックサム、およびLS時代までに定義されます、これらの分野はLink州Requestパケット自体で指定されませんが。 ルータは応答におけるさらに最近のLSAインスタンスを受けるかもしれません。
The sending of Link State Request packets is documented in Section 10.9 of [OSPFV2]. The reception of Link State Request packets is documented in Section 10.7 of [OSPFV2].
Link州Requestパケットの発信は[OSPFV2]のセクション10.9に記録されます。 Link州Requestパケットのレセプションは[OSPFV2]のセクション10.7に記録されます。
Coltun, et al. Standards Track [Page 65] RFC 5340 OSPF for IPv6 July 2008
Coltun、他 IPv6 July 2008のための標準化過程[65ページ]RFC5340OSPF
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をリンクしてください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 広告ルータ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... |
The OSPF Link State Request Packet
OSPFリンク州のリクエスト・パケット
Each LSA requested is specified by its LS type, Link State ID, and Advertising Router. This uniquely identifies the LSA without specifying its instance. Link State Request packets are understood to be requests for the most recent instance of the specified LSAs.
LSAが要求したそれぞれがLink州のLSタイプ、ID、およびAdvertising Routerによって指定されます。 インスタンスを指定しないで、これは唯一LSAを特定します。 リンク州Requestパケットは指定されたLSAsの最新のインスタンスを求める要求であることが理解されています。
A.3.5. The Link State Update Packet
A.3.5。 リンク州のアップデートパケット
Link State Update packets are OSPF packet type 4. These packets implement the flooding of LSAs. Each Link State Update packet carries a collection of LSAs one hop further from their origin. Several LSAs may be included in a single packet.
リンク州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 4.5.
リンク州Updateパケットはマルチキャスト/放送をサポートするそれらの物理ネットワークのマルチキャストです。 氾濫手順を信頼できるようにするように、水につかっているLSAsはLink州Acknowledgmentパケットで承認されます。 あるLSAsの「再-トランスミッション」が必要であるなら、再送されたLSAsはいつもユニキャストLink州Updateパケットによって運ばれます。 LSAsの信頼できる氾濫の詳しい情報に関しては、セクション4.5に相談してください。
Coltun, et al. Standards Track [Page 66] RFC 5340 OSPF for IPv6 July 2008
Coltun、他 IPv6 July 2008のための標準化過程[66ページ]RFC5340OSPF
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| +- +-+ | ... |
The OSPF Link State Update Packet
OSPFリンク州のアップデートパケット
# 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 Appendix A.4.2. Detailed formats of the different types of LSAs are described Appendix A.4.
Link州UpdateパケットのボディーはLSAsのリストから成ります。 各LSAはAppendix A.4.2で説明された一般的な20バイトのヘッダーと共に始まります。 LSAsの異なったタイプの詳細な形式は説明されたAppendix A.4です。
A.3.6. The Link State Acknowledgment Packet
A.3.6。 リンク州の確認応答パケット
Link State Acknowledgment packets are OSPF packet type 5. To make the flooding of LSAs reliable, flooded LSAs are explicitly or implicitly acknowledged. Explicit acknowledgment is accomplished through the sending and receiving of Link State Acknowledgment packets. The sending of Link State Acknowledgment packets is documented in Section 13.5 of [OSPFV2]. The reception of Link State Acknowledgment packets is documented in Section 13.7 of [OSPFV2].
リンク州AcknowledgmentパケットはOSPFパケットタイプ5です。 LSAsの氾濫を信頼できるようにするように、水につかっているLSAsは明らかかそれとなく承認されます。 明白な承認はLink州Acknowledgmentパケットの送受信で実行されます。 Link州Acknowledgmentパケットの発信は[OSPFV2]のセクション13.5に記録されます。 Link州Acknowledgmentパケットのレセプションは[OSPFV2]のセクション13.7に記録されます。
Multiple LSAs MAY be acknowledged in a single Link State Acknowledgment packet. Depending on the state of the sending interface and the sender of the corresponding Link State Update packet, a Link State Acknowledgment packet is sent to the multicast address AllSPFRouters, the multicast address AllDRouters, or to a neighbor's unicast address (see Section 13.5 of [OSPFV2] for details).
複数のLSAsが単一のLink州Acknowledgmentパケットで承認されるかもしれません。 対応するLink州Updateパケットの送付インタフェースと送付者の状態によって、マルチキャストアドレスAllSPFRouters、マルチキャストアドレスAllDRouters、または、隣人のユニキャストアドレスにLink州Acknowledgmentパケットを送ります(詳細に関して[OSPFV2]のセクション13.5を見てください)。
Coltun, et al. Standards Track [Page 67] RFC 5340 OSPF for IPv6 July 2008
Coltun、他 IPv6 July 2008のための標準化過程[67ページ]RFC5340OSPF
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ヘッダーのリストです。
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ヘッダー-+| | +- -+ | | +- -+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... |
The OSPF Link State Acknowledgment Packet
OSPFリンク州の確認応答パケット
Each acknowledged LSA is described by its LSA header. The LSA header is documented in Appendix A.4.2. It contains all the information required to uniquely identify both the LSA and the LSA's current instance.
それぞれの承認されたLSAはLSAヘッダーによって説明されます。 LSAヘッダーはAppendix A.4.2に記録されます。 それは唯一LSAとLSAの現在のインスタンスの両方を特定するのに必要であるすべての情報を含んでいます。
A.4. LSA Formats
A.4。 LSA形式
This document defines eight distinct types of LSAs. Each LSA begins with a standard 20-byte LSA header. This header is explained in Appendix A.4.2. Succeeding sections describe each LSA type individually.
このドキュメントはLSAsの8つの異なったタイプを定義します。 各LSAは標準の20バイトのLSAヘッダーと共に始まります。 このヘッダーはAppendix A.4.2で説明されます。 続くセクションは個別にそれぞれのLSAタイプについて説明します。
Each LSA describes a piece of the OSPF routing domain. Every router originates a router-LSA. A network-LSA is advertised for each link by its Designated Router. A router's link-local addresses are advertised to its neighbors in link-LSAs. IPv6 prefixes are advertised in intra-area-prefix-LSAs, inter-area-prefix-LSAs, AS- external-LSAs, and NSSA-LSAs. Location of specific routers can be advertised across area boundaries in inter-area-router-LSAs. All LSAs are then flooded throughout the OSPF routing domain. The
各LSAはOSPF経路ドメインの1つの断片について説明します。 あらゆるルータがルータ-LSAを溯源します。 ネットワーク-LSAはDesignated Routerによって各リンクに広告を出されます。 リンク-LSAsの隣人にルータのリンクローカルのアドレスの広告を出します。 イントラ領域がLSAsを前に置いていて、相互領域がLSAsを前に置いているAS外部のLSAs、およびNSSA-LSAsにIPv6接頭語の広告を出します。 中にエリアの境界の向こう側に特定のルータの位置の広告を出すことができる、相互領域ルータLSAs すべてのLSAsがその時、OSPF経路ドメイン中で水につかっています。 The
Coltun, et al. Standards Track [Page 68] RFC 5340 OSPF for IPv6 July 2008
Coltun、他 IPv6 July 2008のための標準化過程[68ページ]RFC5340OSPF
flooding algorithm is reliable, ensuring that all routers common to a flooding scope have the same collection of LSAs associated with that flooding scope. (See Section 4.5 for more information concerning the flooding algorithm.) This collection of LSAs is called the link- state database.
氾濫アルゴリズムは信頼できます、氾濫範囲に共通のすべてのルータにはその氾濫範囲に関連しているLSAsの同じ収集があるのを確実にして。 (詳しい情報に関して氾濫アルゴリズムに関してセクション4.5を見てください。) LSAsのこの収集はリンク州のデータベースと呼ばれます。
From the link-state database, each router constructs a shortest-path tree with itself as root. This yields a routing table (see Section 11 of [OSPFV2]). For details on the routing table build process, see Section 4.8.
リンク州のデータベースから、各ルータは根としてそれ自体で最短パス木を組み立てます。 これは経路指定テーブルをもたらします([OSPFV2]のセクション11を見てください)。 経路指定テーブルの詳細に関しては、プロセスを建ててください、そして、セクション4.8を見てください。
A.4.1. IPv6 Prefix Representation
A.4.1。 IPv6接頭語表現
IPv6 addresses are bit strings of length 128. IPv6 routing protocols, and OSPF for IPv6 in particular, advertise IPv6 address prefixes. IPv6 address prefixes are bit strings whose length ranges between 0 and 128 bits (inclusive).
IPv6アドレスは長さ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 Appendix A.4.1.1). Address Prefix is an encoding of the prefix itself as an even multiple of 32-bit words, padding with zero bits as necessary. This encoding consumes ((PrefixLength + 31) / 32) 32-bit words.
OSPFの中では、IPv6アドレス接頭語は3つの分野の組み合わせでいつも表されます: PrefixLength、PrefixOptions、およびアドレス接頭語。 PrefixLengthは接頭語のビットの長さです。 PrefixOptionsは接頭語に関連している様々な能力について説明する8ビットの分野(Appendix A.4.1.1を見る)です。 アドレス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 Appendix A.4.5, Appendix A.4.7, Appendix A.4.8, Appendix A.4.9, and Appendix A.4.10.
Appendix A.4.5、Appendix A.4.7、Appendix A.4.8、Appendix A.4.9、およびAppendix A.4.10で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. For example, they can indicate that prefixes are to be ignored in some cases or are to be marked as not readvertisable in others.
能力の8ビットの分野と共に各接頭語の広告を出します。 これらは様々なルーティング計算に入力されるように役立ちます。 例えば、彼らは、接頭語がいくつかの場合、無視されるか、またはどんな「再-広告を出-可能」としても他のものでマークされないことであることを示すことができます。
0 1 2 3 4 5 6 7
+--+--+--+--+--+-+--+--+
| | | |DN| P|x|LA|NU|
+--+--+--+--+--+-+--+--+
0 1 2 3 4 5 6 7 +--+--+--+--+--+-+--+--+ | | | |DN| P|x|LA|ν| +--+--+--+--+--+-+--+--+
The PrefixOptions Field
PrefixOptions分野
Coltun, et al. Standards Track [Page 69] RFC 5340 OSPF for IPv6 July 2008
Coltun、他 IPv6 July 2008のための標準化過程[69ページ]RFC5340OSPF
NU-bit
The "no unicast" capability bit. If set, the prefix should be
excluded from IPv6 unicast calculations. If not set, it should be
included.
「ユニキャストがありません」能力ビットにNU噛み付きました。 設定されるなら、接頭語はIPv6ユニキャスト計算から除かれるべきです。 設定されないなら、それは含まれるべきです。
LA-bit
The "local address" capability bit. If set, the prefix is
actually an IPv6 interface address of the Advertising Router.
Advertisement of local interface addresses is described in
Section 4.4.3.9. An implementation MAY also set the LA-bit for
prefixes advertised with a host PrefixLength (128).
LA-ビット「ローカルアドレス」能力ビット。 設定されるなら、接頭語は実際にAdvertising RouterのIPv6インターフェース・アドレスです。 局所界面アドレスの広告はセクション4.4.3で.9に説明されます。 また、実装はホストPrefixLength(128)と共に広告に掲載された接頭語にLA-ビットを設定するかもしれません。
x-bit
This bit was previously defined as a "multicast" capability bit.
However, the use was never adequately specified and has been
deprecated for OSPFv3. The bit should be set to 0 and ignored
when received. It may be reassigned in the future.
x-ビットThisビットは以前に、「マルチキャスト」能力ビットと定義されました。 しかしながら、使用は、適切に決して指定されないで、OSPFv3に、推奨しないです。 受け取ると、ビットを0に設定して、無視するべきです。 それは将来、再選任されるかもしれません。
P-bit
The "propagate" bit. Set on NSSA area prefixes that should be
readvertised by the translating NSSA area border [NSSA].
噛み付かれた「伝播してください」にPで噛み付きました。 翻訳しているNSSA領域の境界[NSSA]で「再-広告を出」すべきであるNSSA領域接頭語にセットしてください。
DN-bit
This bit controls an inter-area-prefix-LSAs or AS-external-LSAs
re-advertisement in a VPN environment as specified in [DN-BIT].
相互領域はLSAsを前に置きます。DN-ビットThisがコントロールに噛み付いた、または、[DN-BIT]の指定されるとしてのVPN環境におけるAS外部のLSAs再広告。
A.4.2. The LSA Header
A.4.2。 LSAヘッダー
All LSAs begin with a common 20-byte header. This header contains enough information to uniquely identify the LSA (LS type, Link State ID, and Advertising Router). Multiple instances of the LSA may exist in the routing domain at the same time. It is then necessary to determine which instance is more recent. This is accomplished by examining the LS age, LS sequence number, and LS checksum fields that are also contained in the LSA header.
すべてのLSAsが一般的な20バイトのヘッダーと共に始まります。 このヘッダーは唯一、LSA(Link州のLSタイプ、ID、およびAdvertising Router)を特定できるくらいの情報を含んでいます。 LSAの複数のインスタンスが同時に、経路ドメインに存在するかもしれません。 どちらのインスタンスが、より最近であるかを決定するのがその時、必要です。 これは、また、LSAヘッダーに含まれているLS時代、LS一連番号、およびLSチェックサム分野を調べることによって、達成されます。
Coltun, et al. Standards Track [Page 70] RFC 5340 OSPF for IPv6 July 2008
Coltun、他 IPv6 July 2008のための標準化過程[70ページ]RFC5340OSPF
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チェックサム| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The LSA Header
LSAヘッダー
LS Age
The time in seconds since the LSA was originated.
LS AgeはLSA以来の秒の時に溯源されました。
LS Type
The LS type field indicates the function performed by the LSA.
The high-order three bits of LS type encode generic properties of
the LSA, while the remainder (called LSA function code) indicate
the LSA's specific functionality. See Appendix A.4.2.1 for a
detailed description of LS type.
タイプがさばくLS Type LSは、機能がLSAで働いたのを示します。 LSの高位3ビットはLSAのエンコードジェネリックの特性をタイプします、残り(LSA機能コードと呼ばれる)はLSAの特定の機能性を示しますが。 LSの詳述のためのAppendix A.4.2.1がタイプするのを見てください。
Link State ID
The originating router's identifier for the LSA. The combination
of the Link State ID, LS type, and Advertising Router uniquely
identify the LSA in the link-state database.
州IDをリンクしてください。LSAのための起因するルータの識別子。 Link州IDの組み合わせであり、LSはタイプします、そして、Advertising Routerはリンク州のデータベースで唯一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
Successive instances of an LSA are given successive LS sequence
numbers. The sequence number can be used to detect old or
duplicate LSA instances. See Section 12.1.6 in [OSPFV2] for more
details.
LSAのLS一連番号Successiveインスタンスに連続したLS一連番号を与えます。 古いか写しLSAインスタンスを検出するのに一連番号を使用できます。 [OSPFV2]でその他の詳細に関してセクション12.1.6を見てください。
LS checksum
The Fletcher checksum of the complete contents of the LSA,
including the LSA header but excluding the LS age field. See
Section 12.1.7 in [OSPFV2] for more details.
LSAにもかかわらず、LSAヘッダーを含んでいますが、LS時代を除く完全なコンテンツのフレッチャーチェックサムがさばくLSチェックサム。 [OSPFV2]でその他の詳細に関してセクション12.1.7を見てください。
Coltun, et al. Standards Track [Page 71] RFC 5340 OSPF for IPv6 July 2008
Coltun、他 IPv6 July 2008のための標準化過程[71ページ]RFC5340OSPF
length
The length in bytes of the LSA. This includes the 20-byte LSA
header.
長さ、LSAのバイトで表現される長さ。 これは20バイトのLSAヘッダーを含んでいます。
A.4.2.1. LSA Type
A.4.2.1。 LSAはタイプします。
The LS type field indicates the function performed by the LSA. The high-order three bits of LS type encode generic properties of the LSA, while the remainder (called LSA function code) indicate the LSA's specific functionality. The format of the LS type is as follows:
LSタイプ分野は、機能がLSAで働いたのを示します。 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機能コード| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
LSA Type
LSAはタイプします。
The U-bit indicates how the LSA should be handled by a router that does not recognize the LSA's function code. Its values are:
U-ビットはLSAがLSAの機能コードを認識しないルータによってどう扱われるべきであるかを示します。 値は以下の通りです。
U-bit LSA Handling
-------------------------------------------------------------
0 Treat the LSA as if it had link-local flooding scope
1 Store and flood the LSA as if the type is understood
U-ビットLSA取り扱い------------------------------------------------------------- 0は、まるでリンク地方の氾濫範囲1ストアを持っているかのようにLSAを扱って、まるでタイプが理解されているかのようにLSAをあふれさせます。
U-Bit
U-ビット
The S1 and S2 bits indicate the flooding scope of the LSA. The values are:
S1とS2ビットはLSAの氾濫範囲を示します。 値は以下の通りです。
S2 S1 Flooding Scope
-------------------------------------------------------------
0 0 Link-Local Scoping - Flooded only on originating link
0 1 Area Scoping - Flooded only in originating area
1 0 AS Scoping - Flooded throughout AS
1 1 Reserved
S2 S1氾濫範囲------------------------------------------------------------- 0 0のリンク地方のScoping--単に起因するときにあふれて、0 1Area Scoping--単に領域を溯源する際に1 0AS Scoping--AS1 1Reserved中で浸水するのがあふれさせるのをリンクしてください。
Flooding Scope
氾濫範囲
The LSA function codes are defined as follows. The origination and processing of these LSA function codes are defined elsewhere in this document, except for the NSSA-LSA (see [NSSA]) and 0x2006, which was previously used by MOSPF (see [MOSPF]). MOSPF has been deprecated for OSPFv3. As shown below, each LSA function b code also implies a specific setting for the U, S1, and S2 bits.
LSA機能コードは以下の通り定義されます。 これらのLSA機能コードの創作と処理はほかの場所で本書では定義されます、NSSA-LSA([NSSA]を見る)と0×2006を除いて([MOSPF]を見てください)。(0×2006は以前に、MOSPFによって使用されました)。 OSPFv3に、MOSPFは推奨しないです。 また、以下に示すように、それぞれのLSA機能bコードは特定の設定をU、S1、およびS2ビット含意します。
Coltun, et al. Standards Track [Page 72] RFC 5340 OSPF for IPv6 July 2008
Coltun、他 IPv6 July 2008のための標準化過程[72ページ]RFC5340OSPF
LSA Function Code LS Type Description
----------------------------------------------------
1 0x2001 Router-LSA
2 0x2002 Network-LSA
3 0x2003 Inter-Area-Prefix-LSA
4 0x2004 Inter-Area-Router-LSA
5 0x4005 AS-External-LSA
6 0x2006 Deprecated (may be reassigned)
7 0x2007 NSSA-LSA
8 0x0008 Link-LSA
9 0x2009 Intra-Area-Prefix-LSA
LSA機能コードLS型記述---------------------------------------------------- 1 0×2001ルータ-LSA2 0×2002Network-LSA3 0×2003Inter領域接頭語LSA4 0×2004Inter領域ルータLSA5 0×4005ASの外部のLSA6 0×2006Deprecated(再選任されるかもしれない)7 0×2007NSSA-LSA8 0×0008Link-LSA9 0×2009Intra領域接頭語LSA
LSA Function Code
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 4.4.3.2. Router-LSAs are only flooded throughout a single area.
ルータ-LSAsには、0×2001と等しいLSタイプがあります。 領域の各ルータは1ルータ-LSAsを溯源します。 ルータによって溯源されたルータ-LSAsの完全なコレクションはルータのインタフェースの状態と費用についてその領域に説明します。 ルータ-LSAsの構造に関する詳細に関しては、.2にセクション4.4.3を見てください。 ルータ-LSAsはただ一つの領域中で水につかっているだけです。
Coltun, et al. Standards Track [Page 73] RFC 5340 OSPF for IPv6 July 2008
Coltun、他 IPv6 July 2008のための標準化過程[73ページ]RFC5340OSPF
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Age |0|0|1| 1 |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Sequence Number |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Checksum | Length |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |Nt|x|V|E|B| Options |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | 0 | Metric |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor Interface ID |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor Router ID |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | 0 | Metric |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor Interface ID |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor Router ID |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
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 |Nt|x|V|E|B| オプション| +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 0 | メートル法| +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | インタフェースID| +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 隣人インタフェースID| +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 隣人Router ID| +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 0 | メートル法| +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | インタフェースID| +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 隣人インタフェースID| +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 隣人Router ID| +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... |
Router-LSA Format
ルータ-LSA形式
A single router may originate one or more router-LSAs, distinguished by their Link State IDs (which are chosen arbitrarily by the originating router). The Options field and V, E, and B bits should be the same in all router-LSAs from a single originator. However, in the case of a mismatch, the values in the LSA with the lowest Link State ID take precedence. When more than one router-LSA is received from a single router, the links are processed as if concatenated into a single LSA.
ただ一つのルータは彼らのLink州ID(起因するルータによって任意に選ばれている)によって区別された1ルータ-LSAsを溯源するかもしれません。 Options分野とV、E、およびBビットはすべてのルータ-LSAsで独身の創始者から同じであるべきです。 しかしながら、ミスマッチの場合では、最も低いLink州IDがあるLSAの値は優先します。 ただ一つのルータから1ルータ-LSAを受け取るとき、まるで独身のLSAに連結されるかのようにリンクを処理します。
Coltun, et al. Standards Track [Page 74] RFC 5340 OSPF for IPv6 July 2008
Coltun、他 IPv6 July 2008のための標準化過程[74ページ]RFC5340OSPF
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、ルータはトランジット領域として説明された領域を持っている1個以上の完全に隣接している仮想のリンクの終点(仮想のリンク終点にはVがある)です。
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 x
This bit was previously used by MOSPF (see [MOSPF]) and has been
deprecated for OSPFv3. The bit should be set to 0 and ignored
when received. It may be reassigned in the future.
Thisが噛み付いたビットxは、以前に、MOSPF([MOSPF]を見る)によって使用されて、OSPFv3に、推奨しないです。 受け取ると、ビットを0に設定して、無視するべきです。 それは将来、再選任されるかもしれません。
Bit Nt
When set, the router is an NSSA border router that is
unconditionally translating NSSA-LSAs into AS-external-LSAs (Nt
stands for NSSA translation). Note that such routers have their
NSSATranslatorRole area configuration parameter set to Always.
(See [NSSA].)
Nt Whenが設定するビット、ルータは無条件にASの外部のLSAsにNSSA-LSAsを翻訳しているNSSA境界ルータ(NtはNSSA翻訳を表す)です。 そのようなルータでそれらのNSSATranslatorRole領域設定パラメータをAlwaysに設定することに注意してください。 ([NSSA]を見てください。)
Options
The optional capabilities supported by the router, as documented
in Appendix A.2.
任意の能力がAppendix 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への二地点間接続
Router Link Types
ルータリンク型
Coltun, et al. Standards Track [Page 75] RFC 5340 OSPF for IPv6 July 2008
Coltun、他 IPv6 July 2008のための標準化過程[75ページ]RFC5340OSPF
Metric
The cost of using this router interface for outbound traffic.
メートル法、アウトバウンドトラフィックにこのルータインタフェースを使用する費用。
Interface ID
The Interface ID assigned to the interface being described. See
Section 4.1.2 and Appendix C.3.
Interface IDが説明されるインタフェースに割り当てたIDを連結してください。 セクション4.1.2と付録C.3を見てください。
Neighbor Interface ID
The Interface ID the neighbor router has associated with the link,
as advertised in the neighbor's Hello packets. For transit (type
2) links, the link's Designated Router is the neighbor described.
For other link types, the sole adjacent neighbor is described.
隣人ルータが隣人のHelloパケットの広告に掲載されているようにリンクに関連づけた隣人Interface ID Interface ID。 トランジット(2をタイプする)リンクに関しては、リンクのDesignated Routerは説明された隣接物です。 他のリンク型にとって、唯一の隣接している隣人は説明されます。
Neighbor Router ID
The Router ID the of the neighbor router. For transit (type 2)
links, the link's Designated Router is the neighbor described.
For other link types, the sole adjacent neighbor is described.
隣人Router ID Router ID、隣人ルータについて。 トランジット(2をタイプする)リンクに関しては、リンクのDesignated Routerは説明された隣接物です。 他のリンク型にとって、唯一の隣接している隣人は説明されます。
For transit (Type 2) links, the combination of Neighbor Interface ID and Neighbor Router ID allows the network-LSA for the attached link to be found in the link-state database.
トランジット(2をタイプする)リンクに関しては、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 that includes two or more adjacent routers. The network-LSA is originated by the link's Designated Router. The LSA describes all routers attached to the link including the Designated Router itself. The LSA's Link State ID field is set to the Interface ID that the Designated Router has been advertising in Hello packets on the link.
ネットワーク-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 4.4.3.3.
ネットワークから付属すべてのルータまでの距離はゼロです。 これはMetric分野がネットワーク-LSAで指定される必要はない理由です。 ネットワーク-LSAsの構造に関する詳細に関しては、.3にセクション4.4.3を見てください。
Coltun, et al. Standards Track [Page 76] RFC 5340 OSPF for IPv6 July 2008
Coltun、他 IPv6 July 2008のための標準化過程[76ページ]RFC5340OSPF
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 | オプション| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 付属ルータ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... |
Network-LSA Format
ネットワーク-LSA形式
Attached Router
The Router IDs of each of the routers attached to the link.
Actually, only those routers that are fully adjacent to the
Designated Router are listed. The Designated Router includes
itself in this list. The number of routers included can be
deduced from the LSA header's length field.
それぞれのルータの付属Router Router IDはリンクに付きました。 それは完全にそうです。実際にそれらのルータだけ、記載されたDesignated Routerに隣接して。 Designated Routerはこのリストにそれ自体を含んでいます。 LSAヘッダーの長さの分野からルータを含む数を推論できます。
A.4.5. Inter-Area-Prefix-LSAs
A.4.5。 相互領域接頭語LSAs
Inter-area-prefix-LSAs have LS type equal to 0x2003. These LSAs are the IPv6 equivalent of OSPF for IPv4's type 3 summary-LSAs (see Section 12.4.3 of [OSPFV2]). Originated by area border routers, they describe routes to IPv6 address prefixes that belong to other areas. A separate inter-area-prefix-LSA is originated for each IPv6 address prefix. For details concerning the construction of inter-area- prefix-LSAs, see Section 4.4.3.4.
相互領域はLSAsを前に置きます。LSタイプを0×2003と等しくしてください。 これらのLSAsはIPv4のタイプ3概要-LSAsのためのOSPFのIPv6同等物(.3セクション12.4[OSPFV2]を見る)です。 境界ルータによって溯源されて、それらは他の領域に属すIPv6アドレス接頭語にルートを説明します。 相互領域がLSAを前に置いた状態で、Aは分離します。それぞれのIPv6アドレス接頭語のために、溯源されます。 相互領域接頭語-LSAsの構造に関する詳細に関しては、.4にセクション4.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.
スタッブ領域へ、相互領域はLSAsを前に置きます。また、(領域)デフォルトルートを説明するのを使用できます。 デフォルト概要ルートは完全な外部経路をあふれさせることの代わりにスタッブ領域で使用されます。 デフォルト概要ルートを説明するとき、相互領域がLSAのものを前に置いているPrefixLengthは0に用意ができています。
Coltun, et al. Standards Track [Page 77] RFC 5340 OSPF for IPv6 July 2008
Coltun、他 IPv6 July 2008のための標準化過程[77ページ]RFC5340OSPF
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | アドレス接頭語| | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Inter-Area-Prefix-LSA Format
相互領域接頭語LSA形式
Metric
The cost of this route. Expressed in the same units as the
interface costs in router-LSAs. When the inter-area-prefix-LSA is
describing a route to a range of addresses (see Appendix C.2), the
cost is set to the maximum cost to any reachable component of the
address range.
メートル法、このルートの費用。 インタフェースコストと同じユニットでは、ルータ-LSAsで言い表されます。 相互領域がLSAを前に置くのがさまざまなアドレスにルートを説明しているとき(Appendix C.2を見てください)、費用はアドレスの範囲のどんな届いているコンポーネントへの最大の費用にも設定されます。
PrefixLength, PrefixOptions, and Address Prefix
Representation of the IPv6 address prefix, as described in
Appendix A.4.1.
IPv6のPrefixLength、PrefixOptions、およびAddress Prefix RepresentationはAppendix A.4.1で説明されるように接頭語を扱います。
A.4.6. Inter-Area-Router-LSAs
A.4.6。 相互領域ルータLSAs
Inter-area-router-LSAs have LS type equal to 0x2004. These LSAs are the IPv6 equivalent of OSPF for IPv4's type 4 summary-LSAs (see Section 12.4.3 of [OSPFV2]). Originated by area border routers, they describe routes to AS boundary routers in other areas. To see why it is necessary to advertise the location of each ASBR, consult Section 16.4 in [OSPFV2]. Each LSA describes a route to a single router. For details concerning the construction of inter-area-router-LSAs, see Section 4.4.3.5.
相互領域ルータLSAs、0×2004と等しいLSタイプがあってください。 これらのLSAsはIPv4のタイプ4概要-LSAsのためのOSPFのIPv6同等物(.3セクション12.4[OSPFV2]を見る)です。 境界ルータによって溯源されて、それらは他の領域のAS境界ルータにルートを説明します。 それぞれのASBRの位置の広告を出すのがなぜ必要であるかを確認するには、[OSPFV2]でセクション16.4に相談してください。 各LSAはただ一つのルータにルートを説明します。 工事に関する詳細である、相互領域ルータLSAs、.5にセクション4.4.3を見てください。
Coltun, et al. Standards Track [Page 78] RFC 5340 OSPF for IPv6 July 2008
Coltun、他 IPv6 July 2008のための標準化過程[78ページ]RFC5340OSPF
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| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Inter-Area-Router-LSA Format
相互領域ルータLSA形式
Options
The optional capabilities supported by the router, as documented
in Appendix A.2.
任意の能力がAppendix A.2に記録されるようにルータでサポートしたオプション。
Metric
The cost of this route. Expressed in the same units as the
interface costs in router-LSAs.
メートル法、このルートの費用。 インタフェースコストと同じユニットでは、ルータ-LSAsで言い表されます。
Destination Router ID
The Router ID of the router being described by the LSA.
LSAによって説明されるルータの目的地Router ID Router ID。
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 4.4.3.6.
ASの外部のLSAsには、0×4005と等しいLSタイプがあります。 これらのLSAsはAS境界ルータによって溯源されて、ASへの外部の目的地について説明します。 各LSAはただ一つのIPv6アドレス接頭語にルートを説明します。 ASの外部のLSAsの構造に関する詳細に関しては、.6にセクション4.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に用意ができています。
Coltun, et al. Standards Track [Page 79] RFC 5340 OSPF for IPv6 July 2008
Coltun、他 IPv6 July 2008のための標準化過程[79ページ]RFC5340OSPF
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(任意の)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AS-external-LSA Format
外部のLSA、形式
bit E
The type of external metric. If bit E is set, the metric
specified is a Type 2 external metric. This means the metric is
considered larger than any intra-AS path. If bit E is zero, the
specified metric is a Type 1 external metric. This means that it
is expressed in the same units as other LSAs (i.e., the same units
as the interface costs in router-LSAs).
外部のタイプのEに噛み付いて、メートル法にしました。 ビットEが設定されるなら、指定されたメートル法はa Type2外部メートル法です。 これは、メートル法がどんなイントラ-AS経路よりも大きいと考えられることを意味します。 噛み付かれるならEがゼロである、メートル法で指定されて、Type1外部はメートル法ですか? これは、それが他のLSAs(すなわち、ルータ-LSAsのインタフェースコストと同じユニット)と同じユニットで言い表されることを意味します。
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に含まれています。
Coltun, et al. Standards Track [Page 80] RFC 5340 OSPF for IPv6 July 2008
Coltun、他 IPv6 July 2008のための標準化過程[80ページ]RFC5340OSPF
Metric
The cost of this route. Interpretation depends on the external
type indication (bit E above).
メートル法、このルートの費用。 解釈は外部のタイプ指示(上のEに噛み付く)によります。
PrefixLength, PrefixOptions, and Address Prefix
Representation of the IPv6 address prefix, as described in
Appendix A.4.1.
IPv6のPrefixLength、PrefixOptions、およびAddress Prefix RepresentationはAppendix 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 Type IfはこのLSAに関連させていることになっています(以下のReferenced Link州IDを見てください)非ゼロ、このLSとLSAが、タイプする。
Forwarding address
A fully qualified IPv6 address (128 bits). Included in the LSA if
and only if bit F has been set. If included, data traffic for the
advertised destination will be forwarded to this address. It MUST
NOT be set to the IPv6 Unspecified Address (0:0:0:0:0:0:0:0) or an
IPv6 Link-Local Address (Prefix FE80/10). While OSPFv3 routes are
normally installed with link-local addresses, an OSPFv3
implementation advertising a forwarding address MUST advertise a
global IPv6 address. This global IPv6 address may be the next-hop
gateway for an external prefix or may be obtained through some
other method (e.g., configuration).
フォーワーディング・アドレスAはIPv6アドレス(128ビット)に完全に資格を与えました。 そして、LSAに含まれている、噛み付かれる場合にだけ、Fは設定されました。 含んでいると、広告を出している目的地のためのデータ通信量をこのアドレスに送るでしょう。 IPv6 Unspecified Addressにそれを設定してはいけない、(0:0:、0:0:0、:、0:0:0、)、または、IPv6 Link地方のAddress(接頭語FE80/10)。 通常、OSPFv3ルートがインストールされている間、リンクローカルのアドレス、OSPFv3実装広告によるフォーワーディング・アドレスはグローバルなIPv6アドレスの広告を出さなければなりません。 このグローバルなIPv6アドレスを外部の接頭語のための次のホップゲートウェイであるかもしれないかある他のメソッド(例えば、構成)で得るかもしれません。
External Route Tag
A 32-bit field that MAY be used to communicate additional
information between AS boundary routers. Included in the LSA if
and only if bit T has been set.
AS境界ルータの間の追加情報を伝えるのに使用されるかもしれない外部のRoute Tag A32ビットの分野。 そして、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境界ルータの間の情報を伝えるのに使用されるかもしれません。 この仕様の範囲の外にそのような情報の正確な本質があります。
All, none, or some of the fields labeled Forwarding address, External Route Tag, and Referenced Link State ID MAY be present in the AS- external-LSA (as indicated by the setting of bit F, bit T, and Referenced LS Type respectively). When present, Forwarding Address always comes first, External Route Tag next, and the Referenced Link State ID last.
Forwardingアドレス、External Route Tag、およびReferenced Link州IDとラベルされた分野のすべて、なにも、またはいくつかがASの外部のLSAに出席しているかもしれません(ビットF、ビットT、およびReferenced LS Typeの設定によってそれぞれ示されるように)。 プレゼント、Forwarding Addressがいつも一番になるとき、次のExternal Route Tagと、Referenced Link州ID最終です。
Coltun, et al. Standards Track [Page 81] RFC 5340 OSPF for IPv6 July 2008
Coltun、他 IPv6 July 2008のための標準化過程[81ページ]RFC5340OSPF
A.4.8. NSSA-LSAs
A.4.8。 NSSA-LSAs
NSSA-LSAs have LS type equal to 0x2007. These LSAs are originated by AS boundary routers within an NSSA and describe destinations external to the AS that may or may not be propagated outside the NSSA (refer to [NSSA]). Other than the LS type, their format is exactly the same as AS-external LSAs as described in Appendix A.4.7.
NSSA-LSAsには、0×2007と等しいLSタイプがあります。 これらのLSAsはNSSAの中でAS境界ルータによって溯源されて、NSSAの外で伝播されるかもしれないASへの外部の目的地について説明します([NSSA]を参照してください)。 LSタイプを除いて、彼らの形式はまさにAppendix A.4.7で説明されるAS外部のLSAsと同じです。
A global IPv6 address MUST be selected as forwarding address for NSSA-LSAs that are to be propagated by NSSA area border routers. The selection should proceed the same as OSPFv2 NSSA support [NSSA] with additional checking to ensure IPv6 link-local address are not selected.
グローバルなIPv6アドレスはNSSA境界ルータによって伝播されることになっているNSSA-LSAsのためのアドレスを転送するとして選定されなければなりません。 リンクローカルアドレスをIPv6に確実にする追加照合があるOSPFv2 NSSAサポート[NSSA]が選択されないとき、選択は同じように続くべきです。
A.4.9. Link-LSAs
A.4.9。 リンク-LSAs
Link-LSAs have LS type equal to 0x0008. A router originates a separate link-LSA for each attached physical link. These LSAs have link-local flooding scope; they are never flooded beyond the associated link. Link-LSAs have three purposes:
リンク-LSAsには、0×0008と等しいLSタイプがあります。 ルータはそれぞれの付属物理的なリンクに別々のリンク-LSAを溯源します。 これらのLSAsには、リンク地方の氾濫範囲があります。 それらは関連リンクを超えて決して水につかっていません。 リンク-LSAsには、3つの目的があります:
1. They provide the router's link-local address to all other routers
attached to the link.
1. 彼らはリンクに付けられた他のすべてのルータにルータのリンクローカルアドレスを提供します。
2. They inform other routers attached to the link of a list of IPv6
prefixes to associate with the link.
2. 彼らは、リンクと交際するためにIPv6接頭語のリストのリンクに付けられた他のルータを知らせます。
3. They allow the router to advertise a collection of Options bits
in the network-LSA originated by the Designated Router on a
broadcast or NBMA link.
3. 彼らは、放送かNBMAの上のDesignated Routerによって溯源されたネットワーク-LSAリンクでのOptionsビットの収集の広告を出すためにルータを許します。
For details concerning the construction of links-LSAs, see Section 4.4.3.8.
リンク-LSAsの構造に関する詳細に関しては、.8にセクション4.4.3を見てください。
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 82] RFC 5340 OSPF for IPv6 July 2008
Coltun、他 IPv6 July 2008のための標準化過程[82ページ]RFC5340OSPF
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Age |0|0|0| 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rtr Priority | Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- -+
| |
+- Link-local Interface Address -+
| |
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # prefixes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PrefixLength | PrefixOptions | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Prefix |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PrefixLength | PrefixOptions | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Prefix |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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優先権| オプション| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +- -+ | | + リンク地方のインタフェースアドレス-+| | +- -+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | # 接頭語| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PrefixLength| PrefixOptions| 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | アドレス接頭語| | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PrefixLength| PrefixOptions| 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | アドレス接頭語| | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Link-LSA Format
リンク-LSA形式
Rtr Priority
The Router Priority of the interface attaching the originating
router to the link.
起因するルータをリンクに付けるインタフェースのRtr Priority Router Priority。
Options
The set of Options bits that the router would like set in the
network-LSA that will be originated by the Designated Router on
broadcast or NBMA links.
放送かNBMAの上のDesignated Routerによって溯源されるネットワーク-LSAリンクでルータがセットのようにそうするOptionsビットのセットにゆだねます。
Coltun, et al. Standards Track [Page 83] RFC 5340 OSPF for IPv6 July 2008
Coltun、他 IPv6 July 2008のための標準化過程[83ページ]RFC5340OSPF
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
Appendix A.4.1.
IPv6のPrefixLength、PrefixOptions、およびAddress Prefix RepresentationはAppendix A.4.1で説明されるように接頭語を扱います。
A.4.10. Intra-Area-Prefix-LSAs
A.4.10。 イントラ領域接頭語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 local router address, an attached stub network segment, or an attached transit network segment. In IPv4, the first two were accomplished via the router's router-LSA and the last via a network-LSA. In OSPF for IPv6, all addressing information that was advertised in router-LSAs and network-LSAs has been removed and is now advertised in intra-area-prefix-LSAs. For details concerning the construction of intra-area-prefix-LSA, see Section 4.4.3.9.
イントラ領域はLSAsを前に置きます。LSタイプを0×2009と等しくしてください。 ルータは1つ以上のローカルルータアドレス、付属スタッブネットワークセグメント、または付属トランジットネットワークセグメントに関連しているイントラ領域が広告を出すためにLSAsを前に置いているIPv6アドレス接頭語を使用します。 IPv4では、最初の2はネットワーク-LSAを通してルータのルータ-LSAと最終で達成されました。 IPv6のためのOSPFでは、イントラ領域がLSAsを前に置いた状態で、ルータ-LSAsとネットワーク-LSAsの広告に掲載されたすべてのアドレス指定情報に、取り除いて、現在、広告を出します。 工事に関する詳細である、セクション4.4.3は、イントラ領域がLSAを前に置くのを.9に見ます。
A router can originate multiple intra-area-prefix-LSAs for each router or transit network. Each such LSA is distinguished by its unique Link State ID.
ルータは複数のイントラ領域が各ルータかトランジットのためにLSAsを前に置いているネットワークを溯源できます。 そのような各LSAはユニークなLink州IDによって区別されます。
Coltun, et al. Standards Track [Page 84] RFC 5340 OSPF for IPv6 July 2008
Coltun、他 IPv6 July 2008のための標準化過程[84ページ]RFC5340OSPF
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| メートル法| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | アドレス接頭語| | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Intra-Area-Prefix LSA Format
イントラ領域接頭語LSA形式
# prefixes
The number of IPv6 address prefixes contained in the LSA.
# IPv6アドレス接頭語の数がLSAに含んだ接頭語。
Referenced LS Type, Referenced Link State ID, and Referenced
Advertising Router
Identifies the router-LSA or network-LSA with which the IPv6
address prefixes should be associated. If Referenced LS Type is
0x2001, the prefixes are associated with a router-LSA, Referenced
Link State ID should be 0, and Referenced Advertising Router
should be the originating router's Router ID. If Referenced LS
Type is 0x2002, the prefixes are associated with a network-LSA,
Referenced Link State ID should be the Interface ID of the link's
Designated Router, and Referenced Advertising Router should be the
Designated Router's Router ID.
IPv6と接頭語を扱うReferenced Advertising Router Identifiesの参照をつけられたLS Type、Referenced Link州IDとルータ-LSAかネットワーク-LSAが関連しているべきです。 Referenced LS Typeが0×2001であるなら、接頭語はルータ-LSAに関連しています、そして、Referenced Link州IDは0歳であるべきです、そして、Referenced Advertising Routerは起因するルータのRouter IDであるべきです。 Referenced LS Typeが0×2002であるなら、接頭語はネットワーク-LSAに関連しています、そして、Referenced Link州IDはリンクのDesignated RouterのInterface IDであるべきです、そして、Referenced Advertising RouterはDesignated RouterのRouter IDであるべきです。
Coltun, et al. Standards Track [Page 85] RFC 5340 OSPF for IPv6 July 2008
Coltun、他 IPv6 July 2008のための標準化過程[85ページ]RFC5340OSPF
The rest of the intra-area-prefix-LSA contains a list of IPv6 prefixes to be associated with the router or transit link, as well as their associated costs.
イントラ領域がLSAを前に置くことの残りはルータかトランジットリンクに関連しているIPv6接頭語のリストを含んでいます、それらの関連コストと同様に。
PrefixLength, PrefixOptions, and Address Prefix
Representation of an IPv6 address prefix, as described in
Appendix A.4.1.
IPv6のPrefixLength、PrefixOptions、およびAddress Prefix RepresentationはAppendix A.4.1で説明されるように接頭語を扱います。
Metric
The cost of this prefix. Expressed in the same units as the
interface costs in router-LSAs.
メートル法、この接頭語の費用。 インタフェースコストと同じユニットでは、ルータ-LSAsで言い表されます。
Appendix B. Architectural Constants
付録のB.の建築定数
Architectural constants for the OSPF protocol are defined in Appendix B of [OSPFV2]. The only difference for OSPF for IPv6 is that DefaultDestination is encoded as a prefix with length 0 (see Appendix A.4.1).
OSPFプロトコルのための建築定数は[OSPFV2]のAppendix Bで定義されます。 IPv6のためのOSPFのための唯一の違いはDefaultDestinationが接頭語として長さ0でコード化されるという(Appendix A.4.1を見てください)ことです。
Appendix C. Configurable Constants
付録のC.の構成可能な定数
The OSPF protocol has quite a few configurable parameters. These parameters are listed below. They are grouped into general functional categories (area parameters, interface parameters, etc.). Sample values are given for some of the parameters.
OSPFプロトコルには、かなり多くの構成可能なパラメタがあります。 これらのパラメタは以下にリストアップされています。 それらは一般的な機能的なカテゴリ(領域パラメタ、インタフェース・パラメータなど)に分類されます。 パラメタのいくつかのために標本値を与えます。
Some parameter settings need to be consistent among groups of routers. For example, all routers in an area must agree on that area's parameters. Similarly, all routers attached to a network must agree on that network's HelloInterval and RouterDeadInterval.
いくつかのパラメタ設定が、ルータのグループで一貫している必要があります。 例えば、領域のすべてのルータがその領域のパラメタに同意しなければなりません。 同様に、ネットワークに付けられたすべてのルータがそのネットワークのHelloIntervalとRouterDeadIntervalに同意しなければなりません。
Some parameters may be determined by router algorithms outside of this specification (e.g., the address of a host connected to the router via a SLIP line). From OSPF's point of view, these items are still configurable.
いくつかのパラメタがこの仕様の外でルータアルゴリズムで決定するかもしれません(例えばホストのアドレスはSLIP系列でルータに接続しました)。 OSPFの観点から、これらの項目はまだ構成可能です。
C.1. Global Parameters
C.1。 グローバルなパラメタ
In general, a separate copy of the OSPF protocol is run for each area. Because of this, most configuration parameters are defined on a per-area basis. The few global configuration parameters are listed below.
一般に、OSPFプロトコルの別々のコピーは各領域に動かされます。 これのために、ほとんどの設定パラメータが地域制で定義されます。 わずかなグローバルな設定パラメータが以下にリストアップされています。
Coltun, et al. Standards Track [Page 86] RFC 5340 OSPF for IPv6 July 2008
Coltun、他 IPv6 July 2008のための標準化過程[86ページ]RFC5340OSPF
Router ID
This is a 32-bit number that uniquely identifies the router in the
Autonomous System. If a router's OSPF Router ID is changed, the
router's OSPF software should be restarted before the new Router
ID takes effect. Before restarting due to a Router ID change, the
router should flush its self-originated LSAs from the routing
domain (see Section 14.1 of [OSPFV2]). Otherwise, they will
persist for up to MaxAge seconds.
ルータID ThisはAutonomous Systemで唯一ルータを特定する32ビットの数です。 ルータのOSPF Router IDを変えるなら、新しいRouter IDが効く前にルータのOSPFソフトウェアを再開するべきです。 Router ID変化のため再開する前に、ルータは経路ドメインから自己によって溯源されたLSAsを洗い流すべきです([OSPFV2]のセクション14.1を見てください)。 さもなければ、彼らはMaxAge秒まで固執するでしょう。
Because the size of the Router ID is smaller than an IPv6 address, it cannot be set to one of the router's IPv6 addresses (as is commonly done for IPv4). Possible Router ID assignment procedures for IPv6 include: a) assign the IPv6 Router ID as one of the router's IPv4 addresses or b) assign IPv6 Router IDs through some local administrative procedure (similar to procedures used by manufacturers to assign product serial numbers).
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.
0.0のRouter ID、.0、.0が予約されている、SHOULD NOT、使用されてください。
C.2. Area Parameters
C.2。 領域パラメタ
All routers belonging to an area must agree on that area's configuration. Disagreements between two routers will lead to an inability for adjacencies to form between them, with a resulting hindrance to the flow of both routing protocol information and data traffic. The following items must be configured for an area:
領域に属すすべてのルータがその領域の構成に同意しなければなりません。 2つのルータの不一致はそれらの間で隣接番組を形成できないことにつながるでしょう、ルーティングプロトコル情報とデータ通信量の両方の流れへの結果として起こる妨害で。 以下の項目を領域に構成しなければなりません:
Area ID
This is a 32-bit number that identifies the area. The Area ID of
0 is reserved for the backbone.
領域ID 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 87] RFC 5340 OSPF for IPv6 July 2008
Coltun、他 IPv6 July 2008のための標準化過程[87ページ]RFC5340OSPF
ExternalRoutingCapability
Whether AS-external-LSAs will be flooded into/throughout the area.
If AS-external-LSAs are excluded from the area, the area is called
a stub area or NSSA. Internal to stub areas, routing to external
destinations will be based solely on a default inter-area route.
The backbone cannot be configured as a stub or NSSA area. Also,
virtual links cannot be configured through stub or NSSA areas.
For more information, see Section 3.6 of [OSPFV2] and [NSSA].
ExternalRoutingCapability Whether ASの外部のLSAsは領域中に/へあふれるでしょう。 ASの外部のLSAsが領域から除かれるなら、領域はスタッブ領域かNSSAと呼ばれます。 領域を引き抜くために内部であり、外部の目的地へのルーティングは唯一デフォルト相互領域ルートに基づくでしょう。 スタッブかNSSA領域としてバックボーンを構成できません。 また、スタッブかNSSA領域を通って仮想のリンクを構成できません。 詳しくは、[OSPFV2]と[NSSA]のセクション3.6を見てください。
StubDefaultCost
If the area has been configured as a stub area, and the router
itself is an area border router, then the StubDefaultCost
indicates the cost of the default inter-area-prefix-LSA that the
router should advertise into the area. See Section 12.4.3.1 of
[OSPFV2] for more information.
領域はスタッブ領域として構成されました、そして、ルータ自体が境界ルータである、次に、相互領域がLSAを前に置いた状態で、StubDefaultCostはデフォルトの費用を示します。StubDefaultCost If、ルータは領域に広告を出すべきです。 セクション12.4を見てください。.3 詳しい情報のための.1[OSPFV2。]
NSSATranslatorRole and TranslatorStabilityInterval
These area parameters are described in Appendix D of [NSSA].
Additionally, an NSSA Area Border Router (ABR) is also required to
allow configuration of whether or not an NSSA default route is
advertised in an NSSA-LSA. If advertised, its metric and metric
type are configurable. These requirements are also described in
Appendix D of [NSSA].
NSSATranslatorRoleとTranslatorStabilityInterval These領域パラメタは[NSSA]のAppendix Dで説明されます。 また、さらに、NSSA Area Border Router(ABR)が、NSSA-LSAにNSSAデフォルトルートの広告を出すかどうかに関する構成を許すのに必要です。 広告を出すなら、メートル法の、そして、メートル法のタイプは構成可能です。 また、これらの要件は[NSSA]のAppendix Dで説明されます。
ImportSummaries
When set to enabled, prefixes external to the area are imported
into the area via the advertisement of inter-area-prefix-LSAs.
When set to disabled, inter-area routes are not imported into the
area. The default setting is enabled. This parameter is only
valid for stub or NSSA areas.
広告を通した領域がその領域への可能にされた接頭語外部へのImportSummaries Whenセットにインポートされる、相互領域はLSAsを前に置きます。 身体障害者に設定される場合、相互領域ルートは領域にインポートされません。 既定の設定は可能にされます。 スタッブかNSSA領域だけに、このパラメタは有効です。
C.3. Router Interface Parameters
C.3。 ルータインタフェース・パラメータ
Some of the configurable router interface parameters (such as Area ID, HelloInterval, and RouterDeadInterval) actually imply properties of the attached links. Therefore, these parameters must be consistent across all the routers attached to that link. The parameters that must be configured for a router interface are:
構成可能なルータインタフェース・パラメータ(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リンクローカルアドレス。 自動構成を通して学習されるかもしれません。
Coltun, et al. Standards Track [Page 88] RFC 5340 OSPF for IPv6 July 2008
Coltun、他 IPv6 July 2008のための標準化過程[88ページ]RFC5340OSPF
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
([INTFMIB]).
このルータのインタフェースの収集の中で唯一このインタフェースを特定するIDの32ビットの番号を連結してください。 例えば、いくつかの実装では、MIB-II IfIndex([INTFMIB])を使用するのは可能であるかもしれません。
IPv6 prefixes
The list of IPv6 prefixes to associate with the link. These will
be advertised in intra-area-prefix-LSAs.
IPv6は、リンクと交際するためにIPv6接頭語のリストを前に置きます。 これらでは、イントラ領域がLSAsを前に置いた状態で、広告を出すでしょう。
Interface output cost(s)
The cost of sending a packet on the interface, expressed in the
link-state metric. This is advertised as the link cost for this
interface in the router's router-LSA. The interface output cost
MUST always be greater than 0.
インタフェース出力は(s) リンク状態でメートル法で言い表されたインタフェースにパケットを送る費用かかります。 ルータのルータ-LSAのこのインタフェースへのリンク費用としてこれの広告を出します。 いつもインタフェース製作費は0以上であるに違いありません。
RxmtInterval
The number of seconds between LSA retransmissions for adjacencies
belonging to this interface. Also used when retransmitting
Database Description and Link State Request packets. This should
be well over the expected round-trip delay between any two routers
on the attached link. The setting of this value should be
conservative or needless retransmissions will result. Sample
value for a local area network: 5 seconds.
隣接番組のためのLSA retransmissionsの間の秒がこれに属す数が連結するRxmtInterval。 また、Database記述とLink州Requestパケットを再送するとき、使用されます。 付属リンクの上のどんな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パケットをこのインタフェースの上に伝えるのにそれがかかる秒に付番します。 アップデートパケットに含まれたLSAsはトランスミッションの前にこの量で彼らの時代を増加させなければなりません。 この値はインタフェースのトランスミッションと伝播遅延を考慮に入れるべきです。 それは0以上であるに違いありません。 ローカル・エリア・ネットワークのために値を抽出してください: 1 2番目に。
Router Priority
An 8-bit unsigned integer. When two routers attached to a network
both attempt to become the Designated Router, the one with the
highest Router Priority takes precedence. If there is still a
tie, the router with the highest Router ID takes precedence. A
router whose Router Priority is set to 0 is ineligible to become
the Designated Router on the attached link. Router Priority is
only configured for interfaces to broadcast and NBMA networks.
ルータPriority An、8ビットの符号のない整数。 ネットワークに付けられた2つのルータが、Designated Routerになるのをともに試みるとき、最も高いRouter Priorityがあるものは優先します。 繋がりがまだあれば、最も高いRouter IDがあるルータは優先します。 Router Priorityが0に用意ができているルータは付属リンクの上のDesignated Routerになるのにおいて不適格です。 ルータPriorityは放送するインタフェースとNBMAネットワークのために構成されるだけです。
Coltun, et al. Standards Track [Page 89] RFC 5340 OSPF for IPv6 July 2008
Coltun、他 IPv6 July 2008のための標準化過程[89ページ]RFC5340OSPF
HelloInterval
The length of time, in seconds, between Hello packets that the
router sends on the interface. This value is advertised in the
router's Hello packets. It MUST be the same for all routers
attached to a common link. The smaller the HelloInterval, the
faster topological changes will be detected. However, more OSPF
routing protocol traffic will ensue. Sample value for a X.25 PDN:
30 seconds. Sample value for a local area network (LAN): 10
seconds.
ルータがインタフェースで送るHelloパケットの間の秒の時間の長さのHelloInterval。 ルータのHelloパケットにこの値の広告を出します。 普通リンクに付けられたすべてのルータに、それは同じであるに違いありません。 HelloIntervalが小さければ小さいほど、位相的な変化は、より速く検出されるでしょう。 しかしながら、より多くのOSPFルーティング・プロトコルトラフィックが続くでしょう。 X.25 PDNのために値を抽出してください: 30秒。 ローカル・エリア・ネットワーク(LAN)のために値を抽出してください: 10秒。
RouterDeadInterval
After ceasing to hear a router's Hello packets, the number of
seconds before its neighbors declare the router down. This is
also advertised in the router's Hello packets in their
RouterDeadInterval field. This should be some multiple of the
HelloInterval (e.g., 4). This value again MUST be the same for
all routers attached to a common link.
RouterDeadInterval Afterが、ルータのHelloパケットを聞くのをやめて、隣人がルータを宣言する前に秒数はダウンします。 また、それらのRouterDeadInterval分野のルータのHelloパケットにこれの広告を出します。 これはHelloInterval(例えば、4)の何らかの倍数であるべきです。 普通リンクに付けられたすべてのルータには、この値は再び同じでなければなりません。
LinkLSASuppression
Indicates whether or not origination of a link-LSA is suppressed.
If set to "enabled" and the interface type is not broadcast or
NBMA, the router will not originate a link-LSA for the link. This
implies that other routers on the link will ascertain the router's
next-hop address using a mechanism other than the link-LSA (see
Section 4.8.2). The default value is "disabled" for interface
types described in this specification. It is implicitly
"disabled" if the interface type is broadcast or NBMA. Future
interface types MAY specify a different default.
LinkLSASuppression Indicates、リンク-LSAの創作は抑圧されるのであるかどうか 「可能にされること」へのセットとインターフェース型が放送でない、またNBMAでないなら、ルータはリンク-LSAをリンクに溯源しないでしょう。 これは、リンクの上の他のルータがリンク-LSA(セクション4.8.2を見る)以外のメカニズムを使用することでルータの次のホップアドレスを確かめるのを含意します。 デフォルト値はこの仕様で説明されたインターフェース型のために「無効にされます」。 それはインターフェース型が放送かNBMAであるならそれとなく「無効にされます」。 将来のインターフェース型は異なったデフォルトを指定するかもしれません。
C.4. Virtual Link Parameters
C.4。 仮想のリンクパラメータ
Virtual links are used to restore/increase connectivity of the backbone. Virtual links may be configured between any pair of area border routers having interfaces to a common (non-backbone) area. The virtual link appears as a point-to-point link with no global IPv6 addresses in the graph for the backbone. The virtual link must be configured in both of the area border routers.
仮想のリンクは、バックボーンの接続性を回復するか、または増強するのに使用されます。 仮想のリンクは、一般的な(非バックボーンの)領域にインタフェースを持ちながら、どんな組の境界ルータの間でも構成されるかもしれません。 仮想のリンクはポイントツーポイント接続としてバックボーンのためのグラフにグローバルなIPv6アドレスなしで現れます。 境界ルータの両方で仮想のリンクを構成しなければなりません。
A virtual link appears in router-LSAs (for the backbone) as if it were a separate router interface to the backbone. As such, it has most of the parameters associated with a router interface (see Appendix C.3). Virtual links do not have link-local addresses, but instead use one of the router's global-scope IPv6 addresses as the IP source in OSPF protocol packets it sends on the virtual link. Router Priority is not used on virtual links. Interface output cost is not configured on virtual links, but is dynamically set to be the cost of the transit area intra-area path between the two endpoint routers. The parameter RxmtInterval may be configured and should be well over
仮想のリンクはまるでそれがバックボーンへの別々のルータインタフェースであるかのようにルータ-LSAs(バックボーンのための)に現れます。 そういうものとして、それには、ルータインタフェースに関連しているパラメタの大部分があります(Appendix C.3を見てください)。 仮想のリンクには、リンクローカルのアドレスがありませんが、代わりにそれが仮想のリンクに送るOSPFプロトコルパケットのIPソースとしてルータのグローバルな範囲IPv6アドレスの1つを使用してください。 ルータPriorityは仮想のリンクの上に使用されません。 インタフェース製作費は、仮想のリンクの上に構成されませんが、2つの終点ルータの間のトランジット領域イントラ領域経路の費用であるようにダイナミックに設定されます。 パラメタRxmtIntervalは構成されるかもしれなくて、よく終わっているべきです。
Coltun, et al. Standards Track [Page 90] RFC 5340 OSPF for IPv6 July 2008
Coltun、他 IPv6 July 2008のための標準化過程[90ページ]RFC5340OSPF
the expected round-trip delay between the two routers. This may be hard to estimate for a virtual link; it is better to err on the side of making it too long.
2つのルータの間の予想された往復の遅れ。 これは仮想のリンクに見積もっているのは困難であるかもしれません。 それを長くし過ぎることの側で間違えるほうがよいです。
A virtual link is defined by the following two configurable parameters: the Router ID of the virtual link's other endpoint and the (non-backbone) area that the virtual link traverses (referred to as the virtual link's transit area). Virtual links cannot be configured through stub or NSSA areas. Additionally, an Instance ID may be configured for virtual links from different protocol instances in order to utilize the same transit area (without requiring different Router IDs for demultiplexing).
仮想のリンクは以下の2つの構成可能なパラメタによって定義されます: 仮想のリンクが横断する(仮想のリンクのトランジット領域と呼ばれます)仮想のリンクの他の終点のRouter IDと(非バックボーンの)領域。 スタッブかNSSA領域を通って仮想のリンクを構成できません。 さらに、Instance IDは、同じトランジット領域(逆多重化のために異なったRouter IDを必要とすることのない)を利用するために異なったプロトコルインスタンスから仮想のリンクに構成されるかもしれません。
C.5. NBMA Network Parameters
C.5。 NBMA回路パラメータ
OSPF treats an NBMA network much like it treats a broadcast network. Since there may be many routers attached to the network, a Designated Router is selected for the network. This Designated Router then originates a network-LSA listing all routers attached to the NBMA network.
放送網を扱うようにOSPFはNBMAネットワークを扱います。 ネットワークに付けられた多くのルータがあるかもしれないので、Designated Routerはネットワークのために選択されます。 そしてこのDesignated Routerは、NBMAネットワークに付けられたすべてのルータを記載しながら、ネットワーク-LSAを溯源します。
However, due to the lack of broadcast capabilities, it may be necessary to use configuration parameters in the Designated Router selection. These parameters will only need to be configured in those routers that are themselves eligible to become the Designated Router (i.e., those routers whose Router Priority for the network is non- zero), and then only if no automatic procedure for discovering neighbors exists:
しかしながら、放送能力の不足のために、Designated Router選択に設定パラメータを使用するのが必要であるかもしれません。 これらのパラメタは、それらのDesignated Router(すなわち、ネットワークのためのRouter Priorityが非ゼロであるそれらのルータ)になるのが自分たちで適任のルータで構成されて、隣人を発見するためのどんな自動手順も存在していない場合にだけそして構成される必要があるだけでしょう:
List of all other attached routers
The list of all other routers attached to the NBMA network. Each
router is configured with its Router ID and IPv6 link-local
address on the network. Also, for each router listed, that
router's eligibility to become the Designated Router must be
defined. When an interface to an NBMA network first comes up, the
router only sends Hello packets to those neighbors eligible to
become the Designated Router until such time that a Designated
Router is elected.
他のリストは他のすべてのルータのリストがNBMAネットワークに付けたルータを付けました。 各ルータはネットワークのそのRouter IDとIPv6リンクローカルアドレスによって構成されます。 Designated Routerになる各ルータが記載したのでそのルータのも適任を定義しなければなりません。 NBMAネットワークへのインタフェースが最初に来るとき、ルータはDesignated RouterになるのがDesignated Routerが選出されるくらいの時間まで適任のそれらの隣人へのパケットをHelloに送るだけです。
PollInterval
If a neighboring router has become inactive (Hello packets have
not been seen for RouterDeadInterval seconds), it may still be
necessary to send Hello packets to the dead neighbor. These Hello
packets will be sent at the reduced rate PollInterval, which
should be much larger than HelloInterval. Sample value for a PDN
X.25 network: 2 minutes.
PollInterval Ifのa隣接しているルータが不活発になった、(こんにちは、パケットがRouterDeadInterval秒の間、見られていない、)、死んでいる隣人へのパケットをHelloに送るのがまだ必要であるかもしれません。 割引料金PollIntervalでこれらのHelloパケットを送るでしょう。(PollIntervalはHelloIntervalよりはるかに大きいはずです)。 PDN X.25ネットワークのために値を抽出してください: 2 書き留めます。
Coltun, et al. Standards Track [Page 91] RFC 5340 OSPF for IPv6 July 2008
Coltun、他 IPv6 July 2008のための標準化過程[91ページ]RFC5340OSPF
C.6. Point-to-Multipoint Network Parameters
C.6。 ポイントツーマルチポイント回路パラメータ
On point-to-multipoint networks, it may be necessary to configure the set of neighbors that are directly reachable over the point-to- multipoint network. Each neighbor is configured with its Router ID and IPv6 link-local address on the network. Designated Routers are not elected on point-to-multipoint networks, so the Designated Router eligibility of configured neighbors is not defined.
ポイントツーマルチポイントネットワークでは、ポイントから多点へのネットワークの上で直接届いている隣人のセットを構成するのが必要であるかもしれません。 各隣人はネットワークのそのRouter IDとIPv6リンクローカルアドレスによって構成されます。 指定されたRoutersがポイントツーマルチポイントネットワークで選出されないので、構成された隣人のDesignated Router適任は定義されません。
C.7. Host Route Parameters
C.7。 ホストルートパラメタ
Host prefixes are advertised in intra-area-prefix-LSAs. They indicate either local router addresses, router interfaces to point- to-point networks, looped router interfaces, or IPv6 hosts that are directly connected to the router (e.g., via a PPP connection). For each host directly connected to the router, the following items must be configured:
ホスト接頭語では、イントラ領域がLSAsを前に置いた状態で、広告を出します。 彼らは、ローカルルータアドレス(ポイントへのポイントネットワークへのルータインタフェース)が直接ルータ(例えば、PPP接続を通した)に接続されるルータインタフェース、またはIPv6ホストを輪にしたのを示します。 直接ルータに接続された各ホストに関しては、以下の項目を構成しなければなりません:
Host IPv6 prefix
An IPv6 prefix belonging to the directly connected host. This
must not be a valid IPv6 global prefix.
ホストIPv6接頭語An 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 92] RFC 5340 OSPF for IPv6 July 2008
Coltun、他 IPv6 July 2008のための標準化過程[92ページ]RFC5340OSPF
Authors' Addresses
作者のアドレス
Rob Coltun Acoustra Productions 3204 Brooklawn Terrace Chevy Chase, MD 20815 USA
ロブColtun Acoustra Productions3204Brooklawn Terrace MD20815チェビー・チェイス(米国)
Dennis Ferguson Juniper Networks 1194 N. Mathilda Avenue Sunnyvale, CA 94089 USA
デニスファーガソンJuniperは1194N.マチルダ・Avenueカリフォルニア94089サニーベル(米国)をネットワークでつなぎます。
EMail: dennis@juniper.net
メール: dennis@juniper.net
John Moy Sycamore Networks, Inc 10 Elizabeth Drive Chelmsford, MA 01824 USA
ジョンMoyアメリカスズカケノキネットワーク、Inc10エリザベス・Driveチェルムズフォード、MA01824米国
EMail: jmoy@sycamorenet.com
メール: jmoy@sycamorenet.com
Acee Lindem (editor) Redback Networks 102 Carric Bend Court Cary, NC 27519 USA
Acee Lindem(エディタ)20ドル紙幣ネットワーク102こづなつなぎ法廷のNC27519ケーリー(米国)
EMail: acee@redback.com
メール: acee@redback.com
Coltun, et al. Standards Track [Page 93] RFC 5340 OSPF for IPv6 July 2008
Coltun、他 IPv6 July 2008のための標準化過程[93ページ]RFC5340OSPF
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(2008)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Coltun, et al. Standards Track [Page 94]
Coltun、他 標準化過程[94ページ]
一覧
スポンサーリンク
