Subject: RFC 4584 errata and flaws

From: Alfred Hönes <[email-masked]>
Date: Sat, 12 Aug 2006 16:58:32 +0200 (MESZ)

Hello,
reading the recently published RFC 4584 (Socket API for MIPv6)
authored by you, I found a lot of textual issues that might
need consideration.

In this message, I will report only issues deemed significant
enough (substantially improving clarity) to be incorporated
into an RFC Errata Note.

Further issues (mostly regarding grammar and text formatting)
will be discussed with the authors separately.

(1)  separation of machine readable text and RFC text,
     and missing articles

Section 4.6 of RFC 4584, on page 14, 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:

(2)  unusual capitalization, et al.

All instances of "IPV6" and "ICMPV6" in the RFC text should be
changed to "IPv6" and "ICMPv6", respectively.

E.g., the last paragraph of Section 5, on page 17,

   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.

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.

and the first paragraph of Section 5.1, on page 17,

|  The IPv6 Protocol [3] defines a Routing header extension header for
   Type 0.  Thus, in order to access the IPv6 Routing header Type 2
   extension header, one MUST use type = 2 and segment = 1.  The
|  following existing functions defined in the Advanced Sockets API for
   IPv6 [1] are supported for Mobile IPv6 applications for sending and
   receiving Routing Header Type 2 headers:

Other places affected are:
  Section 5.3, 1st paragraph (page 19);
  Section 6.1, first paragraph (page 21) -- see below.

(3)  grammar

In section 5.3, the last paragraph on page 19 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.

(4)  misleading wording, etc.

The first paragraph of Section 6.1, on p. 21/22, 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
 <<page break>>
   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.

(The marked line is misleading.)
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
 <<page break>>
   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.

Best regards
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+