From sacadmin Mon Nov 5 12:07:18 2007 Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lA5K7I5t016256; Mon, 5 Nov 2007 12:07:18 -0800 (PST) Received: (from meem@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id lA5K7IAh016253; Mon, 5 Nov 2007 12:07:18 -0800 (PST) Date: Mon, 5 Nov 2007 12:07:18 -0800 (PST) From: Peter Memishian Message-Id: <200711052007.lA5K7IAh016253@sac.sfbay.sun.com> To: PSARC-record@sac.sfbay.sun.com Subject: IP_BROADCAST_TTL socket option [PSARC/2007/639 FastTrack timeout 11/09/2007] Status: RO Content-Length: 570 Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI This information is Copyright 2007 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: IP_BROADCAST_TTL socket option 1.2. Name of Document Author/Supplier: Author: Peter Memishian 1.3 Date of This Document: 05 November, 2007 4. Technical Description See the case directory for more detail 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From meem@triplex.east.sun.com Mon Nov 5 12:18:01 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lA5KI0us016455 for ; Mon, 5 Nov 2007 12:18:01 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lA5KDrBD002459 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Mon, 5 Nov 2007 20:14:22 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JR100E1XUVEJU00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 05 Nov 2007 13:14:02 -0700 (MST) Received: from triplex.East.Sun.COM ([129.148.174.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JR100G4CUVD1MF0@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 05 Nov 2007 13:14:01 -0700 (MST) Received: from triplex.East.Sun.COM (localhost [127.0.0.1]) by triplex.East.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id lA5K6WXV112504; Mon, 05 Nov 2007 15:06:32 -0500 (EST) Received: (from meem@localhost) by triplex.East.Sun.COM (8.14.1+Sun/8.14.1/Submit) id lA5K6W2W112501; Mon, 05 Nov 2007 15:06:32 -0500 (EST) Date: Mon, 05 Nov 2007 15:06:31 -0500 From: Peter Memishian Subject: PSARC/2007/639 IP_BROADCAST_TTL socket option To: psarc-ext@sun.com Cc: clearview-discuss@opensolaris.org Message-id: <18223.30663.996889.938291@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.17 under 21.4 (patch 18) "Social Property" XEmacs Lucid Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 1961 Overview -------- This case proposes a consolidation-private IP_BROADCAST_TTL socket option which will be used by the DHCP client to preserve interoperability with broken DHCP servers. Patch binding is requested. Since this case should be straightforward and since we'd like to address the interoperability issue before the current build closes, the timer is set for Friday, November 9th. Details ------- To prevent broadcast packet storms, the TCP/IP stack sends all broadcast packets with a time-to-live of 1 (though this can be overridden with the ndd ip_broadcast_ttl tunable). This restriction has existed since Solaris 2.0 (if not earlier) and has not generally been an issue. However, some broken DHCP servers and DHCP relay agents -- especially those that also act as routers -- decrement the TTL of incoming packets before checking whether the packet is for them. As a result, broadcast DHCP traffic will be dropped by the DHCP server or DHCP relay, and as a result the DHCP client will be unable to obtain a lease. Until recently, the DHCP client has used DLPI to send broadcast DHCP traffic, merilly averting this issue (indeed, the old DHCP client DLPI explicitly set the TTL to 255 when constructing IP packets to combat this problem). However, now that the DHCP client is sockets-based, the issue has arisen. To address this problem, an IP_BROADCAST_TTL socket option is proposed. This option will be identical to the existing stable IP_MULTICAST_TTL socket option, but will apply to broadcast traffic. Since sending broadcast with arbitrary TTLs has no other known use-cases and may induce broadcast storms, IP_BROADCAST_TTL will be consolidation private and require the PRIV_NET_RAWACCESS privilege. Once the option is enabled, its value will override the ip_broadcast_ttl ndd tunable when sending broadcast packets on the given socket. -- meem From Darren.Reed@sun.com Mon Nov 5 16:20:01 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lA60K1nv025254 for ; Mon, 5 Nov 2007 16:20:01 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lA60GN8L001129 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Mon, 5 Nov 2007 16:16:23 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JR200H01639MP00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 05 Nov 2007 16:16:21 -0800 (PST) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JR200HCB6376J00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 05 Nov 2007 16:16:20 -0800 (PST) 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 lA60GJiq006795 for ; Tue, 06 Nov 2007 00:16:19 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JR200H01632C600@mail-apac.sun.com> (original mail from Darren.Reed@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 06 Nov 2007 08:16:19 +0800 (SGT) Received: from [129.146.106.55] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JR200HJ0636YHMH@mail-apac.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 06 Nov 2007 08:16:19 +0800 (SGT) Date: Mon, 05 Nov 2007 16:16:17 -0800 From: Darren Reed Subject: Re: PSARC/2007/639 IP_BROADCAST_TTL socket option In-reply-to: <18223.30663.996889.938291@gargle.gargle.HOWL> Sender: Darren.Reed@sun.com To: Peter Memishian Cc: psarc-ext@sun.com Message-id: <472FB251.9060407@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-au, en X-PMX-Version: 5.2.0.264296 References: <18223.30663.996889.938291@gargle.gargle.HOWL> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20060120 Status: RO Content-Length: 2447 Peter Memishian wrote: >.... >Details >------- > > To prevent broadcast packet storms, the TCP/IP stack sends all broadcast > packets with a time-to-live of 1 (though this can be overridden with the > ndd ip_broadcast_ttl tunable). This restriction has existed since > Solaris 2.0 (if not earlier) and has not generally been an issue. > > However, some broken DHCP servers and DHCP relay agents -- especially > those that also act as routers -- decrement the TTL of incoming packets > before checking whether the packet is for them. As a result, broadcast > DHCP traffic will be dropped by the DHCP server or DHCP relay, and as a > result the DHCP client will be unable to obtain a lease. > > Until recently, the DHCP client has used DLPI to send broadcast DHCP > traffic, merilly averting this issue (indeed, the old DHCP client DLPI > explicitly set the TTL to 255 when constructing IP packets to combat this > problem). However, now that the DHCP client is sockets-based, the issue > has arisen. > > To address this problem, an IP_BROADCAST_TTL socket option is proposed. > This option will be identical to the existing stable IP_MULTICAST_TTL > socket option, but will apply to broadcast traffic. Since sending > broadcast with arbitrary TTLs has no other known use-cases and may > induce broadcast storms, IP_BROADCAST_TTL will be consolidation private > and require the PRIV_NET_RAWACCESS privilege. Once the option is > enabled, its value will override the ip_broadcast_ttl ndd tunable when > sending broadcast packets on the given socket. > > Hmmm.... DHCP works on non-local LANs because of special forwarding performed for DHCP/BOOTP by routers. The implication of this option is that if the ttl is set for a broadcast packet, it will somehow make it past other routers/things on the network. That does not happen. I'd recommend updating the spec to remove the reference to "inducing broadcast storms" - this has nothing to do with why it should be consolidation private, if in fact it should be private. Given that we have IP_TTL as an option for getsockopt, why shouldn't we also implement that for setsockopt? And/or why would that be inappropriate for this problem? How would IP_BROADCAST_TTL interact with IP_TTL? To look into the future, can you explain why we would need to support setting IP_TTL, IP_BROADCAST_TTL and IP_MULTICAST_TTL, all on the same socket? Darren From meem@triplex.east.sun.com Mon Nov 5 18:51:03 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lA62p2os027838 for ; Mon, 5 Nov 2007 18:51:03 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lA62l1ql017291; Tue, 6 Nov 2007 02:47:20 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JR200001D2TNP00@nwk-avmta-2.sfbay.sun.com>; Mon, 05 Nov 2007 18:47:17 -0800 (PST) Received: from triplex.East.Sun.COM ([129.148.174.104]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JR200FXSD2TFS50@nwk-avmta-2.sfbay.sun.com>; Mon, 05 Nov 2007 18:47:17 -0800 (PST) Received: from triplex.East.Sun.COM (localhost [127.0.0.1]) by triplex.East.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id lA62lHIr113926; Mon, 05 Nov 2007 21:47:17 -0500 (EST) Received: (from meem@localhost) by triplex.East.Sun.COM (8.14.1+Sun/8.14.1/Submit) id lA62lGSG113923; Mon, 05 Nov 2007 21:47:16 -0500 (EST) Date: Mon, 05 Nov 2007 21:47:16 -0500 From: Peter Memishian Subject: Re: PSARC/2007/639 IP_BROADCAST_TTL socket option In-reply-to: <472FB251.9060407@Sun.COM> To: Darren Reed Cc: Peter Memishian , psarc-ext@sun.com Message-id: <18223.54708.444979.664741@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.17 under 21.4 (patch 18) "Social Property" XEmacs Lucid Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <18223.30663.996889.938291@gargle.gargle.HOWL> <472FB251.9060407@Sun.COM> Status: RO Content-Length: 1311 > DHCP works on non-local LANs because of special forwarding > performed for DHCP/BOOTP by routers. I'm not sure why you call this "special forwarding" -- it's simply normal DHCP relay agent behavior. Also, there is no requirement that a DHCP relay agent be an IP router. > I'd recommend updating the spec to remove the reference to > "inducing broadcast storms" - this has nothing to do with why > it should be consolidation private, if in fact it should be private. I think it's relevant. If there's no use-case, we should not provide rope to hang oneself. > Given that we have IP_TTL as an option for getsockopt, > why shouldn't we also implement that for setsockopt? We do have it for setsockopt(). It affects unicast traffic. > How would IP_BROADCAST_TTL interact with IP_TTL? It doesn't interact since IP_TTL only affects unicast traffic. > To look into the future, can you explain why we would need > to support setting IP_TTL, IP_BROADCAST_TTL and > IP_MULTICAST_TTL, all on the same socket? One affects unicast, one affects broadcast, and one affects multicast. IP_MULTICAST_TTL is the only one that's a stable API. BTW, this same split exists with IPv6: IPV6_UNICAST_HOPS and IPV6_MULTICAST_HOPS (of course there is no V6 broadcast); both are documented in ip6(7P). -- meem From Darren.Reed@sun.com Mon Nov 5 19:46:19 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lA63kIxq028995 for ; Mon, 5 Nov 2007 19:46:19 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lA63fu3b004509 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Tue, 6 Nov 2007 03:42:39 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JR200701FMTHI00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 05 Nov 2007 19:42:29 -0800 (PST) Received: from sineb-mail-2.sun.com ([192.18.19.7]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JR200B02FMSMLA0@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 05 Nov 2007 19:42:29 -0800 (PST) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lA63gRu6025017 for ; Tue, 06 Nov 2007 03:42:27 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JR200801FG6NN00@mail-apac.sun.com> (original mail from Darren.Reed@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 06 Nov 2007 11:42:27 +0800 (SGT) Received: from [129.146.106.55] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JR200G0EFMQCKT4@mail-apac.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 06 Nov 2007 11:42:27 +0800 (SGT) Date: Mon, 05 Nov 2007 19:42:25 -0800 From: Darren Reed Subject: Re: PSARC/2007/639 IP_BROADCAST_TTL socket option In-reply-to: <18223.54708.444979.664741@gargle.gargle.HOWL> Sender: Darren.Reed@sun.com To: Peter Memishian Cc: psarc-ext@sun.com Message-id: <472FE2A1.3030705@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-au, en X-PMX-Version: 5.2.0.264296 References: <18223.30663.996889.938291@gargle.gargle.HOWL> <472FB251.9060407@Sun.COM> <18223.54708.444979.664741@gargle.gargle.HOWL> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20060120 Status: RO Content-Length: 2352 Peter Memishian wrote: > > DHCP works on non-local LANs because of special forwarding > > performed for DHCP/BOOTP by routers. > >I'm not sure why you call this "special forwarding" -- it's simply normal >DHCP relay agent behavior. Also, there is no requirement that a DHCP >relay agent be an IP router. > > > I'd recommend updating the spec to remove the reference to > > "inducing broadcast storms" - this has nothing to do with why > > it should be consolidation private, if in fact it should be private. > >I think it's relevant. If there's no use-case, we should not provide rope >to hang oneself. > Hanging onself in this manner generally requires cooperation from routers but since smurf (and other) attacks become wide spread, forwarding of packets to networks where the destination address becomes interpreted as a broadcast is generally disabled by default - eg: # ndd /dev/ip ip_forward_directed_broadcasts 0 > > Given that we have IP_TTL as an option for getsockopt, > > why shouldn't we also implement that for setsockopt? > >We do have it for setsockopt(). It affects unicast traffic. > Is there any dependency between IP_BROADCAST_TTL and SO_BROADCAST? > > How would IP_BROADCAST_TTL interact with IP_TTL? > >It doesn't interact since IP_TTL only affects unicast traffic. > > > To look into the future, can you explain why we would need > > to support setting IP_TTL, IP_BROADCAST_TTL and > > IP_MULTICAST_TTL, all on the same socket? > >One affects unicast, one affects broadcast, and one affects multicast. >IP_MULTICAST_TTL is the only one that's a stable API. BTW, this same >split exists with IPv6: IPV6_UNICAST_HOPS and IPV6_MULTICAST_HOPS (of >course there is no V6 broadcast); both are documented in ip6(7P). > FWIW, this behaviour, of IP_TTL vs IP_BROADCAST_TTL vs IP_MULTICAST_TTL is going to differ from other platforms, increasing the difficulty of porting applications to/from Solaris. Whereas IP_MULTICAST_TTL seems to be common across the board, as to IP_TTL, IP_BROADCAST_TTL is not and in its place, IP_TTL is used. What benefit do we (Solaris and OpenSolaris) gain by being architecturally different in this to both BSD and Linux? Or in other words, why shouldn't we just fix IP_TTL to apply to both unicast and broadcast packets (but not multicast) like everyone else? Darren From sommerfeld@sun.com Mon Nov 5 20:15:58 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lA64FvMU029880 for ; Mon, 5 Nov 2007 20:15:57 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lA64C2nQ012698; Tue, 6 Nov 2007 04:12:18 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JR200C05H0FJZ00@nwk-avmta-1.sfbay.Sun.COM>; Mon, 05 Nov 2007 20:12:15 -0800 (PST) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JR200BVQH0EMHC0@nwk-avmta-1.sfbay.Sun.COM>; Mon, 05 Nov 2007 20:12:14 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lA64CC9n032926; Mon, 05 Nov 2007 23:12:12 -0500 (EST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by thunk.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id lA64CC9f029415; Mon, 05 Nov 2007 23:12:12 -0500 (EST) Date: Mon, 05 Nov 2007 23:12:11 -0500 From: Bill Sommerfeld Subject: Re: PSARC/2007/639 IP_BROADCAST_TTL socket option In-reply-to: <18223.30663.996889.938291@gargle.gargle.HOWL> To: Peter Memishian Cc: psarc-ext@sun.com, clearview-discuss@opensolaris.org Message-id: <1194322332.28922.15.camel@thunk> MIME-version: 1.0 X-Mailer: Evolution 2.12.0 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <18223.30663.996889.938291@gargle.gargle.HOWL> Status: RO Content-Length: 379 On Mon, 2007-11-05 at 15:06 -0500, Peter Memishian wrote: > To address this problem, an IP_BROADCAST_TTL socket option is proposed. > This option will be identical to the existing stable IP_MULTICAST_TTL > socket option, but will apply to broadcast traffic. is there some reason we can't simply extend IP_MULTICAST_TTL to also cover broadcast traffic? - Bill From meem@triplex.east.sun.com Mon Nov 5 20:26:20 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lA64QKx4000197 for ; Mon, 5 Nov 2007 20:26:20 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lA64MceL022447; Mon, 5 Nov 2007 20:22:39 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JR20050JHHQOK00@nwk-avmta-2.sfbay.sun.com>; Mon, 05 Nov 2007 20:22:38 -0800 (PST) Received: from triplex.East.Sun.COM ([129.148.174.104]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JR200F9MHHOFQ90@nwk-avmta-2.sfbay.sun.com>; Mon, 05 Nov 2007 20:22:37 -0800 (PST) Received: from triplex.East.Sun.COM (localhost [127.0.0.1]) by triplex.East.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id lA64MapK114148; Mon, 05 Nov 2007 23:22:36 -0500 (EST) Received: (from meem@localhost) by triplex.East.Sun.COM (8.14.1+Sun/8.14.1/Submit) id lA64MaMl114145; Mon, 05 Nov 2007 23:22:36 -0500 (EST) Date: Mon, 05 Nov 2007 23:22:32 -0500 From: Peter Memishian Subject: Re: PSARC/2007/639 IP_BROADCAST_TTL socket option In-reply-to: <472FE2A1.3030705@Sun.COM> To: Darren Reed Cc: Peter Memishian , psarc-ext@sun.com Message-id: <18223.60424.592113.605150@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.17 under 21.4 (patch 18) "Social Property" XEmacs Lucid Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <18223.30663.996889.938291@gargle.gargle.HOWL> <472FB251.9060407@Sun.COM> <18223.54708.444979.664741@gargle.gargle.HOWL> <472FE2A1.3030705@Sun.COM> Status: RO Content-Length: 1696 > >We do have it for setsockopt(). It affects unicast traffic. > > Is there any dependency between IP_BROADCAST_TTL and > SO_BROADCAST? Given that SO_BROADCAST doesn't actually seem to do anything on Solaris (other than retrieve the value it was set to), there's no interaction today. In theory, one would have to enable SO_BROADCAST before being able to send packets that IP_BROADCAST_TTL would apply to. > FWIW, this behaviour, of IP_TTL vs IP_BROADCAST_TTL vs > IP_MULTICAST_TTL is going to differ from other platforms, > increasing the difficulty of porting applications to/from Solaris. > Whereas IP_MULTICAST_TTL seems to be common across > the board, as to IP_TTL, IP_BROADCAST_TTL is not and in > its place, IP_TTL is used. What benefit do we (Solaris and > OpenSolaris) gain by being architecturally different in this > to both BSD and Linux? > > Or in other words, why shouldn't we just fix IP_TTL to apply > to both unicast and broadcast packets (but not multicast) > like everyone else? Have you verified the behavior on the various BSDs and Linux? According to the Linux documentation I've seen, IP_TTL would also apply to multicast packets, and looking at the FreeBSD source's ip_output(), it looks like e.g. sending to 255.255.255.255 always sends with a TTL of 1 (regardless of IP_TTL), and that is precisely the case that's of interest to the DHCP client here. Regardless, neither IP_TTL nor the proposed IP_BROADCAST_TTL are documented interfaces nor does this case propose to make them such, so if someone finds a grand unifying plan across the various Unices here and wants to implement it, this case certainly doesn't stand in their way. -- meem From meem@triplex.east.sun.com Mon Nov 5 20:40:23 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lA64eNE3000643 for ; Mon, 5 Nov 2007 20:40:23 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lA64ahBJ016555; Mon, 5 Nov 2007 20:36:43 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JR200901I4YK900@brm-avmta-1.central.sun.com>; Mon, 05 Nov 2007 21:36:34 -0700 (MST) Received: from triplex.East.Sun.COM ([129.148.174.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JR200IXBI4XX660@brm-avmta-1.central.sun.com>; Mon, 05 Nov 2007 21:36:33 -0700 (MST) Received: from triplex.East.Sun.COM (localhost [127.0.0.1]) by triplex.East.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id lA64T46X114190; Mon, 05 Nov 2007 23:29:04 -0500 (EST) Received: (from meem@localhost) by triplex.East.Sun.COM (8.14.1+Sun/8.14.1/Submit) id lA64T4bR114187; Mon, 05 Nov 2007 23:29:04 -0500 (EST) Date: Mon, 05 Nov 2007 23:29:04 -0500 From: Peter Memishian Subject: Re: PSARC/2007/639 IP_BROADCAST_TTL socket option In-reply-to: <1194322332.28922.15.camel@thunk> To: Bill Sommerfeld Cc: Peter Memishian , psarc-ext@Sun.COM, clearview-discuss@opensolaris.org Message-id: <18223.60816.65596.946590@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.17 under 21.4 (patch 18) "Social Property" XEmacs Lucid Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <18223.30663.996889.938291@gargle.gargle.HOWL> <1194322332.28922.15.camel@thunk> Status: RO Content-Length: 573 > > To address this problem, an IP_BROADCAST_TTL socket option is proposed. > > This option will be identical to the existing stable IP_MULTICAST_TTL > > socket option, but will apply to broadcast traffic. > > is there some reason we can't simply extend IP_MULTICAST_TTL to also > cover broadcast traffic? As per the manpage, it only applies to multicast datagrams on the socket. Having it also apply to broadcast traffic would break that promise. Aside from that, I still think IP_BROADCAST_TTL is clearer, both in semantics and in the code. -- meem From Darren.Reed@sun.com Mon Nov 5 21:00:28 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lA650SiU001241 for ; Mon, 5 Nov 2007 21:00:28 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lA64unOH044408 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Mon, 5 Nov 2007 21:56:49 -0700 (MST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JR200B03J2P6O00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 05 Nov 2007 21:56:49 -0700 (MST) Received: from sineb-mail-2.sun.com ([192.18.19.7]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JR200IQTJ2OX960@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 05 Nov 2007 21:56:49 -0700 (MST) Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lA64ulca029757 for ; Tue, 06 Nov 2007 04:56:47 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JR200B01IYJF300@mail-apac.sun.com> (original mail from Darren.Reed@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 06 Nov 2007 12:56:47 +0800 (SGT) Received: from [129.146.106.55] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JR200HOIJ2MYDUZ@mail-apac.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 06 Nov 2007 12:56:47 +0800 (SGT) Date: Mon, 05 Nov 2007 20:56:45 -0800 From: Darren Reed Subject: Re: PSARC/2007/639 IP_BROADCAST_TTL socket option In-reply-to: <18223.60424.592113.605150@gargle.gargle.HOWL> Sender: Darren.Reed@sun.com To: Peter Memishian Cc: psarc-ext@sun.com Message-id: <472FF40D.1000905@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-au, en X-PMX-Version: 5.2.0.264296 References: <18223.30663.996889.938291@gargle.gargle.HOWL> <472FB251.9060407@Sun.COM> <18223.54708.444979.664741@gargle.gargle.HOWL> <472FE2A1.3030705@Sun.COM> <18223.60424.592113.605150@gargle.gargle.HOWL> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20060120 Status: RO Content-Length: 2218 Peter Memishian wrote: > > >We do have it for setsockopt(). It affects unicast traffic. > > > > Is there any dependency between IP_BROADCAST_TTL and > > SO_BROADCAST? > >Given that SO_BROADCAST doesn't actually seem to do anything on Solaris >(other than retrieve the value it was set to), there's no interaction >today. In theory, one would have to enable SO_BROADCAST before being >able to send packets that IP_BROADCAST_TTL would apply to. > > So there is no intention to change the way things are today? > > FWIW, this behaviour, of IP_TTL vs IP_BROADCAST_TTL vs > > IP_MULTICAST_TTL is going to differ from other platforms, > > increasing the difficulty of porting applications to/from Solaris. > > Whereas IP_MULTICAST_TTL seems to be common across > > the board, as to IP_TTL, IP_BROADCAST_TTL is not and in > > its place, IP_TTL is used. What benefit do we (Solaris and > > OpenSolaris) gain by being architecturally different in this > > to both BSD and Linux? > > > > Or in other words, why shouldn't we just fix IP_TTL to apply > > to both unicast and broadcast packets (but not multicast) > > like everyone else? > >Have you verified the behavior on the various BSDs and Linux? According >to the Linux documentation I've seen, IP_TTL would also apply to multicast >packets, > The source code disagrees with the documentation. >and looking at the FreeBSD source's ip_output(), it looks like >e.g. sending to 255.255.255.255 always sends with a TTL of 1 (regardless >of IP_TTL), and that is precisely the case that's of interest to the DHCP >client here. > > Not all of them exhibit this behaviour and only FreeBSD ditinguishes between 255.255.255.255 and other broadcast addresses. >Regardless, neither IP_TTL nor the proposed IP_BROADCAST_TTL are >documented interfaces nor does this case propose to make them such, so if >someone finds a grand unifying plan across the various Unices here and >wants to implement it, this case certainly doesn't stand in their way. > > Given that this design has a very narrow scope in mind, it would be beneficial if the name associated with the option was also similarly narrow - something like IP_ALL_ONES_TTL - so as to avoid confusion. Darren From meem@triplex.east.sun.com Mon Nov 5 21:14:59 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lA65EwUj001343 for ; Mon, 5 Nov 2007 21:14:59 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lA65BAg8029046; Tue, 6 Nov 2007 05:11:16 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JR200M0PJQRUH00@nwk-avmta-1.sfbay.Sun.COM>; Mon, 05 Nov 2007 21:11:15 -0800 (PST) Received: from triplex.East.Sun.COM ([129.148.174.104]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JR200KXHJQNXD00@nwk-avmta-1.sfbay.Sun.COM>; Mon, 05 Nov 2007 21:11:11 -0800 (PST) Received: from triplex.East.Sun.COM (localhost [127.0.0.1]) by triplex.East.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id lA65BAL4114259; Tue, 06 Nov 2007 00:11:11 -0500 (EST) Received: (from meem@localhost) by triplex.East.Sun.COM (8.14.1+Sun/8.14.1/Submit) id lA65BA3k114256; Tue, 06 Nov 2007 00:11:10 -0500 (EST) Date: Tue, 06 Nov 2007 00:11:10 -0500 From: Peter Memishian Subject: Re: PSARC/2007/639 IP_BROADCAST_TTL socket option In-reply-to: <472FF40D.1000905@Sun.COM> To: Darren Reed Cc: Peter Memishian , psarc-ext@sun.com Message-id: <18223.63342.778997.40135@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.17 under 21.4 (patch 18) "Social Property" XEmacs Lucid Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <18223.30663.996889.938291@gargle.gargle.HOWL> <472FB251.9060407@Sun.COM> <18223.54708.444979.664741@gargle.gargle.HOWL> <472FE2A1.3030705@Sun.COM> <18223.60424.592113.605150@gargle.gargle.HOWL> <472FF40D.1000905@Sun.COM> Status: RO Content-Length: 1165 > > > >We do have it for setsockopt(). It affects unicast traffic. > > > > > > Is there any dependency between IP_BROADCAST_TTL and > > > SO_BROADCAST? > > > >Given that SO_BROADCAST doesn't actually seem to do anything on Solaris > >(other than retrieve the value it was set to), there's no interaction > >today. In theory, one would have to enable SO_BROADCAST before being > >able to send packets that IP_BROADCAST_TTL would apply to. > > So there is no intention to change the way things are today? Not as part of this case. > Given that this design has a very narrow scope in mind, it would > be beneficial if the name associated with the option was also > similarly narrow - something like IP_ALL_ONES_TTL - so as > to avoid confusion. What confusion? This is a consolidation-private socket option with one consumer. All IP_ALL_ONES_TTL would do is add cruft and complexity inside IP, since the semantics would no longer exactly mirror the cases where the ip_broadcast_ttl ndd tunable currently applies. Regardless, I fear this has become a shed-painting exercise. Surely there are more interesting matters to attend to? -- meem From meem@triplex.east.sun.com Mon Nov 5 21:53:37 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lA65ra1V001500 for ; Mon, 5 Nov 2007 21:53:37 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lA65nrLM010527; Tue, 6 Nov 2007 05:49:54 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JR200605LJ5GV00@nwk-avmta-1.sfbay.Sun.COM>; Mon, 05 Nov 2007 21:49:53 -0800 (PST) Received: from triplex.East.Sun.COM ([129.148.174.104]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JR200K57LJ4XB40@nwk-avmta-1.sfbay.Sun.COM>; Mon, 05 Nov 2007 21:49:53 -0800 (PST) Received: from triplex.East.Sun.COM (localhost [127.0.0.1]) by triplex.East.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id lA65gJKh114570; Tue, 06 Nov 2007 00:42:19 -0500 (EST) Received: (from meem@localhost) by triplex.East.Sun.COM (8.14.1+Sun/8.14.1/Submit) id lA65gJLp114567; Tue, 06 Nov 2007 00:42:19 -0500 (EST) Date: Tue, 06 Nov 2007 00:42:19 -0500 From: Peter Memishian Subject: Re: PSARC/2007/639 IP_BROADCAST_TTL socket option In-reply-to: <472FFAFE.50404@Sun.COM> To: Darren Reed Cc: Peter Memishian , Bill Sommerfeld , psarc-ext@Sun.COM, clearview-discuss@opensolaris.org Message-id: <18223.65211.324659.322395@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.17 under 21.4 (patch 18) "Social Property" XEmacs Lucid Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <18223.30663.996889.938291@gargle.gargle.HOWL> <1194322332.28922.15.camel@thunk> <18223.60816.65596.946590@gargle.gargle.HOWL> <472FFAFE.50404@Sun.COM> Status: RO Content-Length: 911 > But I can't help but wonder, with seeing this case and the code > changes required in ip_input, if the change to DHCP's architecture > that requires this was actually a good one. I think the problem is actually the opposite -- too many vendors implement special-case code to handle DHCP, and that leads to a multitude of odd implementations to interoperate with. Combine that with a weakly-worded RFC (e.g. the fact that servers can ignore the broadcast bit is a crime) and you get hacks. That said, I think the end-result is still vastly preferable given that it led to a net reduction of 800 lines of code, allowed the DHCP client to get out of the business of constructing UDP and IP checksums, allowed firewall rules to be consistently applied to DHCP traffic, enabled DHCP to work properly with DR, and will allow DHCP to work with IPMP in the future. Regardless, that's not this case. -- meem From Darren.Reed@sun.com Mon Nov 5 22:32:42 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lA66WgBr002409 for ; Mon, 5 Nov 2007 22:32:42 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lA66T1Kr017939; Mon, 5 Nov 2007 22:29:03 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JR200B0PNCEZW00@nwk-avmta-2.sfbay.sun.com>; Mon, 05 Nov 2007 22:29:02 -0800 (PST) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JR200FKYNCDFGC0@nwk-avmta-2.sfbay.sun.com>; Mon, 05 Nov 2007 22:29:02 -0800 (PST) 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 lA66T0Wx000754; Tue, 06 Nov 2007 06:29:00 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JR200C01NARQ300@mail-apac.sun.com> (original mail from Darren.Reed@Sun.COM); Tue, 06 Nov 2007 14:29:00 +0800 (SGT) Received: from [129.146.106.55] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JR2002HBNC8S6GE@mail-apac.sun.com>; Tue, 06 Nov 2007 14:28:59 +0800 (SGT) Date: Mon, 05 Nov 2007 22:28:56 -0800 From: Darren Reed Subject: Re: PSARC/2007/639 IP_BROADCAST_TTL socket option In-reply-to: <472FFAFE.50404@Sun.COM> Sender: Darren.Reed@sun.com To: Darren Reed Cc: Peter Memishian , Bill Sommerfeld , psarc-ext@sun.com, clearview-discuss@opensolaris.org Message-id: <473009A8.9060704@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-au, en X-PMX-Version: 5.2.0.264296 References: <18223.30663.996889.938291@gargle.gargle.HOWL> <1194322332.28922.15.camel@thunk> <18223.60816.65596.946590@gargle.gargle.HOWL> <472FFAFE.50404@Sun.COM> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20060120 Status: RO Content-Length: 773 Darren Reed wrote: > Peter Memishian wrote: > >> > > To address this problem, an IP_BROADCAST_TTL socket option is >> proposed. >> > > This option will be identical to the existing stable >> IP_MULTICAST_TTL >> > > socket option, but will apply to broadcast traffic. > > is >> there some reason we can't simply extend IP_MULTICAST_TTL to also >> > cover broadcast traffic? >> >> As per the manpage, it only applies to multicast datagrams on the >> socket. >> Having it also apply to broadcast traffic would break that promise. >> > > FWIW, I agree with your comments here... FYI...Bill's comments need expanding on... BSD implemented IP_MULTICAST_TTL to cover 255.255.255.255 in addition to multicast packets but not broadcast packets in general. Darren From carlsonj@phorcys.east.sun.com Tue Nov 6 08:18:29 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lA6GITDr011929 for ; Tue, 6 Nov 2007 08:18:29 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lA6GEhIa000211; Tue, 6 Nov 2007 08:14:47 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JR300M0DEGMJG00@brm-avmta-1.central.sun.com>; Tue, 06 Nov 2007 09:14:46 -0700 (MST) Received: from phorcys.east.sun.com ([129.148.174.143]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JR300BNGEGLK3C0@brm-avmta-1.central.sun.com>; Tue, 06 Nov 2007 09:14:45 -0700 (MST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id lA6GE6ps026668; Tue, 06 Nov 2007 11:14:06 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id lA6GE6GL026665; Tue, 06 Nov 2007 11:14:06 -0500 (EST) Date: Tue, 06 Nov 2007 11:14:06 -0500 From: James Carlson Subject: Re: PSARC/2007/639 IP_BROADCAST_TTL socket option In-reply-to: <472FE2A1.3030705@Sun.COM> To: Darren Reed Cc: Peter Memishian , psarc-ext@sun.com Message-id: <18224.37582.188160.142884@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <18223.30663.996889.938291@gargle.gargle.HOWL> <472FB251.9060407@Sun.COM> <18223.54708.444979.664741@gargle.gargle.HOWL> <472FE2A1.3030705@Sun.COM> Status: RO Content-Length: 1231 Darren Reed writes: > > Hanging onself in this manner generally requires cooperation > from routers but since smurf (and other) attacks become wide > spread, forwarding of packets to networks where the destination > address becomes interpreted as a broadcast is generally disabled > by default - eg: > # ndd /dev/ip ip_forward_directed_broadcasts > 0 > True. Fortunately, DHCP doesn't normally use simply forwarded broadcasts but instead relies on proxy behavior. The problem that's being worked around here is broken behavior in a few other implementations. > Or in other words, why shouldn't we just fix IP_TTL to apply > to both unicast and broadcast packets (but not multicast) > like everyone else? That'd alter existing applications. They don't expect IP_TTL to change the way broadcast works, and it'd be a "surprise" (read: "bug") if it suddenly started doing so. There's no way to guarantee that applications _won't_ trip on this except to keep it out of the way. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Darren.Reed@sun.com Tue Nov 6 12:18:00 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lA6KHxpu022831 for ; Tue, 6 Nov 2007 12:18:00 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lA6KE8WW023843 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Tue, 6 Nov 2007 20:14:19 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JR300H0DPJT9200@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 06 Nov 2007 13:14:17 -0700 (MST) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JR3006U9PJS8Z80@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 06 Nov 2007 13:14:17 -0700 (MST) Received: from fe-apac-04.sun.com (fe-apac-04.sun.com [192.18.19.175] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lA6KEGuZ001925 for ; Tue, 06 Nov 2007 20:14:16 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JR300601OC8QO00@mail-apac.sun.com> (original mail from Darren.Reed@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 07 Nov 2007 04:14:16 +0800 (SGT) Received: from [129.146.106.55] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JR3007EFPJQ6T20@mail-apac.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 07 Nov 2007 04:14:15 +0800 (SGT) Date: Tue, 06 Nov 2007 12:14:13 -0800 From: Darren Reed Subject: Re: PSARC/2007/639 IP_BROADCAST_TTL socket option In-reply-to: <18224.37582.188160.142884@gargle.gargle.HOWL> Sender: Darren.Reed@sun.com To: James Carlson Cc: Peter Memishian , psarc-ext@sun.com Message-id: <4730CB15.3000704@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-au, en X-PMX-Version: 5.2.0.264296 References: <18223.30663.996889.938291@gargle.gargle.HOWL> <472FB251.9060407@Sun.COM> <18223.54708.444979.664741@gargle.gargle.HOWL> <472FE2A1.3030705@Sun.COM> <18224.37582.188160.142884@gargle.gargle.HOWL> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20060120 Status: RO Content-Length: 774 James Carlson wrote: >Darren Reed writes: > > > ... > >>Or in other words, why shouldn't we just fix IP_TTL to apply >>to both unicast and broadcast packets (but not multicast) >>like everyone else? >> >> > >That'd alter existing applications. They don't expect IP_TTL to >change the way broadcast works, and it'd be a "surprise" (read: "bug") >if it suddenly started doing so. There's no way to guarantee that >applications _won't_ trip on this except to keep it out of the way. > > It has been mentioned that IP_TTL is a private interface so we're under no obligation to preserve its behaviour for anything outside of ON, correct? For those within ON that do use IP_TTL (all 3 of them), fixing them (if it is indeed required) shouldn't be that hard. Darren From Darren.Reed@sun.com Wed Nov 7 15:30:10 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lA7NU9VQ015413 for ; Wed, 7 Nov 2007 15:30:09 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lA7NQRp7057160 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 7 Nov 2007 16:26:28 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JR500E0LT3WH800@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 07 Nov 2007 15:26:20 -0800 (PST) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JR500AIJT3VKE80@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 07 Nov 2007 15:26:20 -0800 (PST) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lA7NQJ4v004767 for ; Wed, 07 Nov 2007 23:26:19 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JR500B01T1NI200@mail-apac.sun.com> (original mail from Darren.Reed@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 08 Nov 2007 07:26:19 +0800 (SGT) Received: from [129.146.106.55] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JR500GMRT3TCKA7@mail-apac.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 08 Nov 2007 07:26:19 +0800 (SGT) Date: Wed, 07 Nov 2007 15:26:17 -0800 From: Darren Reed Subject: Re: PSARC/2007/639 IP_BROADCAST_TTL socket option In-reply-to: <18223.30663.996889.938291@gargle.gargle.HOWL> Sender: Darren.Reed@sun.com To: Peter Memishian Cc: psarc-ext@sun.com Message-id: <47324999.9040504@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-au, en X-PMX-Version: 5.2.0.264296 References: <18223.30663.996889.938291@gargle.gargle.HOWL> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20060120 Status: RO Content-Length: 2335 So, in PSARC this morning I asked for more time to consider this case because at that time I hadn't arrived at a place where I thought I was comfortable with what was being proposed and I wanted some time to think it through before letting it go. So if I can ramble on for a bit.... ip_broadcast_ttl exists because of a binary compatibility requirement with SunOS4 in the early days of SunOS5. Even then this wasn't absolutely required, /etc/system could have been used instead (it's not clear that there are any architectural benefits of /etc/system vs ndd as both receive a fair share of criticism.) But alas the change was made and so here we are today... The use of ip_broadcast_ttl seems to be extremely rare (google provided me with no hits to searches for "ndd -set /dev/ip ip_broadcast_ttl") and only in situations where customers want to send out broadcast packets with a higher TTL - there is no way for their application to do so. Whereas on other platforms, a combination of IP_TTL and IP_MULTICAST_TTL seems to allow this to be achieved, we haven't blurred the meaning of IP_MULTICAST_TTL (it applies to multicast and multicast only packets) and neither do we support using IP_TTL to modify the ttl of broadcast packets. So adding in IP_BROADCAST_TTL to provide the means for setting the TTL in broadcast packets for IP fills in a gap we have, while at the same time aligning itself with a (familiar) name from ndd. While we're not aligned with others (and there does appear to be some variance out there), its not too radical. So really nothing to worry about. So there's just one issue remaining... I would like to have seen being able to issue an IP_BROADCAST_TTL require that SO_BROADCAST had been issued first. While there is established behaviour in our deployed code base that requires SO_BROADCAST to be ignored for sending broadcast packets, this case introduces a new socket option so it seems within reason to require IP_BROADCAST_TTL to need SO_BROADCAST to be set. I don't see that this would change the architecture of SO_BROADCAST, just refine that for IP_BROADCAST_TTL. A little bit of a stick to get people to use SO_BROADCAST as they should. ...so having thought it through, I'm happy with the case as it is, I'd just be happier if it recognised SO_BROADCAST as being significant. Darren From meem@triplex.east.sun.com Wed Nov 7 16:06:36 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lA806aN0016526 for ; Wed, 7 Nov 2007 16:06:36 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lA802bdt016230; Thu, 8 Nov 2007 00:02:50 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JR500B05USNUE00@brm-avmta-1.central.sun.com>; Wed, 07 Nov 2007 17:02:47 -0700 (MST) Received: from triplex.East.Sun.COM ([129.148.174.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JR500H81USNKLE0@brm-avmta-1.central.sun.com>; Wed, 07 Nov 2007 17:02:47 -0700 (MST) Received: from triplex.East.Sun.COM (localhost [127.0.0.1]) by triplex.East.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id lA802ldQ123366; Wed, 07 Nov 2007 19:02:47 -0500 (EST) Received: (from meem@localhost) by triplex.East.Sun.COM (8.14.1+Sun/8.14.1/Submit) id lA802lnl123363; Wed, 07 Nov 2007 19:02:47 -0500 (EST) Date: Wed, 07 Nov 2007 19:02:46 -0500 From: Peter Memishian Subject: Re: PSARC/2007/639 IP_BROADCAST_TTL socket option In-reply-to: <47324999.9040504@Sun.COM> To: Darren Reed Cc: Peter Memishian , psarc-ext@sun.com Message-id: <18226.21030.959311.366520@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.17 under 21.4 (patch 18) "Social Property" XEmacs Lucid Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <18223.30663.996889.938291@gargle.gargle.HOWL> <47324999.9040504@Sun.COM> Status: RO Content-Length: 1696 > I would like to have seen being able to issue an > IP_BROADCAST_TTL require that SO_BROADCAST had been > issued first. While there is established behaviour > in our deployed code base that requires SO_BROADCAST > to be ignored for sending broadcast packets, this > case introduces a new socket option so it seems > within reason to require IP_BROADCAST_TTL to need > SO_BROADCAST to be set. I don't see that this would > change the architecture of SO_BROADCAST, just refine > that for IP_BROADCAST_TTL. A little bit of a stick > to get people to use SO_BROADCAST as they should. > > ...so having thought it through, I'm happy with the > case as it is, I'd just be happier if it recognised > SO_BROADCAST as being significant. I don't think that request makes sense. Even if we enforced SO_BROADCAST, it would be (as per the documentation) to restrict the transmission of broadcast messages. That does not mean that it should restrict the configuration of the content of those broadcast messages. That is, the choke point should occur when actually sending the message, not when configuring the characteristics of those messages. Phrased differently, requiring one to call SO_BROADCAST prior to calling IP_BROADCAST_TTL is one more unnecessary rule for the application developer to remember, and one more unnecessary rule for the kernel to enforce. Further, it is especially strange given that SO_BROADCAST has (intentionally) done nothing since Solaris 2.0. However, if one day we decide to enforce SO_BROADCAST, it should be done uniformly by restricting the transmission of broadcast packets, which is both simple and in-line with existing documentation. -- meem From meem@triplex.east.sun.com Thu Nov 8 10:49:57 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lA8Inu9N004151 for ; Thu, 8 Nov 2007 10:49:57 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lA8IjutG001242; Thu, 8 Nov 2007 18:46:12 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JR700C3DASX5M00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 08 Nov 2007 10:46:09 -0800 (PST) Received: from triplex.East.Sun.COM ([129.148.174.104]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JR7004U2ASVWG20@nwk-avmta-1.sfbay.Sun.COM>; Thu, 08 Nov 2007 10:46:08 -0800 (PST) Received: from triplex.East.Sun.COM (localhost [127.0.0.1]) by triplex.East.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id lA8Ik7pX128419; Thu, 08 Nov 2007 13:46:07 -0500 (EST) Received: (from meem@localhost) by triplex.East.Sun.COM (8.14.1+Sun/8.14.1/Submit) id lA8Ik747128416; Thu, 08 Nov 2007 13:46:07 -0500 (EST) Date: Thu, 08 Nov 2007 13:46:07 -0500 From: Peter Memishian Subject: Re: PSARC/2007/639 IP_BROADCAST_TTL socket option In-reply-to: <18226.21030.959311.366520@gargle.gargle.HOWL> To: Peter Memishian Cc: Darren Reed , psarc-ext@sun.com Message-id: <18227.22895.392453.387138@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.17 under 21.4 (patch 18) "Social Property" XEmacs Lucid Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <18223.30663.996889.938291@gargle.gargle.HOWL> <47324999.9040504@Sun.COM> <18226.21030.959311.366520@gargle.gargle.HOWL> Status: RO Content-Length: 187 Since I believe all remaining concerns have now been addressed, and the revised timeout for this case (set at the PSARC meeting) was yesterday, I'm marking this case approved. -- meem