author = {Michael Barnes and Sina Mirtorabi and Rahul Aggarwal and Abhay Roy and Acee Lindem},
title = {{Support of Address Families in OSPFv3}},
pagetotal = 13,
year = 2010,
month = apr,
abstract = {This document describes a mechanism for supporting multiple address families (AFs) in OSPFv3 using multiple instances. It maps an AF to an OSPFv3 instance using the Instance ID field in the OSPFv3 packet header. This approach is fairly simple and minimizes extensions to OSPFv3 for supporting multiple AFs. {[}STANDARDS-TRACK{]}},
}
@misc{rfc8042,
series = {Request for Comments},
number = 8042,
howpublished = {RFC 8042},
publisher = {RFC Editor},
doi = {10.17487/RFC8042},
url = {https://www.rfc-editor.org/info/rfc8042},
author = {Zhaohui (Jeffrey) Zhang and Lili Wang and Acee Lindem},
title = {{OSPF Two-Part Metric}},
pagetotal = 9,
year = 2016,
month = dec,
abstract = {This document specifies an optional OSPF protocol extension to represent router metrics in a multi-access network in two parts: the metric from the router to the network and the metric from the network to the router. For such networks, the router-to-router metric for OSPF route computation is the sum of the two parts. This document updates RFC 2328.},
}
@misc{rfc6919,
series = {Request for Comments},
number = 6919,
howpublished = {RFC 6919},
publisher = {RFC Editor},
doi = {10.17487/RFC6919},
url = {https://www.rfc-editor.org/info/rfc6919},
author = {Eric Rescorla and Richard Barnes and Stephen Kent},
title = {{Further Key Words for Use in RFCs to Indicate Requirement Levels}},
pagetotal = 6,
year = 2013,
month = apr,
day = 1,
abstract = {RFC 2119 defines a standard set of key words for describing requirements of a specification. Many IETF documents have found that these words cannot accurately capture the nuanced requirements of their specification. This document defines additional key words that can be used to address alternative requirements scenarios. Authors who follow these guidelines should incorporate this phrase near the beginning of their document: The key words "MUST (BUT WE KNOW YOU WON\textbackslash{}'T)", "SHOULD CONSIDER", "REALLY SHOULD NOT", "OUGHT TO", "WOULD PROBABLY", "MAY WISH TO", "COULD", "POSSIBLE", and "MIGHT" in this document are to be interpreted as described in RFC 6919.},
}
@misc{rfc2328,
series = {Request for Comments},
number = 2328,
howpublished = {RFC 2328},
publisher = {RFC Editor},
doi = {10.17487/RFC2328},
url = {https://www.rfc-editor.org/info/rfc2328},
author = {John Moy},
title = {{OSPF Version 2}},
pagetotal = 244,
year = 1998,
month = apr,
day = 1,
abstract = {This memo documents version 2 of the OSPF protocol. OSPF is a link- state routing protocol. {[}STANDARDS-TRACK{]}},
title = {{The OSPF Not-So-Stubby Area (NSSA) Option}},
pagetotal = 33,
year = 2003,
month = jan,
abstract = {This memo documents an optional type of Open Shortest Path First (OSPF) area that is somewhat humorously referred to as a "not-so-stubby" area (or NSSA). NSSAs are similar to the existing OSPF stub area configuration option but have the additional capability of importing AS external routes in a limited fashion. The OSPF NSSA Option was originally defined in RFC 1587. The functional differences between this memo and RFC 1587 are explained in Appendix F. All differences, while expanding capability, are backward-compatible in nature. Implementations of this memo and of RFC 1587 will interoperate. {[}STANDARDS-TRACK{]}},
}
@misc{rfc6549,
series = {Request for Comments},
number = 6549,
howpublished = {RFC 6549},
publisher = {RFC Editor},
doi = {10.17487/RFC6549},
url = {https://www.rfc-editor.org/info/rfc6549},
author = {Acee Lindem and Abhay Roy and Sina Mirtorabi},
title = {{OSPFv2 Multi-Instance Extensions}},
pagetotal = 9,
year = 2012,
month = mar,
abstract = {OSPFv3 includes a mechanism to support multiple instances of the protocol running on the same interface. OSPFv2 can utilize such a mechanism in order to support multiple routing domains on the same subnet. This document defines the OSPFv2 Instance ID to enable separate OSPFv2 protocol instances on the same interface. Unlike OSPFv3 where the Instance ID can be used for multiple purposes, such as putting the same interface in multiple areas, the OSPFv2 Instance ID is reserved for identifying protocol instances. This document updates RFC 2328. {[}STANDARDS-TRACK{]}},
}
@misc{rfc5709,
series = {Request for Comments},
number = 5709,
howpublished = {RFC 5709},
publisher = {RFC Editor},
doi = {10.17487/RFC5709},
url = {https://www.rfc-editor.org/info/rfc5709},
author = {M Fanto and Randall Atkinson and Michael Barnes and Vishwas Manral and Russ White and Tony Li and Manav Bhatia},
title = {{OSPFv2 HMAC-SHA Cryptographic Authentication}},
pagetotal = 14,
year = 2009,
month = oct,
abstract = {This document describes how the National Institute of Standards and Technology (NIST) Secure Hash Standard family of algorithms can be used with OSPF version 2's built-in, cryptographic authentication mechanism. This updates, but does not supercede, the cryptographic authentication mechanism specified in RFC 2328. {[}STANDARDS-TRACK{]}},
author = {Dennis Ferguson and Acee Lindem and John Moy},
title = {{OSPF for IPv6}},
pagetotal = 94,
year = 2008,
month = jul,
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. {[}STANDARDS-TRACK{]}},
}
% I have no idea where the abstract is from, but I do not care much.
@misc{rfc1131,
series = {Request for Comments},
number = 1131,
howpublished = {RFC 1131},
publisher = {RFC Editor},
doi = {10.17487/RFC1131},
url = {https://www.rfc-editor.org/info/rfc1131},
author = {John Moy},
title = {{The OSPF Specification}},
pagetotal = 103,
year = 1989,
month = oct,
abstract = {This RFC is the specification of the Open Shortest Path First (OSPF) Internet routing protocol. OSPF is in the class of Internal Gateway Protocols (IGPs) for distributing routing information between gateways of a single Autonomous System. This routing protocol is based on the link-state approach (in contrast to the distance-vector approach). This specification was developed by the OSPF Working Group of the Internet Engineering Task Force. {[}STANDARDS-TRACK{]}},
