RFC Errata
Found 7 records.
Status: Verified (3)
RFC 4632, "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
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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.
Errata ID: 4194
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: larry
Date Reported: 2014-12-04
Verifier Name: Benoit Claise
Date Verified: 2015-07-19
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)
RFC 4632, "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
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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)
RFC 4632, "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
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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.