Blaise Sanouillet wrote:
Hi Rao,
Hi Blaise good to hear from you.
The options described here apply to both 3SOCKET and 3XNET
interfaces. Only 3XNET interfaces, though, have the ancillary data
feature.
I'm sure it's implied, but could you confirm that this will be fully
supported for TLI/TPI endpoints? This would provide an elegant fix for
4300326 and similar bugs in RPC apps.
Yes they are supported.
The following IPPROTO_IP option may be set or retrieved as sticky
options with setsockopt/getsockopt or as ancillary data to a
sendmsg(3XNET) system call:
IP_PKTINFO Set the source address and/or interface out
which the packet(s) will be sent.
Takes a
struct in4_pktinfo as the parameter.
No strong feeling about the option name, but I would say this: it would be
great to see such an API become a standard in the future. So you should try
and make it "standard-ready" from the start - if, for example, the name
conflict between Solaris and Linux is going to give headaches to the
standard bodies, use a different name.
IPV4_PKTINFO/IPV4_RCVPKTINFO should work ?
Other things not implemented (but that might have been expected):
We will not be extending the existing IPV6_PKTINFO feature to
cover IPv4 packets using IPv4-mapped addresses. There are many
things that just don't work with IPv4-mapped addresses (such as
multicast), that render this old transition mechanism unsuitable
for anything but the most trivial of stand-alone services. Thus,
we will instead update the documentation to let customers know
that they should open multiple sockets (using the IPV6_V6ONLY
option) instead, and use inetd's built-in multiple-socket support
when possible, and should not rely on robust v4mapped extensions.
I'll confess that I really like IPv4-mapped addresses, precisely because
they solve the UDP source address issue transparently, without having to
mess about with ancillary data. (The __sin6_src_id field in sockaddr_in6
that makes this work is only present on Solaris, however.) So you wouldn't
have to use IPV6_PKTINFO to specify the source address with IPv4-mapped
addresses anyway. Save the ::ffff :-)
Okay, time to crawl back to my (microsoft-powered) cage.
Oh my :-).
Rao.
Blaise
_______________________________________________
networking-discuss mailing list
[email protected]
_______________________________________________
networking-discuss mailing list
[email protected]
