Internet DRAFT - draft-coltun-ospf-ospfv6
draft-coltun-ospf-ospfv6
HTTP/1.1 200 OK
Date: Mon, 08 Apr 2002 23:20:04 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Tue, 12 Dec 1995 23:00:00 GMT
ETag: "2e7f86-257c4-30ce0970"
Accept-Ranges: bytes
Content-Length: 153540
Connection: close
Content-Type: text/plain
Internet Draft OSPFv6 December 1995
Expiration Date: June 1996 FORE Systems
File name: draft-coltun-ospf-ospfv6-00.txt
OSPF Version 2 For IP Version 6
Rob Coltun
FORE Systems
(301) 571-2521
rcoltun@fore.com
Status Of This Memo
This document is an Internet-Draft. Internet-Drafts are working docu-
ments of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute work-
ing documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress".
To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet- Drafts Shadow
Directories on ds.internic.net (US East Coast), nic.nordu.net
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
Coltun Expires June 1996 [Page 1]
Internet Draft OSPFv6 December 1995
Table Of Contents
1.0 Abstract ................................................. 4
2.0 Overview ................................................. 4
2.1 Organization Of This Document ............................ 4
2.2 Acknowledgments .......................................... 4
3.0 OSPFv4 To OSPFv6 Diffs ................................... 5
3.1 Features That Haven't Been Modified ...................... 5
3.2 Features That Have Been Removed .......................... 6
3.2.1 TOS-Based Routing ...................................... 6
3.3 Modifications And Extensions ............................. 6
3.3.1 Extensions To Address And ID Fields .................... 6
3.3.2 Semantics Of The Network Mask Field .................... 6
3.3.3 External LSA Forwarding Address And Route Tag .......... 7
3.3.4 Protocol Packet Processing Modifications ............... 7
3.4 Additions To OSPFv6 ...................................... 8
3.4.1 Support Of The Opaque LSA .............................. 8
3.4.2 Instance ID ............................................ 8
4.0 Overview Of OSPFv6 Packet Formats ........................ 8
4.1 The OSPF Packet Header ................................... 9
4.2 The Hello Packet ......................................... 9
4.3 The Link-State Advertisement Header ...................... 10
4.4 The Database Description Packet .......................... 10
4.5 The Link-State Request Packet ............................ 10
4.6 The Link-State Acknowledgment Packet ..................... 11
4.7 The Link-State Update Packet ............................. 11
4.7.1 The Router LSA ......................................... 12
4.7.2 The Network LSA ........................................ 12
4.7.3 Summary LSA ............................................ 12
4.7.4 The AS External LSA .................................... 12
5.0 Protocol Packet Processing ............................... 14
5.1 Sending Protocol Packets ................................. 14
5.2 Receiving Protocol Packets ............................... 16
6.0 Opaque LSAs .............................................. 19
6.1 Modifications To The Neighbor State Machine .............. 20
6.2 Modifications To The Flooding Procedures ................. 20
7.0 AS External Routes ....................................... 22
7.1 Origination Of AS External Reference Opaque LSA .......... 22
7.2 Calculating AS External Routes ........................... 22
8.0 References ............................................... 24
Appendix A: OSPFv6 Data Formats .............................. 25
A.1 Encapsulation Of OSPFv6 Packets .......................... 25
A.2 The Options Field ........................................ 27
A.3 OSPFv6 Packet Formats .................................... 29
A.3.1 The OSPFv6 Packet Header ............................... 29
A.3.2 The Hello Packet ....................................... 32
A.3.3 The Database Description Packet ........................ 35
A.3.4 The Link-State Request Packet .......................... 37
A.3.5 The Link-State Update Packet ........................... 40
A.3.6 The Link-State Acknowledgment Packet ................... 41
A.4 Link-State Advertisement (LSA) Formats ................... 43
A.4.1 The Link-State Advertisement Header .................... 43
A.4.2 Router LSA ............................................. 46
A.4.3 Network LSA ............................................ 49
Coltun Expires June 1996 [Page 2]
Internet Draft OSPFv6 December 1995
A.4.4 Summary LSA ............................................ 51
A.4.5 AS External LSA ........................................ 53
A.4.6 Opaque LSA ............................................. 55
A.4.6.1 Link-Local Opaque LSA ................................ 57
A.4.6.2 AS External Reference Opaque LSA ..................... 59
Appendix B: Architectural Constants .......................... 61
Appendix C: Configurable Constants ........................... 62
C.1 Global Parameters ........................................ 62
Coltun Expires June 1996 [Page 3]
Internet Draft OSPFv6 December 1995
1.0 Abstract
This document describes the modifications to OSPF to support version 6
of the Internet Protocol (IPv6). The fundamental mechanisms of OSPF
(flooding, DR election, area support, SPF calculations, etc.) remain
unchanged. The packet formats have been extended to support IPv6
addressing as IPv6 increases the IP address size from 32 bits to 128
bits. Additionally, an Instance ID (i.e., process identifier) has
been added to the OSPF packet header to facilitate routers runing more
than one OSPFv6 instance.
2.0 Overview
Over the last few years the OSPF routing protocol [OSPF] has been
widely deployed throughout the Internet. As a result of this deploy-
ment OSPF has been cleaned up, tuned up and extended as new require-
ments have emerged. We now have a large operational and implementa-
tion knowledge base. Our goal is to utilize this existing experience
base and extend OSPF to support IPv6 [IPV6], which we will refer to as
OSPFv6.
The OSPF area architecture and its fundamental mechanisms (flooding,
DR election, SPF calculations, etc.) remain unchanged. OSPF's options
(on-demand circuits support, NSSA areas, multicast extensions, point-
to-multipoint, etc.) are directly applicable. It is assumed that the
reader is familiar with the OSPF protocol as specified in [OSPF].
The basic change to OSPF to support IPv6 is to extend the net/subnet
address, link-state ID, router ID and area ID fields from 32 to 128
bits. We change the syntax of the network mask from an explicit mask
to an integer which represents the number of bits in the mask. There-
fore when referring to [OSPF], addresses and network masks expressed
as a 32-bit "dotted quads" (e.g., 128.185.1.0) should be thought of as
IPv6 address in the form expressed in the IPv6 address architecture
document [IPV6ADDR] (e.g., FEDC:BA98:7654:3210:FEDC:BA98:7654:3210).
2.1 Organization Of This Document
This document first lists the differences between OSPF for IPv4
(OSPFv4) and OSPFv6, followed by the details of these changes includ-
ing a description of the packet formats which have been extended to
support IPv6. Following that are the mechanisms needed to support the
addition of an instance ID in the packet header. Finally we discuss
the modifications to the AS external LSA processing and AS External
Opaque LSA origination (which is used in conjunction with AS external
LSAs). Appendix A gives the packet formats.
2.2 Acknowledgments
The author would like to thank Fred Baker, Jim Bound, John Moy and the
rest of the OSPF Working Group for the ideas and support they have
Coltun Expires June 1996 [Page 4]
Internet Draft OSPFv6 December 1995
given to this project.
3.0 OSPFv4 To OSPFv6 Diffs
3.1 Features That Haven't Been Modified
The fundamental concept of (sub)networks, CIDR style address and gen-
eral routing architecture of IPv6 [IPV6] is the same as those of IPv4.
Therefore the mechanisms of OSPF remain unchanged including:
o IP subnetting support
o The representation of routers and networks
o The representation of non-broadcast networks
o The link-state database organization
o The link-state database exchange mechanisms
o The link-state database flooding mechanisms
o Neighbor and interface state machines
o The (Backup) Designated Router Election Algorithms
o Building the shortest-path tree
o Support for equal-cost multipath
o The splitting of an AS into Areas
o Supporting stub areas
o The backbone of the Autonomous System
o Inter-area routing
o The use of external routing information (AS external routes)
All of OSPF optional capabilities (on-demand circuits support, NSSA
areas, multicast extensions, point-to-multipoint, etc.) are directly
applicable to OSPFv6 (with the appropriate IPv6 address extensions).
In fact, the version number for OSPFv6 remains as version 2 as this
document is viewed to be an extension of OSPFv4 with [OSPF] remaining
the base document.
Coltun Expires June 1996 [Page 5]
Internet Draft OSPFv6 December 1995
3.2 Features That Have Been Removed
3.2.1 TOS-Based Routing
The semantics of IPv4 TOS have not been moved forward to IPv6; IPv6
has priority and flow identifiers. Priority gives the IPv6 forwarding
engine a hint as to how to queue the packet for processing but does
not necessarily represent an independent routing path. The IPv6 header
does have a 24-bit Flow Label field which may be used by a source to
label those packets for which it requests special handling by IPv6
routers, such as non-default quality of service or "real-time" ser-
vice. In the future the IPv6 Flow Label may be a associated with a
non-default route which may turn out to be loosely related to IPv4
TOS, but the Flow Label concept is still experimental and subject to
change as the requirements for flow support in the Internet become
clearer. Along with the fact that TOS has rarely been used in OSPFv4,
OSPFv6 does not support TOS as defined in OSPFv4.
3.3 Modifications And Extensions
One of the the fundamental motivations for IPv6 was to increase the IP
address size from 32 bits to 128 bits so that IP can support more lev-
els of the addressing hierarchy and so that it can address a much
greater number of nodes. The majority of the changes were made to
accommodate the IPv6 expanded address space while maintaining the phi-
losophy of 32-bit aligned fixed-length fields. (Needless to say the
routing table must be modified to handle 128-bit network addresses).
3.3.1 Extensions To Address And ID Fields
To support IPv6 we extend the (sub)network address, link-state ID,
router ID and area ID fields from 32 to 128 bits. An overview of
these changes and their effect on database size and fragmentation is
given in Section 4.0 entitled "Overview Of OSPFv6 Packet Formats". The
packet formats are given in Appendix A.
3.3.2 Semantics Of The Network Mask Field
The semantics of the network mask has been changed from an explicit
mask to an integer which expresses the number of bits in the network
mask (the field is now called "Network Mask Length"). At the time
that the original OSPF spec was written, non-contiguous masks were
legal. This has since changed and IPv4 and IPv6 allows contiguous
masks only. Since the network mask may be up to 128 bits, link-state
database memory resources can be saved by representing the mask as the
number of bits in the network mask. In the case of the link-data
field in the Router LSA the semantics is type specific so that the
128-bits may be an IPv6 address or a network mask length. When it is
the network mask length, the first 32 bits of the 128-bit field is
treated as an integer which expresses the number of bits in the
Coltun Expires June 1996 [Page 6]
Internet Draft OSPFv6 December 1995
network mask.
3.3.3 External LSA Forwarding Address And Route Tag
OSPFv6 AS External LSAs do not include the forwarding address or the
external route tag. Instead, OSPFv6 external LSAs include a 32-bit
Opaque LSA Reference field. The reason for this is as follows. In
OSPFv4 the Route Tag was not used by the OSPF protocol itself; it was
used to communicate information between AS boundary routers. In
[BGPOSPF] the route tag is divided into two parts or kept as locally
defined information. When it is divided into two parts the upper 16
bits denotes origin information (indications whether the routing
information was originated via an IGP, or some other means) and an
arbitrary tag. The lower 16 bits are used to communicate an auto-
nomous system number. Since CIDR-style addresses [CIDR] are used in
IPv6, it is unlikely that a separate address space will be used for
IPv6 domains as they are for IPv4's Autonomous System numbers.
Instead it is likely that a prefix will be used to represent a domain
as it does in IDRP [IDRP]. For the tag to continue to have the same
function as in OSPFv4 we would need to include the domain identifier
(which is a prefix of a 128-bit address), a length field for the
domain identifier, an arbitrary tag and origin information. This
information would take up 20 octets. Additionally the forwarding
address would have to be extended to 128 bits (another 16 octets).
Within an OSPF system, there are relatively few number of AS boundary
routers and anywhere from a single default route to tens of thousands
of AS external routes injected into the OSPF system. That is a <For-
warding Address, External Tag> pair will most likely be repeated in a
number of External LSAs.
If the External Tag were to be extended to include domain, and origin
information and the forwarding address were extended to a 128-bit
address the External LSA would incur another 36 octets of overhead.
When this is combined with the already extended link-state ID and
router ID fields the external LSA would be 88-octets much of which is
redundant <Forwarding Address, External Tag> information resulting in
unnecessary memory overhead.
OSPFv6 introduces a new type of LSA which carries the forwarding
address, domain and origin information. See Section A.4.6.2 ("AS
External Reference Opaque LSA") for a description of the packet for-
mat. This LSA is referenced by the AS External LSA so as to reduce
the link-state database overhead.
3.3.4 Protocol Packet Processing Modifications
Protocol packet processing has been modified to include the Instance
ID (see Section 3.4.2 below). Also, because there is no checksum in
the IPv6 header, these sections have been removed. See Section 5.0
("Protocol Packet Processing") for a description of the OSPFv6 proto-
col packet processing.
Coltun Expires June 1996 [Page 7]
Internet Draft OSPFv6 December 1995
3.4 Additions To OSPFv6
The following items are not part of OSPF but are part of OSPFv6.
3.4.1 Support Of The Opaque LSA
The Opaque LSA is need by OSPFv6 as a replacement for OSPFv4's exter-
nal LSA's forwarding address and route tag as explained in section
3.3.3 above. To support distribution of the Opaque LSA, modifications
were made to the neighbor state machine and to the flooding pro-
cedures. See Section 6 of this document for the details of these
modifications.
3.4.2 Instance ID
OSPFv6 introduces an Instance ID which is used when multiple OSPFv6
instances (or processes) are used. The Instance ID is used both by
network management to identify the particular instance to be managed
and by the OSPFv6 send and receive functions to identify packet's tar-
get OSPFv6 instance. As an example, multiple Instance IDs may be used
by a network service provider when the provider participates in a
subscriber's IGP (which happens to be OSPF). The provider would
therefore need to support several OSPFv6 instances within the same
router. Multiple OSPF instances allows the router to have logically
partitioned OSPF for reasons of management and policy enforcement.
See section 5 of this document for the details of the modifications to
the protocol packet processing needed to support the Instance ID.
4.0 Overview Of OSPFv6 Packet Formats
The result of extending the IP address to 128 bits is an increase in
the size of several of the packet formats for OSPFv6. To support IPv6
we extend the (sub)network address, link-state ID, router ID and area
ID fields in the OSPF packet formats from 32 to 128 bits. Addition-
ally we change the semantics of the network mask from an explicit mask
to be the number of bits (length) of the network mask. The major
impact of increasing the lengths of several of the fields is on the
link-state database's memory utilization. For larger networks there
may be some impact on IP fragmentation of OSPFv6 packets.
The OSPF protocol has mechanisms which allows an implementation to
manage the contents and size of the OSPF packets. That is, database
description, link-state request, link-state update and link-state ack-
nowledgement packets all include lists of entries so that an implemen-
tation can optimize the size of each of these packets.
Most OSPF packets travel a single hop. Hello, database description,
link-state request, link-state update and link-state acknowledgement
packets are sent on a single interface. At each router, link-state
update packets are disassembled into their constituent link-state
Coltun Expires June 1996 [Page 8]
Internet Draft OSPFv6 December 1995
advertisements which may be then flooded as part of a link-state
update packet originated by the receiving router. Since the MTU for
the media type associated with the interface is known (except in the
case of virtual interfaces), the packets can be optimized for the
interface's MTU.
In the case of virtual links, the path between virtual neighbors is
dynamically discovered so the packets may need to be fragmented by the
IP layer along the way. But unlike IPv4, fragmentation in IPv6 is
performed only by source nodes, not by the routers along a packet's
delivery path.
Needless to say that OSPF would break if it did not handle the MTU
correctly. It is reasonable to assume that for the OSPFv6 packets
traversing a virtual link that either 1) an MTU of 576 octets is
assumed by OSPF and used by the IP layer or 2) the "Path MTU Discovery
for IP version 6" [PMTU] protocol is run by the IP layer on area
border routers which are end points of a virtual link.
The following describes the modifications to the OSPF packet formats
to support IPv6 and the effects of extending the net/subnet address,
link-state ID, router ID and area ID fields from 32 to 128 bits. All
of the packets formats are described in detail in Appendix A.
4.1 The OSPF Packet Header
Every OSPF packet starts with a common header. This header contains
all the necessary information to determine whether the packet should
be accepted for further processing. The packet format has been modi-
fied so that the Router ID field and the Area ID field are increased
to 128 bits. The effect of this is that the packet header is now 48
octets and was 24 octets in OSPFv4. This extension contributes very
little to additional memory overhead of the implementation (as the
packet headers are not usually maintained in the database) and when
added to the extensions of the other OSPF packet formats this exten-
sion is a minor contributor to the need for IP fragmentation.
4.2 The Hello Packet
OSPF's Hello Protocol is responsible for establishing and maintaining
neighbor relationships. It also ensures that communication between
neighbors is bidirectional. Hello packets are sent periodically out
all router interfaces and include a list of the Router IDs of each
router from whom valid Hello packets have been seen recently on the
network. Bidirectional communication is indicated when the router
sees itself listed in the neighbor's Hello Packet. On multi-access
networks, the Hello Protocol elects a Designated Router for the net-
work.
The effect of extending the Area and Router IDs to 128 bits in the
Hello Packet is that the Hello Header is now 88 octets. Additionally,
each advertised neighbor (the Router ID) on the network is 16 octets
Coltun Expires June 1996 [Page 9]
Internet Draft OSPFv6 December 1995
so that at around 90 neighbors the Hello packet would be larger than
an Ethernet MTU. Although for most networks this is not an issue,
there are some networks that exceed this number of neighbors. This
extension only contributes to additional memory overhead of the imple-
mentation if the Hello Packets are maintained (a rare but not unthink-
able occurrence).
4.3 The Link-State Advertisement Header
All link-state advertisements begin with a common header. This header
contains enough information to uniquely identify the advertisement (LS
type, Link-State ID, and Advertising Router). This header is used in
database description packets, link-state advertisements and link-state
acknowledgement packets. The effects of extending the link-state ID
and the advertising router fields to 128 bits is that the link-state
header for OSPFv6 is 44 octets (was 20 octets for OSPFv4).
This clearly increases the memory requirements as the LSA headers are
stored in the link-state database for every link-state advertisement.
The effects on fragmentation are specific to the packet using the
link-state advertisement header.
4.4 The Database Description Packet
Database description packets are exchanged when an adjacency is being
initialized. They describe the contents of the topological database.
Multiple packets may be used to describe the database. Each database
description packet consists of the database description header and
after the initial master/slave determination is complete, a list of
link-state advertisement headers. The database description packet has
an explicit fragmentation mechanism so that an implementation should
build database description packets of the appropriate size (i.e., to
avoid IP fragmentation). Extending the link-state advertisement
header and the OSPF packet header contributes very little to addi-
tional memory overhead as database description packets are not usually
stored after being sent.
4.5 The Link-State Request Packet
Link-state request packets are used during the initial database
exchange process to request the pieces of the neighbor's database that
are more up to date than those held in the router's database. Multiple
link-state request packets may need to be used in the database
exchange. Sending of link-state request packets is the last step in
bringing up an adjacency.
Each link-state request packet includes a link-state request header
and a list of requested advertisements. The requested advertisements
are specified by an LS type, Link-State ID, and Advertising Router
which uniquely identifies the advertisement, but not its instance as
Link-State Request packets are understood to be requests for the most
Coltun Expires June 1996 [Page 10]
Internet Draft OSPFv6 December 1995
recent instance.
In OSPFv6 the link-state ID and advertising router fields are extend
to 128 bits. The link-state request packet has explicit fragmentation
mechanism so that an implementation should build link-state request
packets of the appropriate size (i.e., to avoid IP fragmentation).
This extension contributes little to additional memory overhead as
link-state request packets are not usually stored after being sent.
4.6 The Link-State Acknowledgment Packet
Link-State Acknowledgment Packets are used to make the flooding of
link-state advertisements reliable; flooded advertisements are expli-
citly acknowledged. This acknowledgment is accomplished through the
sending and receiving of Link-State Acknowledgment packets. Multiple
link-state advertisements can be acknowledged in a single Link-State
Acknowledgment packet.
The format of this packet is similar to that of the Data Description
packet. The body of both packets is simply a list of link-state adver-
tisement headers. The database acknowledgement packet has an explicit
fragmentation mechanism so that an implementation should build link-
state acknowledgement packets of the appropriate size (i.e., to avoid
IP fragmentation). Extending the link-state advertisement header and
the OSPF packet header contributes very little to additional memory
overhead as acknowledgement packets are not usually stored after being
sent.
4.7 The Link-State Update Packet
Link-State Update packets implement the flooding of link-state adver-
tisements. Each Link-State Update packet carries a collection of
link-state advertisements one hop further from its origin. Several
link-state advertisements may be included in a single packet. For
OSPFv6 the link-state ID field and advertising router field are 128
bits. Additionally, in the specific advertisements types (see below)
fields that represent network/subnet numbers, interface addresses or
router IDs are also 128 bits. Network mask fields (except for router
LSAs) need not increase since a mask in OSPFv6 is an integer which
represents the number of bits (length) of the network address mask.
It is clear that the memory requirements for the link-state database
for OSPFv6 is significantly greater than those for IPv4. Even though
the link-state update packets have explicit fragmentation mechanism
which allows an implementation to attempt to build link-state update
packets of the appropriate size to avoid IP fragmentation there are
issues that are specific to the link-state types that make it possible
for a specific link-state advertisement to be larger than the required
MTU. We now look at the issues unique to specific link-state adver-
tisement types.
Coltun Expires June 1996 [Page 11]
Internet Draft OSPFv6 December 1995
4.7.1 The Router LSA
Router link-state advertisements are originated by all routers. These
LSAs consist of a list of interfaces to the area which may be a
point-to-point connection to another router, a connections to a tran-
sit network, a connection to a stub network, or virtual links. Each of
these links includes the cost of the link. OSPF requires that all of
the router's links to the area must be described in a single router
LSA.
The link ID and link data fields are now 128 bits making each link 36
octets (as opposed to 12 octets for OSPFv4). A router having greater
than 40 links in its router LSA would exceed an Ethernet MTU.
4.7.2 The Network LSA
Network link-state advertisements are originated for multi-access net-
works by the Designated Router. This advertisement contains a list of
the router IDs for each of the routers attached to the network. Net-
work LSAs are flooded throughout a single area only. Since the OSPFv6
router IDs are 128 bits each link is 16 octets (as opposed to 4 octets
for OSPFv4). A transit network having greater than 90 routers
attached would exceed an Ethernet MTU. Although for most networks
this is not an issue, there are some networks that exceed this number
of neighbors.
4.7.3 Summary LSA
Summary link-state advertisements are the type-3 and type-4 link-state
advertisements. These advertisements are originated by area border
routers and sent into an area. A separate summary LSA is made for
each destination (known to the router) which belongs to the AS, yet is
outside the area.
Type 3 link-state advertisements are used when the destination is an
IP network. In this case the advertisement's link-state ID field is an
IPv6 network number and the Network Mask Length field is an integer
which represents the number of bits in the network number's mask.
When the destination is an AS boundary router, a type-4 advertisement
is used, the link-state ID field is the AS boundary router's OSPF
router ID and the Network Mask Length field is unused (i.e., set to
0).
Since the OSPFv6 Link-State IDs and Router IDs are 128 bits summary
link advertisements are 52 octets (as opposed to 28 octets for
OSPFv4); there are no fragmentation issues for summary link advertise-
ments.
4.7.4 The AS External LSA
AS external link-state advertisements are the type-5 link-state
Coltun Expires June 1996 [Page 12]
Internet Draft OSPFv6 December 1995
advertisements. These advertisements are originated by AS boundary
routers. A separate advertisement is made for each destination (known
to the router) which is external to the AS.
AS external link-state advertisements usually describe a particular
external destination. For these advertisements the Link-State ID field
specifies an IP network number. AS external link advertisements are
also used to describe a default route. Default routes are used when
no specific route exists to the destination. When describing a
default route, the link-state ID is always set to
IPv6DefaultDestination (0::0) and the Network Mask Length is set to 0.
The Link-State ID and Router ID and are 128 bits. OSPFv6 does not
include the forwarding address or the external route tag but does have
a 32-bit Opaque LSA Reference field (see Section 3.3.3 "External LSA
Forwarding Address And Route Tag").
The OSPFv6 AS external LSA is 56 octets (as opposed to 28 octets for
OSPFv4); there are no fragmentation issues for AS external link adver-
tisements.
Coltun Expires June 1996 [Page 13]
Internet Draft OSPFv6 December 1995
5.0 Protocol Packet Processing
This section discusses the general processing of OSPFv6 routing proto-
col packets. It is essentially section 8 of [OSPF] but includes the
specific checks for Instance ID.
It is very important that the router link-state databases remain syn-
chronized. For this reason, routing protocol packets should get pre-
ferential treatment over ordinary data packets, both in sending and
receiving.
Routing protocol packets are sent along adjacencies only (with the
exception of Hello packets, which are used to discover the adjacen-
cies). This means that all routing protocol packets travel a single
IP hop, except those sent over virtual links.
All routing protocol packets begin with a standard header. The sec-
tions below provide details on how to fill in and verify this standard
header. Then, for each packet type, the section giving more details
on that particular packet type's processing is listed.
5.1 Sending Protocol Packets
When a router sends a routing protocol packet, it fills in the fields
of the standard OSPF packet header as follows. For more details on
the header format consult Section A.3.1 of this document:
Version #
Set to 2, the version number of the protocol as documented
in this specification.
Packet type
The type of OSPF packet, such as a Link-State Update or
Hello Packet.
Packet Length
The length of the entire OSPF packet in octets, including
the standard OSPF packet header.
Router ID
The identity of the router itself (who is originating the
packet).
Area ID
The OSPF area that the packet is being sent into.
Instance ID
The OSPFv6 instance that is originating the packet. See
Section 3.4.2 of this document for more details.
AuType and Authentication
Each OSPF packet exchange is authenticated. Authentication
Coltun Expires June 1996 [Page 14]
Internet Draft OSPFv6 December 1995
types are assigned by the protocol and are documented in
Appendix D of [OSPF]. A different authentication procedure
can be used for each IP network/subnet. Autype indicates the
type of authentication procedure in use. The 64-bit authen-
tication field is then for use by the chosen authentication
procedure. This procedure should be the last called when
forming the packet to be sent. See Section D.4 of [OSPF] for
details.
The IPv6 destination address for the packet is selected as follows.
On physical point-to-point networks, the IPv6 destination is always
set to the address Allv6SPFRouters. On all other network types
(including virtual links), the majority of OSPF packets are sent as
unicasts, i.e., sent directly to the other end of the adjacency. In
this case, the IPv6 destination is just the Neighbor'ss IPv6 address
associated with the other end of the adjacency (see Section 10 of
[OSPF]). The only packets not sent as unicasts are on broadcast net-
works; on these networks Hello packets are sent to the multicast des-
tination Allv6SPFRouters, the Designated Router and its Backup send
both Link-State Update Packets and Link-State Acknowledgment Packets
to the multicast address Allv6SPFRouters, while all other routers send
both their Link-State Update and Link-State Acknowledgment Packets to
the multicast address Allv6DRouters.
Retransmissions of Link-State Update packets are ALWAYS sent as uni-
casts.
The IPv6 source address should be set to the IPv6 address of the send-
ing interface. Interfaces to unnumbered point-to-point networks have
no associated IPv6 address. On these interfaces, the IP source should
be set to any of the other IPv6 addresses belonging to the router. For
this reason, there must be at least one IPv6 address assigned to the
router. Note that, for most purposes, virtual links act precisely the
same as unnumbered point-to-point networks. However, each virtual link
does have an IPv6 interface address (discovered during the routing
table build process) which is used as the IP source when sending pack-
ets over the virtual link.
For more information on the format of specific OSPF packet types, con-
sult the sections listed in Table 1.
Type Packet name Detailed section (transmit)
_________________________________________________________
1 Hello Section 9.5 of [OSPF]
2 Database Description Section 10.8 of [OSPF]
3 Link-State Request Section 10.9 of [OSPF]
4 Link-State Update Section 13.3 of [OSPF]
5 Link-State Ack Section 13.5 of [OSPF]
Coltun Expires June 1996 [Page 15]
Internet Draft OSPFv6 December 1995
Table 1: Sections describing OSPF protocol packet transmission.
5.2 Receiving Protocol Packets
Whenever a protocol packet is received by the router it is marked with
the interface it was received on. For routers that have virtual links
configured, it may not be immediately obvious which interface to asso-
ciate the packet with. For example, consider the Router RT11 depicted
in Figure 6 of [OSPF]. 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 accepted at the IP level, it must pass a
number of tests, even before the packet is passed to appropriate OSPF
Instance for processing:
o The packet's IPv6 destination address must be the IPv6 address
of the receiving interface, or one of the IPv6 multicast
addresses Allv6SPFRouters or Allv6DRouters.
o The IP protocol specified must be OSPF (89).
o Locally originated packets should not be passed on to OSPF.
That is, the source IPv6 address should be examined to make sure
this is not a multicast packet that the router itself generated.
Next, the OSPF packet header is verified. The fields specified in the
header must match those configured for the receiving interface. If
they do not, the packet should be discarded:
o The version number field must specify protocol version 2.
o The Instance ID found in the OSPF header must match the
Instance ID of one of the OSPF instances bound to the receiving
interface. Upon locating the OSPF instance all protocol process-
ing of this packet will be associated with this OSPF instance.
If no OSPF instance is located the packet is discarded.
o The Area ID found in the OSPF header must be verified. If both
of the following cases fail, the packet should be discarded. The
Area ID specified in the header must either:
(1) Match the Area ID of the receiving OSPF interface. In this
case, the packet has been sent over a single hop. Therefore, the
packet's IPv6 source address is required to be on the same net-
work as the receiving interface. This can be verified by compar-
ing the packet's IPv6 source address to the OSPF interface's IPv6
address, after masking both addresses with the interface's net-
work mask. This comparison should not be performed on point-to-
point networks. On point-to-point networks, the interface
Coltun Expires June 1996 [Page 16]
Internet Draft OSPFv6 December 1995
addresses of each end of the link are assigned independently, if
they are assigned at all.
(2) Indicate the backbone. In this case, the packet has been sent
over a virtual link. The receiving router must be an area border
router, and the Router ID specified in the packet (the source
router) must be the other end of a configured virtual link. The
receiving OSPF interface must also attach to the virtual link's
configured Transit area. If all of these checks succeed, the
packet is accepted and is from now on associated with the virtual
link (and the backbone area).
o Packets whose IPv6 destination is Allv6DRouters should only be
accepted if the state of the receiving interface is DR or Backup
(see Section 9.1).
o The AuType specified in the packet must match the AuType speci-
fied for the associated area.
o The packet must be authenticated. The authentication procedure
is indicated by the setting of AuType (see Appendix D of [OSPF]).
The authentication procedure may use one or more Authentication
keys, which can be configured on a per- interface basis. The
authentication procedure may also verify the checksum field in
the OSPFv6 packet header (which, when used, is set to the stan-
dard IP 16-bit one's complement checksum of the OSPFv6 packet's
contents after excluding the 64-bit authentication field). If
the authentication procedure fails, the packet should be dis-
carded.
If the packet type is Hello, it should then be further processed by
the Hello Protocol (see Section 10.5 of [OSPF]). 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.
If the receiving interface connects to a broadcast network, Point-to-
MultiPoint network or NBMA network the sender is identified by the
IPv6 source address found in the packet's IPv6 header. If the receiv-
ing interface connects to a point-to-point network or a virtual link,
the sender is identified by the Router ID (source router) found in the
packet's OSPFv6 header. The data structure associated with the
receiving interface contains the list of active neighbors. Packets not
matching any active neighbor are discarded.
At this point all received protocol packets are associated with an
active neighbor. For the further input processing of specific packet
types, consult the sections listed in Table 2.
Type Packet name Detailed section (receive)
________________________________________________________
1 Hello Section 10.5 of [OSPF]
2 Database description Section 10.6 of [OSPF]
3 Link-state request Section 10.7 of [OSPF]
Coltun Expires June 1996 [Page 17]
Internet Draft OSPFv6 December 1995
4 Link-state update Section 13 of [OSPF]
5 Link-state ack Section 13.7 of [OSPF]
Table 2: Sections describing OSPF protocol packet reception.
Coltun Expires June 1996 [Page 18]
Internet Draft OSPFv6 December 1995
6.0 Opaque LSAs
Opaque LSAs are the Type 15 link-state advertisements. These adver-
tisements are originated by any router and may be used directly by
OSPFv6 as well as to provide for future extensibility. The Opaque LSA
may also be used by other protocols such as BGP wishing to distribute
information throughout the OSPFv6 domain. This information isn't used
directly by OSPFv6.
The contents of the Opaque LSA is some number of octets padded to 32-
bit alignment. Like any other LSA, the Opaque LSA uses the link-state
database distribution mechanism for flooding this information
throughout the topology. Flooding Scope identifies the range of the
topology to which this LSA may be distributed to. The following
denotes the possible values of the Flooding Scope field.
o A value of 0 denotes a link-local scope. Opaque LSAs with a
Flooding Scope of 0 are not flooded beyond the local
(sub)network.
o A value of 1 denotes an area-local scope. Opaque LSAs with a
flooding scope of 1 are not flooded beyond the area that they are
originated into.
o A value of 2 denotes that the LSA is flooded throughout (but
not beyond) the routing domain. That is the information contained
within these LSAs will not be distributed to any protocols beyond
OSPFv6.
o A value of 3 or greater denotes distribution throughout as well
as beyond the routing domain.
Origination of Opaque LSAs are unique to the application using it.
OSPFv6 used the Opaque LSA as a replacement for OSPFv4's external
LSA's forwarding address and route tag as explained in section 3.3.3
above.
The link-state ID of the Opaque LSA is divided into a type field (the
first 32 bits) a type-specific ID (the second 32-bit field) and a
reserved field (the remaining 64 bits). The packet format of the AS
External Reference Opaque LSA is given in section A.4.6.1 of this
document.
The responsibility of proper handling of the Opaque LSA's Flooding
Scope field is both on the sender and receiver. The receiver must
always store a valid received Opaque LSA in its link-state database.
Flooding scope effects both the building of the Database summary list
during the initial synchronization of the link-state database and the
flooding procedure. The following describes the modifications to
these procedures necessary for insuring proper use of the Opaque LSA's
Scoping Rules.
Coltun Expires June 1996 [Page 19]
Internet Draft OSPFv6 December 1995
6.1 Modifications To The Neighbor State Machine
The state machine as it exists in section 10.3 of [OSPF] remains
unchanged except for the action associated with State: ExStart, Event:
NegotiationDone which is where the Database summary list is built. To
incorporate the Opaque LSA in OSPFv6 the action is changed to the fol-
lowing.
State(s): ExStart
Event: NegotiationDone
New state: Exchange
Action: The router must list the contents of its entire area
link-state database in the neighbor Database summary
list. The area link-state database consists of the
Router LSAs, Network LSAs and Summary LSAs
contained in the area structure, along with Opaque and
AS External LSAs contained in the global structure.
AS External LSAs are omitted from a
virtual neighbor's Database summary list. AS
External LSAs are omitted from the Database
summary list if the area has been configured
as a stub (see Section 3.6 of [OSPF]).
Opaque LSAs are omitted from the from
the Database summary list if the following conditions
are met: 1) the Flooding Scope is link-local
and the interface address and mask in the Opaque
LSA does not equal the interface address and mask
found in the neighbor's interface; 2) the Flooding Scope
is area-local and the area associated with Opaque LSA
is not the area associated with the neighbor's interface,
see Appendix A.4.6 of this document.
Any advertisement whose age is equal to MaxAge is
omitted from the Database summary list. It is
instead added to the neighbor's link-state
retransmission list. A summary of the Database
summary list will be sent to the neighbor in
Database Description packets. Each Database
Description Packet has a DD sequence number, and is
explicitly acknowledged. Only one Database
Description Packet is allowed outstanding at any one
time. For more detail on the sending and receiving
of Database Description packets, see Sections 10.8
and 10.6 of [OSPF].
6.2 Modifications To The Flooding Procedures
Coltun Expires June 1996 [Page 20]
Internet Draft OSPFv6 December 1995
The flooding of Opaque LSAs must follow the rules of Flooding Scope as
denoted in this section. The flooding mechanisms must therefore
suppress the flooding of Opaque LSAs as follows.
o If the Flooding Scope is link-local and the interface address
and mask in the Opaque advertisement does not equal the address
and mask found in the neighbor's interface the Opaque LSA must
not be flooded out or received by the interface.
o If the Flooding Scope is area-local and the area associated
with Opaque LSA is not the area associated with the neighbor's
interface the Opaque LSA must not be flooded out the interface.
The Flooding Scope rules affect Section 13 ("The Flooding Procedure")
in [OSPF].
Coltun Expires June 1996 [Page 21]
Internet Draft OSPFv6 December 1995
7.0 AS External Routes
7.1 Origination Of AS External Reference Opaque LSA
As explained in Section 3.3.3 of this document the formats of the AS
External LSA has changed. Instead of embedding the Forwarding Address
and the Route Tag in the external LSA, the external LSA has an Opaque
LSA Reference field. This field "references" an Opaque LSA containing
a Forwarding Address and information that was previously stored in the
Route Tag. OSPFv6 therefore must maintain a list of unique <Forward-
ing Address, Route Tag> pairs and a 32-bit identifier for each of
these pairs. (Since the goal of the Opaque LSA is to reduce the size
of the link-state database, a single Opaque LSA should be originated
containing a unique <Forwarding Address, Route Tag>.) AS boundary
routers originating AS External LSAs that require either a Forwarding
Address or Route Tag information, must originate Opaque LSAs which are
referenced in the Opaque LSA Reference field of the AS External LSA.
(see Appendix A.4.6.2 for the format of the AS External Reference
Opaque LSA).
7.2 Calculating AS External Routes
For performing routing table calculations on AS External LSAs, there
is an extra level of indirection needed so that a router 1) must have
a valid path to the originator of the AS External route; 2) locate the
referenced Opaque LSA in its link-state database and 3) validate the
forwarding address contained in the Opaque LSA before it adds it con-
siders the AS External route valid.
To accommodate the changes to the AS External LSA packet format, the
following replaces 16.4 of [OSPF].
AS external routes are calculated by examining AS external LSAs. Each
of the AS external LSAs is considered in turn. Most AS external LSAs
describe routes to specific IP destinations. An AS external LSAs can
also describe a default route for the Autonomous System (Destination
ID = 0::0, subnet mask length = 0). For each AS external link adver-
tisement:
(1) If the cost specified by the advertisement is LSInfinity, or
if the advertisement's LS age is equal to MaxAge, then examine
the next advertisement.
(2) If the advertisement was originated by the calculating router
itself, examine the next advertisement.
(3) Call the destination described by the advertisement N. N's
address is obtained by masking the advertisement's Link-State ID
with the network/subnet mask which is referenced by the network
Mask Length Field (i.e., the length of the network mask in bits)
in the advertisement. Look up the routing table entry for the AS
boundary router (ASBR) that originated the advertisement. If no
Coltun Expires June 1996 [Page 22]
Internet Draft OSPFv6 December 1995
entry exists for router ASBR (i.e., ASBR is unreachable), do
nothing with this advertisement and consider the next in the
list.
Else, this advertisement describes an AS external path to desti-
nation N. Examine the Opaque LSA Reference field in the AS
External LSA. If the field is set to 0x00000000 packets should
be set to the ASBR itself. Otherwise look up the Opaque LSA in
the link-state database. The Opaque LSA was originated by the AS
boundary router that originated the external advertisement. The
Link-State ID of Opaque LSA is <1, Opaque ID Reference, 0, 0>
(see Appendix A.4.6.2 for the format of the AS External Reference
Opaque LSA).
Examine the forwarding address specified in the Opaque LSA. This
indicates the IP address to which packets for the destination
should be forwarded. If the forwarding address is set to 0::0,
packets should be sent to the ASBR itself. Otherwise, look up the
forwarding address in the routing table. An intra-area or inter-
area path must exist to the forwarding address. If no such path
exists, do nothing with the advertisement and consider the next
in the list.
Call the routing table distance to the forwarding address X (when
the forwarding address is set to 0::0, this is the distance to
the ASBR itself), and the cost specified in the advertisement Y.
X is in terms of the link-state metric, and Y is a type 1 or 2
external metric.
(4) Next, look up the routing table entry for the destination N.
If no entry exists for N, install the AS external path to N, with
next hop equal to the list of next hops to the forwarding
address, and advertising router equal to ASBR. If the external
metric type is 1, then the path-type is set to type 1 external
and the cost is equal to X+Y. If the external metric type is 2,
the path-type is set to type 2 external, the link-state component
of the route's cost is X, and the type 2 cost is Y.
(5) Else, if the paths present in the table are not type 1 or
type 2 external paths, do nothing (AS external paths have the
lowest priority).
(6) Otherwise, compare the cost of this new AS external path to
the ones present in the table. Type 1 external paths are always
shorter than type 2 external paths. Type 1 external paths are
compared by looking at the sum of the distance to the forwarding
address and the advertised type 1 metric (X+Y). Type 2 external
paths are compared by looking at the advertised type 2 metrics,
and then if necessary, the distance to the forwarding addresses.
If the new path is shorter, it replaces the present paths in the
routing table entry. If the new path is the same cost, it is
added to the routing table entry's list of paths.
Coltun Expires June 1996 [Page 23]
Internet Draft OSPFv6 December 1995
8.0 References
[OSPF] Moy, J., "OSPF Version 2", IETF Internet Draft,
Cascade, November 1995.
[IPV6] Deering, S., Hinden, R., "Internet Protocol,
Version 6 (IPv6) Specification", IETF Internet
Draft, Xerox PARC, Ipsilon, June 1995
[IPV6ADDR] Hinden, R., Deering, S., "IP Version 6
Addressing Architecture", IETF Internet Draft
Xerox PARC, Ipsilon, June 1995
[BGPOSPF] Varadhan, K., Hares, S., Rekhter, Y., "BGP4/IDRP
for IP---OSPF Interaction", RFC1745, December 1994
[CIDR] Fuller, V., T. Li, J. Yu, and K. Varadhan, "Classless Inter-
Domain Routing (CIDR): an Address Assignment and Aggregation
Strategy", RFC1519, BARRNet, cisco, MERIT, OARnet, September
1993.
[IDRP] Kunzinger, C., Editor, "INTER-DOMAIN ROUTING PROTOCOL
(IDRP)", IETF Internet Draft version of ISO10747,
IBM Corp., June 1995
[PMTU] McCann, J., Deering, S., "Path MTU Discovery for IP version 6",
IETF Internet Draft, Digital Equipment Corporation, Xerox PARC,
November 6, 1995
[MOPSPF] Moy, J., "Multicast Extensions to OSPF", RFC 1584, Proteon,
Inc., March 1994.
[NSSA] Coltun, R. and V. Fuller, "The OSPF NSSA Option", RFC 1587,
RainbowBridge Communications, Stanford University, March 1994.
[DEMD] Moy, J., "Extending OSPF to Support Demand Circuits", RFC 1793,
Cascade, April 1995.
Coltun Expires June 1996 [Page 24]
Internet Draft OSPFv6 December 1995
Appendix A: OSPFv6 Data formats
This appendix describes the format of OSPFv6 protocol packets and
OSPFv6 link-state advertisements. The OSPFv6 protocol runs directly
over the IP version 6 network layer. Before any data formats are
described, the details of the OSPFv6 encapsulation are explained.
Next the OSPFv6 Options field is described. This field describes vari-
ous capabilities that may or may not be supported by pieces of the
OSPFv6 routing domain. The OSPFv6 Options field is contained in OSPFv6
Hello packets, Database Description packets and in OSPFv6 link-state
advertisements.
OSPFv6 packet formats are detailed in Section A.3. A description of
OSPFv6 link-state advertisements appears in Section A.4.
A.1 Encapsulation Of OSPFv6 Packets
OSPFv6 runs directly over the Internet Protocol's version 6 network
layer. OSPFv6 packets are therefore encapsulated solely by IPv6 and
local data-link headers.
OSPFv6 does not define a way to fragment its protocol packets, and
depends on IPv6 fragmentation when transmitting packets larger than
the network MTU. The OSPFv6 packet types that are likely to be large
(Database Description Packets, Link-State Request, Link-State Update,
and Link-State Acknowledgment packets) can usually be split into
several separate protocol packets, without loss of functionality.
This is recommended; IPv6 fragmentation should be avoided whenever
possible. Using this reasoning, an attempt should be made to limit the
sizes of packets sent over virtual links to 576 octets. Alternately,
OSPFv6 routers may run "Path MTU Discovery for IP version 6" [PMTU]
between virtual neighbors so as to discover the optimal size path MTU
between the virtual neighbors. However, if necessary, the length of
OSPF packets can be up to 65,535 octets (including the IPv6 header).
The other important features of OSPFv6's IP encapsulation are:
o Use of IP multicast. Some OSPFv6 messages are multicast, when sent
over broadcast networks. Two distinct IPv6 multicast addresses are
used. Packets sent to these multicast addresses should never be for-
warded; they are meant to travel a single hop only. To ensure that
these packets will not travel multiple hops, their IPv6 Hop Limit must
be set to 1.
Allv6SPFRouters
For IPv6 this multicast address has been assigned the value
FF02:0:0:0:0:0:0:5 (which has a link-local scope). All routers
running OSPFv6 should be prepared to receive packets sent to this
address. Hello packets are always sent to this destination.
Also, certain OSPFv6 protocol packets are sent to this address
during the flooding procedure.
Coltun Expires June 1996 [Page 25]
Internet Draft OSPFv6 December 1995
Allv6DRouters
This multicast address has been assigned the value
FF02:0:0:0:0:0:0:6 (which has a link-local scope). Both the
Designated Router and Backup Designated Router must be prepared
to receive packets destined to this address. Certain OSPFv6 pro-
tocol packets are sent to this address during the flooding pro-
cedure.
o OSPFv6 is IPv6 protocol number 89. This number has been registered
with the Network Information Center. IP protocol number assignments
are documented in [11].
o Routing protocol packets are sent with IPv6 Priority of 7 (internet
control traffic).
o Routing protocol packets are sent with IPv6 Priority of Internet
Control Traffic (type 7). OSPFv6 protocol packets should be given
precedence over regular IPv6 data traffic, in both sending and receiv-
ing. Setting the IPv6 Priority field in the IPv6 header to Internet-
work Control Traffic may help implement this objective.
Coltun Expires June 1996 [Page 26]
Internet Draft OSPFv6 December 1995
A.2 The Options Field
The OSPFv6 Options field is present in OSPFv6 Hello packets, Database
Description packets and all link-state advertisements. The Options
field enables OSPFv6 routers to support (or not support) optional
capabilities, and to communicate their capability level to other
OSPFv6 routers. Through this mechanism routers of differing capabili-
ties can be mixed within an OSPFv6 routing domain.
When used in Hello packets, the Options field allows a router to
reject a neighbor because of a capability mismatch. Alternatively,
when capabilities are exchanged in Database Description packets a
router can choose not to forward certain link-state advertisements to
a neighbor because of its reduced functionality. Lastly, listing
capabilities in link-state advertisements allows routers to forward
traffic around reduced functionality routers, by excluding them from
parts of the routing table calculation.
Six bits of the OSPFv6 Options field have been assigned, although only
two (the T-bit and E-bit) are described completely by this memo. 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 link-state adver-
tisements. Conversely, routers encountering unrecognized Option bits
in received Hello Packets, Database Description packets or link-state
advertisements should ignore the capability and process the
packet/advertisement normally.
+------------------------------------+
| * | * | DC | * | N/P | MC | E | T |
+------------------------------------+
The Options Field
R-bit
This bit is reserved for future TOS/QOS capability definitions.
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 [OSPF].
MC-bit
This bit describes whether IP multicast datagrams are forwarded
according to the specifications in [MOSPF].
N/P-bit
This bit describes the handling of Type-7 LSAs, as specified in
[NSSA].
DC-bit
This bit describes the router's handling of demand circuits, as
Coltun Expires June 1996 [Page 27]
Internet Draft OSPFv6 December 1995
specified in [DEMD].
Coltun Expires June 1996 [Page 28]
Internet Draft OSPFv6 December 1995
A.3 OSPFv6 Packet Formats
There are five distinct OSPFv6 packet types. All OSPFv6 packet types
begin with a standard 24-octets header. This header is described
first. Each packet type is then described in a succeeding section.
In these sections each packet's division into fields is displayed, and
then the field definitions are enumerated.
All OSPFv6 packet types (other than the OSPFv6 Hello packets) deal
with lists of link-state advertisements. For example, Link-State
Update packets implement the flooding of advertisements throughout the
OSPFv6 routing domain. Because of this, OSPFv6 protocol packets cannot
be parsed unless the format of link-state advertisements is also
understood. The format of the link-state advertisements packet is
given in Section A.4. The receive processing of OSPFv6 packets is
detailed in Section 5.2 of this document. The sending of OSPFv6 pack-
ets is explained in Section 5.1 of this document.
A.3.1 The OSPFv6 Packet Header
Every OSPFv6 packet starts with a standard 48-octet header. This
header contains all the information necessary to determine whether the
packet should be accepted for further processing. This determination
is described in Section 5.0 of this document.
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 | AuType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Authentication +
| |
Coltun Expires June 1996 [Page 29]
Internet Draft OSPFv6 December 1995
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version #
The OSPFv6 version number. This specification documents version 2
of the protocol.
Type
The OSPF packet types are as follows. See Sections A.3.2 through
A.3.6 for details.
Type Description
________________________________
1 Hello
2 Database Description
3 Link-State Request
4 Link-State Update
5 Link-State Acknowledgment
Packet Length
The length of the OSPFv6 protocol packet in octets. This length
includes the standard OSPFv6 header.
Router ID
The Router ID of the packet's source.
Area ID
A 128-bit number identifying the area that this packet belongs
to. All OSPFv6 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::0.
Checksum
The standard IP checksum of the entire contents of the packet,
starting with the OSPFv6 packet header but excluding the 64-bit
authentication field. This checksum is calculated as the 16-bit
one's complement of the one's complement sum of all the 16-bit
words in the packet, excepting the authentication field. If the
packet's length is not an integral number of 16-bit words, the
packet is padded with an octet of zero before checksumming. The
checksum is considered to be part of the packet authentication
procedure; for some authentication types the checksum calculation
is omitted.
Instance ID
This is a 8-bit number that uniquely identifies the OSPFv6
Instance (or process) within the router that will be accepting
Coltun Expires June 1996 [Page 30]
Internet Draft OSPFv6 December 1995
this packet. The Instance ID was added to OSPFv6 to facilitate
identifying a particular OSPFv6 Instance by network management
(to identify the particular instance to be managed) and by the
OSPFv6 send and receive functions (to identify packet's target
OSPFv6 instance). See Section 3.4.2 and Section 5 of this docu-
ment for further details.
AuType
Identifies the authentication procedure to be used for the
packet. Authentication is discussed in Appendix D of [OSPF].
Consult Appendix D of [OSPF] for a list of the currently defined
authentication types.
Authentication
A 64-bit field for use by the authentication scheme. See Appendix
D of the [OSPF] for details.
Coltun Expires June 1996 [Page 31]
Internet Draft OSPFv6 December 1995
A.3.2 The Hello Packet
Hello packets are OSPFv6 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 physical networks having a multicast or
broadcast capability, enabling dynamic discovery of neighboring
routers.
All routers connected to a common network must agree on certain param-
eters (Network mask, HelloInterval and RouterDeadInterval). These
parameters are included in Hello packets, so that differences can
inhibit the forming of neighbor relationships. A detailed explanation
of the receive processing for Hello packets is presented in Section
10.5 of [OSPF]. The sending of Hello packets is covered in Section
9.5 of [OSPF].
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 # | 1 | Packet Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Router ID +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Area ID +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Instance ID | AuType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Authentication +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Mask Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HelloInterval | Options | Rtr Pri |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RouterDeadInterval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
Coltun Expires June 1996 [Page 32]
Internet Draft OSPFv6 December 1995
+ Designated Router +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Backup Designated Router +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Neighbor +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
Network Mask Length
The length in bits of the network mask associated with this
interface. Unlike OSPFv4 the network mask length for OSPFv6 is
an integer representing the number of bits in the mask. For exam-
ple, if the interface address is 1080:0:0:0:8:800:200C:417A and
the network mask is FFFF:FFFF:FFFF:FFFF:FFFF:0:0:0 the Network
Mask Length field is 80.
Options
The optional capabilities supported by the router, as documented
in Appendix A.2 of this document.
HelloInterval
The number of seconds between this router's Hello packets.
Rtr Pri
This router's Router Priority as used in the (Backup) Designated
Router election. If set to 0, the router will be ineligible to
become (Backup) Designated Router.
RouterDeadInterval
The number of seconds before declaring a silent router down.
Designated Router
The identity of the Designated Router for this network, in the
view of the sending router. The Designated Router is identified
here by its IP interface address on the network. Set to 0::0 if
there is no Designated Router.
Coltun Expires June 1996 [Page 33]
Internet Draft OSPFv6 December 1995
Backup Designated Router
The identity of the Backup Designated Router for this network, in
the view of the sending router. The Backup Designated Router is
identified here by its IP interface address on the network. Set
to 0::0 if there is no Backup Designated Router.
Neighbor
The Router IDs of each router from whom valid Hello packets have
been seen recently on the network. Recently means in the last
RouterDeadInterval seconds.
Coltun Expires June 1996 [Page 34]
Internet Draft OSPFv6 December 1995
A.3.3 The Database Description Packet
Database Description packets are OSPFv6 packet type 2. These packets
are exchanged when an adjacency is being initialized. They describe
the contents of the link-state database. Multiple packets may be used
to describe the database. For this purpose a poll-response procedure
is used. One of the routers is designated to be the master, the other
the slave. The master sends Database Description packets (polls)
which are acknowledged by Database Description packets sent by the
slave (responses). The responses are linked to the polls via the
packets' DD sequence numbers.
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 # | 2 | Packet Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Router ID +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Area ID +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Instance ID | AuType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Authentication +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 0 | Options |0|0|0|0|0|I|M|MS
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DD sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- -+
| A |
+- Link-State Advertisement -+
| Header |
+- -+
| |
+- -+
| |
Coltun Expires June 1996 [Page 35]
Internet Draft OSPFv6 December 1995
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
The format of the Database Description packet is very similar to both
the Link-State Request and Link-State Acknowledgment packets. The
main part of all three is a list of items, each item describing a
piece of the link-state database. The sending of Database Description
Packets is documented in Section 10.8 of [OSPF]. The reception of
Database Description packets is documented in Section 10.6 of [OSPF].
0 These fields are reserved. They must be 0.
Options
The optional capabilities supported by the router, as documented
in Section A.2 of this document.
I-bit
The Init bit. When set to 1, this packet is the first in the
sequence of Database Description Packets.
M-bit
The More bit. When set to 1, it indicates that more Database
Description Packets are to follow.
MS-bit
The Master/Slave bit. When set to 1, it indicates that the
router is the master during the Database Exchange process. Oth-
erwise, the router is the slave.
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 com-
plete database description has been sent.
The rest of the packet consists of a (possibly partial) list of the
link-state database's pieces. Each link-state advertisement in the
database is described by its link-state advertisement header. The
link-state advertisement header is documented in Section A.4.1. It
contains all the information required to uniquely identify both the
advertisement and the advertisement's current instance.
Coltun Expires June 1996 [Page 36]
Internet Draft OSPFv6 December 1995
A.3.4 The Link-State Request Packet
Link-State Request packets are OSPFv6 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.
A router that sends a Link-State Request packet has in mind the pre-
cise instance of the database pieces it is requesting. Each instance
is defined by its LS sequence number, LS checksum, and LS age,
although these fields are not specified in the Link-State Request
Packet itself. The router may receive even more recent instances in
response.
The sending of Link-State Request packets is documented in Section
10.9 of the [OSPF]. The reception of Link-State Request packets is
documented in Section 10.7 of [OSPF].
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 # | 3 | Packet Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Router ID +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Area ID +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Instance ID | AuType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Authentication +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link-State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
Coltun Expires June 1996 [Page 37]
Internet Draft OSPFv6 December 1995
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
Each advertisement requested is specified by its LS type, Link-State
ID, and Advertising Router. This uniquely identifies the advertise-
ment, but not its instance. Link-State Request packets are understood
to be requests for the most recent instance (whatever that might be).
Coltun Expires June 1996 [Page 38]
Internet Draft OSPFv6 December 1995
A.3.5 The Link-State Update Packet
Link-State Update packets are OSPFv6 packet type 4. These packets
implement the flooding of link-state advertisements. Each Link-State
Update packet carries a collection of link-state advertisements one
hop further from their origin. Several link-state advertisements may
be included in a single packet.
Link-State Update packets are multicast on those physical networks
that support multicast/broadcast. In order to make the flooding pro-
cedure reliable, flooded advertisements are acknowledged in Link-State
Acknowledgment packets. If retransmission of certain advertisements
is necessary, the retransmitted advertisements are always carried by
unicast Link-State Update packets. For more information on the reli-
able flooding of link-state advertisements, consult Section 13 of
[OSPF].
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 # | 4 | Packet Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Router ID +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Area ID +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Instance ID | AuType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Authentication +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # advertisements |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- +-+
| Link-State Advertisements |
+- +-+
| ... |
Coltun Expires June 1996 [Page 39]
Internet Draft OSPFv6 December 1995
# advertisements
The number of link-state advertisements included in this update.
The body of the Link-State Update packet consists of a list of link-
state advertisements. Each advertisement begins with a common 44-
octet header, described in Section A.4.1. Detailed formats of the dif-
ferent types of link-state advertisements are described in Section
A.4.
Coltun Expires June 1996 [Page 40]
Internet Draft OSPFv6 December 1995
A.3.6 The Link-State Acknowledgment Packet
Link-State Acknowledgment Packets are OSPFv6 packet type 5. To make
the flooding of link-state advertisements reliable, flooded advertise-
ments are explicitly acknowledged. This acknowledgment is accomplished
through the sending and receiving of Link-State Acknowledgment pack-
ets. Multiple link-state advertisements can be acknowledged in a sin-
gle Link-State Acknowledgment packet.
Depending on the state of the sending interface and the sender of the
corresponding Link-State Update packet, a Link-State Acknowledgment
packet is sent either to the multicast address Allv6SPFRouters, to the
multicast address Allv6DRouters, or as a unicast. The sending of
Link-State Acknowledgement packets is documented in Section 13.5 of
[OSPF]. The reception of Link-State Acknowledgement packets is docu-
mented in Section 13.7 of [OSPF].
The format of this packet is similar to that of the Data Description
packet. The body of both packets is simply a list of link-state
advertisement headers.
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 # | 5 | Packet Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Router ID +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Area ID +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Instance ID | AuType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Authentication +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- -+
| |
+- -+
Coltun Expires June 1996 [Page 41]
Internet Draft OSPFv6 December 1995
| |
+- -+
| |
+- -+
| A |
+- Link-State Advertisement -+
| Header |
+- -+
| |
+- -+
| |
+- -+
| |
+- -+
| |
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
Each acknowledged link-state advertisement is described by its link-
state advertisement header. The link-state advertisement header is
documented in Section A.4.1 of this document. It contains all the
information required to uniquely identify both the advertisement and
the advertisement's current instance.
Coltun Expires June 1996 [Page 42]
Internet Draft OSPFv6 December 1995
A.4 Link-State Advertisement (LSA) Formats
This memo defines five distinct types of link-state advertisements.
Each link-state advertisement begins with a standard 44-octet link-
state advertisement header. This header is explained in Section A.4.1
of this document. Succeeding sections then diagram the separate
link-state advertisement types.
Each link-state advertisement describes a piece of the OSPFv6 routing
domain. Every router originates a router LSA. In addition, whenever
the router is elected Designated Router, it originates a network LSA.
Other types of link-state advertisements may also be originated (see
Section 12.4 of [OSPF]). All link-state advertisements are then
flooded throughout the OSPFv6 routing domain. The flooding algorithm
is reliable, ensuring that all routers have the same collection of
link-state advertisements. (See Section 13 of [OSPF] for more infor-
mation concerning the flooding algorithm). This collection of adver-
tisements is called the link-state database.
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 [OSPF]). For the details of the routing table build process, see
Section 16 of [OSPF].
A.4.1 The Link-State Advertisement Header
All link-state advertisements begin with a common 44-octet header.
This header contains enough information to uniquely identify the
advertisement (LS type, Link-State ID, and Advertising Router). Mul-
tiple instances of the link-state advertisement may exist in the rout-
ing 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 link-state advertisement 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age | Options | LS type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Link-State ID +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
Coltun Expires June 1996 [Page 43]
Internet Draft OSPFv6 December 1995
+ Advertising Router +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LS age
The time in seconds since the link-state advertisement was ori-
ginated.
Options
The optional capabilities supported by the described portion of
the routing domain. OSPFv6's optional capabilities are docu-
mented in Section A.2 of this document.
LS type
The type of the link-state advertisement. Each link-state type
has a separate advertisement format. The link-state types
defined in this memo are as follows (see Section 12.1.3 of [OSPF]
for further explanation):
LS Type Description
___________________________________
1 Router LSA
2 Network LSA
3 Summary LSA (IP network)
4 Summary LSA (ASBR)
5 AS External LSA
15 Opaque LSA
Link-State ID
This field identifies the portion of the internet environment
that is being described by the advertisement. The contents of
this field depend on the advertisement's LS type. For example,
in network LSAs the Link-State ID is set to the IPv6 interface
address of the network's Designated Router (from which the
network's IP address can be derived). The Link-State ID is
further discussed in Section 12.1.4 in [OSPF].
Advertising Router
The Router ID of the router that originated the link-state adver-
tisement. For example, in network LSAs this field is equal to the
Coltun Expires June 1996 [Page 44]
Internet Draft OSPFv6 December 1995
Router ID of the network's Designated Router.
LS sequence number
Detects old or duplicate link-state advertisements. Successive
instances of a link-state advertisement are given successive LS
sequence numbers. See Section 12.1.6 of [OSPF] for more details.
LS checksum
The Fletcher checksum of the complete contents of the link-state
advertisement, including the link-state advertisement header but
excluding the LS age field. See Section 12.1.7 of [OSPF] for more
details.
Length
The length in octets of the link-state advertisement. This
includes the 44-octet link-state advertisement header.
Coltun Expires June 1996 [Page 45]
Internet Draft OSPFv6 December 1995
A.4.2 Router LSA
Router LSAs are the Type 1 link-state advertisements. Each router in
an area originates a router LSA. The advertisement describes the
state and cost of the router's links (i.e., interfaces) to the area.
All of the router's links to the area must be described in a single
router LSA. For details concerning the construction of router LSAs,
see Section 12.4.1 of [OSPF].
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 | Options | 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Link-State ID +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Advertising Router +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |V|E|B| 0 | # links |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Link ID +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Link Data +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Reserved | Metric |
Coltun Expires June 1996 [Page 46]
Internet Draft OSPFv6 December 1995
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
In router LSAs, the Link-State ID field is set to the router's OSPFv6
Router ID. Router LSAs are flooded throughout a single area only.
bit V
When set, the router is an endpoint of an active virtual link
that is using the described area as a Transit area (V is for vir-
tual link endpoint).
bit E
When set, the router is an AS boundary router (E is for exter-
nal).
bit B
When set, the router is an area border router (B is for border).
# links
The number of router links described in this advertisement. This
must be the total collection of router links (i.e., interfaces)
to the area.
The following fields are used to describe each router link (i.e.,
interface). Each router link is typed (see the below Type field). The
Type field indicates the kind of link being described. It may be a
link to a transit network, to another router or to a stub network.
The values of all the other fields describing a router link depend on
the link's Type. For example, each link has an associated 128-bit
Link Data field. For links to stub networks this field specifies the
length of the network's IP address mask. For other link types the
Link Data field specifies the router interface's IP address. When the
Link Data field is the IP address mask length, the first 32-bit field
is treated as an integer which contains the length in bits of the
mask.
Type
A quick description of the router link. One of the following.
Note that host routes are classified as links to stub networks
with network mask length of 128.
Type Description
__________________________________________________
1 Point-to-point connection to another router
2 Connection to a transit network
3 Connection to a stub network
4 Virtual link
Coltun Expires June 1996 [Page 47]
Internet Draft OSPFv6 December 1995
Link ID
Identifies the object that this router link connects to. Value
depends on the link's Type. When connecting to an object that
also originates a link-state advertisement (i.e., another router
or a transit network) the Link ID is equal to the neighboring
advertisement's Link-State ID. This provides the key for looking
up the neighboring advertisement in the link-state database dur-
ing the routing table calculation. See Section 12.2 of [OSPF] for
more details.
Type Link ID
______________________________________
1 Neighboring router's Router ID
2 IP address of Designated Router
3 IP network/subnet number
4 Neighboring router's Router ID
Link Data
Value again depends on the link's Type field. For connections to
stub networks, Link Data specifies the bit-length of the
network's IPv6 address mask. For unnumbered point-to-point con-
nections, it specifies (in the first 32-bit field) the
interface's MIB-II [8] ifIndex value. For the other link types
it specifies the router interface's IP address. This latter
piece of information is needed during the routing table build
process, when calculating the IP address of the next hop. See
Section 16.1.1 of [OSPF] for more details.
Reserved
Currently unused.
Metric
The cost of using this outbound router link.
Coltun Expires June 1996 [Page 48]
Internet Draft OSPFv6 December 1995
A.4.3 Network LSA
Network LSAs are the Type 2 link-state advertisements. A network LSA
is originated for each broadcast and NBMA network in the area which
supports two or more routers. The network LSA is originated by the
network's Designated Router. The advertisement describes all routers
attached to the network, including the Designated Router itself. The
advertisement's Link-State ID field lists the IP interface address of
the Designated Router.
The distance from the network to all attached routers is zero. For
details concerning the construction of network LSAs, see Section
12.4.2 of [OSPF].
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 | Options | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Link-State ID +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Advertising Router +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Mask Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Attached Router +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
Coltun Expires June 1996 [Page 49]
Internet Draft OSPFv6 December 1995
Network Mask Length
The length in bits of the network mask associated with this
interface. Unlike OSPFv4 the network mask length for OSPFv6 is
an integer representing the number of bits in the mask. For exam-
ple, if the interface address is 1080:0:0:0:8:800:200C:417A and
the network mask is FFFF:FFFF:FFFF:FFFF:FFFF:0:0:0 the Network
Mask Length field is 80.
Attached Router
The Router IDs of each of the routers attached to the network.
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 link-state advertisement header's length field.
Coltun Expires June 1996 [Page 50]
Internet Draft OSPFv6 December 1995
A.4.4 Summary LSA
Summary LSA are the Type 3 and 4 link-state advertisements. These
advertisements are originated by area border routers. Summary link
advertisements describe inter-area destinations. For details concern-
ing the construction of summary link advertisements, see Section
12.4.3 of [OSPF].
Type 3 link-state advertisements are used when the destination is an
IPv6 network. In this case the advertisement's Link-State ID field is
an IPv6 network number (if necessary, the Link-State ID can also have
one or more of the network's "host" bits set; see Appendix E of [OSPF]
for details). When the destination is an AS boundary router, a Type 4
advertisement is used, and the Link-State ID field is the AS boundary
router's OSPFv6 Router ID. (To see why it is necessary to advertise
the location of each ASBR, consult Section 16.4 of [OSPF].) Other than
the difference in the Link-State ID field, the format of Type 3 and 4
link-state advertisements is identical.
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 | Options | 3 or 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Link-State ID +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Advertising Router +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Mask Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
For stub areas, Type 3 summary link advertisements can also be used to
describe a (per-area) default route. Default summary routes are used
Coltun Expires June 1996 [Page 51]
Internet Draft OSPFv6 December 1995
in stub areas instead of flooding a complete set of external routes.
When describing a default summary route, the advertisement's Link-
State ID is always set to DefaultDestination (0::0) and the Network
Mask Length is set to 0.
Network Mask Length
For Type 3 link-state advertisements, this indicates the number
of bits in the destination network's IPv6 address mask. For
example, when advertising the location of FF01:0::0 with the net-
work mask of FFFF:0::0, the value of 16 would be used in the mask
field. This field is not meaningful and must be zero for Type 4
link-state advertisements.
Metric
The cost of this route. Expressed in the same units as the inter-
face costs in the router LSA.
Reserved
This field is currently unused.
Coltun Expires June 1996 [Page 52]
Internet Draft OSPFv6 December 1995
A.4.5 AS External LSA
AS external link advertisements are the Type 5 link-state advertise-
ments. These advertisements are originated by AS boundary routers, and
describe destinations external to the AS. For details concerning the
construction of AS external link advertisements, see Section 12.4.3 of
[OSPF] and Section 7.0 of this document.
AS external link advertisements usually describe a particular external
destination. For these advertisements the Link-State ID field speci-
fies an IP network number (if necessary, the Link-State ID can also
have one or more of the network's "host" bits set; see Appendix E for
details). AS external link advertisements are also used to describe a
default route. Default routes are used when no specific route exists
to the destination. When describing a default route, the Link-State
ID is always set to DefaultDestination (0::0) and the Network Mask
Length is set to 0.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age | Options | 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Link-State ID +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Advertising Router +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Mask Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E| Reserved | Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque LSA Reference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Network Mask Length
Coltun Expires June 1996 [Page 53]
Internet Draft OSPFv6 December 1995
The number if bits in the IPv6 address mask for the advertised
destination. For example, when advertising the location of
FF01:0::0 with the network mask of FFFF:0::0, the value of 16
would be used in the mask field.
bit E
The type of external metric. If bit E is set, the metric speci-
fied is a Type 2 external metric. This means the metric is con-
sidered larger than any link-state path. If bit E is zero, the
specified metric is a Type 1 external metric. This means that it
is expressed in the same units as the link-state metric (i.e.,
the same units as interface cost).
Metric
The cost of this route. Interpretation depends on the external
type indication (bit E above).
Opaque LSA Reference
A 32-bit field attached to each external route. The semantics of
the Opaque LSA Reference for OSPFv6 is different than the OSPFv4
Route Tag in that it is used to reference an Opaque LSA (see Sec-
tion 7.0 of this document) which may include the Forwarding
Address as well as information which may be used for policy by
other protocols resident in the AS boundary router (i.e., used to
communicate information between AS boundary routers). If the
External Route Tag is not set (i.e., set to zero), data traffic
will be forwarded to the advertisement's originator.
Coltun Expires June 1996 [Page 54]
Internet Draft OSPFv6 December 1995
A.4.6 Opaque LSA
Opaque LSAs are the Type 15 link-state advertisements. These adver-
tisements are originated by any router and may be used directly by
OSPFv6; they are a useful tool for providing for future extensibility
to OSPFv6. The Opaque LSA may also be used by other protocols such as
BGP wishing to distribute information throughout the OSPFv6 domain.
The BGP information isn't used directly by OSPFv6.
The contents of the Opaque LSA is some number of octets padded to 32-
bit alignment. Like any other LSA, the Opaque LSA uses the link-state
database distribution mechanism for flooding this information
throughout the topology. However, the Opaque LSA has a Flooding Scope
associated with it so that the scope of flooding may be link-local,
area-local, the OSPFv6 routing domain or beyond.
Origination of Opaque LSAs are unique to the application using it.
Section 6 of this document describes the flooding procedures for the
Opaque LSA.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age | Options | 15 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Reserved +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Advertising Router +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flooding Scope | Network Mask Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Opaque Information |
+ +
| ... |
Coltun Expires June 1996 [Page 55]
Internet Draft OSPFv6 December 1995
Syntax Of The Opaque LSA's Link-State ID
The link-state ID of the Opaque LSA is divided into an Opaque
Type field (the first 32 bits), an Opaque ID (the second 32-bit
field) and a reserved field (the remaining 64 bits).
Flooding Scope
Flooding Scope identifies the range of the topology to which this
LSA may be distributed to. The following denotes the possible
values of the Flooding Scope field.
o A value of 0 denotes a link-local scope. Opaque LSAs with a
Flooding Scope of 0 are not flooded beyond the local
(sub)network. The local network is identified by the interface's
network number and network mask length. See Section A.4.6.1 below
for a description of the Link-Local Opaque LSA.
o A value of 1 denotes an area-local scope. Opaque LSAs with a
flooding scope of 1 are not flooded beyond the area that they are
originated into.
o A value of 2 denotes that the LSA is flooded throughout (but
not beyond) the routing domain. That is, the information con-
tained within these LSAs will not be distributed to any protocols
beyond OSPFv6.
o A value of 3 or greater denotes distribution throughout as well
as beyond the routing domain.
Network Mask Length
The Network Mask Length field is an integer representing the
length in bits of the prefix's mask. This field may be used when
the first 128 bits of the Opaque Information is an address prefix
(the interpretation of this field is dependent on the Opaque
Type). When unused the Network Mask Length should be set to 0.
Coltun Expires June 1996 [Page 56]
Internet Draft OSPFv6 December 1995
A.4.6.1 Link-Local Opaque LSA
Link-Local Opaque LSAs the Type 15 link-state advertisements. These
advertisements are originated by any router and may be used directly
by OSPFv6; they are a useful tool for providing for future extensibil-
ity to OSPFv6.
The contents of the Opaque LSA is some number of octets padded to 32-
bit alignment. Like any other LSA, the Opaque LSA uses the link-state
database distribution mechanism for flooding this information
throughout the topology. However, the Opaque LSA has a Flooding Scope
associated with it so that the scope of flooding may be link-local,
area-local, the OSPFv6 routing domain or beyond. This section pro-
vides the packet format for Link-Local Opaque LSAs which must include
the IPv6 address and mask of the IP interface to insure that the
intended Flooding Scope is realized.
Origination of Opaque LSAs are unique to the application using it.
Section 6 of this document describes the flooding procedures for the
Opaque LSA.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age | Options | 15 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Reserved +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Advertising Router +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flooding Scope = 0 | Network Mask Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ IPv6 Interface Address +
| |
Coltun Expires June 1996 [Page 57]
Internet Draft OSPFv6 December 1995
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Opaque Information |
+ +
| ... |
Syntax Of The Opaque LSA's Link-State ID
The link-state ID of the Opaque LSA is divided into an Opaque
Type field (the first 32 bits), an Opaque ID (the second 32-bit
field) and a reserved field (the remaining 64 bits).
Flooding Scope
Flooding Scope identifies the range of the topology to which this
LSA may be distributed to. A value of 0 denotes a link-local
scope. Opaque LSAs with a Flooding Scope of 0 are not flooded
beyond the local (sub)network.
Network Mask Length
The Network Mask Length field is an integer representing the
length in bits of the IPv6 interface network mask. The length is
used along with the IPv6 interface address to insure that the
intended Flooding Scope is realized.
IPv6 Interface Address
The IPv6 interface address representing the (sub)network to which
the link-local flooding this Opaque LSA is limited to. The IPv6
Interface Address is used along with the Network Mask field to
insure that the intended Flooding Scope is realized.
Coltun Expires June 1996 [Page 58]
Internet Draft OSPFv6 December 1995
A.4.6.2 AS External Reference Opaque LSA
Opaque LSAs are the Type 15 link-state advertisements. AS External
Reference Opaque LSA are originated by an AS boundary routers and used
directly by OSPFv6 in conjunction with AS External LSAs.
AS External Reference Opaque LSA are Opaque Type 1 LSAs. These are
used to distribute the forwarding address, tag and origination infor-
mation that were previously included in the AS External LSA. These are
referenced by the Opaque LSA Reference field in the OSPFv6 AS External
LSA by including the Opaque ID in Opaque LSA Reference field. Section
6 of this document describes the flooding procedures for the Opaque
LSA.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age | Options | 15 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque Type = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Reserved +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Advertising Router +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flooding Scope = 2 | Network Mask Length = 128 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Forwarding Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Optional External Route Tag |
+ +
Coltun Expires June 1996 [Page 59]
Internet Draft OSPFv6 December 1995
| ... |
Opaque Type
The Opaque Type for AS External Reference Opaque LSAs is 1.
Opaque ID
The Opaque ID is a local reference to the contents of the Opaque
LSA which consists of the Forwarding Address, Origin Flags,
Domain ID Length and Domain ID.
Flooding Scope
The Flooding Scope field of the AS External Reference Opaque LSA
is set to 2 which denotes that the LSA is flooded throughout the
routing domain but not distributed beyond the routing domain.
Network Mask Length
This field may be used when the first 128 bits of the Opaque
Information is an address prefix (the interpretation of this
field is dependent on the Opaque Type). For AS External Reference
Opaque LSAs this field is set to 128 denoting that the Forwarding
Address which follows is a host route.
Forwarding Address
Data traffic for the destination advertised in the referencing AS
External LSA is forwarded to this address. If the Forwarding
Address is set to 0::0, data traffic will be forwarded instead to
the advertisement's originator (i.e., the responsible AS boundary
router). Note that setting the Opaque LSA Reference field to 0
will also result in data traffic being forwarded to the
advertisement's originator.
Optional External Route Tag
A 32-bit aligned variable length optional field that is not used
by the OSPF protocol itself but may be used to communicate infor-
mation between AS boundary routers. This information may be
locally defined information, prefix origin information or a list
of domain identifiers. The precise nature of such information is
outside the scope of this specification. The length of the
External Route Tag (which may be 0 if the field is omitted) may
be determined by the LSA's length field.
Coltun Expires June 1996 [Page 60]
Internet Draft OSPFv6 December 1995
Appendix B: Architectural Constants
Several OSPF protocol parameters have fixed architectural values.
These parameters have been referred to in the text by names such as
LSRefreshTime. The same naming convention is used for the configur-
able protocol parameters. They are defined in Appendix C of this docu-
ment and [OSPF].
The name of the OSPFv6 specific architectural constant follows,
together with its value and a short description of its function.
IPv6DefaultDestination
The Destination ID that indicates the default route. This route
is used when no other matching routing table entry can be found.
The default destination can only be advertised in AS External LSA
and in stub areas' type 3 summary LSAs. Its value is the IP
address 0::0. Its associated Network Mask Length is always 0.
Allv6SPFRouters
For IPv6 this multicast address has been assigned the value
FF02:0:0:0:0:0:0:5. All routers running OSPFv6 should be prepared
to receive packets sent to this address. Hello packets are
always sent to this destination. Also, certain OSPFv6 protocol
packets are sent to this address during the flooding procedure.
This address has a link-local scope. See [IPV6ADDR] for a
further description of IP version 6 Addresses Architecture.
Allv6DRouters
This IPv6 multicast address has been assigned the value
FF02:0:0:0:0:0:0:6. Both the Designated Router and Backup Desig-
nated Router must be prepared to receive packets destined to this
address. Certain OSPFv6 protocol packets are sent to this
address during the flooding procedure. This address has a link-
local scope. See [IPV6ADDR] for a further description of IP ver-
sion 6 Addresses Architecture.
Coltun Expires June 1996 [Page 61]
Internet Draft OSPFv6 December 1995
Appendix C: Configurable Constants
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.).
Some parameter settings need to be consistent among groups of routers.
For example, all routers in an area must agree on that area's parame-
ters, and all routers attached to a network must agree on that
network's IP network number and mask.
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 confi-
gurable.
This specification gives the Global Parameters for OSPFv6. Appendix C
of [OSPF] should be referred to for the remaining parameters.
C.1 Global Parameters
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.
Router ID
This is a 128-bit number that uniquely identifies the router in
the Autonomous System. One algorithm for Router ID assignment is
to choose the largest or smallest IP address assigned to the
router. If a router's OSPF Router ID is changed, the router's
OSPF software should be restarted before the new Router ID takes
effect. Before restarting in order to change its Router ID, the
router should flush its self-originated link state advertisements
from the routing domain (see Section 14.1 of [OSPF]), or they
will persist for up to MaxAge minutes.
Instance ID
This is a 8-bit number that uniquely identifies the OSPFv6
Instance (or process) within the router. The Instance ID was
added to OSPFv6 to facilitate identifying a particular OSPFv6
Instance by network management (to identify the particular
instance to be managed) and by the OSPFv6 send and receive func-
tions (to identify packet's target OSPFv6 instance). See Section
3.4.2 and Section 5 of this document for further details.
Coltun Expires June 1996 [Page 62]
