Subject: Re: [advanced API] how to get the destination address for IPV6_RECVPATHMTU

From: Tim Hartrick <[email-masked]>
Date: Thu, 16 Nov 2000 11:45:15 -0800 (PST)

All,

>    
>    >>> I've implemented the IPV6_RECVPATHMTU option adopting #3 approach. I
>    >>> defined a new structure "ip6_mtuinfo" as ancillary data item for
>    >>> IPV6_PATHMTU as follows:
>    >>> struct ip6_mtuinfo {
>    >>> u_int32_t ip6mtu_mtu;
>    >>> struct sockaddr_in6 ip6mtu_dst;
>    >>> };
>    >> How do you think about alignment?
>    >Currently, I only consider 32-bit alignment, but I'm open to hear
>    >others' opinions.
>    
>    	as this structure is host-local (will not appear on wire) there's no
>    	serious issue with alignment, I believe.
> 
> => I disagree, I'd like to be able to defined struct in6_addr as a pair
> of 64 bit integers one day (:-)!
>

I don't understand the point.  The two 64 bit fields will be forced onto
their natural boundaries.  This might lead to the compiler adding padding
between the ip6mtu_mtu and ip6mtu_dst but so what.  This structure doesn't
go on the wire so padding that is added by the compiler is not relevent.

With regard to the Endianness of the ip6mtu_mtu, I agree that it should be
in host order.

tim
--------------------------------------------------------------------
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: Francis Dupont <[email-masked]>
Date: Fri, 17 Nov 2000 17:14:03 +0100

I don't understand the point.  The two 64 bit fields will be forced onto
   their natural boundaries.  This might lead to the compiler adding padding
   between the ip6mtu_mtu and ip6mtu_dst but so what.

=> not so what, I prefer to have a layout which gives the same padding
with 4*32 and 2*64 bit definitions!

   This structure doesn't go on the wire so padding that is added by
   the compiler is not relevent.
   
=> with a right order 4*32 and 2*64 are binary compatible and you can
get this nice property for free.

[email-masked]

PS: I've tried one day the 2*64 definition on a Sparc (ie. with 64 bit
alignment). It didn't work because of some details, for instance the
route structure (pointer + sockaddr) or IPv6 over ATM (32 bit difference
in alignment between unicast and multicast). I can't see a good reason
to add a new source of problems...
--------------------------------------------------------------------
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: Jun-ichiro itojun Hagino <[email-masked]>
Date: Sat, 18 Nov 2000 01:18:01 +0900

>to add a new source of problems...

	for the latter case, you need __attribute__((__packed__)) (gcc-ism)
	for header declaration.  to control structure packing.

itojun

---

From: Francis Dupont <[email-masked]>
Date: Sat, 18 Nov 2000 15:57:21 +0100

=> don't joke with my stomach! Just put the fields in the best order.

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Sun, 19 Nov 2000 02:23:21 +0900

>=> don't joke with my stomach! Just put the fields in the best order.

	for packet format on the wire, you really need to control the alignment
	of structure members explicitly.  you cannot just rely upon the
	compiler padding (or your code will not be future-proven).

itojun

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 20 Nov 2000 16:19:41 -0800 (PST)

> to add a new source of problems...

We tried the same thing a while back (thinking it would be trivial).
Turned out that the embedded in6_addr structures in various places
(ancillary data which gets mapping into TPI option buffers, socket
options, etc) made the introduction of 64 bit alignment non-trivial.
So we punted for the time being.

  Erik