RFC Errata
Found 5 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