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 <[EMAIL PROTECTED]>
Subject: (IPng 4241) msg_controllen and "padding at end" issue:
draft-stevens-advanced-api-04.txt
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
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.
[EMAIL PROTECTED] | Violence punctuated by committee meetings.
415-786-5156 | -- George Will
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
