Subject: sizeof(sockaddr_in6) % 8 != 0 (more on 2553)

From: [email-masked]
Date: Sun, 20 Feb 2000 15:34:03 +0900

Some of BSD folks came to notice that sizeof(sockaddr_in6) is
	not multiple of 8.  This is usually sized 28 bytes.

(without sa_len)
>struct sockaddr_in6 {
>    sa_family_t     sin6_family;    /* AF_INET6 */
>    in_port_t       sin6_port;      /* transport layer port # */
>    uint32_t        sin6_flowinfo;  /* IPv6 traffic class & flow info */
>    struct in6_addr sin6_addr;      /* IPv6 address */
>    uint32_t        sin6_scope_id;  /* set of interfaces for a scope */
>};
(with sa_len)
>struct sockaddr_in6 {
>    uint8_t         sin6_len;       /* length of this struct */
>    sa_family_t     sin6_family;    /* AF_INET6 */
>    in_port_t       sin6_port;      /* transport layer port # */
>    uint32_t        sin6_flowinfo;  /* IPv6 flow information */
>    struct in6_addr sin6_addr;      /* IPv6 address */
>    uint32_t        sin6_scope_id;  /* set of interfaces for a scope */
>};

	If we use packed structs, this will generate unaligned data on 64bit
	architectures.  One example is SIOCGIFCONF (kernel returns all the
	addresses configured to the interfaces).  On 64bit architectures
	(like alpha), we can no longer use pointers to parse the result from
	SIOCGIFCONF, we need to memcpy() beforehand.
	I admit packed structs are not a good API choice, but SIOCGIFCONF
	has been there.  We can't just nuke it, and it looks more sane to
	return IPv6 address with it.  It is also true that, for packed structs,
	we cannot really be sure about alignment constraints.

	2553 cares about alignment of sin6_addr member, but not the
	packed structs.
>   The ordering of elements in this structure is specifically designed
>   so that when sin6_addr field is aligned on a 64-bit boundary, the
>   start of the structure will also be aligned on a 64-bit boundary.
>   This is done for optimum performance on 64-bit architectures.

	Possible breakage sceneario would be:
	- we have a binary compiled before IPv6.  it parses returned structure
	  from SIOCGIFCONF by using pointers.
	- replace the kernel with IPv6-ready kernel.
	- see the binary dies with alignment violation.

	There are multiple ways to escape from this problem:
	1. change ioctl # for SIOCGIFCONF, old one kept as OSIOCGIFCONF (which
	   ignores IPv6 addresses)
	2. add extra member to sockaddr_in6 to align it
	3. broken appliation should die, leave it as is

	My questions are:
	- did it discussed in the past?
	- is there any standards/whatever for SIOCGIFCONF?  Is there any
	  material talked about it?  (or no vendor UNIXes are using
	  SIOCGIFCONF?)
	- is it legal for *a platform* to add extra member for padding,
	  like:
>struct sockaddr_in6 {
>    uint8_t         sin6_len;       /* length of this struct */
>    sa_family_t     sin6_family;    /* AF_INET6 */
>    in_port_t       sin6_port;      /* transport layer port # */
>    uint32_t        sin6_flowinfo;  /* IPv6 flow information */
>    struct in6_addr sin6_addr;      /* IPv6 address */
>    uint32_t        sin6_scope_id;  /* set of interfaces for a scope */
>    uint32_t	     sin6_zero;	     /* padding */	<---
>};
	- is it worth including the above into 2553bis?
	- if not, could we add some warning into it?  like:

>Note that struct sockaddr_in6 is normally sized 28 bytes, from the definition
>presented in the above.  This may raise alingment issues if we use it in
>packed structs, on top of architecture with requires 8 byte alignment.

itojun
--------------------------------------------------------------------
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]
Date: Mon, 21 Feb 2000 09:32:39 +0900

>	- is it worth including the above into 2553bis?

	Just to be clear: I'm actually not in favor of the above change,
	actually I wouldn't do it(changing definition in this LATE stage is
	very harmful).  I just would like to know how people solved this for
	other 64bit-ready operating systems with SIOCGIFCONF, and tried to
	list possible solutions.

itojun