RFC Errata
Found 9 records.
Status: Verified (5)
RFC 5340, "OSPF for IPv6", July 2008
Note: This RFC has been updated by RFC 6845, RFC 6860, RFC 7503, RFC 8362, RFC 9454
Source of RFC: ospf (rtg)
Errata ID: 2078
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Acee Lindem
Date Reported: 2010-03-17
Verifier Name: Stewart Bryant
Date Verified: 2013-01-07
Section 4.8.1 says:
o In Step 2, when a router Vertex V has just been added to the
shortest-path tree, there may be multiple LSAs associated with the
router. All router-LSAs with the Advertising Router set to V's
OSPF Router ID MUST be processed as an aggregate, treating them as
fragments of a single large router-LSA. The Options field and the
Coltun, et al. Standards Track [Page 45]
^L
RFC 5340 OSPF for IPv6 July 2008
router type bits (bits Nt, V, E, and B) should always be taken
from the router-LSA with the smallest Link State ID.
o Step 2a is not needed in IPv6, as there are no longer stub network
links in router-LSAs.
o In Step 2b, if W is a router and the router-LSA V6-bit or R-bit is
not set in the LSA options, the transit link W is ignored and V's
next link is examined.
It should say:
o In Step 2, when a router Vertex V other than the root (which is
the router doing the calculation) has just been added to the
shortest-path tree and the router-LSA R-bit is not set in the
LSA options, Vertex V's links are ignored and the next vertex on
the candidate list should be examined as described in Step 3.
Coltun, et al. Standards Track [Page 45]
^L
RFC 5340 OSPF for IPv6 July 2008
o Also In Step 2, when a router Vertex V has just been added to the
shortest-path tree, there may be multiple LSAs associated with the
router. All router-LSAs with the Advertising Router set to V's
OSPF Router ID MUST be processed as an aggregate, treating them as
fragments of a single large router-LSA. The Options field and the
router type bits (bits Nt, V, E, and B) should always be taken
from the router-LSA with the smallest Link State ID.
o Step 2a is not needed in IPv6, as there are no longer stub network
links in router-LSAs.
o In Step 2b, if W is a router and the router-LSA V6-bit is not set
in the LSA options, the transit link to W is ignored and V's next
link is examined.
Notes:
This change corrects errata 2046 described below:
This change reflects the fact that the R-bit and the V6-bit should not be handled identically. The R-bit allows the router to participate in the IPv6 unicast topology but does not allow transit traffic. The V6-bit doesn't allow either. This problem was pointed out by Balaji Ganesh.
Michael Barnes brought up the fact that the R-Bit should be ignored in the Router-LSA for the calculating router. This errata fixes this omission in the first paragraph of the corrected text.
Errata ID: 3350
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Michael Barnes
Date Reported: 2012-09-12
Verifier Name: Stewart Bryant
Date Verified: 2013-01-07
Section 2.7 says:
o Two Options bits, the "R-bit" and the "V6-bit", have been added to
the Options field for processing router-LSAs during the SPF
calculation (see Appendix A.2). If the "R-bit" is clear, an OSPF
speaker can participate in OSPF topology distribution without
being used to forward transit traffic; this can be used in multi-
homed hosts that want to participate in the routing protocol. The
V6-bit specializes the R-bit; if the V6-bit is clear, an OSPF
speaker can participate in OSPF topology distribution without
being used to forward IPv6 datagrams. If the R-bit is set and the
V6-bit is clear, IPv6 datagrams are not forwarded but datagrams
belonging to another protocol family may be forwarded.
It should say:
o Two Options bits, the "R-bit" and the "V6-bit", have been added to
the Options field for processing router-LSAs during the SPF
calculation (see Appendix A.2). If the "R-bit" is clear, an OSPF
speaker can participate in OSPF topology distribution without
being used to forward transit traffic; this can be used in multi-
homed hosts that want to participate in the routing protocol. An
Area Border Router MUST advertise a consistent R-bit setting in
its self-originated router-LSAs for all attached areas.
The V6-bit specializes the R-bit; if the V6-bit is clear, an OSPF
speaker can participate in OSPF topology distribution without
being used to forward IPv6 datagrams. If the R-bit is set and the
V6-bit is clear, IPv6 datagrams are not forwarded but datagrams
belonging to another protocol family may be forwarded.
Notes:
This addresses a corner case.
Errata ID: 3351
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Michael Barnes
Date Reported: 2012-09-12
Verifier Name: Stewart Bryant
Date Verified: 2013-01-07
Section 4.4.3.4 says:
o Link-local addresses MUST never be advertised in inter-area-
prefix-LSAs.
It should say:
o Link-local addresses MUST never be advertised in inter-area-
prefix-LSAs.
o If the router's router-LSA R-bit is clear, only IPv6 prefixes
associated with local interfaces MAY be advertised in
inter-area-prefix-LSAs. Non-local IPv6 prefixes, e.g., those
advertised by other routers and installed during the SPF computation,
MUST NOT be advertised in inter-area-prefixes-LSAs.
Errata ID: 3352
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Michael Barnes
Date Reported: 2012-09-12
Verifier Name: Stewart Bryant
Date Verified: 2013-01-07
Section 4.4.3.6 says:
o Link-local addresses can never be advertised in AS-external-LSAs.
It should say:
o Link-local addresses can never be advertised in AS-external-LSAs.
o If the router's router-LSA R-bit is clear, only IPv6 prefixes
associated with local interfaces MAY be advertised in AS-external-LSAs.
Non-local IPv6 prefixes, e.g., those exported from other routing
protocols, MUST NOT be advertised in AS-external-LSAs.
Errata ID: 3357
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: David Ward
Date Reported: 2012-09-17
Verifier Name: Stewart Bryant
Date Verified: 2013-01-07
Section C.7 says:
Host IPv6 prefix
An IPv6 prefix belonging to the directly connected host. This
must not be a valid IPv6 global prefix.
It should say:
Host IPv6 prefix
An IPv6 prefix belonging to the directly connected host. This
must be a valid IPv6 global prefix.
Notes:
http://www.ietf.org/mail-archive/web/ospf/current/msg06446.html
Status: Held for Document Update (2)
RFC 5340, "OSPF for IPv6", July 2008
Note: This RFC has been updated by RFC 6845, RFC 6860, RFC 7503, RFC 8362, RFC 9454
Source of RFC: ospf (rtg)
Errata ID: 1582
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Faraz Shamim
Date Reported: 2008-11-01
Held for Document Update by: Stewart Bryant
Section 8 says:
Faraz Shamin reviewed a late version of the document and provided editorial comments.
It should say:
Faraz Shamim reviewed a late version of the document and provided editorial comments.
Notes:
Last name is mis-spelled with "n" at the end instead of "m"
Errata ID: 1583
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Faraz Shamim
Date Reported: 2008-11-01
Held for Document Update by: Stewart Bryant
Section 8 says:
Faraz Shamin reviewed a late version of the document and provided
editorial comments.
It should say:
Faraz Shamim reviewed a late version of the document and provided
editorial comments.
Notes:
Last name is mis-spelled. Instead of "m" at the end it says "n"
Status: Rejected (2)
RFC 5340, "OSPF for IPv6", July 2008
Note: This RFC has been updated by RFC 6845, RFC 6860, RFC 7503, RFC 8362, RFC 9454
Source of RFC: ospf (rtg)
Errata ID: 2046
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Acee Lindem
Date Reported: 2010-02-17
Rejected by: Stewart Bryant
Date Rejected: 2012-02-07
Section 4.8.1 says:
o In Step 2, when a router Vertex V has just been added to the
shortest-path tree, there may be multiple LSAs associated with the
router. All router-LSAs with the Advertising Router set to V's
OSPF Router ID MUST be processed as an aggregate, treating them as
fragments of a single large router-LSA. The Options field and the
Coltun, et al. Standards Track [Page 45]
^L
RFC 5340 OSPF for IPv6 July 2008
router type bits (bits Nt, V, E, and B) should always be taken
from the router-LSA with the smallest Link State ID.
o Step 2a is not needed in IPv6, as there are no longer stub network
links in router-LSAs.
o In Step 2b, if W is a router and the router-LSA V6-bit or R-bit is
not set in the LSA options, the transit link W is ignored and V's
next link is examined.
It should say:
o In Step 2, when a router Vertex V has just been added to the
shortest-path tree and the router-LSA R-bit is not set in the
LSA options, Vertex V's links are ignored and the next vertex on
the candidate list should be examined as described in Step 3.
Coltun, et al. Standards Track [Page 45]
^L
RFC 5340 OSPF for IPv6 July 2008
o Also In Step 2, when a router Vertex V has just been added to the
shortest-path tree, there may be multiple LSAs associated with the
router. All router-LSAs with the Advertising Router set to V's
OSPF Router ID MUST be processed as an aggregate, treating them as
fragments of a single large router-LSA. The Options field and the
router type bits (bits Nt, V, E, and B) should always be taken
from the router-LSA with the smallest Link State ID.
o Step 2a is not needed in IPv6, as there are no longer stub network
links in router-LSAs.
o In Step 2b, if W is a router and the router-LSA V6-bit is not set
in the LSA options, the transit link to W is ignored and V's next
link is examined.
Notes:
This changes reflects the fact that the R-bit and the V6-bit should not be handled identically. The R-bit allows the router to participate in the IPv6 unicast topology but does not allow transit traffic. The V6-bit doesn't allow either. This problem was pointed out by Balaji Ganesh.
--VERIFIER NOTES--
This has been superseded by Errata 2078
Errata ID: 7649
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Owen DeLong
Date Reported: 2023-09-19
Rejected by: John Scudder
Date Rejected: 2024-01-11
Section A.3.3 (in part) says:
Interface MTU
The size in bytes of the largest IPv6 datagram that can be sent
out the associated interface without fragmentation. The MTUs of
common Internet link types can be found in Table 7-1 of [MTUDISC].
Interface MTU should be set to 0 in Database Description packets
sent over virtual links.
It should say:
Interface MTU
The size in bytes of the largest IPv6 datagram that can be sent
out the associated interface without fragmentation. The MTUs of
common Internet link types can be found in Table 7-1 of [MTUDISC].
Interface MTU should be set to 0 in Database Description packets
sent over OSPF virtual links. This rule should not be applied to tunnel
or other software interfaces.
Notes:
OSPF Virtual links carry only OSPF packets so MTU negotiation is not needed and this provision makes sense. For interfaces that have an actual MTU, even though they may be "virtual" interfaces, they are not "virtual links" in the intended meaning of this paragraph. As such, this change will provide clarification and remove ambiguity from the current standard. At least one popular router vendor implements this RFC as MTU = 0 sent on all GRE interfaces which results in incompatibilities with most other router platforms which expect an actual value. The router vendor points to this provision in the RFCs as justification for their implementation. It is (arguably) a legitimate, if nonsensical interpretation of the existing text.
--VERIFIER NOTES--
See discussion at https://mailarchive.ietf.org/arch/msg/lsr/mrmkQt9ETTYemukBzl6K_FmgHps/
It seems as though there is not clear consensus for the proposed change or even to make a similar change; as such the normal WG process (internet draft, WG consensus) is a better way to pursue the goal.