Subject: sockaddr_storage issue

From: [email-masked]
Date: Wed, 01 Dec 1999 21:52:26 +0900

I have a question about RFC2553, on struct sockaddr_storage.

	RFC2553 defines sockaddr_storage like this:

>struct sockaddr_storage {
>    uint8_t      __ss_len;        /* address length */
>    sa_family_t  __ss_family;     /* address family */
>    /* Following fields are implementation specific */
>    char         __ss_pad1[_SS_PAD1SIZE];
>                  /* 6 byte pad, this is to make implementation
>                  /* specific pad up to alignment field that */
>                  /* follows explicit in the data structure */
>    int64_t      __ss_align;  /* field to force desired structure */
>                  /* storage alignment */
>    char         __ss_pad2[_SS_PAD2SIZE];
>                  /* 112 byte pad to achieve desired size, */
>                  /* _SS_MAXSIZE value minus size of ss_len, */
>                  /* __ss_family, __ss_pad1, __ss_align fields is 112 */
>};

	I remember that that there was last-minute discussion about
	"ss_len" and "ss_family", rather than "__ss_len".  This did not make
	it to RFC2553, and I am still curious what was the last consensus on
	this.  Do any of you remember it exactly?

	Just for reference, OpenBSD 2.6 (NRL IPv6) defines it as "ss_len". 
	BSDI4 (NRL IPv6) defines as "__ss_len".  KAME currently using
	"__ss_len".
	Personally, "ss_len" makes more sense for me.

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: Assar Westerlund <[email-masked]>
Date: 01 Dec 1999 14:02:46 +0100

> 	I have a question about RFC2553, on struct sockaddr_storage.

I did re-read RFC2553, and...

> 	RFC2553 defines sockaddr_storage like this:

It doesn't actually.  It says `An example implementation design...'.
As far as I can tell, it doesn't seem to define the names of these
fields anywhere.  And I didn't find any consensus on this in the
mailing list archives either.

> 	Personally, "ss_len" makes more sense for me.

If it's supposed to be used, I think `ss_len' is a better name, and if
it's not, I would vote for `__ss_len'.

/assar

---

From: [email-masked]
Date: Wed, 01 Dec 1999 22:06:53 +0900

>	BSDI4 (NRL IPv6) defines as "__ss_len".  KAME currently using

	correction: it seems vanilla BSDI4 does not have sockaddr_storage.

itojun

---

From: Jim Bound <[email-masked]>
Date: Wed, 01 Dec 1999 23:25:21 -0500

hi itojun,

this does need to be fixed.  xnet uncovered an issue here too.

Chris Harding...can you comment for XNET?

thanks
/jim

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 2 Dec 1999 01:09:34 -0800 (PST)

> 	this.  Do any of you remember it exactly?

I recall X/Open wanting to change the names to ss_family etc.
I don't  know if they decided to go ahead with this or not.

   Erik

---

From: Francis Dupont <[email-masked]>
Date: Wed, 08 Dec 1999 16:39:41 +0100

In your previous mail you wrote:

=> I (for the "INRIA" stack) use ss_len, ss_family, and _ss_... for
others (they are not supposed to be used). I am (already :-) in favor
of ss_len and ss_family (ie. don't cast to sockaddr only for these
two common fields).

Regards

[email-masked]

PS: I have some #define __ss_len ss_len for KAME compatibility,
I'd like to remove them if possible.
--------------------------------------------------------------------
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]
--------------------------------------------------------------------