3. Differences with RFC 2740
OSPFv3 implementations based on RFC 2740 will fully interoperate with implementations based on this specification. There are, however, some protocol additions and changes (all of which are backward compatible).
3.1. Support for Multiple Interfaces on the Same Link
This protocol feature was only partially specified in the RFC 2740. The level of specification was insufficient to implement the feature. Section 4.9 specifies the additions and clarifications necessary for implementation. They are fully compatible with RFC 2740.
3.2. Deprecation of MOSPF for IPv6
This protocol feature was only partially specified in RFC 2740. The level of specification was insufficient to implement the feature. There are no known implementations. Multicast Extensions to OSPF (MOSPF) support and its attendant protocol fields have been deprecated from OSPFv3. Refer to Section 4.4.3.2, Section 4.4.3.4, Section 4.4.3.6, Section 4.4.3.7, Appendix A.2, Appendix A.4.2.1, Appendix A.4.3, Appendix A.4.1.1, and Section 7.1.
3.3. NSSA Specification
This protocol feature was only partially specified in RFC 2740. The level of specification was insufficient to implement the function. This document includes an NSSA specification unique to OSPFv3. This specification coupled with [NSSA] provide sufficient specification for implementation. Refer to Section 4.8.5, Appendix A.4.3, Appendix A.4.8, and [NSSA].
3.4. Stub Area Unknown LSA Flooding Restriction Deprecated
In RFC 2740 [OSPFV3], flooding of unknown LSA was restricted within stub and NSSA areas. The text describing this restriction is included below.
However, unlike in IPv4, IPv6 allows LSAs with unrecognized LS types to be labeled "Store and flood the LSA, as if type understood" (see the U-bit in Appendix A.4.2.1). Uncontrolled introduction of such LSAs could cause a stub area's link-state database to grow larger than its component routers' capacities.
To guard against this, the following rule regarding stub areas has been established: an LSA whose LS type is unrecognized can only be flooded into/throughout a stub area if both a) the LSA has area or link-local flooding scope and b) the LSA has U-bit set to 0. See Section 3.5 for details.
This restriction has been deprecated. OSPFv3 routers will flood link and area scope LSAs whose LS type is unrecognized and whose U-bit is set to 1 throughout stub and NSSA areas. There are no backward-compatibility issues other than OSPFv3 routers still supporting the restriction may not propagate newly defined LSA types.
3.5. Link LSA Suppression
The LinkLSASuppression interface configuration parameter has been added. If LinkLSASuppression is configured for an interface and the interface type is not broadcast or NBMA, origination of the link-LSA may be suppressed. The LinkLSASuppression interface configuration parameter is described in Appendix C.3. Section 4.8.2 and Section 4.4.3.8 were updated to reflect the parameter's usage.
3.6. LSA Options and Prefix Options Updates
The LSA Options and Prefix Options fields have been updated to reflect recent protocol additions. Specifically, bits related to MOSPF have been deprecated, Options field bits common with OSPFv2 have been reserved, and the DN-bit has been added to the prefix-options. Refer to Appendix A.2 and Appendix A.4.1.1.
3.7. IPv6 Site-Local Addresses
All references to IPv6 site-local addresses have been removed.