errata logo graphic

Found 7 records.

Status: Verified (2)

RFC4632, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", August 2006

Source of RFC: grow (ops)

Errata ID: 2955

Status: Verified
Type: Technical

Reported By: Olivier Le Rigoleur
Date Reported: 2011-09-03
Verifier Name: ron bonica
Date Verified: 2011-09-09

Section 6.1 says:

 C2: 10.24.16.0/20       \ |    |  _10.24.12.0 - 10.24.15.0__  |    |
                          \|    | / C4: 10.24.12.0/20        \ |    |
                                                 ~~~~~

It should say:

 C2: 10.24.16.0/20       \ |    |  _10.24.12.0 - 10.24.15.0__  |    |
                          \|    | / C4: 10.24.12.0/22        \ |    |

Notes:

~Should be 10.24.12.0/22 as described just above


Errata ID: 3485

Status: Verified
Type: Technical

Reported By: Markus Falb
Date Reported: 2013-02-18
Verifier Name: RonBonica
Date Verified: 2013-02-18

Section 2 says:

three classes of networks: Class A
(most significant address bits '00'), with 128 possible networks each
and 16777216 end systems

It should say:

three classes of networks: Class A
(most significant address bit '0'), with 128 possible networks each
and 16777216 end systems

Notes:

MSB bits ’00’ would mean that only 6 bits are available for the network part and this would mean only 64 CLASS A networks.


Status: Reported (1)

RFC4632, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", August 2006

Source of RFC: grow (ops)

Errata ID: 4194

Status: Reported
Type: Editorial

Reported By: larry
Date Reported: 2014-12-04

Section 5.3 says:

 Systems that process route announcements must be able to verify that
   information that they receive is acceptable according to policy
   rules.  Implementations that filter route advertisements must allow
   masks or prefix lengths in filter elements.  Thus, filter elements
   that formerly were specified as

      accept 172.16.0.0
      accept 172.25.120.0.0
      accept 172.31.0.0
      deny 10.2.0.0
      accept 10.0.0.0

It should say:

 Systems that process route announcements must be able to verify that
   information that they receive is acceptable according to policy
   rules.  Implementations that filter route advertisements must allow
   masks or prefix lengths in filter elements.  Thus, filter elements
   that formerly were specified as

      accept 172.16.0.0
      accept 172.25.120.0
      accept 172.31.0.0
      deny 10.2.0.0
      accept 10.0.0.0

Notes:

the second network address has 40 bits (5 groups of numbers instead of 4-32 bits).

172.25.120.0.0


Status: Held for Document Update (2)

RFC4632, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", August 2006

Source of RFC: grow (ops)

Errata ID: 1577

Status: Held for Document Update
Type: Technical

Reported By: Tony Li
Date Reported: 2008-10-23
Held for Document Update by: Ron Bonica

Section 3.1 says:

   For example, the legacy "Class B" network 172.16.0.0, with an implied
   network mask of 255.255.0.0, is defined as the prefix 172.16.0.0/16,
   the "/16" indicating that the mask to extract the network portion of
   the prefix is a 32-bit value where the most significant 16 bits are
   ones and the least significant 16 bits are zeros.  Similarly, the
   legacy "Class C" network number 192.168.99.0 is defined as the prefix
   192.168.99.0/24; the most significant 24 bits are ones and the least
   significant 8 bits are zeros.


It should say:

   For example, the legacy "Class B" network 172.16.0.0, with an implied
   network mask of 255.255.0.0, is defined as the prefix 172.16.0.0/16,
   the "/16" indicating that the mask to extract the network portion of
   the prefix is a 32-bit value where the most significant 16 bits are
   ones and the least significant 16 bits are zeros.  Similarly, the
   legacy "Class C" network number 192.168.99.0 is defined as the prefix
   192.168.99.0/24; the most significant 24 bits are ones and the least
   significant 8 bits are zeros.

   In cases where a prefix has 1, 2, or 3 trailing insignificant
   octets, it is permissible to elide the insignificant octets and
   trailing '.' separators. Thus, 172.16.0.0/16 may also be represented
   as 172.16/16, and 192.168.99.0/24 is equivalent to 192.168.99/24.



Notes:

This adds some clarifying text and documents a common convention for displaying prefixes. It was never the intention of the authors to exclude the alternative notation and it has since come into vogue. It should be explicitly documented as being acceptable.


Errata ID: 1824

Status: Held for Document Update
Type: Editorial

Reported By: Dande Rajasekhar
Date Reported: 2009-08-05
Held for Document Update by: Ron Bonica

Section 6.1 says:

To make this example more realistic, assume that C4 and C5 are multi-
   homed through some other service provider, "PB".  Further assume the
   existence of a site, "C7", that was originally connected to "RB" but
   that has moved to "PA".  For this reason, it has a block of network
   numbers that are assigned out PB's block of (the next) 2048 x /24.

   o  C7.  Assign 10.32.0 through 10.32.15.  This block is described by
      the route 10.32.0.0/20 (mask 255.255.240.0).

For the multi-homed sites, assume that C4 is advertised as primary
   via "RA" and secondary via "RB"; and that C5 is primary via "RB" and
   secondary via "RA".  In addition, assume that "RA" and "RB" are both
   connected to the same transit service provider, "BB".

   Graphically, this topology looks something like this:

   10.24.0.0 -- 10.24.7.0__         __10.32.0.0 - 10.32.15.0
   C1: 10.24.0.0/21        \       /  C7: 10.32.0.0/20
                            \     /
                             +----+                              +----+
   10.24.16.0 - 10.24.31.0_  |    |                              |    |
   C2: 10.24.16.0/20       \ |    |  _10.24.12.0 - 10.24.15.0__  |    |
                            \|    | / C4: 10.24.12.0/20        \ |    |
                             |    |/                            \|    |
   10.24.8.0 - 10.24.11.0___/| PA |\                             | PB |
   C3: 10.24.8.0/22          |    | \__10.24.32.0 - 10.24.33.0___|    |
                             |    |    C5: 10.24.32.0/23         |    |
                             |    |                              |    |
   10.24.34.0 - 10.24.35.0__/|    |                              |    |
   C6: 10.24.34.0/23         |    |                              |    |
                             +----+                              +----+
                               ||                                  ||
   routing advertisements:     ||                                  ||
                               ||                                  ||
           10.24.12.0/22 (C4)  ||              10.24.12.0/22 (C4)  ||
           10.32.0.0/20 (C7)   ||              10.24.32.0/23 (C5)  ||
           10.24.0.0/13 (PA)   ||              10.32.0.0/13 (PB)   ||
                               ||                                  ||
                               VV                                  VV
                            +---------- BACKBONE NETWORK BB ----------+

It should say:

To make this example more realistic, assume that C4 and C5 are multi-
   homed through some other service provider, "PB".  Further assume the
   existence of a site, "C7", that was originally connected to "PB" but
   that has moved to "PA".  For this reason, it has a block of network
   numbers that are assigned out PB's block of (the next) 2048 x /24.

   o  C7.  Assign 10.32.0 through 10.32.15.  This block is described by
      the route 10.32.0.0/20 (mask 255.255.240.0).

For the multi-homed sites, assume that C4 is advertised as primary
   via "PA" and secondary via "PB"; and that C5 is primary via "PB" and
   secondary via "PA".  In addition, assume that "PA" and "PB" are both
   connected to the same transit service provider, "BB".

   Graphically, this topology looks something like this:

   10.24.0.0 -- 10.24.7.0__         __10.32.0.0 - 10.32.15.0
   C1: 10.24.0.0/21        \       /  C7: 10.32.0.0/20
                            \     /
                             +----+                              +----+
   10.24.16.0 - 10.24.31.0_  |    |                              |    |
   C2: 10.24.16.0/20       \ |    |  _10.24.12.0 - 10.24.15.0__  |    |
                            \|    | / C4: 10.24.12.0/20        \ |    |
                             |    |/                            \|    |
   10.24.8.0 - 10.24.11.0___/| PA |\                             | PB |
   C3: 10.24.8.0/22          |    | \__10.24.32.0 - 10.24.33.0___|    |
                             |    |    C5: 10.24.32.0/23         |    |
                             |    |                              |    |
   10.24.34.0 - 10.24.35.0__/|    |                              |    |
   C6: 10.24.34.0/23         |    |                              |    |
                             +----+                              +----+
                               ||                                  ||
   routing advertisements:     ||                                  ||
                               ||                                  ||
           10.24.12.0/22 (C4)  ||              10.24.12.0/22 (C4)  ||
           10.32.0.0/20 (C7)   ||              10.24.32.0/23 (C5)  ||
           10.24.0.0/13 (PA)   ||              10.32.0.0/13 (PB)   ||
                               ||                                  ||
                               VV                                  VV
                            +---------- BACKBONE NETWORK BB ----------+

Notes:

All the reference of "RA" and "RB" to be replaced with "PA" and "PB".


Status: Rejected (2)

RFC4632, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", August 2006

Source of RFC: grow (ops)

Errata ID: 38

Status: Rejected
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2006-11-01
Rejected by: Tony Li
Date Rejected: 2006-11-01

Section 2 says:

   3.  Eventual exhaustion of the 32-bit IPv4 address space.

       It was clear that then-current rates of Internet growth would
       cause the first two problems to become critical sometime between
       1993 and 1995.  Work already in progress on topological
       assignment of addressing for Connectionless Network Service
       (CLNS), which was presented to the community at the Boulder IETF
       in December of 1990, led to thoughts on how to re-structure the
       32-bit IPv4 address space to increase its lifespan.  Work in the
       ROAD group followed and eventually resulted in the publication of
       [RFC1338], and later, [RFC1519].

       The design and deployment of CIDR was intended to solve these
       problems by providing a mechanism to slow the growth of global
       routing tables and to reduce the rate of consumption of IPv4
       address space.  It did not and does not attempt to solve the
       third problem, which is of a more long-term nature; instead, it
       endeavors to ease enough of the short- to mid-term difficulties
       to allow the Internet to continue to function efficiently while
       progress is made on a longer-term solution.

       More historical background on this effort and on the ROAD group
       may be found in [RFC1380] and at [LWRD].

3.  Classless Addressing as a Solution

It should say:

   3.  Eventual exhaustion of the 32-bit IPv4 address space.

   It was clear that then-current rates of Internet growth would
   cause the first two problems to become critical sometime between
   1993 and 1995.  Work already in progress on topological
   assignment of addressing for Connectionless Network Service
   (CLNS), which was presented to the community at the Boulder IETF
   in December of 1990, led to thoughts on how to re-structure the
   32-bit IPv4 address space to increase its lifespan.  Work in the
   ROAD group followed and eventually resulted in the publication of
   [RFC1338], and later, [RFC1519].

   The design and deployment of CIDR was intended to solve these
   problems by providing a mechanism to slow the growth of global
   routing tables and to reduce the rate of consumption of IPv4
   address space.  It did not and does not attempt to solve the
   third problem, which is of a more long-term nature; instead, it
   endeavors to ease enough of the short- to mid-term difficulties
   to allow the Internet to continue to function efficiently while
   progress is made on a longer-term solution.

   More historical background on this effort and on the ROAD group
   may be found in [RFC1380] and at [LWRD].

3.  Classless Addressing as a Solution

Notes:

In Section 2, on page 4 of RFC 4632, the text after the
enumerated item '3.' up to the end of the section is indented
too much (by 4 columns), making it erroneously appear to belong
to that item '3.'

--VERIFIER COMMENT--
Thank you very much for your eagle eyes and your comments. I agree
with all of them. If you had submitted them during the Internet-draft
process, I would make all of these modifications immediately.
However, now that the RFC is issued, I believe that we should be quite
a bit more conservative before issuing Errata, so as to not congest
the Errata and obscure vital and substantive changes that might affect
actual interoperability of standards interpretation. With that view
in mind, I'd like to suggest that we not issue any Errata at this
time. I look forward to your input on subsequent draft documents.


Errata ID: 799

Status: Rejected
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2006-11-01
Rejected by: Tony Li
Date Rejected: 2006-11-01

 

(1) [[posted separately.]]

(2)  typo (word replication)

In the second paragraph of Section 5.2, at the bottom of page 12,
RFC 4632 says:

                                             [...].  If the "child"
   network were to lose internal connectivity to 192.168.65.0/24 (which
|  is part of its aggregate), traffic from the "parent" to the to the
   "child" destined for 192.168.65.1 will follow the "child's"
   advertised route.  [...]
                                                        ^^^^^^^^^^^^^
It should say:

                                             [...].  If the "child"
   network were to lose internal connectivity to 192.168.65.0/24 (which
|  is part of its aggregate), traffic from the "parent" to the "child"
   destined for 192.168.65.1 will follow the "child's" advertised route.
   [...]


(3)  garbled sentence

The second paragraph of Section 7, on page 18, says:

   A description of techniques to populate the IN-ADDR.ARPA zone when
   and used address that blocks that do not align to octet boundaries is
   described in [RFC2317].

Apparently, this sentence is garbled; as written, it makes no sense.
Perhaps, it was intended to say:

   A description of techniques to populate the IN-ADDR.ARPA zone when
|  used address blocks do not align to octet boundaries is described in
   [RFC2317].


(4)  typo (singular/plural mismatch)

On page 19, the second enumerated bullet in Section 9 says:

   2.  Acceleration of the exponential trend in late 1993 and early 1994
       as CIDR "supernet" blocks were first assigned by the NIC and
       routed as separate legacy class-C networks by service provider.

It should say:

   2.  Acceleration of the exponential trend in late 1993 and early 1994
       as CIDR "supernet" blocks were first assigned by the NIC and
|      routed as separate legacy class-C networks by service providers.
                                                                     ^


(5)  incomplete status change of legacy documents

Section 11 (pp. 21/22) re-classifies a couple of legacy RFCs as
Historic.
Unfortunately, there are additional documents closely related to
these re-classified documents left alone -- and apparently still
current.
IMHO, it would have been much clearer to also re-classify RFC 1797
and RFC 1879 as Historic, as well.

Note:
Admittedly, there may be a gap in the IETF document maintenance
procedures not formally allowing Informational and Experimental
RFCs to be re-classified as Historic.  If this was the reason for
omitting the named RFCs from Section 11 of RFC 4632, it would
perhaps have been useful to "obsolete" these RFCs by RFC 4632.
This situation is bound to recur with more Informational RFCs
published as companion documents to Standards Track RFCs;
thus, a general procedural solution should be sought to visibly
(in the RFC index) 'outdate' such RFCs when updates get published.

Notes:

from pending

--VERIFIER COMMENT--
Thank you very much for your eagle eyes and your comments. I agree
with all of them. If you had submitted them during the Internet-draft
process, I would make all of these modifications immediately.
However, now that the RFC is issued, I believe that we should be quite
a bit more conservative before issuing Errata, so as to not congest
the Errata and obscure vital and substantive changes that might affect
actual interoperability of standards interpretation. With that view
in mind, I'd like to suggest that we not issue any Errata at this
time. I look forward to your input on subsequent draft documents.


Report New Errata