RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

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

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

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

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

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

Report New Errata



Search RFCs
Advanced Search
×