From sacadmin Wed Aug 2 13:37:21 2006 Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k72KbKtI015292 for ; Wed, 2 Aug 2006 13:37:20 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.13.7+Sun/8.13.7) with ESMTP id k72KcoQI008184; Wed, 2 Aug 2006 16:38:50 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.13.7+Sun/8.13.7/Submit) id k72Kco2H008181; Wed, 2 Aug 2006 16:38:50 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17617.3417.776571.76791@gargle.gargle.HOWL> Date: Wed, 2 Aug 2006 16:38:49 -0400 From: James Carlson To: psarc@sac.sfbay.sun.com cc: rao.shoaib@sun.com Subject: 2006/466 IP_PKTINFO Socket Option X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 5720 I'm sponsoring this fast-track request for Rao Shoaib. The timer is set for 07/09/2006. The stability level is "Committed" and the release binding is "patch/micro." We're tip-toeing around Linux compatibility and some ugly Linux kernel hackery, so please read carefully. Currently Solaris does not provide a mechanism to set the IP source address for UDP packets on AF_INET (IPv4) sockets. This is a hazard for implementors of UDP based services on Solaris, as it's substantially difficult to get RFC 1123 compliant behavior correct, and many applications (including those shipped with Solaris) fail to do so. See CR 4773220 for details. This project implements such a feature in Solaris The following IPPROTO_IP boolean option may be set or cleared with setsockopt() or retrieved with getsockopt(): IP_RECVPKTINFO Enable/disable receipt of the index of the interface the packet arrived on, the local address that was matched for reception, and the inbound packet's actual destination address. Takes boolean as the parameter. Returns struct in_pktinfo as ancillary data. The following IPPROTO_IP option is only supported as an ancillary data option for sendmsg(3XNET) system call: IP_PKTINFO Set the source address and/or transmit interface of the packet(s). Takes a struct in_pktinfo as the parameter. The symbols and structure are defined as (note the duplicated constant; explained below): /* * New IP source address options */ #define IP_PKTINFO 0x1a /* source address info*/ #define IP_RCVPKTINFO 0x1a /* receive pkt info */ struct in_pktinfo { unsigned int ipi_ifindex; /* send/recv interface index */ struct in_addr ipi_spec_dst; /* src address matched */ struct in_addr ipi_addr; /* src/dst header IP address */ }; When passed in (on transmit) via ancillary data with IP_PKTINFO, ipi_spec_dst is used as the source address and ipi_ifindex is used as the interface index to send the packet out. Differences between Solaris and Linux: This implementation is not completely compatible with the Linux implementation of IP_PKTINFO. However it is compatible with the IPV6_PKTINFO options as described in RFC 3542 for UDP and Raw Sockets. The semantics and behavior of IP_PKTINFO in Linux are not well documented and our efforts to reverse engineer it produced varying results. However we believe in normal cases this implementation will work exactly like the Linux implementation. In particular, Linux uses the setsockopt/getsockopt IP_PKTINFO symbol with two different argument lengths: either 1-4 bytes for boolean, or sizeof (struct in_pktinfo) for the sticky option. We use only the boolean variant, and we duplicate the constant value so that setting IP_PKTINFO trivially has the same effect as setting IP_RECVPKTINFO. - No known Linux application uses the sticky variant of IP_PKTINFO; all that we have been able to locate use IP_PKTINFO as a boolean socket option to enable the ancillary data. For that reason, we expect that nearly all existing Linux applications will port over to Solaris without modification. - The IP_RECVPKTINFO symbol is provided to keep parity with the existing Solaris naming practices. Any Linux application that might use the sticky form in the future will fail this call with EINVAL. If a sticky variant is required in the future, we will revisit using the length hack that Linux uses or create a new symbol. 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. As stated above sticky option is not supported. Behavior Details: IP_XMIT_IF and IP_DONTFAILOVER_IF options take precedence over IF index passed in IP_PKTINFO. The source address specified on output, if not INADDR_ANY, must be a local host address. No check is made if another process is bound to that . This socket option does not render the socket actually bound for reception of inbound packets. Note that this is consistent with the way the existing IPv6 option works. EADDRNOTAVAIL is returned if a non-INADDR_ANY address that is not local address is passed in. EINVAL is returned if the index passed in is non-zero and does not correspond to a valid interface. When a non-zero interface index is given along with an all-zero (INADDR_ANY) source address, the packet source address is set to the bound address on the socket or, if that is unset, to one of the addresses hosted on the given physical interface, using the existing source address selection logic to choose among them. When a zero interface index is given along with a non-zero source address, the packet source address is as given in the ancillary data. The output interface will be chosen in the usual manner based on the destination address. Currently Solaris has a consolidation private structure called in_pktinfo that ip uses internally to pass interface information to upper layers. This structure will be renamed to ip_pktinfo. From sacadmin Wed Aug 2 14:01:22 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.228.31]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k72L1MDR016138 for ; Wed, 2 Aug 2006 14:01:22 -0700 (PDT) Received: from [129.146.11.231] (sr1-umpk-25.SFBay.Sun.COM [129.146.11.231]) by jurassic.eng.sun.com (8.13.7+Sun/8.13.6) with ESMTP id k72L1Mpk596255; Wed, 2 Aug 2006 14:01:22 -0700 (PDT) Message-ID: <44D112A2.9080208@Sun.COM> Date: Wed, 02 Aug 2006 14:01:22 -0700 From: Kais Belgaied User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20050530 X-Accept-Language: ar-eg, en-us, en, ar, ar-dz, ar-bh, ar-iq, ar-jo, ar-kw, ar-lb, ar-ly, ar-ma, ar-om, ar-qa, ar-sa, ar-sy, ar-tn, ar-ae, ar-ye MIME-Version: 1.0 To: James Carlson CC: psarc@sac.sfbay.sun.com, rao.shoaib@Sun.COM Subject: Re: 2006/466 IP_PKTINFO Socket Option References: <17617.3417.776571.76791@gargle.gargle.HOWL> In-Reply-To: <17617.3417.776571.76791@gargle.gargle.HOWL> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 276 what's the behavior when a src address is specified witth IP_PKTINFO, then the interface corresponding to that addr is brought down? will subsequent send()/sendto()/write() calls fail? result in packets sent with a different src addr (the bound addr when set?) ? Kais From sacadmin Wed Aug 2 14:05:29 2006 Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k72L5ScI016333 for ; Wed, 2 Aug 2006 14:05:29 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.13.7+Sun/8.13.7) with ESMTP id k72L6xWh008341; Wed, 2 Aug 2006 17:06:59 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.13.7+Sun/8.13.7/Submit) id k72L6xwO008338; Wed, 2 Aug 2006 17:06:59 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17617.5106.731745.572385@gargle.gargle.HOWL> Date: Wed, 2 Aug 2006 17:06:58 -0400 From: James Carlson To: Kais Belgaied Cc: psarc@sac.sfbay.sun.com, rao.shoaib@sun.com Subject: Re: 2006/466 IP_PKTINFO Socket Option In-Reply-To: Kais Belgaied's message of 2 August 2006 14:01:22 References: <17617.3417.776571.76791@gargle.gargle.HOWL> <44D112A2.9080208@Sun.COM> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 612 Kais Belgaied writes: > what's the behavior when a src address is specified witth IP_PKTINFO, > then the interface corresponding to that addr > is brought down? will subsequent send()/sendto()/write() calls fail? > result in packets sent with a > different src addr (the bound addr when set?) ? You can bind to a down interface, so I'd expect it to succeed and use that address. Rao? -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Wed Aug 2 15:32:42 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.68.130]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k72MWg2N025455 for ; Wed, 2 Aug 2006 15:32:42 -0700 (PDT) Received: from [129.146.106.54] (caduceus.SFBay.Sun.COM [129.146.106.54]) by jurassic.eng.sun.com (8.13.7+Sun/8.13.6) with ESMTP id k72MWfMH635062; Wed, 2 Aug 2006 15:32:41 -0700 (PDT) Message-ID: <44D127A0.9000809@sun.com> Date: Wed, 02 Aug 2006 15:30:56 -0700 From: Rao Shoaib User-Agent: Thunderbird 1.5 (X11/20060113) MIME-Version: 1.0 To: James Carlson CC: Kais Belgaied , psarc@sac.sfbay.sun.com Subject: Re: 2006/466 IP_PKTINFO Socket Option References: <17617.3417.776571.76791@gargle.gargle.HOWL> <44D112A2.9080208@Sun.COM> <17617.5106.731745.572385@gargle.gargle.HOWL> In-Reply-To: <17617.5106.731745.572385@gargle.gargle.HOWL> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 824 James Carlson wrote: > Kais Belgaied writes: > >> what's the behavior when a src address is specified witth IP_PKTINFO, >> then the interface corresponding to that addr >> is brought down? will subsequent send()/sendto()/write() calls fail? >> result in packets sent with a >> different src addr (the bound addr when set?) ? >> > > You can bind to a down interface, so I'd expect it to succeed and use > that address. > Currently the implementation does what is done for V6 i.e it only checks if a route exists. So the send will fail since bringing down an interface will delete the ire's. In your question you are probably implying the use of sticky option. Please note sticky option is not supported. Each send has to supply a IP_PKTINFO option and the check is made for each send. Rao. > Rao? > > From sacadmin Wed Aug 9 10:29:34 2006 Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k79HTX9m005739 for ; Wed, 9 Aug 2006 10:29:33 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.13.7+Sun/8.13.7) with ESMTP id k79HVAHn023370; Wed, 9 Aug 2006 13:31:10 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.13.7+Sun/8.13.7/Submit) id k79HV96r023367; Wed, 9 Aug 2006 13:31:10 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17626.7133.794873.433369@gargle.gargle.HOWL> Date: Wed, 9 Aug 2006 13:31:09 -0400 From: James Carlson To: psarc@sac.sfbay.sun.com cc: rao.shoaib@sun.com Subject: Re: 2006/466 IP_PKTINFO Socket Option In-Reply-To: James Carlson's message of 2 August 2006 16:38:49 References: <17617.3417.776571.76791@gargle.gargle.HOWL> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 429 This fast-track request was approved during ARC business at today's PSARC meeting. I've put a final version of the specification (with the nit that Kais raised correct) as spec.txt in the case directory. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Thu Aug 31 21:55:07 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.68.36]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k814t7pe015259 for ; Thu, 31 Aug 2006 21:55:07 -0700 (PDT) Received: from [192.168.1.100] (vpn-129-150-25-59.SFBay.Sun.COM [129.150.25.59]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id k814t3Xw968546 for ; Thu, 31 Aug 2006 21:55:05 -0700 (PDT) Message-ID: <44F7BBEB.80907@sun.com> Date: Thu, 31 Aug 2006 21:49:47 -0700 From: Rao Shoaib User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20041207 X-Accept-Language: en-us, en MIME-Version: 1.0 To: psarc@sac.sfbay.sun.com Subject: 2006/466 IP_PKTINFO Socket Option Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 134 I would like to add a clarification to the case. The behavior of IP_PKTINFO is undefined when the address is a broadcast address. From sacadmin Thu Aug 31 23:18:17 2006 Received: from sineb-mail-1.sun.com ([192.18.19.6]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k816IGZN016540 for ; Thu, 31 Aug 2006 23:18:16 -0700 (PDT) Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k816I9PM021154 for ; Fri, 1 Sep 2006 14:18:10 +0800 (SGT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J4W00001H7DXE00@mail-apac.sun.com> (original mail from Darren.Reed@Sun.COM) for psarc@sac.sfbay.sun.com; Fri, 01 Sep 2006 14:18:09 +0800 (SGT) Received: from [129.158.219.204] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J4W00HUPHI7RMZA@mail-apac.sun.com>; Fri, 01 Sep 2006 14:18:08 +0800 (SGT) Date: Fri, 01 Sep 2006 14:18:07 +0800 From: Darren Reed Subject: Re: 2006/466 IP_PKTINFO Socket Option In-reply-to: <44F7BBEB.80907@sun.com> Sender: Darren.Reed@Sun.COM To: Rao Shoaib Cc: psarc@sac.sfbay.sun.com Message-id: <44F7D09F.1030109@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <44F7BBEB.80907@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20060120 Status: RO Content-Length: 540 Rao Shoaib wrote: > I would like to add a clarification to the case. > > The behavior of IP_PKTINFO is undefined when the address is a > broadcast address. Can IP_PKTINFO be used with multicast addresses or is the behaviour here also undefined? Wouldn't it be better to restrict the validity of the IP address supplied in the ancillary data to be one of the addresses currently assigned to a network interface? Or is there a need for IP_PKTINFO to be able to used to supply a fraudulent source address for UDP packets? Darren From sacadmin Thu Aug 31 23:47:52 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.17.57]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k816lp0d016879 for ; Thu, 31 Aug 2006 23:47:51 -0700 (PDT) Received: from [192.168.1.100] (vpn-129-150-25-59.SFBay.Sun.COM [129.150.25.59]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id k816lnNq988397; Thu, 31 Aug 2006 23:47:51 -0700 (PDT) Message-ID: <44F7D659.7070603@sun.com> Date: Thu, 31 Aug 2006 23:42:33 -0700 From: Rao Shoaib User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20041207 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Darren Reed CC: psarc@sac.sfbay.sun.com Subject: Re: 2006/466 IP_PKTINFO Socket Option References: <44F7BBEB.80907@sun.com> <44F7D09F.1030109@sun.com> In-Reply-To: <44F7D09F.1030109@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 998 Darren Reed wrote: > Rao Shoaib wrote: > >> I would like to add a clarification to the case. >> >> The behavior of IP_PKTINFO is undefined when the address is a >> broadcast address. > > > > Can IP_PKTINFO be used with multicast addresses or is the behaviour > here also undefined? It can be used with multicast addresses. > > Wouldn't it be better to restrict the validity of the IP address > supplied in the ancillary data to be one of the addresses currently > assigned to a network interface? > > Or is there a need for IP_PKTINFO to be able to used to supply a > fraudulent source address for UDP packets? The source address that can be used is already limited to any address that the process can bind to. The issue is with the destination address being a broadcast address. In which case we can not gaurantee that the packet will only go out on the interface specified. We also can not gaurantee that the packet will go out on all the interfaces it should. Rao. > > Darren From sacadmin Wed Dec 20 12:00:42 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.56.144]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id kBKK0gPs010589 for ; Wed, 20 Dec 2006 12:00:42 -0800 (PST) Received: from [129.146.106.54] (caduceus.SFBay.Sun.COM [129.146.106.54]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id kBKK0gxF995410; Wed, 20 Dec 2006 12:00:42 -0800 (PST) Message-ID: <45899666.50003@sun.com> Date: Wed, 20 Dec 2006 12:00:38 -0800 From: Rao Shoaib User-Agent: Thunderbird 1.5.0.8 (X11/20061113) MIME-Version: 1.0 To: psarc@sac.sfbay.sun.com CC: David.Comay@sun.com Subject: PSARC/2006/466 IP_PKTINFO Socket Option Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 208 The specification lists error codes that should be returned in case of errors. However Solaris implementation of sendmsg() does not allow protcols to return an error. So want to explicitly point this out.