Hi Rao, > 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. > 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. > 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. Blaise _______________________________________________ networking-discuss mailing list [email protected]
