[RFCs/IDs] [Plain Text] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01 02 03 04 05 06 07 08 09 10 11
12 13 14 15 16 17 18 19 20 21 22 23
RFC 5340
Network Working Group R. Coltun
Internet-Draft Acoustra Productions
Obsoletes: 2740 (if approved) D. Ferguson
Intended status: Standards Track Juniper Networks
Expires: November 14, 2008 J. Moy
Sycamore Networks, Inc
A. Lindem (Editor)
Redback Networks
May 13, 2008
OSPF for IPv6
draft-ietf-ospf-ospfv3-update-23.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working 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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 14, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Coltun, et al. Expires November 14, 2008 [Page 1]
Internet-Draft OSPF for IPv6 May 2008
Abstract
This document describes the modifications to OSPF to support version
6 of the Internet Protocol (IPv6). The fundamental mechanisms of
OSPF (flooding, Designated Router (DR) election, area support, Short
Path First (SPF) calculations, etc.) remain unchanged. However, some
changes have been necessary, either due to changes in protocol
semantics between IPv4 and IPv6, or simply to handle the increased
address size of IPv6. These modifications will necessitate
incrementing the protocol version from version 2 to version 3. OSPF
for IPv6 is also referred to as OSPF Version 3 (OSPFv3).
Changes between OSPF for IPv4, OSPF Version 2, and OSPF for IPv6 as
described herein include the following. Addressing semantics have
been removed from OSPF packets and the basic Link State
Advertisements (LSAs). New LSAs have been created to carry IPv6
addresses and prefixes. OSPF now runs on a per-link basis rather
than on a per-IP-subnet basis. Flooding scope for LSAs has been
generalized. Authentication has been removed from the OSPF protocol
and instead relies on IPv6's Authentication Header and Encapsulating
Security Payload (ESP).
Even with larger IPv6 addresses, most packets in OSPF for IPv6 are
almost as compact as those in OSPF for IPv4. Most fields and packet-
size limitations present in OSPF for IPv4 have been relaxed. In
addition, option handling has been made more flexible.
All of OSPF for IPv4's optional capabilities, including demand
circuit support and Not-So-Stubby Areas (NSSAs) are also supported in
OSPF for IPv6.
Coltun, et al. Expires November 14, 2008 [Page 2]
Internet-Draft OSPF for IPv6 May 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1. Requirements notation . . . . . . . . . . . . . . . . . . 6
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
2. Differences from OSPF for IPv4 . . . . . . . . . . . . . . . 7
2.1. Protocol processing per-link, not per-subnet . . . . . . 7
2.2. Removal of addressing semantics . . . . . . . . . . . . . 7
2.3. Addition of Flooding scope . . . . . . . . . . . . . . . 8
2.4. Explicit support for multiple instances per link . . . . 8
2.5. Use of link-local addresses . . . . . . . . . . . . . . . 8
2.6. Authentication changes . . . . . . . . . . . . . . . . . 9
2.7. Packet format changes . . . . . . . . . . . . . . . . . . 9
2.8. LSA format changes . . . . . . . . . . . . . . . . . . . 10
2.9. Handling unknown LSA types . . . . . . . . . . . . . . . 12
2.10. Stub/NSSA area support . . . . . . . . . . . . . . . . . 12
2.11. Identifying neighbors by Router ID . . . . . . . . . . . 13
3. Differences with RFC 2740 . . . . . . . . . . . . . . . . . . 14
3.1. Support for Multiple Interfaces on the same Link . . . . 14
3.2. Deprecation of MOSPF for IPv6 . . . . . . . . . . . . . . 14
3.3. NSSA Specification . . . . . . . . . . . . . . . . . . . 14
3.4. Stub Area Unknown LSA Flooding Restriction Deprecated . . 14
3.5. Link LSA Suppression . . . . . . . . . . . . . . . . . . 15
3.6. LSA Options and Prefix Options Updates . . . . . . . . . 15
3.7. IPv6 Site-Local Addresses . . . . . . . . . . . . . . . . 15
4. Implementation details . . . . . . . . . . . . . . . . . . . 16
4.1. Protocol data structures . . . . . . . . . . . . . . . . 17
4.1.1. The Area Data structure . . . . . . . . . . . . . . . 17
4.1.2. The Interface Data structure . . . . . . . . . . . . 18
4.1.3. The Neighbor Data Structure . . . . . . . . . . . . . 19
4.2. Protocol Packet Processing . . . . . . . . . . . . . . . 20
4.2.1. Sending protocol packets . . . . . . . . . . . . . . 20
4.2.1.1. Sending Hello Packets . . . . . . . . . . . . . . 21
4.2.1.2. Sending Database Description Packets . . . . . . 22
4.2.2. Receiving Protocol Packets . . . . . . . . . . . . . 22
4.2.2.1. Receiving Hello Packets . . . . . . . . . . . . . 24
4.3. The Routing table Structure . . . . . . . . . . . . . . . 25
4.3.1. Routing table lookup . . . . . . . . . . . . . . . . 26
4.4. Link State Advertisements . . . . . . . . . . . . . . . . 26
4.4.1. The LSA Header . . . . . . . . . . . . . . . . . . . 26
4.4.2. The link-state database . . . . . . . . . . . . . . . 27
4.4.3. Originating LSAs . . . . . . . . . . . . . . . . . . 27
4.4.3.1. LSA Options . . . . . . . . . . . . . . . . . . . 31
4.4.3.2. Router-LSAs . . . . . . . . . . . . . . . . . . . 31
4.4.3.3. Network-LSAs . . . . . . . . . . . . . . . . . . 33
4.4.3.4. Inter-Area-Prefix-LSAs . . . . . . . . . . . . . 34
4.4.3.5. Inter-Area-Router-LSAs . . . . . . . . . . . . . 35
4.4.3.6. AS-external-LSAs . . . . . . . . . . . . . . . . 36
Coltun, et al. Expires November 14, 2008 [Page 3]
Internet-Draft OSPF for IPv6 May 2008
4.4.3.7. NSSA-LSAs . . . . . . . . . . . . . . . . . . . . 37
4.4.3.8. Link-LSAs . . . . . . . . . . . . . . . . . . . . 38
4.4.3.9. Intra-Area-Prefix-LSAs . . . . . . . . . . . . . 40
4.4.4. Future LSA Validation . . . . . . . . . . . . . . . . 43
4.5. Flooding . . . . . . . . . . . . . . . . . . . . . . . . 43
4.5.1. Receiving Link State Update packets . . . . . . . . . 44
4.5.2. Sending Link State Update packets . . . . . . . . . . 44
4.5.3. Installing LSAs in the database . . . . . . . . . . . 46
4.6. Definition of self-originated LSAs . . . . . . . . . . . 47
4.7. Virtual links . . . . . . . . . . . . . . . . . . . . . . 47
4.8. Routing table calculation . . . . . . . . . . . . . . . . 48
4.8.1. Calculating the shortest path tree for an area . . . 48
4.8.2. The next hop calculation . . . . . . . . . . . . . . 50
4.8.3. Calculating the inter-area routes . . . . . . . . . . 51
4.8.4. Examining transit areas' summary-LSAs . . . . . . . . 51
4.8.5. Calculating AS external and NSSA routes . . . . . . . 51
4.9. Multiple interfaces to a single link . . . . . . . . . . 52
4.9.1. Standby Interface State . . . . . . . . . . . . . . . 54
5. Security Considerations . . . . . . . . . . . . . . . . . . . 56
6. Manageability Considerations . . . . . . . . . . . . . . . . 57
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 58
7.1. MOSPF for OSPFv3 Deprecation IANA Considerations . . . . 58
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 60
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 62
9.1. Normative References . . . . . . . . . . . . . . . . . . 62
9.2. Informative References . . . . . . . . . . . . . . . . . 63
Appendix A. OSPF data formats . . . . . . . . . . . . . . . . . 64
A.1. Encapsulation of OSPF packets . . . . . . . . . . . . . . 64
A.2. The Options field . . . . . . . . . . . . . . . . . . . . 65
A.3. OSPF Packet Formats . . . . . . . . . . . . . . . . . . . 67
A.3.1. The OSPF packet header . . . . . . . . . . . . . . . 67
A.3.2. The Hello Packet . . . . . . . . . . . . . . . . . . 69
A.3.3. The Database Description Packet . . . . . . . . . . . 70
A.3.4. The Link State Request Packet . . . . . . . . . . . . 72
A.3.5. The Link State Update Packet . . . . . . . . . . . . 73
A.3.6. The Link State Acknowledgment Packet . . . . . . . . 74
A.4. LSA formats . . . . . . . . . . . . . . . . . . . . . . . 75
A.4.1. IPv6 Prefix Representation . . . . . . . . . . . . . 76
A.4.1.1. Prefix Options . . . . . . . . . . . . . . . . . 76
A.4.2. The LSA header . . . . . . . . . . . . . . . . . . . 77
A.4.2.1. LSA Type . . . . . . . . . . . . . . . . . . . . 79
A.4.3. Router-LSAs . . . . . . . . . . . . . . . . . . . . . 80
A.4.4. Network-LSAs . . . . . . . . . . . . . . . . . . . . 83
A.4.5. Inter-Area-Prefix-LSAs . . . . . . . . . . . . . . . 84
A.4.6. Inter-Area-Router-LSAs . . . . . . . . . . . . . . . 85
A.4.7. AS-external-LSAs . . . . . . . . . . . . . . . . . . 86
A.4.8. NSSA-LSAs . . . . . . . . . . . . . . . . . . . . . . 89
A.4.9. Link-LSAs . . . . . . . . . . . . . . . . . . . . . . 89
Coltun, et al. Expires November 14, 2008 [Page 4]
Internet-Draft OSPF for IPv6 May 2008
A.4.10. Intra-Area-Prefix-LSAs . . . . . . . . . . . . . . . 91
Appendix B. Architectural Constants . . . . . . . . . . . . . . 94
Appendix C. Configurable Constants . . . . . . . . . . . . . . . 95
C.1. Global parameters . . . . . . . . . . . . . . . . . . . . 95
C.2. Area parameters . . . . . . . . . . . . . . . . . . . . . 95
C.3. Router interface parameters . . . . . . . . . . . . . . . 97
C.4. Virtual link parameters . . . . . . . . . . . . . . . . . 99
C.5. NBMA network parameters . . . . . . . . . . . . . . . . . 99
C.6. Point-to-Multipoint network parameters . . . . . . . . . 100
C.7. Host route parameters . . . . . . . . . . . . . . . . . . 100
Appendix D. Change Log (To Be Removed Prior To Publication) . . 102
D.1. Changes from RFC 2740 to 00 Version . . . . . . . . . . . 102
D.2. Changes from the 00 Version to the 01 Version . . . . . . 102
D.3. Changes from the 01 Version to the 02 Version . . . . . . 103
D.4. Changes from the 02 Version to the 03 Version . . . . . . 103
D.5. Changes from the 03 Version to the 04 Version . . . . . . 103
D.6. Changes from the 04 Version to the 05 Version . . . . . . 104
D.7. Changes from the 05 Version to the 06 Version . . . . . . 104
D.8. Changes from the 06 Version to the 07 Version . . . . . . 104
D.9. Changes from the 07 Version to the 08 Version . . . . . . 104
D.10. Changes from the 08 Version to the 09 Version . . . . . . 105
D.11. Changes from the 09 Version to the 10 Version . . . . . . 105
D.12. Changes from the 10 Version to the 11 Version . . . . . . 105
D.13. Changes from the 11 Version to the 12 Version . . . . . . 106
D.14. Changes from the 12 Version to the 13 Version . . . . . . 106
D.15. Changes from the 13 Version to the 14 Version . . . . . . 106
D.16. Changes from the 14 Version to the 15 Version . . . . . . 107
D.17. Changes from the 15 Version to the 16 Version . . . . . . 107
D.18. Changes from the 16 Version to the 17 Version . . . . . . 107
D.19. Changes from the 17 Version to the 18 Version . . . . . . 107
D.20. Changes from the 18 Version to the 19 Version . . . . . . 108
D.21. Changes from the 19 Version to the 20 Version . . . . . . 108
D.22. Changes from the 20 Version to the 21 Version . . . . . . 108
D.23. Changes from the 21 Version to the 22 Version . . . . . . 108
D.24. Changes from the 22 Version to the 23 Version . . . . . . 109
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 110
Intellectual Property and Copyright Statements . . . . . . . . . 111
Coltun, et al. Expires November 14, 2008 [Page 5]
Internet-Draft OSPF for IPv6 May 2008
1. Introduction
This document describes the modifications to OSPF to support version
6 of the Internet Protocol (IPv6). The fundamental mechanisms of
OSPF (flooding, Designated Router (DR) election, area support,
(Shortest Path First) SPF calculations, etc.) remain unchanged.
However, some changes have been necessary, either due to changes in
protocol semantics between IPv4 and IPv6, or simply to handle the
increased address size of IPv6. These modifications will necessitate
incrementing the protocol version from version 2 to version 3. OSPF
for IPv6 is also referred to as OSPF Version 3 (OSPFv3).
This document is organized as follows. Section 2 describes the
differences between OSPF for IPv4 (OSPF Version 2) and OSPF for IPv6
(OSPF Version 3) in detail. Section 3 describes the difference
between RFC 2740 and this document. Section 4 provides
implementation details for the changes. Appendix A gives the OSPF
for IPv6 packet and Link State Advertisement (LSA) formats. Appendix
B lists the OSPF architectural constants. Appendix C describes
configuration parameters.
1.1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC-KEYWORDS].
1.2. Terminology
This document attempts to use terms from both the OSPF for IPv4
specification ([OSPFV2]) and the IPv6 protocol specifications
([IPV6]). This has produced a mixed result. Most of the terms used
both by OSPF and IPv6 have roughly the same meaning (e.g.,
interfaces). However, there are a few conflicts. IPv6 uses "link"
similarly to IPv4 OSPF's "subnet" or "network". In this case, we
have chosen to use IPv6's "link" terminology. "Link" replaces OSPF's
"subnet" and "network" in most places in this document, although
OSPF's network-LSA remains unchanged (and possibly unfortunately, a
new link-LSA has also been created).
The names of some of the OSPF LSAs have also changed. See
Section 2.8 for details.
In the context of this document, an OSPF instance is a separate
protocol instance complete with its own protocol data structures
(e.g., areas, interfaces, neighbors), link-state database, protocol
state machines, and protocol processing (e.g., SPF calculation).
Coltun, et al. Expires November 14, 2008 [Page 6]
Internet-Draft OSPF for IPv6 May 2008
2. Differences from OSPF for IPv4
Most of the algorithms from OSPF for IPv4 [OSPFV2] have been
preserved in OSPF for IPv6. However, some changes have been
necessary, either due to changes in protocol semantics between IPv4
and IPv6, or simply to handle the increased address size of IPv6.
The following subsections describe the differences between this
document and [OSPFV2].
2.1. Protocol processing per-link, not per-subnet
IPv6 uses the term "link" to indicate "a communication facility or
medium over which nodes can communicate at the link layer" ([IPV6]).
"Interfaces" connect to links. Multiple IPv6 subnets can be assigned
to a single link, and two nodes can talk directly over a single link,
even if they do not share a common IPv6 subnet (IPv6 prefix).
For this reason, OSPF for IPv6 runs per-link instead of the IPv4
behavior of per-IP-subnet. The terms "network" and "subnet" used in
the IPv4 OSPF specification ([OSPFV2]) should generally be replaced
by link. Likewise, an OSPF interface now connects to a link instead
of an IP subnet.
This change affects the receiving of OSPF protocol packets, the
contents of Hello packets, and the contents of network-LSAs.
2.2. Removal of addressing semantics
In OSPF for IPv6, addressing semantics have been removed from the
OSPF protocol packets and the main LSA types, leaving a network-
protocol-independent core. In particular:
o IPv6 Addresses are not present in OSPF packets, except in LSA
payloads carried by the Link State Update packets. See
Section 2.7 for details.
o Router-LSAs and network-LSAs no longer contain network addresses,
but simply express topology information. See Section 2.8 for
details.
o OSPF Router IDs, Area IDs, and LSA Link State IDs remain at the
IPv4 size of 32-bits. They can no longer be assigned as (IPv6)
addresses.
o Neighboring routers are now always identified by Router ID.
Previously, they had been identified by IPv4 address on broadcast,
Coltun, et al. Expires November 14, 2008 [Page 7]
Internet-Draft OSPF for IPv6 May 2008
NBMA, and point-to-multipoint links.
2.3. Addition of Flooding scope
Flooding scope for LSAs has been generalized and is now explicitly
coded in the LSA's LS type field. There are now three separate
flooding scopes for LSAs:
o Link-local scope. LSA is only flooded on the local link and no
further. Used for the new link-LSA. See Section 4.4.3.8 for
details.
o Area scope. LSA is only flooded throughout a single OSPF area.
Used for router-LSAs, network-LSAs, inter-area-prefix-LSAs, inter-
area-router-LSAs, and intra-area-prefix-LSAs.
o AS scope. LSA is flooded throughout the routing domain. Used for
AS-external-LSAs. A router that originates AS scoped LSAs is
considered an AS Boundary Router (ASBR) and will set its E-bit in
Router-LSAs for regular areas.
2.4. Explicit support for multiple instances per link
OSPF now supports the ability to run multiple OSPF protocol instances
on a single link. For example, this may be required on a NAP segment
shared between several providers. Providers may be supporting
separate OSPF routing domains that wish to remain separate even
though they have one or more physical network segments (i.e., links)
in common. In OSPF for IPv4 this was supported in a haphazard
fashion using the authentication fields in the OSPF for IPv4 header.
Another use for running multiple OSPF instances is if you want, for
one reason or another, to have a single link belong to two or more
OSPF areas.
Support for multiple protocol instances on a link is accomplished via
an "Instance ID" contained in the OSPF packet header and OSPF
interface data structures. Instance ID solely affects the reception
of OSPF packets and applies to normal OSPF interfaces and virtual
links.
2.5. Use of link-local addresses
IPv6 link-local addresses are for use on a single link, for purposes
of neighbor discovery, auto-configuration, etc. IPv6 routers do not
forward IPv6 datagrams having link-local source addresses [IP6ADDR].
Link-local unicast addresses are assigned from the IPv6 address range
Coltun, et al. Expires November 14, 2008 [Page 8]
Internet-Draft OSPF for IPv6 May 2008
FE80/10.
OSPF for IPv6 assumes that each router has been assigned link-local
unicast addresses on each of the router's attached physical links
[IP6ADDR]. On all OSPF interfaces except virtual links, OSPF packets
are sent using the interface's associated link-local unicast address
as the source address. A router learns the link-local addresses of
all other routers attached to its links and uses these addresses as
next hop information during packet forwarding.
On virtual links, a global scope IPv6 address MUST be used as the
source address for OSPF protocol packets.
Link-local addresses appear in OSPF link-LSAs (see Section 4.4.3.8).
However, link-local addresses are not allowed in other OSPF LSA
types. In particular, link-local addresses MUST NOT be advertised in
inter-area-prefix-LSAs (Section 4.4.3.4), AS-external-LSAs
(Section 4.4.3.6), NSSA-LSAs (Section 4.4.3.7), or intra-area-prefix-
LSAs (Section 4.4.3.9).
2.6. Authentication changes
In OSPF for IPv6, authentication has been removed from the OSPF
protocol. The "AuType" and "Authentication" fields have been removed
from the OSPF packet header, and all authentication related fields
have been removed from the OSPF area and interface data structures.
When running over IPv6, OSPF relies on the IP Authentication Header
(see [IPAUTH]) and the IP Encapsulating Security Payload (see
[IPESP]) as described in [OSPFV3-AUTH] to ensure integrity and
authentication/confidentiality of routing exchanges.
Protection of OSPF packet exchanges against accidental data
corruption is provided by the standard IPv6 Upper-Layer checksum (as
described in section 8.1 of [IPV6]), covering the entire OSPF packet
and prepended IPv6 pseudo-header (see Appendix A.3.1).
2.7. Packet format changes
OSPF for IPv6 runs directly over IPv6. Aside from this, all
addressing semantics have been removed from the OSPF packet headers,
making it essentially "network-protocol-independent". All addressing
information is now contained in the various LSA types only.
In detail, changes in OSPF packet format consist of the following:
Coltun, et al. Expires November 14, 2008 [Page 9]
Internet-Draft OSPF for IPv6 May 2008
o The OSPF version number has been incremented from 2 to 3.
o The Options field in Hello packets and Database Description
packets has been expanded to 24-bits.
o The Authentication and AuType fields have been removed from the
OSPF packet header (see Section 2.6)
o The Hello packet now contains no address information at all
Rather, it now includes an Interface ID which the originating
router has assigned to uniquely identify (among its own
interfaces) its interface to the link. This Interface ID will be
used as the network-LSA's Link State ID if the router becomes
Designated-Router on the link.
o Two option bits, the "R-bit" and the "V6-bit", have been added to
the Options field for processing router-LSAs during the SPF
calculation (see Appendix A.2). If the "R-bit" is clear an OSPF
speaker can participate in OSPF topology distribution without
being used to forward transit traffic; this can be used in multi-
homed hosts that want to participate in the routing protocol. The
V6-bit specializes the R-bit; if the V6-bit is clear an OSPF
speaker can participate in OSPF topology distribution without
being used to forward IPv6 datagrams. If the R-bit is set and the
V6-bit is clear, IPv6 datagrams are not forwarded but datagrams
belonging to another protocol family may be forwarded.
o The OSPF packet header now includes an "Instance ID" which allows
multiple OSPF protocol instances to be run on a single link (see
Section 2.4).
2.8. LSA format changes
All addressing semantics have been removed from the LSA header,
router-LSAs, and network-LSAs. These two LSAs now describe the
routing domain's topology in a network protocol independent manner.
New LSAs have been added to distribute IPv6 address information and
data required for next hop resolution. The names of some of IPv4's
LSAs have been changed to be more consistent with each other.
In detail, changes in LSA format consist of the following:
o The Options field has been removed from the LSA header, expanded
to 24 bits, and moved into the body of router-LSAs, network-LSAs,
inter-area-router-LSAs, and link-LSAs. See Appendix A.2 for
details.
Coltun, et al. Expires November 14, 2008 [Page 10]
Internet-Draft OSPF for IPv6 May 2008
o The LSA Type field has been expanded (into the former Options
space) to 16 bits, with the upper three bits encoding flooding
scope and the handling of unknown LSA types (see Section 2.9).
o Addresses in LSAs are now expressed as [prefix, prefix length]
instead of [address, mask] (see Appendix A.4.1). The default
route is expressed as a prefix with length 0.
o Router-LSAs and network-LSAs now have no address information and
are network protocol independent.
o Router interface information MAY be spread across multiple router-
LSAs. Receivers MUST concatenate all the router-LSAs originated
by a given router when running the SPF calculation.
o A new LSA called the link-LSA has been introduced. Link-LSAs have
local-link flooding scope; they are never flooded beyond the link
with which they are associated. Link-LSAs have three purposes: 1)
they provide the router's link-local address to all other routers
attached to the link, 2) they inform other routers attached to the
link of a list of IPv6 prefixes to associate with the link, and 3)
they allow the router to advertise a collection of Options bits to
associate with the network-LSA that will be originated for the
link. See Section 4.4.3.8 for details.
o In IPv4, the router-LSA carries a router's IPv4 interface
addresses, the IPv4 equivalent of link-local addresses. These are
only used when calculating next hops during the OSPF routing
calculation (see Section 16.1.1 of [OSPFV2]), so they do not need
to be flooded past the local link. Hence, using link-LSAs to
distribute these addresses is more efficient. Note that link-
local addresses cannot be learned through the reception of Hellos
in all cases. On NBMA links, next hop routers do not necessarily
exchange hellos. Rather, these routers learn of each other's
existence by way of the Designated Router (DR).
o The Options field in the Network LSA is set to the logical OR of
the Options that each router on the link advertises in its link-
LSA.
o Type-3 summary-LSAs have been renamed "inter-area-prefix-LSAs".
Type-4 summary LSAs have been renamed "inter-area-router-LSAs".
o The Link State ID in inter-area-prefix-LSAs, inter-area-router-
LSAs, NSSA-LSAs, and AS-external-LSAs, has lost its addressing
semantics and now serves solely to identify individual pieces of
the Link State Database. All addresses or Router IDs that were
formerly expressed by the Link State ID are now carried in the LSA
Coltun, et al. Expires November 14, 2008 [Page 11]
Internet-Draft OSPF for IPv6 May 2008
bodies
o Network-LSAs and link-LSAs are the only LSAs whose Link State ID
carries additional meaning. For these LSAs, the Link State ID is
always the Interface ID of the originating router on the link
being described. For this reason, network-LSAs and link-LSAs are
now the only LSAs whose size cannot be limited: a network-LSA MUST
list all routers connected to the link and a link-LSA MUST list
all of a router's addresses on the link.
o A new LSA called the intra-area-prefix-LSA has been introduced.
This LSA carries all IPv6 prefix information that in IPv4 is
included in router-LSAs and network-LSAs. See Section 4.4.3.9 for
details.
o Inclusion of a forwarding address or external route tag in AS-
external-LSAs is now optional. In addition, AS-external-LSAs can
now reference another LSA, for inclusion of additional route
attributes that are outside the scope of the OSPF protocol. For
example, this reference could be used to attach BGP path
attributes to external routes.
2.9. Handling unknown LSA types
Handling of unknown LSA types has been made more flexible so that,
based on LS type, unknown LSA types are either treated as having
link-local flooding scope, or are stored and flooded as if they were
understood. This behavior is explicitly coded in the LSA Handling
bit of the link state header's LS type field (see the U-bit in
Appendix A.4.2.1).
The IPv4 OSPF behavior of simply discarding unknown types is
unsupported due to the desire to mix router capabilities on a single
link. Discarding unknown types causes problems when the Designated
Router supports fewer options than the other routers on the link.
2.10. Stub/NSSA area support
In OSPF for IPv4, stub and NSSA areas were designed to minimize link-
state database and routing table sizes for the areas' internal
routers. This allows routers with minimal resources to participate
in even very large OSPF routing domains.
In OSPF for IPv6, the concept of stub and NSSA areas is retained. In
IPv6, of the mandatory LSA types, stub areas carry only router-LSAs,
network-LSAs, inter-area-prefix-LSAs, link-LSAs, and intra-area-
prefix-LSAs. NSSA areas are restricted to these types and, of
course, NSSA-LSAs. This is the IPv6 equivalent of the LSA types
Coltun, et al. Expires November 14, 2008 [Page 12]
Internet-Draft OSPF for IPv6 May 2008
carried in IPv4 stub areas: router-LSAs, network-LSAs, type 3
summary-LSAs and for NSSA areas: stub area types and NSSA-LSAs.
2.11. Identifying neighbors by Router ID
In OSPF for IPv6, neighboring routers on a given link are always
identified by their OSPF Router ID. This contrasts with the IPv4
behavior where neighbors on point-to-point networks and virtual links
are identified by their Router IDs while neighbors on broadcast,
NBMA, and Point-to-Multipoint links are identified by their IPv4
interface addresses.
This change affects the reception of OSPF packets (see Section 8.2 of
[OSPFV2]), the lookup of neighbors (Section 10 of [OSPFV2]) and the
reception of Hello packets (Section 10.5 of [OSPFV2]).
The Router ID of 0.0.0.0 is reserved and SHOULD NOT be used.
Coltun, et al. Expires November 14, 2008 [Page 13]
Internet-Draft OSPF for IPv6 May 2008
3. Differences with RFC 2740
OSPFv3 implementations based on RFC 2740 will fully interoperate with
implementations based on this specification. There are, however,
some protocol additions and changes (all of which are backward
compatible).
3.1. Support for Multiple Interfaces on the same Link
This protocol feature was only partially specified in the RFC 2740.
The level of specification was insufficient to implement the feature.
Section 4.9 specifies the additions and clarifications necessary for
implementation. They are fully compatible with RFC 2740.
3.2. Deprecation of MOSPF for IPv6
This protocol feature was only partially specified in the RFC 2740.
The level of specification was insufficient to implement the feature.
There are no known implementations. MOSPF support and its attendant
protocol fields have been deprecated from OSPFv3. Refer to
Section 4.4.3.2, Section 4.4.3.4, Section 4.4.3.6, Section 4.4.3.7,
Appendix A.2, Appendix A.4.2.1, Appendix A.4.3, Appendix A.4.1.1, and
Section 7.1.
3.3. NSSA Specification
This protocol feature was only partially specified in the RFC 2740.
The level of specification was insufficient to implement the
function. This document includes NSSA specification unique to
OSPFv3. This specification coupled with [NSSA] provide sufficient
specification for implementation. Refer to Section 4.8.5,
Appendix A.4.3, Appendix A.4.8, and [NSSA].
3.4. Stub Area Unknown LSA Flooding Restriction Deprecated
In RFC 2740 [OSPFV3], flooding of unknown LSA was restricted within
stub and NSSA areas. The text describing this restriction is
included below.
Coltun, et al. Expires November 14, 2008 [Page 14]
Internet-Draft OSPF for IPv6 May 2008
However, unlike in IPv4, IPv6 allows LSAs with unrecognized
LS types to be labeled "Store and flood the LSA, as if type
understood" (see the U-bit in Appendix A.4.2.1). Uncontrolled
introduction of such LSAs could cause a stub area's link-state
database to grow larger than its component routers' capacities.
To guard against this, the following rule regarding stub areas
has been established: an LSA whose LS type is unrecognized can
only be flooded into/throughout a stub area if both a) the LSA
has area or link-local flooding scope and b) the LSA has U-bit
set to 0. See Section 3.5 for details.
This restriction has been deprecated. OSPFv3 routers will flood link
and area scope LSAs whose LS type is unrecognized and whose U-bit is
set to 1 throughout stub and NSSA areas. There are no backward
compatibility issues other than OSPFv3 routers still supporting the
restriction may not propagate newly defined LSA types.
3.5. Link LSA Suppression
The LinkLSASuppression interface configuration parameter has been
added. If LinkLSASuppression is configured for an interface and the
interface type is not broadcast or NBMA, origination of the Link-LSA
may be suppressed. The LinkLSASuppression interface configuration
parameter is described in Appendix C.3. Section 4.8.2 and
Section 4.4.3.8 were updated to reflect the parameter's usage.
3.6. LSA Options and Prefix Options Updates
The LSA options and Prefix Options fields have been updated to
reflect recent protocols additions. Specifically, bits related to
MOSPF have been deprecated, options field bits common with OSPFv2
have been reserved, and the DN-bit has been added to the prefix-
options. Refer to Appendix A.2 and Appendix A.4.1.1.
3.7. IPv6 Site-Local Addresses
All references to IPv6 site-local addresses have been removed.
Coltun, et al. Expires November 14, 2008 [Page 15]
Internet-Draft OSPF for IPv6 May 2008
4. Implementation details
When going from IPv4 to IPv6, the basic OSPF mechanisms remain
unchanged from those documented in [OSPFV2]. These mechanisms are
briefly outlined in Section 4 of [OSPFV2]. Both IPv6 and IPv4 have a
link-state database composed of LSAs and synchronized between
adjacent routers. Initial synchronization is performed through the
Database Exchange process, which includes the exchange of Database
Description, Link State Request, and Link State Update packets.
Thereafter, database synchronization is maintained via flooding,
utilizing Link State Update and Link State Acknowledgment packets.
Both IPv6 and IPv4 use OSPF Hello packets to discover and maintain
neighbor relationships, as well as to elect Designated Routers and
Backup Designated Routers on broadcast and NBMA links. The decision
as to which neighbor relationships become adjacencies, along with the
basic ideas behind inter-area routing, importing external information
in AS-external-LSAs, and the various routing calculations are also
the same.
In particular, the following IPv4 OSPF functionality described in
[OSPFV2] remains completely unchanged for IPv6:
o Both IPv4 and IPv6 use OSPF packet types described in Section 4.3
of [OSPFV2], namely: Hello, Database Description, Link State
Request, Link State Update, and Link State Acknowledgment packets.
While in some cases (e.g., Hello packets) their format has changed
somewhat, the functions of the various packet types remain the
same.
o The system requirements for an OSPF implementation remain
unchanged, although OSPF for IPv6 requires an IPv6 protocol stack
(from the network layer on down) since it runs directly over the
IPv6 network layer.
o The discovery and maintenance of neighbor relationships, and the
selection and establishment of adjacencies remain the same. This
includes election of the Designated Router and Backup Designated
Router on broadcast and NBMA links. These mechanisms are
described in Sections 7, 7.1, 7.2, 7.3, 7.4, and 7.5 of [OSPFV2].
o The link types (or equivalently, interface types) supported by
OSPF remain unchanged, namely: point-to-point, broadcast, NBMA,
Point-to-Multipoint, and virtual links.
o The interface state machine, including the list of OSPF interface
states and events, and the Designated Router and Backup Designated
Router election algorithm, remain unchanged. These are described
Coltun, et al. Expires November 14, 2008 [Page 16]
Internet-Draft OSPF for IPv6 May 2008
in Sections 9.1, 9.2, 9.3, and 9.4 of [OSPFV2].
o The neighbor state machine, including the list of OSPF neighbor
states and events, remains unchanged. The neighbor state machine
is described in Sections 10.1, 10.2, 10.3, and 10.4 of [OSPFV2].
o Aging of the link-state database, as well as flushing LSAs from
the routing domain through the premature aging process, remains
unchanged from the description in Sections 14 and 14.1 of
[OSPFV2].
However, some OSPF protocol mechanisms have changed as previously
described in Section 2 herein. These changes are explained in detail
in the following subsections, making references to the appropriate
sections of [OSPFV2].
The following subsections provide a recipe for turning an IPv4 OSPF
implementation into an IPv6 OSPF implementation.
4.1. Protocol data structures
The major OSPF data structures are the same for both IPv4 and IPv6:
areas, interfaces, neighbors, the link-state database, and the
routing table. The top-level data structures for IPv6 remain those
listed in Section 5 of [OSPFV2], with the following modifications:
o All LSAs with known LS type and AS flooding scope appear in the
top-level data structure, instead of belonging to a specific area
or link. AS-external-LSAs are the only LSAs defined by this
specification that have AS flooding scope. LSAs with unknown LS
type, U-bit set to 1 (flood even when unrecognized), and AS
flooding scope also appear in the top-level data structure.
4.1.1. The Area Data structure
The IPv6 area data structure contains all elements defined for IPv4
areas in Section 6 of [OSPFV2]. In addition, all LSAs of known type
which have area flooding scope are contained in the IPv6 area data
structure. This always includes the following LSA types: router-
LSAs, network-LSAs, inter-area-prefix-LSAs, inter-area-router-LSAs,
and intra-area-prefix-LSAs. LSAs with unknown LS type, U-bit set to
1 (flood even when unrecognized) and area scope also appear in the
area data structure. NSSA-LSAs are also included in an NSSA area's
data structure.
Coltun, et al. Expires November 14, 2008 [Page 17]
Internet-Draft OSPF for IPv6 May 2008
4.1.2. The Interface Data structure
In OSPF for IPv6, an interface connects a router to a link. The IPv6
interface structure modifies the IPv4 interface structure (as defined
in Section 9 of [OSPFV2]) as follows:
Interface ID
Every interface is assigned an Interface ID, which uniquely
identifies the interface with the router. For example, some
implementations MAY be able to use the MIB-II IfIndex ([INTFMIB])
as Interface ID. The Interface ID appears in Hello packets sent
out the interface, the link-local-LSA originated by router for the
attached link, and the router-LSA originated by the router-LSA for
the associated area. It will also serve as the Link State ID for
the network-LSA that the router will originate for the link if the
router is elected Designated Router.
The interface ID for a virtual link is independent of the
interface ID of the outgoing interface it traverses in the transit
area.
Instance ID
Every interface is assigned an Instance ID. This should default
to 0. It is only necessary to assign differently on those links
that will contain multiple separate communities of OSPF Routers.
For example, suppose that there are two communities of routers on
a given ethernet segment that you wish to keep separate.
The first community is assigned an Instance ID of 0 and all the
routers in the first community will be assigned 0 as the Instance
ID for interfaces connected to the ethernet segment. An Instance
ID of 1 is assigned to the other routers' interfaces connected to
the ethernet segment. The OSPF transmit and receive processing
(see Section 4.2) will then keep the two communities separate.
List of LSAs with link-local scope
All LSAs with link-local scope and which were originated/flooded
on the link belong to the interface structure that connects to the
link. This includes the collection of the link's link-LSAs.
IP interface address
For IPv6, the IPv6 address appearing in the source of OSPF packets
sent out the interface is almost always a link-local address. The
one exception is for virtual links which MUST use one of the
router's own global IPv6 addresses as IP interface address.
Coltun, et al. Expires November 14, 2008 [Page 18]
Internet-Draft OSPF for IPv6 May 2008
List of link prefixes
A list of IPv6 prefixes can be configured for the attached link.
These will be advertised by the router in link-LSAs, so that they
can be advertised by the link's Designated Router in intra-area-
prefix-LSAs.
In OSPF for IPv6, each router interface has a single metric
representing the cost of sending packets out the interface. In
addition, OSPF for IPv6 relies on the IP Authentication Header (see
[IPAUTH]) and the IP Encapsulating Security Payload (see [IPESP]) as
described in [OSPFV3-AUTH] to ensure integrity and authentication/
confidentiality of routing exchanges. For this reason, AuType and
Authentication key are not associated with IPv6 OSPF interfaces.
Interface states, events, and the interface state machine remain
unchanged from IPv4 as documented in Sections 9.1, 9.2, and 9.3 of
[OSPFV2] respectively. The Designated Router and Backup Designated
Router election algorithm also remains unchanged from the IPv4
election in Section 9.4 of [OSPFV2].
4.1.3. The Neighbor Data Structure
The neighbor structure performs the same function in both IPv6 and
IPv4. Namely, it collects all information required to form an
adjacency between two routers when such an adjacency becomes
necessary. Each neighbor structure is bound to a single OSPF
interface. The differences between the IPv6 neighbor structure and
the neighbor structure defined for IPv4 in Section 10 of [OSPFV2]
are:
Neighbor's Interface ID
The Interface ID that the neighbor advertises in its Hello packets
must be recorded in the neighbor structure. The router will
include the neighbor's Interface ID in the router's router-LSA
when either a) advertising a point-to-point or point-to-multipoint
link to the neighbor or b) advertising a link to a network where
the neighbor has become Designated Router.
Neighbor IP address
The neighbor's IPv6 address contained as the source address in
OSPF for IPv6 packets. This will be an IPv6 link-local address
for all link types except virtual links.
Neighbor's Designated Router
The neighbor's choice of Designated Router is now encoded as a
Router ID instead of as an IP address.
Coltun, et al. Expires November 14, 2008 [Page 19]
Internet-Draft OSPF for IPv6 May 2008
Neighbor's Backup Designated Router
The neighbor's choice of Backup Designated Router is now encoded
as a Router ID instead of as an IP address.
Neighbor states, events, and the neighbor state machine remain
unchanged from IPv4 as documented in Sections 10.1, 10.2, and 10.3 of
[OSPFV2] respectively. The decision as to which adjacencies to form
also remains unchanged from the IPv4 logic documented in Section 10.4
of [OSPFV2].
4.2. Protocol Packet Processing
OSPF for IPv6 runs directly over IPv6's network layer. As such, it
is encapsulated in one or more IPv6 headers with the Next Header
field of the immediately encapsulating IPv6 header set to the value
89.
As for OSPF for IPv4, OSPF for IPv6 OSPF routing protocol packets are
sent along adjacencies only (with the exception of Hello packets,
which are used to discover the adjacencies). OSPF packet types and
functions are the same in both IPv4 and IPv6, encoded by the Type
field of the standard OSPF packet header.
4.2.1. Sending protocol packets
When an IPv6 router sends an OSPF routing protocol packet, it fills
in the fields of the standard OSPF for IPv6 packet header (see
Appendix A.3.1) as follows:
Version #
Set to 3, the version number of the protocol as documented in this
specification.
Type
The type of OSPF packet, such as Link State Update or Hello
packet.
Packet length
The length of the entire OSPF packet in bytes, including the
standard OSPF packet header.
Router ID
The identity of the router itself (who is originating the packet).
Coltun, et al. Expires November 14, 2008 [Page 20]
Internet-Draft OSPF for IPv6 May 2008
Area ID
The OSPF area for the interface that the packet is being sent on.
Instance ID
The OSPF Instance ID associated with the interface that the packet
is being sent out of.
Checksum
The standard IPv6 Upper-Layer checksum (as described in section
8.1 of [IPV6]) covering the entire OSPF packet and prepended IPv6
pseudo-header (see Appendix A.3.1).
Selection of OSPF routing protocol packets' IPv6 source and
destination addresses is performed identically to the IPv4 logic in
Section 8.1 of [OSPFV2]. The IPv6 destination address is chosen from
among the addresses AllSPFRouters, AllDRouters, and the Neighbor IP
address associated with the other end of the adjacency (which in
IPv6, for all links except virtual links, is an IPv6 link-local
address).
The sending of Link State Request packets and Link State
Acknowledgment packets remains unchanged from the IPv4 procedures
documented in Sections 10.9 and 13.5 of [OSPFV2] respectively.
Sending Hello packets is documented in Section 3.2.1.1, and the
sending of Database Description packets in Section 3.2.1.2. The
sending of Link State Update packets is documented in Section 3.5.2.
4.2.1.1. Sending Hello Packets
IPv6 changes the way OSPF Hello packets are sent in the following
ways (compare to Section 9.5 of [OSPFV2]):
o Before the Hello packet is sent out an interface, the interface's
Interface ID MUST be copied into the Hello packet.
o The Hello packet no longer contains an IP network mask since OSPF
for IPv6 runs per-link instead of per-subnet.
o The choice of Designated Router and Backup Designated Router are
now indicated within Hellos by their Router IDs instead of by
their IP interface addresses. Advertising the Designated Router
(or Backup Designated Router) as 0.0.0.0 indicates that the
Designated Router (or Backup Designated Router) has not yet been
chosen.
o The Options field within Hello packets has moved around, getting
larger in the process. More options bits are now possible. Those
Coltun, et al. Expires November 14, 2008 [Page 21]
Internet-Draft OSPF for IPv6 May 2008
that MUST be set correctly in Hello packets are: The E-bit is set
if and only if the interface attaches to a regular area, i.e., not
a stub or NSSA area. Similarly, the N-bit is set if and only if
the interface attaches to an NSSA area (see [NSSA]). Finally, the
DC-bit is set if and only if the router wishes to suppress the
sending of future Hellos over the interface (see [DEMAND]).
Unrecognized bits in the Hello packet's Options field should be
cleared.
Sending Hello packets on NBMA networks proceeds for IPv6 in exactly
the same way as for IPv4, as documented in Section 9.5.1 of [OSPFV2].
4.2.1.2. Sending Database Description Packets
The sending of Database Description packets differs from Section 10.8
of [OSPFV2] in the following ways:
o The Options field within Database Description packets has moved
around, getting larger in the process. More options bits are now
possible. Those that MUST be set correctly in Database
Description packets are: The DC-bit is set if and only if the
router wishes to suppress the sending of Hellos over the interface
(see [DEMAND]). Unrecognized bits in the Database Description
packet's Options field should be cleared.
4.2.2. Receiving Protocol Packets
Whenever a router receives an OSPF protocol packet it is marked with
the interface it was received on. For routers that have virtual
links configured, it may not be immediately obvious which interface
to associate the packet with. For example, consider the Router RT11
depicted in Figure 6 of [OSPFV2]. If RT11 receives an OSPF protocol
packet on its interface to Network N8, it may want to associate the
packet with the interface to Area 2, or with the virtual link to
Router RT10 (which is part of the backbone). In the following, we
assume that the packet is initially associated with the non-virtual
link.
In order for the packet to be passed to OSPF for processing, the
following tests must be performed on the encapsulating IPv6 headers:
o The packet's IP destination address MUST be one of the IPv6
unicast addresses associated with the receiving interface (this
includes link-local addresses), one of the IPv6 multicast
addresses AllSPFRouters or AllDRouters, or an IPv6 global address
(for virtual links).
Coltun, et al. Expires November 14, 2008 [Page 22]
Internet-Draft OSPF for IPv6 May 2008
o The Next Header field of the immediately encapsulating IPv6 header
MUST specify the OSPF protocol (89).
o Any encapsulating IP Authentication Headers (see [IPAUTH]) and the
IP Encapsulating Security Payloads (see [IPESP]) MUST be processed
and/or verified to ensure integrity and authentication/
confidentiality of OSPF routing exchanges. This is described in
[OSPFV3-AUTH].
After processing the encapsulating IPv6 headers, the OSPF packet
header is processed. The fields specified in the header must match
those configured for the receiving OSPFv3 interface. If they do not,
the packet SHOULD be discarded:
o The version number field MUST specify protocol version 3.
o The IPv6 Upper-Layer checksum (as described in section 8.1 of
[IPV6]), covering the entire OSPF packet and prepended IPv6
pseudo-header, must be verified (see Appendix A.3.1).
o The Area ID and Instance ID found in the OSPF header must be
verified. If both of the following cases fail, the packet should
be discarded. The Area ID and Instance ID specified in the header
must either:
1. Match one of the Area ID(s) and Interface Instance ID(s) for
the receiving link. Unlike IPv4, the IPv6 source address is
not restricted to lie within the same IPv6 subnet as the
receiving link. IPv6 OSPF runs per-link instead of per-IP-
subnet.
2. Match the backbone area and other criteria for a configured
virtual link. The receiving router must be an ABR (Area
Border Router) and the Router ID specified in the packet (the
source router) must be the other end of a configured virtual
link. Additionally, the receiving link must have an OSPFv3
interface which attaches to the virtual link's configured
transit area and the Instance ID must match the virtual link's
Instance ID. If all of these checks succeed, the packet is
accepted and is associated with the virtual link (and the
backbone area).
o Locally originated packets SHOULD NOT be processed by OSPF except
for support of multiple interfaces attached to the same link as
described in Section 4.9. Locally originated packets have a
source address equal to one of the router's local addresses.
Coltun, et al. Expires November 14, 2008 [Page 23]
Internet-Draft OSPF for IPv6 May 2008
o Packets whose IPv6 destination is AllDRouters should only be
accepted if the state of the receiving OSPFv3 interface is DR or
Backup (see Section 9.1 [OSPFV2]).
After header processing, the packet is further processed according to
its OSPF packet type. OSPF packet types and functions are the same
for both IPv4 and IPv6.
If the packet type is Hello, it should then be further processed by
the Hello packet processing as described in Section 4.2.2.1. All
other packet types are sent/received only on adjacencies. This means
that the packet must have been sent by one of the router's active
neighbors. The neighbor is identified by the Router ID appearing in
the received packet's OSPF header. Packets not matching any active
neighbor are discarded.
The receive processing of Database Description packets, Link State
Request packets, and Link State Acknowledgment packets is almost
identical to the IPv4 procedures documented in Sections 10.6, 10.7,
and 13.7 of [OSPFV2] respectively with the exceptions noted below.
o LSAs with unknown LS types in Database Description packets that
have an acceptable flooding scope are processed the same as LSAs
with known LS types. In OSPFv2 [OSPFV2], these would result in
the adjacency being brought down with a SequenceMismatch event.
The receiving of Hello packets is documented in Section 4.2.2.1 and
the receiving of Link State Update packets is documented in
Section 4.5.1.
4.2.2.1. Receiving Hello Packets
The receive processing of Hello packets differs from Section 10.5 of
[OSPFV2] in the following ways:
o On all link types (e.g., broadcast, NBMA, point-to-point, etc),
neighbors are identified solely by their OSPF Router ID. For all
link types except virtual links, the Neighbor IP address is set to
the IPv6 source address in the IPv6 header of the received OSPF
Hello packet.
o There is no longer a Network Mask field in the Hello packet.
o The neighbor's choice of Designated Router and Backup Designated
Router is now encoded as an OSPF Router ID instead of an IP
interface address.
Coltun, et al. Expires November 14, 2008 [Page 24]
Internet-Draft OSPF for IPv6 May 2008
4.3. The Routing table Structure
The routing table used by OSPF for IPv4 is defined in Section 11 of
[OSPFV2]. For IPv6 there are analogous routing table entries: there
are routing table entries for IPv6 address prefixes and also for AS
boundary routers. The latter routing table entries are only used to
hold intermediate results during the routing table build process (see
Section 4.8).
Also, to hold the intermediate results during the shortest-path
calculation for each area, there is a separate routing table for each
area holding the following entries:
o An entry for each router in the area. Routers are identified by
their OSPF router ID. These routing table entries hold the set of
shortest paths through a given area to a given router, which in
turn allows calculation of paths to the IPv6 prefixes advertised
by that router in intra-area-prefix-LSAs. If the router is also
an area-border router, these entries are also used to calculate
paths for inter-area address prefixes. If in addition the router
is the other endpoint of a virtual link, the routing table entry
describes the cost and viability of the virtual link.
o An entry for each transit link in the area. Transit links have
associated network-LSAs. Both the transit link and the network-
LSA are identified by a combination of the Designated Router's
Interface ID on the link and the Designated Router's OSPF Router
ID. These routing table entries allow later calculation of paths
to IP prefixes advertised for the transit link in intra-area-
prefix-LSAs.
The fields in the IPv4 OSPF routing table (see Section 11 of
[OSPFV2]) remain valid for IPv6: Optional capabilities (routers
only), path type, cost, type 2 cost, link state origin, and for each
of the equal cost paths to the destination, the next hop and
advertising router.
For IPv6, the link-state origin field in the routing table entry is
the router-LSA or network-LSA that has directly or indirectly
produced the routing table entry. For example, if the routing table
entry describes a route to an IPv6 prefix, the link state origin is
the router-LSA or network-LSA that is listed in the body of the
intra-area-prefix-LSA that has produced the route (see
Appendix A.4.10).
Coltun, et al. Expires November 14, 2008 [Page 25]
Internet-Draft OSPF for IPv6 May 2008
4.3.1. Routing table lookup
Routing table lookup (i.e., determining the best matching routing
table entry during IP forwarding) is the same for IPv6 as for IPv4.
4.4. Link State Advertisements
For IPv6, the OSPF LSA header has changed slightly, with the LS type
field expanding and the Options field being moved into the body of
appropriate LSAs. Also, the formats of some LSAs have changed
somewhat (namely router-LSAs, network-LSAs, AS-external-LSAs, and
NSSA-LSAs), while the names of other LSAs have been changed (type 3
and 4 summary-LSAs are now inter-area-prefix-LSAs and inter-area-
router-LSAs respectively) and additional LSAs have been added (link-
LSAs and intra-area-prefix-LSAs). Type of Service (TOS) has been
removed from the OSPFv2 specification [OSPFV2], and is not encoded
within OSPF for IPv6's LSAs.
These changes will be described in detail in the following
subsections.
4.4.1. The LSA Header
In both IPv4 and IPv6, all OSPF LSAs begin with a standard 20 byte
LSA header. However, the contents of this 20 byte header have
changed in IPv6. The LS age, Advertising Router, LS Sequence Number,
LS checksum, and length fields within the LSA header remain
unchanged, as documented in Sections 12.1.1, 12.1.5, 12.1.6, 12.1.7
and A.4.1 of [OSPFV2] respectively. However, the following fields
have changed for IPv6:
Options
The Options field has been removed from the standard 20 byte LSA
header and moved into the body of router-LSAs, network-LSAs,
inter-area-router-LSAs, and link-LSAs. The size of the Options
field has increased from 8 to 24 bits, and some of the bit
definitions have changed (see Appendix A.2). Additionally, a
separate PrefixOptions field, 8 bits in length, is attached to
each prefix advertised within the body of an LSA.
LS type
The size of the LS type field has increased from 8 to 16 bits,
with high order bit encoding the handling of unknown types and the
next two bits encoding flooding scope. See Appendix A.4.2.1 for
the current coding of the LS type field.
Coltun, et al. Expires November 14, 2008 [Page 26]
Internet-Draft OSPF for IPv6 May 2008
Link State ID
Link State ID remains at 32 bits in length. However, except for
network-LSAs and link-LSAs, Link State ID has shed any addressing
semantics. For example, an IPv6 router originating multiple AS-
external-LSAs could start by assigning the first a Link State ID
of 0.0.0.1, the second a Link State ID of 0.0.0.2, and so on.
Instead of the IPv4 behavior of encoding the network number within
the AS-external-LSA's Link State ID, the IPv6 Link State ID simply
serves as a way to differentiate multiple LSAs originated by the
same router.
For network-LSAs, the Link State ID is set to the Designated
Router's Interface ID on the link. When a router originates a
link-LSA for a given link, its Link State ID is set equal to the
router's Interface ID on the link.
4.4.2. The link-state database
In IPv6, as in IPv4, individual LSAs are identified by a combination
of their LS type, Link State ID, and Advertising Router fields.
Given two instances of an LSA, the most recent instance is determined
by examining the LSAs' LS Sequence Number, using LS checksum and LS
age as tiebreakers (see Section 13.1 of [OSPFV2]).
In IPv6, the link-state database is split across three separate data
structures. LSAs with AS flooding scope are contained within the
top-level OSPF data structure (see Section 4.1) as long as either
their LS type is known or their U-bit is 1 (flood even when
unrecognized); this includes the AS-external-LSAs. LSAs with area
flooding scope are contained within the appropriate area structure
(see Section 4.1.1) as long as either their LS type is known or their
U-bit is 1 (flood even when unrecognized); this includes router-LSAs,
network-LSAs, inter-area-prefix-LSAs, inter-area-router-LSAs, NSSA-
LSAs, and intra-area-prefix-LSAs. LSAs with unknown LS type and
U-bit set to 0 and/or link-local flooding scope are contained within
the appropriate interface structure (see Section 4.1.2); this
includes link-LSAs.
To lookup or install an LSA in the database, you first examine the LS
type and the LSA's context (i.e., the area or link to which the LSA
belongs). This information allows you to find the correct database
of LSAs where you then search based on the LSA's type, Link State ID,
and Advertising Router.
4.4.3. Originating LSAs
The process of reoriginating an LSA in IPv6 is the same as in IPv4:
the LSA's LS sequence number is incremented, its LS age is set to 0,
its LS checksum is calculated, and the LSA is added to the link state
Coltun, et al. Expires November 14, 2008 [Page 27]
Internet-Draft OSPF for IPv6 May 2008
database and flooded on the appropriate interfaces.
The list of events causing LSAs to be reoriginated for IPv4 is given
in Section 12.4 of [OSPFV2]. The following events and/or actions are
added for IPv6:
o The state or interface ID of one of the router's interfaces
changes. The router may need to (re)originate or flush its link-
LSA and one or more router-LSAs and/or intra-area-prefix-LSAs. If
the router is Designated Router, the router may also need to
(re)originate and/or flush the network LSA corresponding to the
interface.
o The identity of a link's Designated Router changes. The router
may need to (re)originate or flush the link's network-LSA and one
or more router-LSAs and/or intra-area-prefix-LSAs.
o A neighbor transitions to/from "Full" state. The router may need
to (re)originate or flush the link's network-LSA and one or more
router-LSAs and/or intra-area-prefix-LSAs.
o The Interface ID of a neighbor changes. This may cause a new
instance of a router-LSA to be originated for the associated area.
o A new prefix is added to an attached link, or a prefix is deleted
(both through configuration). This causes the router to
reoriginate its link-LSA for the link or, if it is the only router
attached to the link, causes the router to reoriginate an intra-
area-prefix-LSA.
o A new link-LSA is received, causing the link's collection of
prefixes to change. If the router is Designated Router for the
link, it originates a new intra-area-prefix-LSA.
o A new link-LSA is received, causing the logical OR of LSA options
advertised by adjacent routers on the link to change. If the
router is Designated Router for the link, it originates a new
network-LSA.
Detailed construction of the seven required IPv6 LSA types is
supplied by the following subsections. In order to display example
LSAs, the network map in Figure 15 of [OSPFV2] has been reworked to
show IPv6 addressing, resulting in Figure 1. The OSPF cost of each
interface is has been displayed in Figure 1. The assignment of IPv6
prefixes to network links is shown in Table 1. A single area address
range has been configured for Area 1, so that outside of Area 1 all
of its prefixes are covered by a single route to 2001:0db8:c001::/48.
Coltun, et al. Expires November 14, 2008 [Page 28]
Internet-Draft OSPF for IPv6 May 2008
The OSPF interface IDs and the link-local addresses for the router
interfaces in Figure 1 are given in Table 2.
Coltun, et al. Expires November 14, 2008 [Page 29]
Internet-Draft OSPF for IPv6 May 2008
..........................................
. Area 1.
. + .
. | .
. | 3+---+1 .
. N1 |--|RT1|-----+ .
. | +---+ \ .
. | \ ______ .
. + \/ \ 1+---+
. * N3 *------|RT4|------
. + /\_______/ +---+
. | / | .
. | 3+---+1 / | .
. N2 |--|RT2|-----+ 1| .
. | +---+ +---+ .
. | |RT3|----------------
. + +---+ .
. |2 .
. | .
. +------------+ .
. N4 .
..........................................
Figure 1: Area 1 with IP addresses shown
Network IPv6 prefix
-----------------------------------
N1 2001:0db8:c001:0200::/56
N2 2001:0db8:c001:0300::/56
N3 2001:0db8:c001:0100::/56
N4 2001:0db8:c001:0400::/56
Table 1: IPv6 link prefixes for sample network
Router Interface Interface ID link-local address
-------------------------------------------------------
RT1 to N1 1 fe80:0001::RT1
to N3 2 fe80:0002::RT1
RT2 to N2 1 fe80:0001::RT2
to N3 2 fe80:0002::RT2
RT3 to N3 1 fe80:0001::RT3
to N4 2 fe80:0002::RT3
RT4 to N3 1 fe80:0001::RT4
Table 2: OSPF Interface IDs and link-local addresses
Coltun, et al. Expires November 14, 2008 [Page 30]
Internet-Draft OSPF for IPv6 May 2008
Figure 1
4.4.3.1. LSA Options
The Options field in LSAs should be coded as follows. The V6-bit
should be set unless the router will not participate in transit IPv6
routing. The E-bit should be clear if and only if the attached area
is an OSPF stub or OSPF NSSA area. The E-bit should always be set in
AS scoped LSAs. The N-bit should be set if and only if the attached
area is an OSPF NSSA area. The R-bit should be set unless the router
will not participate in any transit routing. The DC-bit should be
set if and only if the router can correctly process the DoNotAge bit
when it appears in the LS age field of LSAs (see [DEMAND]). All
unrecognized bits in the Options field should be cleared.
The V6-bit and R-bit are only examined in Router-LSAs during the SPF
computation. In other LSA types containing options, they are set for
informational purposes only.
4.4.3.2. Router-LSAs
The LS type of a router-LSA is set to the value 0x2001. Router-LSAs
have area flooding scope. A router MAY originate one or more router-
LSAs for a given area. Each router-LSA contains an integral number
of interface descriptions. Taken together, the collection of router-
LSAs originated by the router for an area describes the collected
states of all the router's interfaces attached to the area. When
multiple router-LSAs are used, they are distinguished by their Link
State ID fields.
To the left of the Options field, the router capability bits V, E,
and B should be set according to Section 12.4.1 of [OSPFV2].
Each of the router's interfaces to the area are then described by
appending "link descriptions" to the router-LSA. Each link
description is 16 bytes long, consisting of 5 fields: (link) Type,
Metric, Interface ID, Neighbor Interface ID, and Neighbor Router ID
(see Appendix A.4.3). Interfaces in state "Down" or "Loopback" are
not described (although looped back interfaces can contribute
prefixes to intra-area-prefix-LSAs). Nor are interfaces without any
full adjacencies described (except in the case of multiple standby
interfaces as described in Section 4.9). All other interfaces to the
area add zero, one, or more link descriptions. The number and
content of these depend on the interface type. Within each link
description, the Metric field is always set to the interface's output
cost and the Interface ID field is set to the interface's OSPF
Interface ID.
Coltun, et al. Expires November 14, 2008 [Page 31]
Internet-Draft OSPF for IPv6 May 2008
Point-to-point interfaces
If the neighboring router is fully adjacent, add a Type 1 link
description (point-to-point). The Neighbor Interface ID field is
set to the Interface ID advertised by the neighbor in its Hello
packets and the Neighbor Router ID field is set to the neighbor's
Router ID.
Broadcast and NBMA interfaces
If the router is fully adjacent to the link's Designated Router or
if the router itself is Designated Router and is fully adjacent to
at least one other router, add a single Type 2 link description
(transit network). The Neighbor Interface ID field is set to the
Interface ID advertised by the Designated Router in its Hello
packets and the Neighbor Router ID field is set to the Designated
Router's Router ID.
Virtual links
If the neighboring router is fully adjacent, add a Type 4 link
description (virtual). The Neighbor Interface ID field is set to
the Interface ID advertised by the neighbor in its Hello packets
and the Neighbor Router ID field is set to the neighbor's Router
ID. Note that the output cost of a virtual link is calculated
during the routing table calculation (see Section 4.7).
Point-to-Multipoint interfaces
For each fully adjacent neighbor associated with the interface,
add a separate Type 1 link description (point-to-point) with
Neighbor Interface ID field set to the Interface ID advertised by
the neighbor in its Hello packets and Neighbor Router ID field set
to the neighbor's Router ID.
As an example, consider the router-LSA that router RT3 would
originate for Area 1 in Figure 1. Only a single interface must be
described, namely that which connects to the transit network N3. It
assumes that RT4 has been elected Designated Router of Network N3.
Coltun, et al. Expires November 14, 2008 [Page 32]
Internet-Draft OSPF for IPv6 May 2008
; RT3's router-LSA for Area 1
LS age = 0 ;newly (re)originated
LS type = 0x2001 ;router-LSA
Link State ID = 0 ;first fragment
Advertising Router = 192.0.2.3 ;RT3's Router ID
bit E = 0 ;not an AS boundary router
bit B = 1 ;area border router
Options = (V6-bit|E-bit|R-bit)
Type = 2 ;connects to N3
Metric = 1 ;cost to N3
Interface ID = 1 ;RT3's Interface ID on N3
Neighbor Interface ID = 1 ;RT4's Interface ID on N3
Neighbor Router ID = 192.0.2.4 ; RT4's Router ID
RT3's router-LSA for Area 1
For example, if another router was added to Network N4, RT3 would
have to advertise a second link description for its connection to
(the now transit) network N4. This could be accomplished by
reoriginating the above router-LSA, this time with two link
descriptions. Or, a separate router-LSA could be originated with a
separate Link State ID (e.g., using a Link State ID of 1) to describe
the connection to N4.
Host routes for stub networks no longer appear in the router-LSA.
Rather, they are included in intra-area-prefix-LSAs.
4.4.3.3. Network-LSAs
The LS type of a network-LSA is set to the value 0x2002. Network-
LSAs have area flooding scope. A network-LSA is originated for every
broadcast or NBMA link with an elected Designated Router that is
fully adjacent with at least one other router on the link. The
network-LSA is originated by the link's Designated Router and lists
all routers on the link with whom it is fully adjacent.
The procedure for originating network-LSAs in IPv6 is the same as the
IPv4 procedure documented in Section 12.4.2 of [OSPFV2], with the
following exceptions:
o An IPv6 network-LSA's Link State ID is set to the Interface ID of
the Designated Router on the link.
o IPv6 network-LSAs do not contain a Network Mask. All addressing
information formerly contained in the IPv4 network-LSA has now
been consigned to intra-Area-Prefix-LSAs originated by the link's
Coltun, et al. Expires November 14, 2008 [Page 33]
Internet-Draft OSPF for IPv6 May 2008
Designated Router.
o The Options field in the network-LSA is set to the logical OR of
the Options fields contained within the link's associated link-
LSAs corresponding to fully adjacent neighbors. In this way, the
network link exhibits a capability when at least one fully
adjacent neighbor on the link requests that the capability be
advertised.
As an example, assuming that Router RT4 has been elected Designated
Router of Network N3 in Figure 1, the following network-LSA is
originated:
; Network-LSA for Network N3
LS age = 0 ;newly (re)originated
LS type = 0x2002 ;network-LSA
Link State ID = 1 ;RT4's Interface ID on N3
Advertising Router = 192.0.2.4 ;RT4's Router ID
Options = (V6-bit|E-bit|R-bit)
Attached Router = 192.0.2.4 ;Router ID
Attached Router = 192.0.2.1 ;Router ID
Attached Router = 192.0.2.2 ;Router ID
Attached Router = 192.0.2.3 ;Router ID
Network-LSA for Network N3
4.4.3.4. Inter-Area-Prefix-LSAs
The LS type of an inter-area-prefix-LSA is set to the value 0x2003.
Inter-area-prefix-LSAs have area flooding scope. In IPv4, inter-
area-prefix-LSAs were called type 3 summary-LSAs. Each inter-area-
prefix-LSA describes a prefix external to the area yet internal to
the Autonomous System.
The procedure for originating inter-area-prefix-LSAs in IPv6 is the
same as the IPv4 procedure documented in Sections 12.4.3 and 12.4.3.1
of [OSPFV2], with the following exceptions:
o The Link State ID of an inter-area-prefix-LSA has lost all of its
addressing semantics and simply serves to distinguish multiple
inter-area-prefix-LSAs that are originated by the same router.
o The prefix is described by the PrefixLength, PrefixOptions, and
Address Prefix fields embedded within the LSA body. Network Mask
is no longer specified.
Coltun, et al. Expires November 14, 2008 [Page 34]
Internet-Draft OSPF for IPv6 May 2008
o The NU-bit in the PrefixOptions field should be clear.
o Link-local addresses MUST never be advertised in inter-area-
prefix-LSAs.
As an example, the following shows the inter-area-prefix-LSA that
Router RT4 originates into the OSPF backbone area, condensing all of
Area 1's prefixes into the single prefix 2001:0db8:c001::/48. The
cost is set to 4, which is the maximum cost of all of the individual
component prefixes. The prefix is padded out to an even number of
32-bit words, so that it consumes 64-bits of space instead of 48
bits.
; Inter-area-prefix-LSA for Area 1 addresses
; originated by Router RT4 into the backbone
LS age = 0 ;newly (re)originated
LS type = 0x2003 ;inter-area-prefix-LSA
Advertising Router = 192.0.2.4 ;RT4's ID
Metric = 4 ;maximum to components
PrefixLength = 48
PrefixOptions = 0
Address Prefix = 2001:0db8:c001 ;padded to 64-bits
Inter-area-prefix-LSA for Area 1 addresses originated
by Router
RT4 into the backbone
4.4.3.5. Inter-Area-Router-LSAs
The LS type of an inter-area-router-LSA is set to the value 0x2004.
Inter-area-router-LSAs have area flooding scope. In IPv4, inter-
area-router-LSAs were called type 4 summary-LSAs. Each inter-area-
router-LSA describes a path to a destination OSPF router (an AS
Boundary Router or ASBR) that is external to the area yet internal to
the Autonomous System.
The procedure for originating inter-area-router-LSAs in IPv6 is the
same as the IPv4 procedure documented in Section 12.4.3 of [OSPFV2],
with the following exceptions:
o The Link State ID of an inter-area-router-LSA is no longer the
destination router's OSPF Router ID and now simply serves to
distinguish multiple inter-area-router-LSAs that are originated by
the same router. The destination router's Router ID is now found
in the body of the LSA.
Coltun, et al. Expires November 14, 2008 [Page 35]
Internet-Draft OSPF for IPv6 May 2008
o The Options field in an inter-area-router-LSA should be set equal
to the Options field contained in the destination router's own
router-LSA. The Options field thus describes the capabilities
supported by the destination router.
As an example, consider the OSPF Autonomous System depicted in Figure
6 of [OSPFV2]. Router RT4 would originate into Area 1 the following
inter-area-router-LSA for destination router RT7.
; inter-area-router-LSA for AS boundary router RT7
; originated by Router RT4 into Area 1
LS age = 0 ;newly (re)originated
LS type = 0x2004 ;inter-area-router-LSA
Advertising Router = 192.0.2.4 ;RT4's ID
Options = (V6-bit|E-bit|R-bit) ;RT7's capabilities
Metric = 14 ;cost to RT7
Destination Router ID = Router RT7's ID
Inter-area-router-LSA for AS boundary router RT7
originated by
Router RT4 into Area 1
4.4.3.6. AS-external-LSAs
The LS type of an AS-external-LSA is set to the value 0x4005. AS-
external-LSAs have AS flooding scope. Each AS-external-LSA describes
a path to a prefix external to the Autonomous System.
The procedure for originating AS-external-LSAs in IPv6 is the same as
the IPv4 procedure documented in Section 12.4.4 of [OSPFV2], with the
following exceptions:
o The Link State ID of an AS-external-LSA has lost all of its
addressing semantics and simply serves to distinguish multiple AS-
external-LSAs that are originated by the same router.
o The prefix is described by the PrefixLength, PrefixOptions, and
Address Prefix fields embedded within the LSA body. Network Mask
is no longer specified.
o The NU-bit in the PrefixOptions field should be clear.
o Link-local addresses can never be advertised in AS-external-LSAs.
o The forwarding address is present in the AS-external-LSA if and
only if the AS-external-LSA's bit F is set.
Coltun, et al. Expires November 14, 2008 [Page 36]
Internet-Draft OSPF for IPv6 May 2008
o The external route tag is present in the AS-external-LSA if and
only if the AS-external-LSA's bit T is set.
o The capability for an AS-external-LSA to reference another LSA has
been supported through the inclusion of the Referenced LS Type
field and the optional Referenced Link State ID field (the latter
present if and only if Referenced LS Type is non-zero). This
capability is for future use; Referenced LS Type should be set to
0 and received non-zero values for this field should be ignored
until its use is defined.
As an example, consider the OSPF Autonomous System depicted in Figure
6 of [OSPFV2]. Assume that RT7 has learned its route to N12 via BGP,
and that it wishes to advertise a Type 2 metric into the AS. Also
assume that the IPv6 prefix for N12 is the value 2001:0db8:0a00::/40.
RT7 would then originate the following AS-external-LSA for the
external network N12. Note that within the AS-external-LSA, N12's
prefix occupies 64 bits of space in order to maintain 32-bit
alignment.
; AS-external-LSA for Network N12,
; originated by Router RT7
LS age = 0 ;newly (re)originated
LS type = 0x4005 ;AS-external-LSA
Link State ID = 123 ;or something else
Advertising Router = Router RT7's ID
bit E = 1 ;Type 2 metric
bit F = 0 ;no forwarding address
bit T = 1 ;external route tag included
Metric = 2
PrefixLength = 40
PrefixOptions = 0
Referenced LS Type = 0 ;no Referenced Link State ID
Address Prefix = 2001:0db8:0a00 ;padded to 64-bits
External Route Tag = as per BGP/OSPF interaction
AS-external-LSA for Network N12, originated by Router RT7
4.4.3.7. NSSA-LSAs
The LS type of an NSSA-LSA is set to the value 0x2007. NSSA-LSAs
have area flooding scope. Each NSSA-LSA describes a path to a prefix
external to the Autonomous System whose flooding scope is restricted
to a single NSSA area.
The procedure for originating NSSA-LSAs in IPv6 is the same as the
IPv4 procedure documented in [NSSA], with the following exceptions:
Coltun, et al. Expires November 14, 2008 [Page 37]
Internet-Draft OSPF for IPv6 May 2008
o The Link State ID of an NSSA-LSA has lost all of its addressing
semantics and simply serves to distinguish multiple NSSA-LSAs that
are originated by the same router in the same area.
o The prefix is described by the PrefixLength, PrefixOptions, and
Address Prefix fields embedded within the LSA body. Network Mask
is no longer specified.
o The NU-bit in the PrefixOptions field should be clear.
o Link-local addresses can never be advertised in NSSA-LSAs.
o The forwarding address is present in the NSSA-LSA if and only if
the NSSA-LSA's bit F is set.
o The external route tag is present in the NSSA-LSA if and only if
the NSSA-LSA's bit T is set.
o The capability for an NSSA-LSA to reference another LSA has been
supported through the inclusion of the Referenced LS Type field
and the optional Referenced Link State ID field (the latter
present if and only if Referenced LS Type is non-zero). This
capability is for future use; Referenced LS Type should be set to
0 and received non-zero values for this field should be ignored
until its use is defined.
An example of an NSSA-LSA would only differ from an AS-external-LSA
in that the LS type would be 0x2007 rather than 0x4005.
4.4.3.8. Link-LSAs
The LS type of a link-LSA is set to the value 0x0008. Link-LSAs have
link-local flooding scope. A router originates a separate link-LSA
for each attached link that supports 2 or more (including the
originating router itself) routers. Link-LSAs SHOULD NOT be
originated for virtual links.
Link-LSAs have three purposes:
1. They provide the router's link-local address to all other routers
attached to the link.
2. They inform other routers attached to the link of a list of IPv6
prefixes to associate with the link.
3. They allow the router to advertise a collection of Options bits
in the network-LSA originated by the Designated Router on a
Coltun, et al. Expires November 14, 2008 [Page 38]
Internet-Draft OSPF for IPv6 May 2008
broadcast or NBMA link.
A link-LSA for a given Link L is built in the following fashion:
o The Link State ID is set to the router's Interface ID on Link L.
o The Router Priority of the router's interface to Link L is
inserted into the link-LSA.
o The link-LSA's Options field is set to those bits that the router
wishes set in Link L's Network LSA.
o The router inserts its link-local address on Link L into the link-
LSA. This information will be used when the other routers on Link
L do their next hop calculations (see Section 4.8.2).
o Each IPv6 address prefix that has been configured on Link L is
added to the link-LSA by specifying values for PrefixLength,
PrefixOptions, and Address Prefix fields.
After building a link-LSA for a given link, the router installs the
link-LSA into the associated interface data structure and floods the
link-LSA on the link. All other routers on the link will receive the
link-LSA but they will not flood the link-LSA on other links.
If LinkLSASuppression is configured for the interface and the
interface type is not broadcast or NBMA, origination of the Link-LSA
may be suppressed. This implies that other routers on the link will
ascertain the router's next-hop address using a mechanism other than
the Link-LSA (see Section 4.8.2). Refer to Appendix C.3 for a
description of the LinkLSASuppression interface configuration
parameter.
As an example, consider the link-LSA that RT3 will build for N3 in
Figure 1. Suppose that the prefix 2001:0db8:c001:0100::/56 has been
configured within RT3 for N3. This will result in the following
link-LSA that RT3 will flood only on N3. Note that not all routers
on N3 need be configured with the prefix; those not configured will
learn the prefix when receiving RT3's link-LSA.
Coltun, et al. Expires November 14, 2008 [Page 39]
Internet-Draft OSPF for IPv6 May 2008
; RT3's link-LSA for N3
LS age = 0 ;newly (re)originated
LS type = 0x0008 ;Link-LSA
Link State ID = 1 ;RT3's Interface ID on N3
Advertising Router = 192.0.2.3 ;RT3's Router ID
Rtr Priority = 1 ;RT3's N3 Router Priority
Options = (V6-bit|E-bit|R-bit)
Link-local Interface Address = fe80:0001::RT3
# prefixes = 1
PrefixLength = 56
PrefixOptions = 0
Address Prefix = 2001:0db8:c001:0100 ;pad to 64-bits
RT3's link-LSA for N3
4.4.3.9. Intra-Area-Prefix-LSAs
The LS type of an intra-area-prefix-LSA is set to the value 0x2009.
Intra-area-prefix-LSAs have area flooding scope. An intra-area-
prefix-LSA has one of two functions. It either associates a list of
IPv6 address prefixes with a transit network link by referencing a
network-LSA, or associates a list of IPv6 address prefixes with a
router by referencing a router-LSA. A stub link's prefixes are
associated with its attached router.
A router MAY originate multiple intra-area-prefix-LSAs for a given
area. Each intra-area-prefix-LSA has a unique Link-State ID and
contains an integral number of prefix descriptions.
A link's Designated Router originates one or more intra-area-prefix-
LSAs to advertise the link's prefixes throughout the area. For a
link L, L's Designated Router builds an intra-area-prefix-LSA in the
following fashion:
o In order to indicate that the prefixes are to be associated with
the Link L, the fields Referenced LS Type, Referenced Link State
ID, and Referenced Advertising Router are set to the corresponding
fields in Link L's network-LSA (namely LS type, Link State ID, and
Advertising Router respectively). This means that Referenced LS
Type is set to 0x2002, Referenced Link State ID is set to the
Designated Router's Interface ID on Link L, and Referenced
Advertising Router is set to the Designated Router's Router ID.
o Each link-LSA associated with Link L is examined (these are in the
Designated Router's interface structure for Link L). If the link-
LSA's Advertising Router is fully adjacent to the Designated
Coltun, et al. Expires November 14, 2008 [Page 40]
Internet-Draft OSPF for IPv6 May 2008
Router and the Link State ID matches the neighbor's interface ID,
the list of prefixes in the link-LSA is copied into the intra-
area-prefix-LSA that is being built. Prefixes having the NU-bit
and/or LA-bit set in their Options field SHOULD NOT be copied, nor
should link-local addresses be copied. Each prefix is described
by the PrefixLength, PrefixOptions, and Address Prefix fields.
Multiple prefixes having the same PrefixLength and Address Prefix
are considered to be duplicates. In this case their Prefix
Options fields should be logically OR'ed together and a single
instance of the duplicate prefix should be included in the intra-
area-prefix-LSA. The Metric field for all prefixes is set to 0.
o The "# prefixes" field is set to the number of prefixes that the
router has copied into the LSA. If necessary, the list of
prefixes can be spread across multiple intra-area-prefix-LSAs in
order to keep the LSA size small.
A router builds an intra-area-prefix-LSA to advertise prefixes for
its attached stub links, looped back interfaces, and hosts. A Router
RTX would build its intra-area-prefix-LSA in the following fashion:
o In order to indicate that the prefixes are to be associated with
the Router RTX itself, RTX sets Referenced LS Type to 0x2001,
Referenced Link State ID to 0, and Referenced Advertising Router
to RTX's own Router ID.
o Router RTX examines its list of interfaces to the area. If the
interface is in state Down, its prefixes are not included. If the
interface has been reported in RTX's router-LSA as a Type 2 link
description (link to transit network), prefixes which will be
included in the intra-area-prefix-LSA for the link are skipped.
However, any prefixes which would normally have the LA-bit set
SHOULD be advertised independent of whether or not the interface
is advertised as a transit link. If the interface type is Point-
to-Multipoint or the interface is in state Loopback, the global
scope IPv6 addresses associated with the interface (if any) are
copied into the intra-area-prefix-LSA with the PrefixOptions LA-
bit set, the PrefixLength set to 128, and the metric set to 0.
Otherwise, the list of global prefixes configured in RTX for the
link are copied into the intra-area-prefix-LSA by specifying the
PrefixLength, PrefixOptions, and Address Prefix fields. The
Metric field for each of these prefixes is set to the interface's
output cost.
o RTX adds the IPv6 prefixes for any directly attached hosts
belonging to the area (see Appendix C.7) to the intra-area-prefix-
LSA.
Coltun, et al. Expires November 14, 2008 [Page 41]
Internet-Draft OSPF for IPv6 May 2008
o If RTX has one or more virtual links configured through the area,
it includes one of its global scope IPv6 interface addresses in
the LSA (if it hasn't already), setting the LA-bit in the
PrefixOptions field, the PrefixLength to 128, and the Metric to 0.
This information will be used later in the routing calculation so
that the two ends of the virtual link can discover each other's
IPv6 addresses.
o The "# prefixes" field is set to the number of prefixes that the
router has copied into the LSA. If necessary, the list of
prefixes can be spread across multiple intra-area-prefix-LSAs in
order to keep the LSA size small.
For example, the intra-area-prefix-LSA originated by RT4 for Network
N3 (assuming that RT4 is N3's Designated Router), and the intra-area-
prefix-LSA originated into Area 1 by Router RT3 for its own prefixes,
are pictured below.
; RT4's Intra-area-prefix-LSA for network link N3
LS age = 0 ;newly (re)originated
LS type = 0x2009 ;Intra-area-prefix-LSA
Link State ID = 5 ;or something
Advertising Router = 192.0.2.4 ;RT4's Router ID
# prefixes = 1
Referenced LS Type = 0x2002 ;network-LSA reference
Referenced Link State ID = 1
Referenced Advertising Router = 192.0.2.4
PrefixLength = 56 ;N3's prefix
PrefixOptions = 0
Metric = 0
Address Prefix = 2001:0db8:c001:0100 ;pad
; RT3's Intra-area-prefix-LSA for its own prefixes
LS age = 0 ;newly (re)originated
LS type = 0x2009 ;Intra-area-prefix-LSA
Link State ID = 177 ;or something
Advertising Router = 192.0.2.3 ;RT3's Router ID
# prefixes = 1
Referenced LS Type = 0x2001 ;router-LSA reference
Referenced Link State ID = 0
Referenced Advertising Router = 192.0.2.3
PrefixLength = 56 ;N4's prefix
PrefixOptions = 0
Metric = 2 ;N4 interface cost
Address Prefix = 2001:0db8:c001:0400 ;pad
Coltun, et al. Expires November 14, 2008 [Page 42]
Internet-Draft OSPF for IPv6 May 2008
Intra-area-prefix-LSA for network link N3
When network conditions change, it may be necessary for a router to
move prefixes from one intra-area-prefix-LSA to another. For
example, if the router is Designated Router for a link but the link
has no other attached routers, the link's prefixes are advertised in
an intra-area-prefix-LSA referring to the Designated Router's router-
LSA. When additional routers appear on the link, a network-LSA is
originated for the link and the l