RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

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.

Report New Errata



Advanced Search