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 PROTECTED]
--------------------------------------------------------------------
