Technical Summary
This document describes the modifications to OSPF to support version
6 of the Internet Protocol (IPv6). The fundamental mechanisms of
OSPF (flooding, Designated Router (DR) election, area support,
(Shortest Path First) SPF calculations, etc.) remain unchanged.
However, some changes have been necessary, either due to changes in
protocol semantics between IPv4 and IPv6, or simply to handle the
increased address size of IPv6. These modifications will necessitate
incrementing the protocol version from version 2 to version 3. OSPF
for IPv6 is also referred to as OSPF Version 3 (OSPFv3).
This document is organized as follows. Section 2 describes the
differences between OSPF for IPv4 (OSPF Version 2) and OSPF for IPv6
(OSPF Version 3) in detail. Section 3 provides implementation
details for the changes. Appendix A gives the OSPF for IPv6 packet
and Link State Advertisement (LSA) formats. Appendix B lists the
OSPF architectural constants. Appendix C describes configuration
parameters.
Working Group Summary
This document could be considered the lifework of Acee Lindem. The doc
was originally WG LC'ed at rev 11 (we are at 21 now). The document
represents a complete overhaul of the specification of OSPFv3 from
something that was a "sketch" by the original authors to something that is
now widely deployed.
Document Quality
There are multiple deployed implementations of OSPFV3 and the document
is of excellent quality at this point. It has been through multiple LCs,
edits, revisions, clarifications and had a large amount of expert review.
It is believed that OSPFV3 can be implemented from this specification.
Personnel
DWard is the shepherding AD and been working/discussing the document
for it seems 10 years.
proto-writeup below:
1. Have the chairs personally reviewed this version of the Internet
Draft (ID), and in particular, do they believe this ID is ready
to forward to the IESG for publication?
Yes
2. Has the document had adequate review from both key WG members and
key non-WG members?
Yes
Do you have any concerns about the depth or breadth of the reviews
that have been performed?
No. This document is a counterpart to rfc3623 and uses similar
mechanism as specified in rfc3623.
3. Do you have concerns that the document needs more review from a
particular (broader) perspective (e.g., security, operational
complexity, someone familiar with AAA, etc.)?
No
4. Do you have any specific concerns/issues with this document that
you believe the ADs and/or IESG should be aware of? For example,
perhaps you are uncomfortable with certain parts of the document,
or have concerns whether there really is a need for it. In any event,
if your issues have been discussed in the WG and the WG has
indicated it that it still wishes to advance the document, detail
those concerns in the write-up.
No
5. How solid is the WG consensus behind this document? Does it
represent
the strong concurrence of a few individuals, with others being
silent,
or does the WG as a whole understand and agree with it?
Since it's a similar mechanism as in use by OSPFv2, there is
a strong consensus for this document.
6. Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict
in separate email to the Responsible Area Director.
No
7. Have the chairs verified that the document adheres to all
of the ID Checklist items ?
Yes (used idnits 2.04.16 to verify)
8. Is the document split into normative and informative references?
Are there normative references to IDs, where the IDs are not
also ready for advancement or are otherwise in an unclear state?
(note
here that the RFC editor will not publish an RFC with normative
references to IDs, it will delay publication until all such IDs
are also ready for publication as RFCs.)
Yes, No
9. What is the intended status of the document? (e.g., Proposed
Standard,
Informational?)
Proposed Standard
10. For Standards Track and BCP documents, the IESG approval
announcement
includes a write-up section with the following sections:
* Technical Summary
This documents extends OSPF graceful restart as documented
in RFC 3623 to OSPFv3. An OSPFv3 LSA type is used for signaling
and there are additional concerns with respect to avoiding churn
when determining whether pre-restart LSAs need to be reoriginated.
* Working Group Summary
There was no opposition to this document. There was one proposal
to modify the existing OSPF graceful restart mechanism but it was
not adopted by the working group and the requirement is unclear.
* Protocol Quality
The OSPFv3 graceful restart exhibits the quality as the
base OSPF Graceful Restart specification (RFC 3623). Both planned
and unplanned restart are supported. Depending on configuration,
OSPF LSAs changes may result in helping routers aborting graceful
restart or allowing the restarting router to proceed.