question about trailing padding of ancillary data chain (RFC3542)

[JINMEI Tatuya / 神明達哉 <[e-mail]>]

I have a quick question about the following part of RFC3542.  It's
in Section 20.2 discussing cmsghdr:

  [...]  While sending an
  application may or may not include padding at the end of last
  ancillary data in msg_controllen and implementations must accept both
  as valid.

This first appeared in draft-ietf-ipngwg-2292bis-00.txt, but I
couldn't find why this was added (I was asked why by someone else and
I couldn't answer).  Does anyone know the background of this addition?
I found a e-mail message to the ipng wg that might trigger this
change, but I couldn't find any subsequent discussion.

Thanks,

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.

Date: Sun, 3 Aug 1997 15:20:03 -0700 (PDT)
From: Mukesh Kacker <[e-mail]>
Subject: (IPng 4241) msg_controllen and "padding at end" issue: draft-stevens-advanced-api-04.txt
To: [e-mail]
Cc: [e-mail]

This IPng 4188 message from Koji Imada referred to some minor inconsistencies
with respect to whether msg_controllen includes the padding in the
last "ancillary data object" which were present in some initial copies of
draft-stevens-advanced-api-04.txt.

This appears to have been fixed in the "current" copy of
draft-stevens-advanced-api-04.txt at the FTP site in manner that support the
interpretation that msg_controllen DOES include the padding at the end of
the last ancillary data in the msg_control buffer.

However there are still some portability issues that may affect applications
which should be explicitly clarified which center around the interpretation
of msg_controllen and whether or not it includes

 (1) When receiving a control message buffer from kernel to userspace
    in recvmsg().

 - Is MSG_CTRUNC set in msg_flags when msg_controllen is large enough to
 include the "content" of the last ancillary data but not the padding ?


 (2) When sending a control message buffer from user space to the kernel
    in sendmsg()

   - Is msg_controllen required to include the padding at the end of
      last ancillary data object in this case ? If so, will the sendmsg()
      call fail (and so with what errno ?) if that padding is not included
      in msg_controllen ? [ setting MSG_CTRUNC as in recvmsg() is not an
      option since msg_flags is not a "return" parameter in this case ].
      Or are the implementations required to be "liberal" in what they
      acceptthis case and not fail ? (I suspect this latter case may
      predominate in implementations and therefore the spec should specify
      this).


I don't think the formal standards do not affect guidance on these issues.
Since the use msg_control/msg_controllen is likely to increase when IPv6 APIs
are used, I would like this draft should further clarify the specification
keeping existing implemenation practices into account in the cases raised
in (1) and (2) above.


----------------------------------------------------------------------
Mukesh Kacker                   | Football incorporates the two worst
Sun Microsystems Inc (SunSoft)  | characteristics of American society.
[e-mail]       | Violence punctuated by committee meetings.
415-786-5156                    |                      -- George Will
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------