Open Shortest Path First for IPv6
Template:TOC-right A standard IP routing protocol, Open Shortest Path First, has been issued in a major new version,[1] which can handle both Internet Protocol version 4 and Internet Protocol version 6. Familiarity with basic Open Shortest Path First (OSPF) and link state routing terminology is assumed in this article.
In some respects, readers will find that OSPF packets are simpler, in that this protocol allows IPv6 headers to do a number of things that previous OSPF did itself, occasionally duplicating IPv4 functionality. The packet headers do not contain source and destination addresses. Another simplification of the header is that OSPF-specific authentication has been removed, since the Authentication Header and Encapsulating Security Payload headers of IPv6 provide a quite adequate authentication function.
It remains true that most OSPF packets consist of a general-purpose header, and, in most packets, a variable number of Link State Advertisements. The most striking difference, however, is that the headers, and most of the LSAs, do not carry addresses, but a more compact identifier — which also gets around the problem of determining the type of address carried in an LSA. Actual addresses, IPv4 and IPv6, are only carried in Link State Updates.
Terminology changes
Due to the need to carry more than one kind of address, some of which will be quite long, terminology often has been generalized. Some data structures also have become less dependent on IPv4 conventions: where OSPFv2 encoded subnet identifications as a 32-bit address and a 32-bit subnet mask, the new version has the prefix, but uses the CIDR convention of an integer for prefix length rather than a mask. Since discontiguous masks have not been used in years, the /length notation is more readable and more general, but also more compact in storage.
Generalizing identifiers
There are many places, in all OSPF versions, where fields are 32 bits long. Simply because a field is 32 bits long, and may even be displayed in the format of an IPv4 address, does not mean that the field has to be a valid IPv4 address. Since OSPF for IPv6 continues to retain 32-bit identifiers in many places, even though all its actual addressing is IPv6, getting into the habit of thinking "identifier" rather than "address" will enormously simplify OSPF for IPv6 deployment.
Generalizing links
Some places in OSPFv2 used addresses when all that was needed by an identifier. That consumed address space, but could also lead to ambiguities. The need for address uniqueness was one reason that a single "link" could belong to only one OSPF instance.
Previous OSPF flooded information in what it called "networks", which were actually IPv4 subnets. OSPF for v6 floods on links, which may contain multiple subnets; note that from the IP standpoint, virtual local area networks (VLAN) are different links.
OSPF packets
There remain five OSPF packet types, with a header, and, in four of the five cases, a variable number of link state advertisements (LSA). This is still true, but the header and LSAs often have been both simplified and generalized.
To review relationships, Hellos are used in interface initialization, learning about the other routers on the common link, and to detect router failures. Database description are means of initializing the topology information.
Link state request, link state update, and link state acknowledgement work together as parts of the same function: efficiently propagating confirmed information about topology changes, both announcement and withdrawal of elements of the topology.
Packet header
This is much the same as in earlier versions, but simpler, with such things as addresses and authentication removed because IPv6 adequately performs their functions.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version # | Type | Packet length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Instance ID | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Instance ID is new; it relaxes the requirement for unique area and router identifiers and allows multiple instances of OSPF to coexist (i.e., multiple independent OSPF routing domains.
Packet type
Hello packet
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | 1 | Packet Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Instance ID | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rtr Priority | Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HelloInterval | RouterDeadInterval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Designated Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Backup Designated Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...
Database description
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+
| 3 | 2 | Packet Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+
| Checksum | Instance ID | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+
| 0 | Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+
| Interface MTU | 0 |0|0|0|0|0|I|M|MS|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+
| DD sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+
| |
+- -+
| |
+- An LSA Header -+
| |
+- -+
| |
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+
| ... |
Link state request
In the link state request/update procedure, the requesting router has learned that some of its information is outdated, and it wants to get the most recent instance of information about the topologic element.
Each LSA requested is specified by its LS type, Link State ID, and Advertising Router. This uniquely identifies the LSA without specifying its instance. Link State Request packets are understood to be requests for the most recent instance of the specified LSAs.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | 3 | Packet Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Instance ID | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | LS Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
Link state update
This is the only type of OSPF packet that now carries complete topology informtion information, although the common information here is not address-dependent. The address-dependent information is in an LSA.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | 4 | Packet Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Instance ID | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # LSAs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- +-+
| LSAs |
+- +-+
| ... |
Link state acknowledgement
Link state advertisements
New LSAs are more general. While they now can carry IPv4 or IPv6 information, there is no reason they cannot handle additional types of addresses.
LSA header
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Age | LS Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IP prefix representation and options
IPv6 addresses are bit strings of length 128. IPv6 routing protocols, and OSPF for IPv6 in particular, advertise IPv6 address prefixes. IPv6 address prefixes are bit strings whose length ranges between 0 and 128 bits (inclusive).
Within OSPF, IPv6 address prefixes are always represented by a combination of three fields: PrefixLength, PrefixOptions, and Address Prefix. PrefixLength is the length in bits of the prefix. PrefixOptions is an 8-bit field describing various capabilities associated with the prefix (see Appendix A.4.1.1). Address Prefix is an encoding of the prefix itself as an even multiple of 32-bit words, padding with zero bits as necessary. This encoding consumes ((PrefixLength + 31) / 32) 32-bit words.
Each prefix is advertised along with an 8-bit field of capabilities. These serve as input to the various routing calculations. For example, they can indicate that prefixes are to be ignored in some cases or are to be marked as not readvertisable in others.
0 1 2 3 4 5 6 7
+--+--+--+--+--+-+--+--+
| | | |DN| P|x|LA|NU|
+--+--+--+--+--+-+--+--+
The PrefixOptions Field
NU-bit
The "no unicast" capability bit. If set, the prefix should be
excluded from IPv6 unicast calculations. If not set, it should be
included.
LA-bit
The "local address" capability bit. If set, the prefix is
actually an IPv6 interface address of the Advertising Router.
Advertisement of local interface addresses is described in
Section 4.4.3.9. An implementation MAY also set the LA-bit for
prefixes advertised with a host PrefixLength (128).
x-bit
This bit was previously defined as a "multicast" capability bit.
However, the use was never adequately specified and has been
deprecated for OSPFv3. The bit should be set to 0 and ignored
when received. It may be reassigned in the future.
P-bit
The "propagate" bit. Set on NSSA area prefixes that should be
readvertised by the translating NSSA area border [NSSA].
DN-bit
This bit controls an inter-area-prefix-LSAs or AS-external-LSAs
re-advertisement in a VPN environment as specified in [DN-BIT].
LSA types
The LS type field indicates the function performed by the LSA. The high-order three bits of LS type encode generic properties of the LSA, while the remainder (called LSA function code) indicate the LSA's specific functionality. The format of the LS type is as follows:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|U |S2|S1| LSA Function Code |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
LSA Type
The U-bit indicates how the LSA should be handled by a router that does not recognize the LSA's function code. Its values are:
U-bit LSA Handling
-------------------------------------------------------------
0 Treat the LSA as if it had link-local flooding scope
1 Store and flood the LSA as if the type is understood
U-Bit
The S1 and S2 bits indicate the flooding scope of the LSA. The values are:
S2 S1 Flooding Scope
-------------------------------------------------------------
0 0 Link-Local Scoping - Flooded only on originating link
0 1 Area Scoping - Flooded only in originating area
1 0 AS Scoping - Flooded throughout AS
1 1 Reserved
Flooding Scope
There are several new codes, and one old but deprecated code Type 6 was used for OSPF multicast, which is deprecated. The LSA type also infers values for U, S1, and S2 bits
Note that the LSA names and numbers differ from those in OSPFv2
| Name | Function code | LS type |
|---|---|---|
| Router-LSA | 1 | 0x2001 |
| Network-LSA | 2 | 0x2003 |
| Inter-area-prefix-LSA | 3 | 0x2003 |
| Inter-area-router-LSA | 4 | 0x2004 |
| AS-External-LSA | 5 | 0x2001 |
| Deprecated; may be reassigned | 6 | 0x2006 |
| NSSA-LSA | 7 | 0x2007 |
| Router-LSA | 8 | 0x0008 |
| Intra-area-prefix LSA | 9 | 0x2009 |
Deployment
Cisco
Juniper
Juniper supports core functions of OSPF for IPv6, although some features in OSPFv2 are not currently support the following features in OSPF for IPv6. Some of the unsupported features are traditional in OSPFv2, but not necessarily the best practice even there.[3]
- Virtual link
- Not-so-stubby-area (NSSA)
- Nonbroadcast multiaccess (NBMA)
- Remote neighbor
- Traffic engineering extensions
- SNMP traps
- Features specified in "OSPF as the PE/CE Protocol in BGP/MPLS IP VPNs" (draft-ietf-l3vpn-ospf-2547)
Nortel
Quagga
Quagga has limited RFC2740 support. It does not implement areas.[4]
References
- ↑ R. Coltun, D. Ferguson, J. Moy, A. Lindem (July 2008), OSPF for IPv6, RFC5340
- ↑ Cisco Systems, Implementing OSPF for IPv6
- ↑ Juniper Networks, Configuring OSPF: Features
- ↑ Quagga Routing Software Suite