Subject: (IPng 6581) Re: Basic API; "struct in6_addr" section needs to mention alignment issues

From: [email-masked] (Tim Hartrick)
Date: Mon, 5 Oct 1998 17:42:01 -0700

Mukesh, Jim,

> 
> In Section 3.2, the "struct in6_addr" implementation illustrated is
> one with no alignment fields
> 
>    struct in6_addr {
>        uint8_t  s6_addr[16];      /* IPv6 address */
>    }
> 
> We should add some text to hint how a real implementation may be different.
>

Indeed.  In fact it may be useful to have an example of a more alignment
friendly implementation in the document if the form of the example does
not lead to a bunch of arguing about names and whatnot.

Something like:

struct in6_addr {
	union {
		uint8_t _S6_b[16];
		uint32_t _S6_w[4];
		uint64_t _S6_l[2];
	} _S6_un;
};
#define	s6_addr	_S6_un._S6_b

Tim Hartrick

--------------------------------------------------------------------
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: Craig Metz <[email-masked]>
Date: Mon, 05 Oct 1998 23:24:28 -0300

>#define	s6_addr	_S6_un._S6_b

  I believe that this was once the way the structure looked (certainly, many
implementations used to do it that way until the wording of the spec made it
verboten). I'm not sure why it came to look the way it does now, though it
might have had something to do with some people's issues with unions.

									-Craig

---

From: [email-masked]
Date: Tue, 06 Oct 1998 00:22:51 -0400

>#define	s6_addr	_S6_un._S6_b

I can add as "EXAMPLE" the folks at the time doing Cray words did not
want it to be specified in this manner with the union.  But as an
example that is fine, but we need to leave in6_addr as defined now.

thanks
/jim

Tim Hartrick

---

From: [email-masked]
Date: Tue, 06 Oct 1998 00:25:04 -0400

>might have had something to do with some people's issues with unions.

That was it.  I will put it in as example though.

thanks
/jim

---

From: [email-masked] (Alexey Kuznetsov)
Date: Tue, 6 Oct 1998 17:30:47 +0400 (MSK DST)

Hello!

> example that is fine, but we need to leave in6_addr as defined now.

It is not so minor issue: API should explicitly say about required
in6_addr alignment constraints as a "MUST"("NOT") statement.

F.e. RSVP (and PIM even worse) was badly designed and carries misaligned
IPv6 addresses in messages. Particularly, it means that using
in6_addr in protocol definition templates (as ISI rsvpd does) is
illegal.

Explicit statement in API is necessary just to avoid anarchy.
F.e. if rsvpd developers will stuck on using in6_addr, believing
that it is not aligned, it is not easy to port it to OS, where
in6_addr is forced to be aligned.

Alexey Kuznetsov

---

From: Jim Bound IPv6 Technical Leader UNIX Engineering Internet Group <[email-masked]>
Date: Tue, 06 Oct 1998 10:30:51 -0400

Alexey,

>in6_addr alignment constraints as a "MUST"("NOT") statement.

It was proposed as an example and it will stay an example unless we hear
a strong consensus from the working group that this should change. It is
not the IETF's role or The Open Group to mandate alignment in an API
spec.  It is an implementation issue and all we can do is advise them. 

>in6_addr in protocol definition templates (as ISI rsvpd does) is

If that is true then that is there problem not ours for the API.

>in6_addr is forced to be aligned.

The market will provide forthright corrections to vendors who break
because of alignment issues, it is not the IETF's role to police
alignment in implementations.

We on IPng have provided direction for IPv6 to be aligned on 64bit
architectures consistenly in our specs.  We cannot mandate it.
This is crossing a line that is not valid for standards except maybe for
ANSI compiler standards and they even avoid mandating alignment.

If we have done something to prevent alignment than that is an issue.

/jim