Re: API draft: section 8.3 and 8.5

From: Peter Lei (peterlei) <peterlei@cisco.com>
Date: Tue Feb 08 2005 - 11:44:43 EST
('binary' encoding is not supported, stored as-is) ('binary' encoding is not supported, stored as-is) David Lehmann wrote:
> Hello,
>
> Sections 8.3 and 8.5 are not clear on exactly what structures are being
> returned. It states:
> On return, addrs will point to a dynamically allocated array of
> sockaddr structures of the appropriate type for the socket type. The
> caller should use sctp_freeladdrs() to free the memory. Note that
> the in/out parameter addrs must not be NULL.
>
> If sd is an IPv4 socket, the addresses returned will be all IPv4
> addresses. If sd is an IPv6 socket, the addresses returned can be a
> mix of IPv4 or IPv6 addresses.
>
> IMHO, something similar to the following would be more explicit:
> On return, addrs will point to a dynamically allocated array of
> sockaddr structures of the appropriate type for the socket type.
> If sd is an IPv4 socket, 'addrs' will point to an array of struct
> sockaddr_in
> and the addresses returned will be all IPv4 addresses. If sd is an
> IPv6 socket, 'addrs' will point to an array of struct sockaddr_in6
> and the
> addresses returned will be IPv6 addresses and/or IPv4 mapped addresses.

It is not necessarily v4-mapped addresses that are returned (if
allowed/enabled). The SCTP_I_WANT_MAPPED_V4_ADDRESSES option
determines what kind of v4 addresses are returned: v4 addresses
(if "off"), or v4-mapped addresses (if "on"). See section 7.1.16.

Our BSD implementation (in KAME) supports this option.

regards,
--peter
> The caller should use sctp_freeladdrs() to free the memory. Note that
> the in/out parameter 'addrs' must not be NULL.
>
>
Received on Tue Feb 8 11:46:30 2005

This archive was generated by hypermail 2.1.8 : Mon Mar 13 2006 - 15:22:23 EST