RFC Errata
Found 4 records.
Status: Verified (4)
RFC 4584, "Extension to Sockets API for Mobile IPv6", July 2006
Source of RFC: mip6 (int)
Errata ID: 741
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-12
Verifier Name: Samita Chakrabarti
Date Verified: 2006-08-14
Section 6.1 says:
This specification recommends that the IPv6 RAW sockets mechanism send and receive Mobility Header (MH) packets. The behavior is | similar to ICMPV6 processing, where the kernel passes a copy of the mobility header packet to the receiving socket. Depending on the implementation, the kernel may process the mobility header in addition to passing the mobility header to the application. In order to comply with the restriction in the Advanced Sockets API for IPv6 [1], applications should set the IPV6_CHECKSUM socket option with IPPROTO_MH protocol RAW Sockets. A Mobile IPv6 implementation that supports the Mobile IPv6 API must implement Mobility Header API checksum calculations by default at the kernel for both incoming and outbound paths. A Mobile IPv6 implementation must not return error on the IPV6_CHECKSUM socket option setting, even if the socket option is a NO-OP function for that implementation because it verifies the checksum at the kernel level. The Mobility Header checksum procedure is described in the Mobile IPv6 Protocol [2] specification. Again, for application portability it is recommended that the applications set the IPV6_CHECKSUM socket option along with the RAW sockets for IPPROTO_MH protocol.
It should say:
This specification recommends that the IPv6 RAW sockets mechanism send and receive Mobility Header (MH) packets. The behavior is | similar to ICMPv6 processing; the kernel passes a copy of the mobility header packet to the receiving socket. Depending on the implementation, the kernel may process the mobility header in addition to passing the mobility header to the application. In order to comply with the restriction in the Advanced Sockets API for IPv6 [1], applications should set the IPV6_CHECKSUM socket option with IPPROTO_MH protocol RAW Sockets. A Mobile IPv6 implementation that supports the Mobile IPv6 API must implement Mobility Header API | checksum calculations by default in the kernel for both incoming and outbound paths. A Mobile IPv6 implementation must not return an error on the IPV6_CHECKSUM socket option setting, even if the socket option is a NO-OP function for that implementation because it verifies the checksum at the kernel level. The Mobility Header checksum procedure is described in the Mobile IPv6 Protocol [2] specification. Again, for application portability it is recommended that the applications set the IPV6_CHECKSUM socket option along with | the RAW sockets for the IPPROTO_MH protocol.
Notes:
misleading wording
from pending
Errata ID: 52
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-12
Verifier Name: Samita Chakrabarti
Date Verified: 2006-08-14
Section 4.6 says:
IPv6 Neighbor Discovery changes are also defined in <netinet/icmp6.h>. New 'Home Agent' flag in router advertisement: #define ND_RA_FLAG_HOMEAGENT 0x20 /* Home Agent flag in RA */ New Router flag with prefix information of the home agent: #define ND_OPT_PI_FLAG_ROUTER 0x20 /* Router flag in PI */ As per the Mobile IPv6 specification [2], Section 7.2, a Home Agent MUST include at least one prefix option with the Router Address (R) bit set. Advanced Socket API [1] defines data structure for prefix option as follows:
It should say:
IPv6 Neighbor Discovery changes are also defined in <netinet/icmp6.h>. New 'Home Agent' flag in router advertisement: #define ND_RA_FLAG_HOMEAGENT 0x20 /* Home Agent flag in RA */ New Router flag with prefix information of the home agent: #define ND_OPT_PI_FLAG_ROUTER 0x20 /* Router flag in PI */ As per the Mobile IPv6 specification [2], Section 7.2, a Home Agent MUST include at least one prefix option with the Router Address (R) bit set. The Advanced Socket API [1] defines a data structure for the prefix option as follows:
Notes:
separation of machine readable text and RFC text, and missing articles
from pending
Errata ID: 739
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-12
Verifier Name: Samita Chakrabarti
Date Verified: 2006-08-14
All instances of
IPV6 and ICMPV6 For example, in section 5: Legacy IPv6 applications/implementations using the Advanced Socket API [1] mechanisms, upon receiving Home Address destination options or Routing headers(Type 2), will discard the packet as per Sections 4.2 and 4.4 of IPV6 Protocol [3] specification, respectively; otherwise, they should properly handle the Home Address destination option and the Routing Header Type 2 specified in this document.
It should say:
IPv6 and ICMPv6 For example, should say (also incorporating other corrections): Legacy IPv6 applications/implementations using the Advanced Socket API [1] mechanisms, upon receiving Home Address destination options or Routing headers (Type 2), will discard the packet as per Sections 4.2 and 4.4 of the IPv6 Protocol [3] specification, respectively; otherwise, they should properly handle the Home Address destination option and the Routing Header Type 2 specified in this document.
Notes:
unusual capitalization
Other places affected are:
Section 5.1, 1st paragraph (page 17);
Section 5.3, 1st paragraph (page 19);
Section 6.1, 1st paragraph (page 21)
from pending
Errata ID: 740
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-12
Verifier Name: Samita Chakrabarti
Date Verified: 2006-08-14
Section 5.3 says:
Any user-level implementation or application that sends the Home address destination option through ancillary data objects should follow the order extension header defined in this document when using IPV6_MIPDSTOPTS socket options.
It should say:
Any user-level implementation or application that sends the Home address destination option through ancillary data objects should | follow the order of extension headers defined in this document when | using the IPV6_MIPDSTOPTS socket options.
Notes:
from pending