Subject: Re: more 2292-bis comments

From: Mukesh Kacker <[email-masked]>
Date: Wed, 11 Aug 1999 22:19:41 -0700 (PDT)

I will comment on one of the comments from Sam Manthrope which is
related to some changes in RFC2292bis that I contributed to.

Sam wrote (among other things).
> 
>     7.	There seems to be some confusion as to whether the cmsg_len
> 	field of struct cmsghdr includes the header length or
> 	not.  The definition says it does, as does the ascii
> 	diagram, but some of the macro examples, CMSG_NXTHDR for
> 	example, imply that it does not.  I assume it is the
> 	macro examples that are wrong.
> 

I do not think CMSG_NXTHDR macro example is broken. In this draft
the ALIGN_H and ALIGN_D macros to take care of the separate alignment
boundaries are defined and used which could be contributing some
confusion. The text says that on many implementations, the two could
be identical.
Also, the concept that cmsg_len includes the header as well as value
is architecture derived from classic BSD Socket implementations (Reno)
and I don't think any enhancements could try to "fix" or change that.

Some more details follow that will explain the motivation for some
of this change for CMSG_* stuff.
It is hard to see this stuff now but if people move to 64
(or 128, 256 bit :-)) architectures in future these things begin to
matter. :-).
Note that the ASCII art for packing of ancillary data into buffers
shows padding both after the header and data content. [ Solaris implementation
uses different alignment valeis for the two boundaries ].
That had a conflict with the prototypes of the CMSG_LEN and CMSG_SPACE
macros. I pointed  out that brokenness two years ago in message "IPng 4240"
sent on 3 August 1997 in what was then draft-stevens-advanced-api-04.txt but
that was not taken care of and that turned into RFC2292.
The problem was that with certain alignment choices and the implied
definitions of CMSG_LEN and CMSG_SPACE required the "cmsg" pointer but
only the "length" part was passed in.

- CMSG_SPACE() is fixed by redefining it to be the upper bound on space
  (instead of exact boundary) needed to store an option which knowing the
  alignment choices can be computed and is in fact what is needed based on
  for what the CMSG_SPACE() is used for. In most implmentations it may in
  fact be the exact space but that is a property of the alignment boundaries
  chosen. (Passing "cmsg" to it would have been the wrong fix since it is
  called before filling and walking the control buffer is done.)

- CMSG_LEN() still has only length. That implies a (not written in document)
  restriction that "hdr_alignment_boundary >= data_alignment_boundary".
  That happens to be true of all current implementations I am aware of.
  That is a broken restriction however, but here I have bowed to the
  compatibility monster. Another solution could be similar to what
  I had proposed two years ago.

      - define a new macro with a different name, for example,
        CMSG_FOO(cmsg, length)) which has both "cmsg" and "length"
        arguments which fixes the architectural problems.
      - deprecate/obsolete CMSG_LEN().

   That would not affect any existing implementation as with their alignment
   choices, they can ignore the "cmsg" argument.
   I chose not to propose that as that would be larger change....and I
   was not sure how much change people would be comfortable with in this
   update of RFC2292.
   If people think fixing that aspect of Socket interface architecture is
   important, consider this a proposal to add the CMSG_FOO macro with
   prototype as above. (I would not get into choosing names now :-)).

-Mukesh Kacker
 Internet Engineering
 [email-masked]
 Sun Microsystems Inc.
 +1-650-786-5156
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: [email-masked] (Sam Manthorpe)
Date: Wed, 11 Aug 1999 22:32:47 -0700 (PDT)

I have discussed this point off-line with Mukesh and withdraw the
comment he references below.  The macro isn't broken and the comment
was down to my own misunderstanding of the ALIGN_[HD] macros/functions.

Cheers,
- Sam

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Sam Manthorpe, SGI.  tel: (650)933-2856 fax: (650)932-2856  [email-masked]
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------