< draft-ietf-ospf-ospfv3-lsa-extend-01.txt   draft-ietf-ospf-ospfv3-lsa-extend-02.txt >
Network Working Group A. Lindem Network Working Group A. Lindem
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Standards Track S. Mirtorabi Intended status: Standards Track S. Mirtorabi
Expires: August 14, 2014 A. Roy Expires: October 20, 2014 A. Roy
F. Baker F. Baker
Cisco Systems Cisco Systems
February 10, 2014 April 18, 2014
OSPFv3 LSA Extendibility OSPFv3 LSA Extendibility
draft-ietf-ospf-ospfv3-lsa-extend-01.txt draft-ietf-ospf-ospfv3-lsa-extend-02.txt
Abstract Abstract
OSPFv3 requires functional extension beyond what can readily be done OSPFv3 requires functional extension beyond what can readily be done
with the fixed-format Link State Advertisement (LSA) as described in with the fixed-format Link State Advertisement (LSA) as described in
RFC 5340. Without LSA extension, attributes associated with OSPFv3 RFC 5340. Without LSA extension, attributes associated with OSPFv3
links and advertised IPv6 prefixes must be advertised in separate links and advertised IPv6 prefixes must be advertised in separate
LSAs and correlated to the fixed-format LSA. This document extends LSAs and correlated to the fixed-format LSAs. This document extends
the LSA format by allowing the optional inclusion of Type-Length- the LSA format by encoding the existing OSPFv3 LSA information in
Value (TLV) tuples in the LSAs. Backward compatibility mechanisms Type-Length-Value (TLV) tuples and allowing advertisement of
are also described. additional information with additional TLVs. Backward compatibility
mechanisms are also described.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 14, 2014. This Internet-Draft will expire on October 20, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 11 skipping to change at page 3, line 11
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements notation . . . . . . . . . . . . . . . . . . 4 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 4
1.2. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 4 1.2. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 4
2. OSPFv3 Extended LSA Types . . . . . . . . . . . . . . . . . . 6 2. OSPFv3 Extended LSA Types . . . . . . . . . . . . . . . . . . 6
3. OSPFv3 Extended LSA TLV . . . . . . . . . . . . . . . . . . . 7 3. OSPFv3 Extended LSA TLVs . . . . . . . . . . . . . . . . . . . 7
4. OSPFv3 E-Router-LSA . . . . . . . . . . . . . . . . . . . . . 8 3.1. Router-Link TLVs . . . . . . . . . . . . . . . . . . . . . 8
5. OSPFv3 E-Network-LSA . . . . . . . . . . . . . . . . . . . . . 10 3.2. Attached-Routers TLV . . . . . . . . . . . . . . . . . . . 9
6. OSPFv3 E-Inter-Area-Prefix-LSA . . . . . . . . . . . . . . . . 12 3.3. Inter-Area-Prefix TLV . . . . . . . . . . . . . . . . . . 10
7. OSPFv3 E-Inter-Area-Router-LSA . . . . . . . . . . . . . . . . 14 3.4. Inter-Area-Router TLV . . . . . . . . . . . . . . . . . . 11
8. OSPFv3 E-AS-External-LSA . . . . . . . . . . . . . . . . . . . 16 3.5. External-Prefix TLV . . . . . . . . . . . . . . . . . . . 12
9. OSPFv3 E-NSSA-LSA . . . . . . . . . . . . . . . . . . . . . . 19 3.6. Intra-Area-Prefix TLV . . . . . . . . . . . . . . . . . . 13
10. OSPFv3 E-Link-LSA . . . . . . . . . . . . . . . . . . . . . . 20 3.7. IPv6 Link-Local Address TLV . . . . . . . . . . . . . . . 14
11. OSPFv3 E-Intra-Area-Prefix-LSA . . . . . . . . . . . . . . . . 23 3.8. IPv4 Link-Local Address TLV . . . . . . . . . . . . . . . 15
12. LSA Extension Backward Compatibility . . . . . . . . . . . . . 24 3.9. Forwarding-Address Sub-TLV . . . . . . . . . . . . . . . . 16
12.1. Extended LSA Mixed-Mode Backward Compatibility . . . . . . 25 3.10. Route-Tag Sub-TLV . . . . . . . . . . . . . . . . . . . . 16
12.1.1. Area Extended LSA Mixed-Mode Backward 4. OSPFv3 Extended LSAs . . . . . . . . . . . . . . . . . . . . . 17
Compatibility . . . . . . . . . . . . . . . . . . . . 25 4.1. OSPFv3 E-Router-LSA . . . . . . . . . . . . . . . . . . . 17
12.2. LSA TLV Processing Backward Compatibility . . . . . . . . 26 4.2. OSPFv3 E-Network-LSA . . . . . . . . . . . . . . . . . . . 18
13. Security Considerations . . . . . . . . . . . . . . . . . . . 27 4.3. OSPFv3 E-Inter-Area-Prefix-LSA . . . . . . . . . . . . . . 19
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 4.4. OSPFv3 E-Inter-Area-Router-LSA . . . . . . . . . . . . . . 20
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 4.5. OSPFv3 E-AS-External-LSA . . . . . . . . . . . . . . . . . 21
15.1. Normative References . . . . . . . . . . . . . . . . . . . 29 4.6. OSPFv3 E-NSSA-LSA . . . . . . . . . . . . . . . . . . . . 22
15.2. Informative References . . . . . . . . . . . . . . . . . . 29 4.7. OSPFv3 E-Link-LSA . . . . . . . . . . . . . . . . . . . . 23
Appendix A. Global Configuration Parameters . . . . . . . . . . . 30 4.8. OSPFv3 E-Intra-Area-Prefix-LSA . . . . . . . . . . . . . . 25
Appendix B. Area Configuration Parameters . . . . . . . . . . . . 31 5. LSA Extension Backward Compatibility . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 5.1. Extended LSA Mixed-Mode Backward Compatibility . . . . . . 27
5.1.1. Area Extended LSA Mixed-Mode Backward Compatibility . 28
5.2. LSA TLV Processing Backward Compatibility . . . . . . . . 28
6. Security Considerations . . . . . . . . . . . . . . . . . . . 30
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
8.1. Normative References . . . . . . . . . . . . . . . . . . . 32
8.2. Informative References . . . . . . . . . . . . . . . . . . 32
Appendix A. Global Configuration Parameters . . . . . . . . . . . 33
Appendix B. Area Configuration Parameters . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
1. Introduction 1. Introduction
OSPFv3 requires functional extension beyond what can readily be done OSPFv3 requires functional extension beyond what can readily be done
with the fixed-format Link State Advertisement (LSA) as described in with the fixed-format Link State Advertisement (LSA) as described in
RFC 5340 [OSPFV3]. Without LSA extension, attributes associated with RFC 5340 [OSPFV3]. Without LSA extension, attributes associated with
OSPFv3 links and advertised IPv6 prefixes must be advertised in OSPFv3 links and advertised IPv6 prefixes must be advertised in
separate LSAs and correlated to the fixed-format LSA. This document separate LSAs and correlated to the fixed-format LSAs. This document
extends the LSA format by allowing the optional inclusion of Type- extends the LSA format by encoding the existing OSPFv3 LSA
Length-Value (TLV) tuples in the LSAs. Backward compatibility information in Type-Length-Value (TLV) tuples and allowing
mechanisms are also described. advertisement of additional information with additional TLVs.
Backward compatibility mechanisms are also described.
A similar extension was previously proposed in support of multi- A similar extension was previously proposed in support of multi-
topology routing. Additional requirements for OSPFv3 LSA extension topology routing. Additional requirements for OSPFv3 LSA extension
include source/destination routing, route tagging, and others. include source/destination routing, route tagging, and others.
A final requirement is to limit the changes to OSPFv3 to those A final requirement is to limit the changes to OSPFv3 to those
necessary for TLV-based LSAs. For the most part, the semantics of necessary for TLV-based LSAs. For the most part, the semantics of
existing OSPFv3 LSA are retained for their TLV-based successor LSAs existing OSPFv3 LSAs are retained for their TLV-based successor LSAs
described herein. Additionally, encoding details, e.g., the described herein. Additionally, encoding details, e.g., the
representation of IPv6 prefixes as described in section A.4.1 in RFC representation of IPv6 prefixes as described in section A.4.1 in RFC
5340 [OSPFV3], have been retained. This requirement was included to 5340 [OSPFV3], have been retained. This requirement was included to
increase the expedience of IETF adoption and deployment. increase the expedience of IETF adoption and deployment.
The following aspects of OSPFv3 LSA extension are described: The following aspects of OSPFv3 LSA extension are described:
1. Extended LSA Types 1. Extended LSA Types
2. Extended LSA Formats 2. Extended LSA TLVs
3. Backward Compatibility 3. Extended LSA Formats
4. Backward Compatibility
1.1. Requirements notation 1.1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC-KEYWORDS]. document are to be interpreted as described in [RFC-KEYWORDS].
1.2. Acknowledgments 1.2. Acknowledgments
OSPFv3 TLV-based LSAs were first proposed in "Multi-topology routing OSPFv3 TLV-based LSAs were first proposed in "Multi-topology routing
in OSPFv3 (MT-OSPFv3)" [MT-OSPFV3]. in OSPFv3 (MT-OSPFv3)" [MT-OSPFV3].
Thanks for Peter Psenak for significant contributions to the backward Thanks for Peter Psenak for significant contributions to the backward
compatibility mechanisms. compatibility mechanisms.
Thanks go to Michael Barnes, Mike Dubrovsky, and Anton Smirnov for Thanks go to Michael Barnes, Mike Dubrovsky, and Anton Smirnov for
review of the draft versions and discussions of backward review of the draft versions and discussions of backward
compatibility. compatibility.
Thanks to Alan Davey for review and comments including the suggestion
to separate the extended LSA TLV definitions from the extended LSAs
definitions.
Thanks to David Lamparter for review and suggestions on backward
compatibility.
The RFC text was produced using Marshall Rose's xml2rfc tool. The RFC text was produced using Marshall Rose's xml2rfc tool.
2. OSPFv3 Extended LSA Types 2. OSPFv3 Extended LSA Types
In order to provide backward compatibility, new LSA codes must be In order to provide backward compatibility, new LSA codes must be
allocated. There are eight fixed-format LSAs defined in RFC 5340 allocated. There are eight fixed-format LSAs defined in RFC 5340
[OSPFV3]. For ease of implementation and debugging, the LSA function [OSPFV3]. For ease of implementation and debugging, the LSA function
codes are the same as the fixed-format LSAs only with 32, i.e., 0x20, codes are the same as the fixed-format LSAs only with 32, i.e., 0x20,
added. The alternative was to allocate a bit in the LSA Type added. The alternative to this mapping was to allocate a bit in the
indicating the new LSA format. However, this would have used one LS Type indicating the new LSA format. However, this would have used
half the LSA function code space for the migration of the eight one half the LSA function code space for the migration of the eight
original fixed-format LSAs. For backward compatibility, the U-bit original fixed-format LSAs. For backward compatibility, the U-bit
will be set in LS Type so that the LSAs will be flooded by OSPFv3 will be set in LS Type so that the LSAs will be flooded by OSPFv3
routers that do not understand them. routers that do not understand them.
LSA function code LS Type Description LSA function code LS Type Description
---------------------------------------------------- ----------------------------------------------------
33 0xA021 E-Router-LSA 33 0xA021 E-Router-LSA
34 0xA022 E-Network-LSA 34 0xA022 E-Network-LSA
35 0xA023 E-Inter-Area-Prefix-LSA 35 0xA023 E-Inter-Area-Prefix-LSA
36 0xA024 E-Inter-Area-Router-LSA 36 0xA024 E-Inter-Area-Router-LSA
37 0xC025 E-AS-External-LSA 37 0xC025 E-AS-External-LSA
38 N/A Unused (Not to be allocated) 38 N/A Unused (Not to be allocated)
39 0xA027 E-Type-7-LSA 39 0xA027 E-Type-7-LSA
40 0x8028 E-Link-LSA 40 0x8028 E-Link-LSA
41 0xA029 E-Intra-Area-Prefix-LSA 41 0xA029 E-Intra-Area-Prefix-LSA
OSPFv3 Extended LSA Types OSPFv3 Extended LSA Types
3. OSPFv3 Extended LSA TLV 3. OSPFv3 Extended LSA TLVs
The format of the TLVs within the body of the extended LSAs is the The format of the TLVs within the body of the extended LSAs is the
same as the format used by the Traffic Engineering Extensions to OSPF same as the format used by the Traffic Engineering Extensions to OSPF
[TE]. The variable TLV section consists of one or more nested Type/ [TE]. The variable TLV section consists of one or more nested Type/
Length/Value (TLV) tuples. The format of each TLV is: Length/Value (TLV) tuples. Nested TLVs are also referred to as sub-
TLVs. The format of each TLV is:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value... | | Value... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV Format TLV Format
The Length field defines the length of the value portion in octets The Length field defines the length of the value portion in octets
(thus a TLV with no value portion would have a length of 0). The TLV (thus a TLV with no value portion would have a length of 0). The TLV
is padded to 4-octet alignment; padding is not included in the length is padded to 4-octet alignment; padding is not included in the length
field (so a 3-octet value would have a length of 3, but the total field (so a 3-octet value would have a length of 3, but the total
size of the TLV would be 8 octets). Nested TLVs are also 32-bit size of the TLV would be 8 octets). Nested TLVs are also 32-bit
aligned. For example, a 1-byte value would have the length field set aligned. For example, a 1-byte value would have the length field set
to 1, and 3 octets of padding would be added to the end of the value to 1, and 3 octets of padding would be added to the end of the value
portion of the TLV. Unrecognized types are ignored. portion of the TLV.
4. OSPFv3 E-Router-LSA This document defines the following top-level TLV types:
The E-Router-LSA has an LS Type of 0xA021 and has the same base o 0 - Reserved
information content as the Router-LSA, section 4.4.3.2 in [OSPFV3].
However, unlike the existing Router-LSA, it is fully extendable and
represented as TLVs.
0 1 2 3 o 1 - Router-Link TLV
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 |1|0|1| 0x21 |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Sequence Number |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Checksum | Length |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |Nt|x|V|E|B| Options |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. TLVs .
. .
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Extended Router-LSA o 2 - Attached-Routers TLV
All LSA Header fields are the same as defined for the Router-LSA. o 3 - Inter-Area Prefix TLV
The following top-level TLVs are defined:
o 4 - Inter-Area Router TLV
o 5 - External Prefix TLV
o 6 - Intra-Area Prefix TLV
o 7 - IPv6 Link-Local Address TLV
o 8 - IPv4 Link-Local Address TLV
Additionally, this document defines the following sub-TLV types:
o 0 - Reserved o 0 - Reserved
o 1 - Router-Link TLV o 1 - Forwarding Address sub-TLV
o 2 - Route Tag sub-TLV
In general, TLVs and sub-TLVs MAY occur in any order and the
specification should define whether the TLV or sub-TLV is required
and the behavior when there are multiple occurances of the TLV or
sub-TLVs.
3.1. Router-Link TLVs
The Router-Link TLV defines a single router link and the field
definitions correspond directly to links in the OSPFv3 Router-LSA,
section A.4.3, [OSPFV3]. The Router-Link TLV is only applicable to
the E-Router-LSA (Section 4.1). Inclusion in other Extended LSAs
MUST be ignored.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 (Router-Link) | TLV Length | | 1 (Router-Link) | TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | 0 | Metric | | Type | 0 | Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID | | Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor Interface ID | | Neighbor Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor Router ID | | Neighbor Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. sub-TLVs . . sub-TLVs .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Router-Link TLV Router-Link TLV
Like the existing Router-LSA, the LSA length is used to determine the 3.2. Attached-Routers TLV
end of the LSA including TLVs. The Router-Link TLV is only
applicable to the E-Router-LSA. Inclusion in other Extended LSAs
MUST be ignored.
5. OSPFv3 E-Network-LSA
The E-Network-LSA has an LS Type of 0xA022 and has the same base
information content as the Network-LSA, section 4.4.3.3 in [OSPFV3].
However, unlike the existing Network-LSA, it is fully extendable and
represented as TLVs.
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 |1|0|1| 0x22 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. TLVs .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
E-Network-LSA
All LSA Header fields are the same as defined for the Network-LSA.
The following top-level TLVs are defined:
o 2 - Attached-Routers TLV The Attached-Routers TLV defines all the routers attached to an
OSPFv3 multi-access network. The field definitions correspond
directly to content of the OSPFv3 Network-LSA, section A.4.4,
[OSPFV3]. The Attached-Routers TLV is only applicable to the
E-Network-LSA (Section 4.2). Inclusion in other Extended LSAs MUST
be ignored.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 (Attached-Routers) | TLV Length | | 2 (Attached-Routers) | TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Adjacent Neighbor Router ID | | Adjacent Neighbor Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. Additional Adjacent Neighbors . . Additional Adjacent Neighbors .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Attached-Routers TLV Attached-Routers TLV
There are two reasons for not having a separate TLV or sub-TLV for There are two reasons for not having a separate TLV or sub-TLV for
each adjacent neighbor. The first is to discourage using the each adjacent neighbor. The first is to discourage using the
E-Network-LSA for more than its current role of solely advertising E-Network-LSA for more than its current role of solely advertising
the routers attached to a multi-access network. The router's metric the routers attached to a multi-access network. The router's metric
as well as her attributes of individual attached routers should be as well as the attributes of individual attached routers should be
advertised in their respective E-Router-LSAs. The second reason is advertised in their respective E-Router-LSAs. The second reason is
that there is only a single E-Network-LSA per multi-access link with that there is only a single E-Network-LSA per multi-access link with
the Link State ID set to the Designated Router's Interface ID and, the Link State ID set to the Designated Router's Interface ID and,
consequently, compact encoding has been chosen to decrease the consequently, compact encoding has been chosen to decrease the
likelihood of the size of the E-Network-LSA requiring IPv6 likelihood that the size of the E-Network-LSA will require IPv6
fragmentation when advertised in an OSPFv3 Link State Update packet. fragmentation when advertised in an OSPFv3 Link State Update packet.
Like the existing Network-LSA, the LSA length is used to determine 3.3. Inter-Area-Prefix TLV
the end of the LSA including TLVs. The Attached-Routers TLV is only
applicable to the E-Network-LSA. Inclusion in other Extended LSAs
MUST be ignored.
6. OSPFv3 E-Inter-Area-Prefix-LSA
The E-Inter-Area-Prefix-LSA has an LS Type of 0xA023 and has the same The Inter-Area-Prefix TLV defines a single OSPFV3 inter-area prefix.
base information content as the Inter-Area-Prefix-LSA, section The field definitions correspond directly to the content of an OSPFv3
4.4.3.4 in [OSPFV3]. However, unlike the existing Inter-Area-Prefix- IPv6 Prefix as defined in Section A.4.1, [OSPFV3] and an OSPFv3
LSA, it is fully extendable and represented as TLVs. Inter-Area-Prefix-LSA, as defined in section A.4.5, [OSPFV3]. The
Inter-Area-Prefix TLV is only applicable to the E-Inter-Area-Prefix-
LSA (Section 4.3). Inclusion in other Extended LSAs MUST be ignored.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 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 |1|0|1| 0x23 | | 3 (Inter-Area Prefix) | TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router | | 0 | Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Sequence Number | | PrefixLength | PrefixOptions | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Checksum | Length | | Address Prefix |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. TLVs . . sub-TLVs .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
E-Inter-Area-Prefix-LSA Inter-Area Prefix TLV
All LSA Header fields are the same as defined for the Network-LSA. 3.4. Inter-Area-Router TLV
The following top-level TLVs are defined:
The Inter-Area-Router TLV defines a single OSPFv3 Autonomous System
Boundary Router (ASBR) reachable in another area. The field
definitions correspond directly to the content of an OSPFv3 Inter-
Area-Router-LSA, as defined in section A.4.6, [OSPFV3]. The Inter-
Area-Router TLV is only applicable to the E-Inter-Area-Router-LSA
(Section 4.4). Inclusion in other Extended LSAs MUST be ignored.
o 3 - Inter-Area Prefix TLV
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 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 (Inter-Area Prefix) | TLV Length | | 4 (Inter-Area Router) | TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | Metric | | 0 | Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PrefixLength | PrefixOptions | 0 | | 0 | Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Prefix | | Destination Router ID |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. sub-TLVs . . sub-TLVs .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Inter-Area Prefix TLV Inter-Area Router TLV
In order to retain compatibility and semantics with the current
OSPFv3 specification, each LSA MUST contain a single Inter-Area
Prefix TLV. This will facilitate migration and avoid changes to
functions such as incremental SPF computation.
Like the existing Inter-Area-Prefix-LSA, the LSA length is used to
determine the end of the LSA including TLV. The Inter-Area-Prefix
TLV is only applicable to the E-Inter-Area-Prefix-LSA. Inclusion in
other Extended LSAs MUST be ignored.
7. OSPFv3 E-Inter-Area-Router-LSA 3.5. External-Prefix TLV
The E-Inter-Area-Router-LSA has an LS Type of 0xA024 and has the same The External-Prefix TLV defines a single OSPFv3 external prefix. The
base information content as the Inter-Area-Router-LSA, section field definitions correspond directly to the content of an OSPFv3
4.4.3.5 in [OSPFV3]. However, unlike the Inter-Area-Router-LSA, it IPv6 Prefix as defined in Section A.4.1, [OSPFV3] and an OSPFv3 AS-
is fully extendable and represented as TLVs. External-LSA, as defined in section A.4.7, [OSPFV3]. The External-
Prefix TLV is only applicable to the E-AS-External-LSA (Section 4.5)
and the E-NSSA-LSA (Section 4.6). Inclusion in other Extended LSAs
MUST be ignored.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 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 |1|0|1| 0x24 | | 5 (External Prefix) | TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router | | |E| | | Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Sequence Number | | PrefixLength | PrefixOptions | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Checksum | Length | | Address Prefix |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. TLVs . . sub-TLVs .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
E-Inter-Area-Router-LSA External Prefix TLV
All LSA Header fields are the same as defined for the Inter-Area- In the External-Prefix TLV, the optional Forwarding Address and
Router-LSA. The following top-level TLVs are defined: External Route Tag are now sub-TLVs. Given the Referenced LS type
and Referenced Link State ID from the AS-External-LSA have never been
used or even specified, they have been omitted from the External
Prefix TLV. If there were ever a requirement for a referenced LSA,
it could be satisfied with a sub-TLV.
The following sub-TLVs are defined for optional inclusion in the
External Prefix TLV:
o 1 - Forwarding Address sub-TLV (Section 3.9)
o 2 - Route Tag sub-TLV (Section 3.10)
3.6. Intra-Area-Prefix TLV
The Intra-Area-Prefix TLV defines a single OSPFv3 intra-area prefix.
The field definitions correspond directly to the content of an OSPFv3
IPv6 Prefix as defined in Section A.4.1, [OSPFV3] and an OSPFv3 Link-
LSA, as defined in section A.4.9, [OSPFV3]. The Intra-Area-Prefix
TLV is only applicable to the E-Link-LSA (Section 4.7) and the
E-Intra-Area-Prefix-LSA (Section 4.8). Inclusion in other Extended
LSAs MUST be ignored.
o 4 - Inter-Area Router TLV
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 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 (Inter-Area Router) | TLV Length | | 6 (Intra-Area Prefix) | TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | Options | | 0 | Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | Metric | | PrefixLength | PrefixOptions | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Router ID | | Address Prefix |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. sub-TLVs . . sub-TLVs .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Inter-Area Router TLV Intra-Area Prefix TLV
In order to retain compatibility and semantics with the current
OSPFv3 specification, each LSA MUST contain a single Inter-Area
Router TLV. This will facilitate migration and avoid changes to
functions such as incremental SPF computation.
Like the existing Inter-Area-Router-LSA, the LSA length is used to
determine the end of the LSA including sub-TLVs. The Inter-Area-
Router TLV is only applicable to the E-Inter-Area-Router-LSA.
Inclusion in other Extended LSAs MUST be ignored.
8. OSPFv3 E-AS-External-LSA 3.7. IPv6 Link-Local Address TLV
The E-AS-External-LSA has an LS Type of 0xC025 and has the same base The IPv6 Link-Local Address TLV is to be used with IPv6 address
information content as the AS-External-LSA, section 4.4.3.6 in families as defined in [OSPFV3-AF]. The IPv6 Link-Local Address TLV
[OSPFV3]. However, unlike the existing AS-External-LSA, it is fully is only applicable to the E-Link-LSA (Section 4.7). Inclusion in
extendable and represented as TLVs. other Extended LSAs MUST be ignored.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 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 |1|1|0| 0x25 | | 7 (IPv6 Local-Local Address) | TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Checksum | Length | | |
+- -+
| |
+- IPv6 Link-Local Interface Address -+
| |
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. TLVs . . sub-TLVs .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
E-AS-External-LSA IPv6 Link-Local Address TLV
All LSA Header fields are the same as defined for the AS-External- 3.8. IPv4 Link-Local Address TLV
LSA. The following top-level TLVs are defined:
The IPv4 Link-Local Address TLV is to be used with IPv4 address
families as defined in [OSPFV3-AF]. The IPv4 Link-Local Address TLV
is only applicable to the E-Link-LSA (Section 4.7). Inclusion in
other Extended LSAs MUST be ignored.
o 5 - External Prefix TLV
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 5 (External Prefix) | TLV Length | | 8 (IPv4 Local-Local Address) | TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |E| | | Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PrefixLength | PrefixOptions | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Prefix | | IPv4 Link-Local Interface Address |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. sub-TLVs . . sub-TLVs .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
External Prefix TLV IPv4 Link-Local Address TLV
In order to retain compatibility and semantics with the current
OSPFv3 specification, each LSA MUST contain a single External Prefix
TLV. This will facilitate migration and avoid changes to OSPFv3
processes such as incremental SPF computation. In External Prefix
TLV, the optional Forwarding Address and External Route Tag are now
sub-TLVs. Given the Referenced LS type and Referenced Link State ID
from the AS-External-LSA have never been used or even specified, they
have been omitted from the External Prefix TLV. If there were ever a
requirement for a referenced LSA, it could be satisfied with a sub-
TLV.
Like the existing AS-External-LSA, the LSA length is used to
determine the end of the LSA including sub-TLVs. The External-Prefix
TLV is only applicable to the E-AS-External-LSA and the E-NSSA-LSA.
Inclusion in other Extended LSAs MUST be ignored.
The following sub-TLVs are defined for the External Prefix TLV: 3.9. Forwarding-Address Sub-TLV
o 1 - Forwarding Address sub-TLV The Forwarding Address TLV has identical semantics to the optional
forwarding address in section A.4.7 of [OSPFV3]. The Forwarding
Address TLV is applicable to the External-Prefix TLV (Section 3.5).
Specification as a sub-TLV of other TLVs is not defined herein. The
sub-TLV is optional and the first specified instance is used as the
Forwarding Address as defined in [OSPFV3]. Instances subsequent to
the first are ignored.
o 2 - Route Tag sub-TLV
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 - Forwarding Address | sub-TLV Length (16) | | 1 - Forwarding Address | sub-TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+- -+ +- -+
| | | |
+- Forwarding Address -+ +- Forwarding Address -+
| | | |
+- -+ +- -+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
External Route Tag Sub-TLV Forwarding Address Tag TLV
The optional Forwarding Address sub-TLV has identical semantics to 3.10. Route-Tag Sub-TLV
the optional forwarding address in section 4.4.3.6 of [OSPFV3]. The
Forwarding Address sub-TLV is applicable to the External-Prefix TLV. The optional Route Tag sub-TLV has identical semantics to the
optional External Route Tag in section A.4.7 of [OSPFV3]. The Route
Tag sub-TLV is applicable to the External-Prefix TLV (Section 3.5).
Specification as a sub-TLV of other TLVs is not defined herein. The Specification as a sub-TLV of other TLVs is not defined herein. The
sub-TLV is optional and the first specified instance is used as the sub-TLV is optional and the first specified instance is used as the
Forwarding Address as defined in [OSPFV3]. Instances subsequent to Route Tag as defined in [OSPFV3]. Instances subsequent to the first
the first are ignored. are ignored.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 - Route Tag | sub-TLV Length (4) | | 2 - Route Tag | sub-TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Tag | | Route Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Route Tag Sub-TLV Route Tag Sub-TLV
The optional Route Tag sub-TLV has identical semantics to the 4. OSPFv3 Extended LSAs
optional External Route Tag in section 4.4.3.6 of [OSPFV3]. The
Route Tag sub-TLV is applicable to the External-Prefix TLV.
Specification as a sub-TLV of other TLVs is not defined herein. The
sub-TLV is optional and the first specified instance is used as the
Route Tag as defined in [OSPFV3]. Instances subsequent to the first
are ignored.
9. OSPFv3 E-NSSA-LSA This section specifies the OSPFv3 Extended LSA formats and encoding.
The Extended OSPFv3 LSAs corresponded directly to the original OSPFv3
LSAs specifed in [OSPFV3].
The E-NSSA-LSA will have the same format and TLVs as the Extended AS- 4.1. OSPFv3 E-Router-LSA
External-LSA Section 8. This is the same relationship as exists
between the NSSA-LSA, section 4.4.3.7 in [OSPFV3], and the AS-
External-LSA. The NSSA-LSA will have type 0xA027 which implies area
flooding scope. Future requirements may dictate that supported TLVs
differ between the E-AS-External-LSA and the E-NSSA-LSA. However,
future requirements are beyond the scope of this document.
10. OSPFv3 E-Link-LSA The E-Router-LSA has an LS Type of 0xA021 and has the same base
information content as the Router-LSA defined in section A.4.3 of
[OSPFV3]. However, unlike the existing Router-LSA, it is fully
extendable and represented as TLVs.
The E-Link-LSA has an LS Type of 0x8028 and will have the same base 0 1 2 3
information content as the Link-LSA, section 4.4.3.8 in [OSPFV3]. 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
However, unlike the existing Link-LFA, it is extendable and +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
represented as TLVs. | LS Age |1|0|1| 0x21 |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Sequence Number |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Checksum | Length |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |Nt|x|V|E|B| Options |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. TLVs .
. .
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Extended Router-LSA
All LSA Header fields are the same as defined for the Router-LSA.
Initially, only the top-level Router-Link TLV Section 3.1 is
applicable and an E-Router-LSA may include multiple Router-Link TLVs.
Like the existing Router-LSA, the LSA length is used to determine the
end of the LSA including TLVs.
4.2. OSPFv3 E-Network-LSA
The E-Network-LSA has an LS Type of 0xA022 and has the same base
information content as the Network-LSA defined in section A.4.4 of
[OSPFV3]. However, unlike the existing Network-LSA, it is fully
extendable and represented as TLVs.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 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 |1|0|0| 0x28 | | LS Age |1|0|1| 0x22 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID | | Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router | | Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Sequence Number | | LS Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Checksum | Length | | LS Checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rtr Priority | Options | | 0 | Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. TLVs . . TLVs .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
E-Link-LSA E-Network-LSA
The following top-level TLVs are defined: All LSA Header fields are the same as defined for the Network-LSA.
Like the existing Network-LSA, the LSA length is used to determine
the end of the LSA including TLVs. Initially, only the top-level
Attached-Routers TLV Section 3.2 is applicable.
o 6 - Intra-Area Prefix TLV 4.3. OSPFv3 E-Inter-Area-Prefix-LSA
o 7 - IPv6 Link-Local Address TLV The E-Inter-Area-Prefix-LSA has an LS Type of 0xA023 and has the same
base information content as the Inter-Area-Prefix-LSA defined in
section A.4.5 of [OSPFV3]. However, unlike the existing Inter-Area-
Prefix-LSA, it is fully extendable and represented as TLVs.
o 8 - IPv4 Link-Local Address TLV
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 6 (Intra-Area Prefix) | TLV Length | | LS Age |1|0|1| 0x23 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | Metric | | Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PrefixLength | PrefixOptions | 0 | | Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Prefix | | LS Sequence Number |
| ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. sub-TLVs . . TLVs .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Intra-Area Prefix TLV E-Inter-Area-Prefix-LSA
Like the Link-LSA, the E-Link-LSA affords advertisement of multiple All LSA Header fields are the same as defined for the Inter-Area-
intra-area prefixes. Hence, multiple Intra-Area Prefix TLVs may be Prefix-LSA. In order to retain compatibility and semantics with the
specified and the LSA length defines the end of the LSA including all current OSPFv3 specification, each Inter-Area-Prefix LSA MUST contain
TLVs. The Intra-Area-Prefix TLV is only applicable to the E-Link-LSA a single Inter-Area Prefix TLV. This will facilitate migration and
and the E-Intra-Area-Prefix-LSA. Inclusion in other Extended LSAs avoid changes to functions such as incremental SPF computation.
MUST be ignored.
Like the existing Inter-Area-Prefix-LSA, the LSA length is used to
determine the end of the LSA including TLV. Initially, only the top-
level Inter-Area-Prefix TLV (Section 3.3) is applicable.
4.4. OSPFv3 E-Inter-Area-Router-LSA
The E-Inter-Area-Router-LSA has an LS Type of 0xA024 and has the same
base information content as the Inter-Area-Router-LSAE defined in
section A.4.6 of [OSPFV3]. However, unlike the Inter-Area-Router-
LSA, it is fully extendable and represented as TLVs.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 7 (IPv6 Local-Local Address) | TLV Length | | LS Age |1|0|1| 0x24 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | Link State ID |
+- -+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | Advertising Router |
+- IPv6 Link-Local Interface Address -+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | LS Sequence Number |
+- -+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | LS Checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. sub-TLVs . . TLVs .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 Link-Local Address TLV E-Inter-Area-Router-LSA
The IPv6 Link-Local Address TLV is to be used with IPv6 address All LSA Header fields are the same as defined for the Inter-Area-
families as defined in [OSPFV3-AF]. The IPv6 Link-Local Address TLV Router-LSA. In order to retain compatibility and semantics with the
is only applicable to the E-Link-LSA. Inclusion in other Extended current OSPFv3 specification, each Inter-Area-Router LSA MUST contain
LSAs MUST be ignored. Only a single instance of the IPv6 Link-Local a single Inter-Area Router TLV. This will facilitate migration and
Address family SHOULD be included in the E-Link-LSA. Instances avoid changes to functions such as incremental SPF computation.
following the first MUST be ignored. For IPv4 address families as
defined in [OSPFV3-AF], this TLV SHOULD be ignored. Future Like the existing Inter-Area-Router-LSA, the LSA length is used to
specifications may support advertisement of routing and topology determine the end of the LSA including TLV. Initially, only the top-
information for multiple address families. However, this is beyond level Inter-Area-Router TLV (Section 3.4) is applicable.
the scope of this document.
4.5. OSPFv3 E-AS-External-LSA
The E-AS-External-LSA has an LS Type of 0xC025 and has the same base
information content as the AS-External-LSA defined in section A.4.7
of [OSPFV3]. However, unlike the existing AS-External-LSA, it is
fully extendable and represented as TLVs.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 8 (IPv4 Local-Local Address) | TLV Length | | LS Age |1|1|0| 0x25 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Link-Local Interface Address | | Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. sub-TLVs . . TLVs .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 Link-Local Address TLV E-AS-External-LSA
The IPv4 Link-Local Address TLV is to be used with IPv4 address All LSA Header fields are the same as defined for the AS-External-
families as defined in [OSPFV3-AF]. The IPv4 Link-Local Address TLV LSA. In order to retain compatibility and semantics with the current
is only applicable to the E-Link-LSA. Inclusion in other Extended OSPFv3 specification, each LSA MUST contain a single External Prefix
LSAs MUST be ignored. Only a single instance of the IPv4 Link-Local TLV. This will facilitate migration and avoid changes to OSPFv3
Address family SHOULD be included in the E-Link-LSA. Instances processes such as incremental SPF computation.
Like the existing AS-External-LSA, the LSA length is used to
determine the end of the LSA including sub-TLVs. Initially, only the
top-level External-Prefix TLV (Section 3.5) is applicable.
4.6. OSPFv3 E-NSSA-LSA
The E-NSSA-LSA will have the same format and TLVs as the Extended AS-
External-LSA Section 4.5. This is the same relationship as exists
between the NSSA-LSA defined in section A.4.8 of [OSPFV3], and the
AS-External-LSA. The NSSA-LSA will have type 0xA027 which implies
area flooding scope. Future requirements may dictate that supported
TLVs differ between the E-AS-External-LSA and the E-NSSA-LSA.
However, future requirements are beyond the scope of this document.
4.7. OSPFv3 E-Link-LSA
The E-Link-LSA has an LS Type of 0x8028 and will have the same base
information content as the Link-LSA defined in section A.4.9 of
[OSPFV3]. However, unlike the existing Link-LFA, it is extendable
and represented as TLVs.
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 |1|0|0| 0x28 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rtr Priority | Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. TLVs .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
E-Link-LSA
All LSA Header fields are the same as defined for the Link-LSA.
Only the Intra-Area-Prefix TLV (Section 3.6), IPv6 Link-Local Address
TLV (Section 3.7), and IPv4 Link-Local Address TLV (Section 3.8) are
applicable to the E-Link-LSA. Like the Link-LSA, the E-Link-LSA
affords advertisement of multiple intra-area prefixes. Hence,
multiple Intra-Area Prefix TLVs (Section 3.6) may be specified and
the LSA length defines the end of the LSA including all TLVs.
Only a single instance of the IPv6 Link-Local Address TLV
(Section 3.7) SHOULD be included in the E-Link-LSA. Instances
following the first MUST be ignored. For IPv4 address families as
defined in [OSPFV3-AF], this TLV MUST be ignored.
Similarly, only a single instance of the IPv4 Link-Local Address TLV
(Section 3.8) SHOULD be included in the E-Link-LSA. Instances
following the first MUST be ignored. For OSPFv3 IPv6 address following the first MUST be ignored. For OSPFv3 IPv6 address
families as defined in [OSPFV3-AF], this TLV MUST be ignored. Future families as defined in [OSPFV3-AF], this TLV MUST be ignored.
specifications may support advertisement of routing and topology
information for multiple address families. However, this is beyond
the scope of this document.
11. OSPFv3 E-Intra-Area-Prefix-LSA Future specifications may support advertisement of routing and
topology information for multiple address families. However, this is
beyond the scope of this document.
4.8. OSPFv3 E-Intra-Area-Prefix-LSA
The E-Intra-Area-Prefix-LSA has an LS Type of 0xA029 and has the same The E-Intra-Area-Prefix-LSA has an LS Type of 0xA029 and has the same
base information content as the Intra-Area-Prefix-LSA, section base information content as the Intra-Area-Prefix-LSA defined in
4.4.3.9 in [OSPFV3]. However, unlike the Intra-Area-Prefix-LSA, it section A.4.10 of [OSPFV3]. However, unlike the Intra-Area-Prefix-
is fully extendable and represented as TLVs. LSA, it is fully extendable and represented as TLVs.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 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 |1|0|1| 0x29 | | LS Age |1|0|1| 0x29 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID | | Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router | | Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 23, line 39 skipping to change at page 25, line 39
| Referenced Advertising Router | | Referenced Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. TLVs . . TLVs .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
E-Intra-Area-Prefix-LSA E-Intra-Area-Prefix-LSA
All LSA Header fields are the same as defined for the Intra-Area- All LSA Header fields are the same as defined for the Intra-Area-
Prefix-LSA. The following top-level TLVs are defined: Prefix-LSA.
o 6 - Intra-Area-Prefix TLV (defined in Section 10)
Like the Intra-Area-Prefix-LSA, the E-Intra-Area-Link-LSA affords Like the Intra-Area-Prefix-LSA, the E-Intra-Area-Link-LSA affords
advertisement of multiple intra-area prefixes. Hence, multiple advertisement of multiple intra-area prefixes. Hence, multiple
Intra-Area Prefix TLVs may be specified and the LSA length defines Intra-Area Prefix TLVs may be specified and the LSA length defines
the end of the LSA including all TLVs. the end of the LSA including all TLVs.
12. LSA Extension Backward Compatibility 5. LSA Extension Backward Compatibility
In the context of this document, backward compatibility is solely In the context of this document, backward compatibility is solely
related to the capability of an OSPFv3 router to receive, process, related to the capability of an OSPFv3 router to receive, process,
and originate the TLV-based LSAs defined herein. Backward and originate the TLV-based LSAs defined herein. Unrecognized TLVs
compatibility for future OSPFv3 extensions utilizing the TLV-based and sub-TLVs are ignored. Backward compatibility for future OSPFv3
LSAs is out of scope and must be covered in the documents describing extensions utilizing the TLV-based LSAs is out of scope and must be
those extensions. Both full and, if applicable, partial deployment covered in the documents describing those extensions. Both full and,
should be covered for future OSPFv3 LSA extensions. if applicable, partial deployment SHOULD be specified for future TLV-
based OSPFv3 LSA extensions.
For simplicity and to avoid the scaling impact of maintaining both For simplicity and to avoid the scaling impact of maintaining both
TLV and non-TLV based versions of the same LSA within a routing TLV and non-TLV based versions of the same LSA within a routing
domain, the base backward compatibility mode will not allow mixing of domain, the base backward compatibility mode will not allow mixing of
LSA formats. Different formats could still be supported with LSA formats. Different formats could still be supported with
multiple OSPFv3 instances and separate OSPFv3 routing domains. multiple OSPFv3 instances and separate OSPFv3 routing domains.
Additionally, a more complex mode is provided in Section 12.1, where Additionally, a more complex mode is provided in Section 5.1, where
both formats of LSA coexist. In order to facilitate backward both formats of LSA coexist. In order to facilitate backward
compatibility, the OSPFv3 options field (as described in Appendix A.2 compatibility, the OSPFv3 options field (as described in Appendix A.2
of RFC 5340 [OSPFV3]), will contain an additional options bits. The of RFC 5340 [OSPFV3]), will contain two additional options bits. The
EL-bit will be used to indicate that the advertising OSPFv3 Router EL-bits will be used to indicate that the OSPFv3 router's level of
can receive, process, and originate TLV-based LSAs. An OSPFv3 router Extended LSA support. An OSPFv3 router configured to support
configured to support TLV-based LSAs WILL set its option field EL-bit extended LSAs WILL set its options field EL-bits in OSPFv3 Hello and
in OSPFv3 Hello and Database Description packets. If Full is Database Description packets as follows:
B'00'
None - Extended LSAs are not originate nor used in the SPF
calculation.
B'01'
MixedModeOriginateOnly - Both extended and non-extended LSAs are
originated. Non-extended LSAs are used in the SPF computation.
B'10'
MixedModeOriginateSPF - Both extended and non-extended LSAs are
originated. Extended LSAs are used in the SPF computation.
B'11'
Full - Only extended LSAs are originated and used in the SPF
computation.
If Full is specified for ExtendedLSASupport, the OSPFv3 router MUST
NOT form adjacencies with OSPFv3 Routers sending OSPFv3 Hello and
Database Description packets with the options field EL-bits set to
MixedModeOriginateOnly or None. Similarly, if MixModeOriginateSPF is
specified for ExtendedLSASupport, the OSPFv3 router MUST NOT form specified for ExtendedLSASupport, the OSPFv3 router MUST NOT form
adjacencies with OSPFv3 Routers sending OSPFv3 Hello and Database adjacencies with OSPFv3 Routers sending OSPFv3 Hello and Database
Description packets with the options field EL-bit clear. In this Description packets with the options field EL-bits set to None
manner, OSPFv3 routing domains utilizing the new encoding will be (B'00'). In this manner, OSPFv3 routers using new encodings can be
completely isolated from those using the RFC 5340 encodings. completely isolated from those OSPFv3 routers depending on the RFC
5340 encoding and not setting their options field EL-bits since the
If MixedModeOriginateOnly, MixedModeOriginateSPF, or Full is default setting indicates no support for extended LSAs.
specified for ExtendedLSASupport, (Appendix A), or
AreaExtendedLSASupport (Appendix B) the EL-bit will be set in the
OSPFv3 Hello and Database Description packet options field.
1 2 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+--+--+-+--+-+-+--+-+-+-+--+--+ +-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+--+-+-+--+-+-+-+-+--+
| | | | | | | | | | | | |EL|AT|L|AF|*|*|DC|R|N|x| E|V6| | | | | | | | | | | | | EL|AT|L|AF|*|*|DC|R|N|x|E|V6|
+-+-+-+-+-+-+-+-+-+-+-+-+--+--+-+--+-+-+--+-+-+-+--+--+ +-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+--+-+-+--+-+-+-+-+--+
The Options field The Options field
EL-bit EL-bits
This bit is indicates whether or not the OSPFv3 router These bits indicate the level of Extended LSA support.
supports the Extended LSA format with the bit set condition B'00' - Extended LSAs are not originate nor used in the
indicating support. SPF calculation.
B'01' - Both extended and non-extended LSAs are originated.
Non-extended LSAs are used in the SPF computation.
B'10' - Both extended and non-extended LSAs are originated.
Extended LSAs are used in the SPF computation.
B'11' - Only extended LSA are originated and used in the
SPF computation.
Options Field EL-bit Options Field EL-bits
12.1. Extended LSA Mixed-Mode Backward Compatibility The EL-bits will also be set in the LSA options field in Extended and
Non-Extended LSAs. While the value of the EL-bits has no functional
significance in the LSA options field, visibility of every OSPFv3
Router's extended LSA support is expected to be very useful for
management and troubleshooting during the migration period.
5.1. Extended LSA Mixed-Mode Backward Compatibility
An implementation MAY support configuration allowing a graceful An implementation MAY support configuration allowing a graceful
transition from the non-extended (non-TLV-based) LSAs to the extended transition from the non-extended (non-TLV-based) LSAs to the extended
(TLV-based) LSAs in an OSPFv3 routing domain. In these routing (TLV-based) LSAs in an OSPFv3 routing domain. In these routing
domains, the OSPFv3 routers configured with a value of domains, the OSPFv3 routers configured with a value of
MixedModeOriginateOnly or MixedModeOriginateSPF for MixedModeOriginateOnly or MixedModeOriginateSPF for
ExtendedLSASupport, (Appendix A), MUST originate both the extended ExtendedLSASupport, (Appendix A), MUST originate both the extended
and non-extended versions of the OSPFv3 LSAs described herein. For and non-extended versions of the OSPFv3 LSAs described herein. For
the purposes of Shortest Path First (SPF) computation, the non- the purposes of Shortest Path First (SPF) computation, the non-
exteneded versions of the OSPFv3 LSAs are used for SPF computation extended OSPFv3 LSAs are used for SPF computation when
when MixedModeOrignateOnly is configured and the extended versions MixedModeOriginateOnly is configured and the extended LSAs are used
are used when MixedModeOriginateSPF is specified. The extended LSAs when MixedModeOriginateSPF is specified. The extended LSAs MAY be
MAY be used for functions other than routing computation as long as used for functions other than routing computation as long as backward
backward compatility is described in the documents describing those compatibility is specified in the documents specifying those
functions. OSPFv3 routers configured for mixed mode operation also functions.
MUST form adjacencies with OSPFv3 Routers sending OSPFv3 Hello and
Database Description packets with the options field EL-bit clear.
In this manner, OSPFv3 routing domains utilizing the new encodings In this manner, OSPFv3 routing domains utilizing the new encodings
can be gradually migrated with a worst-case cost of approximately can be gradually migrated with a worst-case overhead cost of
doubling the number of LSAs in the routing domain. The transition approximately doubling the number of LSAs in the routing domain. The
within an OSPFv3 routing domain would progress as follows: transition within an OSPFv3 routing domain would progress as follows:
1. Configure OSPFv3 Router ExtendedLSASupport to 1. Configure OSPFv3 Router ExtendedLSASupport to
MixedModeOriginateOnly so that routers orginate the extended MixedModeOriginateOnly so that routers originate the extended
LSAs. LSAs.
2. When all the OSPFv3 Routers have been reconfigured to 2. When all the OSPFv3 Routers have been reconfigured to
MixedModeOriginateOnly, gradually reconfigure OSPFv3 Routers to MixedModeOriginateOnly, gradually reconfigure OSPFv3 Routers to
use the extended LSAs by configuring ExtendedLSASupport to use the extended LSAs by configuring ExtendedLSASupport to
MixedModeOriginateSPF. This can be done on a small subset of MixedModeOriginateSPF. This can be done on a small subset of
OSPFv3 Routers and the route tables can be verified. OSPFv3 Routers and the route tables can be verified.
3. When all the OSPFv3 Routers have been reconfigured to 3. When all the OSPFv3 Routers have been reconfigured to
MixedModeOriginateSPF and the routing has been verified, MixedModeOriginateSPF and the routing has been verified,
reconfigure OSPFv3 Routers to purge or simply not refresh the reconfigure OSPFv3 Routers to purge or simply not refresh the
non-extended OSPFv3 LSA by configuring ExtendedLSASupport to non-extended OSPFv3 LSA by configuring ExtendedLSASupport to
Full. Full.
12.1.1. Area Extended LSA Mixed-Mode Backward Compatibility 5.1.1. Area Extended LSA Mixed-Mode Backward Compatibility
An implemenation MAY also support configuration allowing graceful An implementation MAY also support configuration allowing graceful
transition from the non-extended LSAs to the extended LSAs within a transition from the non-extended LSAs to the extended LSAs within a
single area. In these area, the parameter AreaExtendedLSASupport single area. In these areas, the parameter AreaExtendedLSASupport
(Appendix B) may be configured to take precedence over the global (Appendix B) may be configured to take precedence over the global
parameter ExtendedLSASupport. However, the AreaExtendedLSASupport parameter ExtendedLSASupport. However, the AreaExtendedLSASupport
will only apply to link and area scoped LSAs within the area and area will only apply to link and area scoped LSAs within the area and area
based SPF calculations. The default is for the based SPF calculations. The default is for the
AreaExtendedLSASupport to be inherited from the ExtendedLSASupport. AreaExtendedLSASupport to be inherited from the ExtendedLSASupport.
The configuration of ExtendedLSASupport will apply to AS-External
LSAs even when AreaExtendedLSASupport takes precedence.
12.2. LSA TLV Processing Backward Compatibility 5.2. LSA TLV Processing Backward Compatibility
This section defines the general rules for processing LSA TLVs. To This section defines the general rules for processing LSA TLVs. To
ensure compatibility of future TLV-based LSA extensions, all ensure compatibility of future TLV-based LSA extensions, all
implementations MUST adhere to these rules: implementations MUST adhere to these rules:
1. Unrecognized TLVs and sub-TLVs are ignored when parsing or 1. Unrecognized TLVs and sub-TLVs are ignored when parsing or
processing Extended-LSAs. processing Extended-LSAs.
2. Whether or not partial deployment of a given TLV is supported 2. Whether or not partial deployment of a given TLV is supported
MUST be specified. MUST be specified.
3. If partial deployment is not supported, mechanisms to ensure the 3. If partial deployment is not supported, mechanisms to ensure the
corresponding feature are not deployed MUST be specified in the corresponding feature are not deployed MUST be specified in the
document defining the new TLV or sub-TLV. document defining the new TLV or sub-TLV.
4. If partial deployment is supported, backward compatibility and 4. If partial deployment is supported, backward compatibility and
partial deployment MUST be specified in the document defining the partial deployment MUST be specified in the document defining the
new TLV or sub-TLV. new TLV or sub-TLV.
13. Security Considerations 6. Security Considerations
In general, extendible OSPFv3 LSAs are subject to the same security In general, extendible OSPFv3 LSAs are subject to the same security
concerns as those described in RFC 5340 [OSPFV3]. Additionally, concerns as those described in RFC 5340 [OSPFV3]. Additionally,
implementations must assure that malformed TLV and Sub-TLV implementations must assure that malformed TLV and Sub-TLV
permutations do not result in errors which cause hard OSPFv3 permutations do not result in errors that cause hard OSPFv3 failures.
failures.
If there were ever a requirement to digitally sign OSPFv3 LSAs as If there were ever a requirement to digitally sign OSPFv3 LSAs as
described for OSPFv2 LSAs in RFC 2154 [OSPF-DIGITAL-SIGNATURE], the described for OSPFv2 LSAs in RFC 2154 [OSPF-DIGITAL-SIGNATURE], the
mechanisms described herein would greatly simplify the extension. mechanisms described herein would greatly simplify the extension.
14. IANA Considerations 7. IANA Considerations
This specification defines nine OSPFv3 Extended LSA types as This specification defines nine OSPFv3 Extended LSA types as
described in Section 2. described in Section 2.
This specification also creates two registries OSPFv3 Extended-LSAs This specification also creates two registries OSPFv3 Extended-LSAs
TLVs and sub-TLVs. The TLV and Sub-TLV code-points in these TLVs and sub-TLVs. The TLV and Sub-TLV code-points in these
registries are common to all Extended-LSAs and their respective registries are common to all Extended-LSAs and their respective
definitions must define where they are applicable. definitions must define where they are applicable.
The OSPFv3 Extend-LSA TLV registry will define top-level TLVs for The OSPFv3 Extend-LSA TLV registry will define top-level TLVs for
Extended-LSAs and should be placed in the existing OSPFv3 IANA Extended-LSAs and should be placed in the existing OSPFv3 IANA
registry. New values can be allocated via IETF Consensus or IESG registry. New values can be allocated via IETF Consensus or IESG
Approval. Approval.
Nine initial values are allocated: Nine values are allocated by this specification:
o 0 - Reserved o 0 - Reserved
o 1 - Router-Link TLV o 1 - Router-Link TLV
o 2 - Attached-Routers TLV o 2 - Attached-Routers TLV
o 3 - Inter-Area Prefix TLV o 3 - Inter-Area Prefix TLV
o 4 - Inter-Area Router TLV o 4 - Inter-Area Router TLV
skipping to change at page 28, line 45 skipping to change at page 31, line 45
o 7 - IPv6 Link-Local Address TLV o 7 - IPv6 Link-Local Address TLV
o 8 - IPv4 Link-Local Address TLV o 8 - IPv4 Link-Local Address TLV
The OSPFv3 Extend-LSA sub-TLV registry will define sub-TLVs at any The OSPFv3 Extend-LSA sub-TLV registry will define sub-TLVs at any
level of nesting for Extended-LSAs and should be placed in the level of nesting for Extended-LSAs and should be placed in the
existing OSPFv3 IANA registry. New values can be allocated via IETF existing OSPFv3 IANA registry. New values can be allocated via IETF
Consensus or IESG Approval. Consensus or IESG Approval.
One initial value is allocated: Three values are allocated by this specification:
o 0 - Reserved o 0 - Reserved
o 1 - Forwarding Address o 1 - Forwarding Address
o 2 - Route Tag o 2 - Route Tag
15. References 8. References
15.1. Normative References 8.1. Normative References
[OSPFV3] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF [OSPFV3] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, July 2008. for IPv6", RFC 5340, July 2008.
[OSPFV3-AF] [OSPFV3-AF]
Lindem, A., Mirtorabi, S., Roy, A., Barnes, M., and R. Lindem, A., Mirtorabi, S., Roy, A., Barnes, M., and R.
Aggarwal, "Support of Address Families in OSPFv3", Aggarwal, "Support of Address Families in OSPFv3",
RFC 5838, April 2010. RFC 5838, April 2010.
[RFC-KEYWORDS] [RFC-KEYWORDS]
Bradner, S., "Key words for use in RFCs to Indicate Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997. Requirement Levels", RFC 2119, March 1997.
[TE] Katz, D., Yeung, D., and K. Kompella, "Traffic Engineering [TE] Katz, D., Yeung, D., and K. Kompella, "Traffic Engineering
Extensions to OSPF", RFC 3630, September 2003. Extensions to OSPF", RFC 3630, September 2003.
15.2. Informative References 8.2. Informative References
[MT-OSPFV3] [MT-OSPFV3]
Mirtorabi, S. and A. Roy, "Multi-topology routing in Mirtorabi, S. and A. Roy, "Multi-topology routing in
OSPFv3 (MT-OSPFV3)", draft-ietf-ospf-mt-ospfv3-04.txt OSPFv3 (MT-OSPFV3)", draft-ietf-ospf-mt-ospfv3-04.txt
(work in progress). (work in progress).
[OSPF-DIGITAL-SIGNATURE] [OSPF-DIGITAL-SIGNATURE]
Murphy, S., Badger, M., and B. Wellington, "OSPF with Murphy, S., Badger, M., and B. Wellington, "OSPF with
Digital Signatures", RFC 2154, June 1997. Digital Signatures", RFC 2154, June 1997.
Appendix A. Global Configuration Parameters Appendix A. Global Configuration Parameters
An additional global configurable parameter will be added to the An additional global configurable parameter will be added to the
OSPFv3 protocol. OSPFv3 protocol.
ExtendedLSASupport ExtendedLSASupport
This is an enumeration type indicating the extent to which the This is an enumeration type indicating the extent to which the
OSPFv3 instance supports the TLV format described herein for OSPFv3 instance supports the TLV format described herein for
Extended LSAs. The valid value for the enumeration are: Extended LSAs. The valid values for the enumeration are:
* None - Non-extended LSAs will not be originated or used in the * None - Extended LSAs will not be originated or used in the SPF
SPF calculation. This is the default. calculation. This is the default.
* MixedModeOriginateOnly - Both extended and non-extended LSAs * MixedModeOriginateOnly - Both extended and non-extended LSAs
will be originated. OSPFv3 adjacencies will be formed with will be originated. OSPFv3 adjacencies will be formed with
OSPFv3 routers not supporting this specification. The non- OSPFv3 routers not supporting this specification. The non-
extended LSAs are used for the SPF computation. extended LSAs are used for the SPF computation.
* MixedModeOriginateSPF - Both extended and non-extended LSAs * MixedModeOriginateSPF - Both extended and non-extended LSAs
will be originated. OSPFv3 adjacencies will be formed with will be originated. OSPFv3 adjacencies will be formed with
OSPFv3 routers not supporting this specification. The extended OSPFv3 routers not supporting this specification. The extended
LSAs are used for the SPF computation. LSAs are used for the SPF computation.
 End of changes. 134 change blocks. 
370 lines changed or deleted 499 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/