|
|
|
|
Found 8 records.
Errata ID: 3480
Status: Verified
Type: Technical
Reported By: Erik Hugne
Date Reported: 2013-02-07
Verifier Name: Brian Haberman
Date Verified: 2013-03-16
Section 2.7 says:
Interface-Local scope spans only a single interface on a node and is useful only for loopback transmission of multicast.
It should say:
Interface-Local scope spans only a single interface on a node and is useful only for loopback transmission of multicast. Packets with interface-local scope received from another node must be discarded.
Notes:
It should be explicitly stated that interface-local scoped multicast packets
received from the link must be discarded.
The BSD implementation currently does this, but not Linux.
http://www.ietf.org/mail-archive/web/ipv6/current/msg17154.html
Errata ID: 1627
Status: Held for Document Update
Type: Editorial
Reported By: Yelland Mr Michael
Date Reported: 2007-03-02
Held for Document Update by: RFC Editor
Date Held: 2008-12-03
Section 2.7 says:
Routers must not forward any multicast packets beyond of the scope indicated by the scop field in the destination multicast address.
It should say:
Routers must not forward any multicast packets beyond the scope indicated by the scop field in the destination multicast address.
Notes:
extraneous "of"
Errata ID: 2702
Status: Rejected
Type: Technical
Reported By: Bassam Al-Khaffaf
Date Reported: 2011-02-01
Rejected by: Ralph Droms
Date Rejected: 2012-03-26
Section 2.3 says:
For example, the following are legal representations of the 60-bit prefix 20010DB80000CD3 (hexadecimal): 2001:0DB8:0000:CD30:0000:0000:0000:0000/60 2001:0DB8::CD30:0:0:0:0/60 2001:0DB8:0000:CD30::/60
It should say:
For example, the following are legal representations of the 60-bit prefix 20010DB80000CD3 (hexadecimal): 2001:0DB8:0000:CD30:0000:0000:0000:0000/60 2001:0DB8:0000:CD30::/60
Notes:
According to the erratum reported on 2010-08-16 by Michael Rushton, the second text representation address of the example will be no more valid and should be taken away and keep the first and third ones.
This is because the use of "::" indicates two or more groups of 16 bits of zeros. Thank you
--VERIFIER NOTES--
Related to Bob Hinden's review of errata 2466:
I believe that this errata should be rejected. This was discussed on the v6ops mailing list around February 25, 2011. I responded:
http://www.ietf.org/mail-archive/web/v6ops/current/msg07741.html
The thread starts at:
http://www.ietf.org/mail-archive/web/v6ops/current/msg07722.html
Also, two errata were filed based on this one (Errata ID: 2735, Errata ID: 2702) that I think should also be rejected as they assume that this errata was correct.
Errata ID: 2735
Status: Rejected
Type: Technical
Reported By: Richard Hartmann
Date Reported: 2011-02-24
Rejected by: Ralph Droms
Date Rejected: 2012-03-26
Section 2.2 says:
2. Due to some methods of allocating certain styles of IPv6
addresses, it will be common for addresses to contain long strings
of zero bits. In order to make writing addresses containing zero
bits easier, a special syntax is available to compress the zeros.
The use of "::" indicates one or more groups of 16 bits of zeros.
The "::" can only appear once in an address. The "::" can also be
used to compress leading or trailing zeros in an address.
For example, the following addresses
2001:DB8:0:0:8:800:200C:417A a unicast address
FF01:0:0:0:0:0:0:101 a multicast address
0:0:0:0:0:0:0:1 the loopback address
0:0:0:0:0:0:0:0 the unspecified address
may be represented as
2001:DB8::8:800:200C:417A a unicast address
FF01::101 a multicast address
::1 the loopback address
:: the unspecified address
It should say:
2. Due to some methods of allocating certain styles of IPv6
addresses, it will be common for addresses to contain long strings
of zero bits. In order to make writing addresses containing zero
bits easier, a special syntax is available to compress the zeros.
The use of "::" indicates two or more groups of 16 bits of zeros.
The "::" can only appear once in an address. The "::" can also be
used to compress leading or trailing zeros in an address. All
compressed groups of 16 bits of zeros MUST be aligned with their
respective leading and trailing ":".
For example, the following addresses
2001:DB8:9300:0:12:0:0:417A a unicast address
FF01:0:0:0:0:0:0:101 a multicast address
0:0:0:0:0:0:0:1 the loopback address
0:0:0:0:0:0:0:0 the unspecified address
may be represented as
2001:DB8:9300:0:12::417A a unicast address
FF01::101 a multicast address
::1 the loopback address
:: the unspecified address
and MUST NOT be represented as
2001:DB8:93::12:0:0:417A an incorrect unicast address
Notes:
Errata ID: 2466 would change the text I am changing, as well.
My changed text includes the change from errata 2466 to avoid the likelyhood of human mistakes.
In case http://tools.ietf.org/html/draft-denog-v6ops-addresspartnaming becomes a RFC before this errata can be worked in, "group of 16 bits of zeros" should be replaced with "$new_term of zeros" or similar. As it looks today, $new_term will most likely end up being "hextet".
The current wording allows for 2001:DB8:9300:12:0:0:417A to be written as 2001:DB8:93::12:0:0:417A which is clearly wrong and against the intentions behind the relevant RFCs. While RFC 5952 puts additional constraints on compression, it still allows for the incorrect example given above.
Thus, alignment of 16 bit groups of zeros along ":" is enforced specifically.
--VERIFIER NOTES--
Related to Bob Hinden's report on errata 2466:
I believe that this errata should be rejected. This was discussed on the v6ops mailing list around February 25, 2011. I responded:
http://www.ietf.org/mail-archive/web/v6ops/current/msg07741.html
The thread starts at:
http://www.ietf.org/mail-archive/web/v6ops/current/msg07722.html
Also, two errata were filed based on this one (Errata ID: 2735, Errata ID: 2702) that I think should also be rejected as they assume that this errata was correct.
Errata ID: 2466
Status: Rejected
Type: Editorial
Reported By: Michael Rushton
Date Reported: 2010-08-16
Rejected by: Ralph Droms
Date Rejected: 2012-03-26
Section 2.2.2 says:
In order to make writing addresses containing zero
bits easier, a special syntax is available to compress the zeros.
The use of "::" indicates one or more groups of 16 bits of zeros.
The "::" can only appear once in an address.
It should say:
In order to make writing addresses containing zero
bits easier, a special syntax is available to compress the zeros.
The use of "::" indicates two or more groups of 16 bits of zeros.
The "::" can only appear once in an address.
Notes:
--VERIFIER NOTES--
Bob Hinden evaluated this errata:
I believe that this errata should be rejected. This was discussed on the v6ops mailing list around February 25, 2011. I responded:
http://www.ietf.org/mail-archive/web/v6ops/current/msg07741.html
The thread starts at:
http://www.ietf.org/mail-archive/web/v6ops/current/msg07722.html
Also, two errata were filed based on this one (Errata ID: 2735, Errata ID: 2702) that I think should also be rejected as they assume that this errata was correct.
Errata ID: 863
Status: Rejected
Type: Editorial
Reported By: Yelland Mr Michael
Date Reported: 2007-03-02
Rejected by: RFC Editor
Date Rejected: 2008-12-03
Section 2.7 says:
Nodes must not originate a packet to a multicast address whose scop field contains the reserved value 0; if such a packet is received, it must be silently dropped. Nodes should not originate a packet to a multicast address whose scop field contains the reserved value F; ...
It should say:
Nodes must not originate a packet to a multicast address whose scope field contains the reserved value 0; if such a packet is received, it must be silently dropped. Nodes should not originate a packet to a multicast address whose scope field contains the reserved value F; ...
Notes:
Typo: scop --> scope (2 times)
-- RATIONALE FOR REJECTION --
This isn't a typo. The field is named "scop". See Section 2.7:
scop is a 4-bit multicast scope value used to limit the scope of
the multicast group.
Thanks to Bob Hinden for pointing this out.
This report was incorrectly marked "Verified" from 2007-11-01 to 2008-12-03.
Errata ID: 864
Status: Rejected
Type: Editorial
Reported By: Yelland Mr Michael
Date Reported: 2007-03-02
Rejected by: RFC Editor
Date Rejected: 2008-12-03
Section 2.7 says:
Routers must not forward any multicast packets beyond of the scope indicated by the scop field in the destination multicast address.
It should say:
Routers must not forward any multicast packets beyond the scope indicated by the scope field in the destination multicast address.
Notes:
Typo: scop --> scope; extraneous "of"
-- RATIONALE FOR REJECTION --
This isn't a typo. The field is named "scop". See Section 2.7:
scop is a 4-bit multicast scope value used to limit the scope of
the multicast group.
Thanks to Bob Hinden for pointing this out.
This report was incorrectly marked "Verified" from 2007-11-01 to 2008-12-03.
[There is an extraneous "of", which has been listed in a separate report: Errata ID 1627.]
Errata ID: 865
Status: Rejected
Type: Editorial
Reported By: Yelland Mr Michael
Date Reported: 2007-03-02
Rejected by: RFC Editor
Date Rejected: 2007-12-03
Section 2.7 says:
Nodes must not originate a packet to a multicast address whose scop field contains the reserved value 0; if such a packet is received, it must be silently dropped. Nodes should not originate a packet to a multicast address whose scop field contains the reserved value F; ...
It should say:
Nodes must not originate a packet to a multicast address whose scope field contains the reserved value 0; if such a packet is received, it must be silently dropped. Nodes should not originate a packet to a multicast address whose scope field contains the reserved value F; ...
Notes:
Typo: scop --> scope (2 times)
-- RATIONALE FOR REJECTION --
This isn't a typo. The field is named "scop". See Section 2.7:
scop is a 4-bit multicast scope value used to limit the scope of
the multicast group.
Thanks to Bob Hinden for pointing this out.
This report was incorrectly marked "Verified" from 2007-11-01 to 2008-12-03.