From Sebastien.Roy@sun.com Tue Mar 2 15:20:58 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o22NKwBq020208 for ; Tue, 2 Mar 2010 15:20:58 -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.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o22NKvtW002743 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Tue, 2 Mar 2010 15:20:58 -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 <0KYO00B03GUXY200@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 02 Mar 2010 16:20:57 -0700 (MST) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KYO00MCNGUX6680@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 02 Mar 2010 16:20:57 -0700 (MST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o22NKvLA003294 for ; Tue, 02 Mar 2010 23:20:57 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KYO00J00GIYWM00@mail-amer.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 02 Mar 2010 16:20:57 -0700 (MST) Received: from [129.148.174.103] ([unknown] [129.148.174.103]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KYO00GZWGUWEK20@mail-amer.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 02 Mar 2010 16:20:57 -0700 (MST) Date: Tue, 02 Mar 2010 18:18:14 -0500 From: Sebastien Roy Subject: Brussels II addendum [PSARC/2010/080 FastTrack timeout 03/09/2010] Sender: Sebastien.Roy@sun.com To: psarc-ext@sun.com Cc: Girish.Moodalbail@sun.com Message-id: <4B8D9CB6.8010700@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100131 Lightning/1.0b1 Thunderbird/3.0.1 Status: RO Content-Length: 7880 I'm submitting the following fast-track for Girish Moodalbail, the timer is set for 03/09/2010. This case depends on PSARC 2009/306, the release binding is Minor. 1. Introduction: ================ In the course of completing the implementation of Brussels II - ipadm and libipadm (PSARC 2009/306), few interface changes were made. They are all documented below. 1.1 Following new interfaces were added since PSARC 2009/306. ------------------------------------------------------------- ------------------------------------------------------------------------------ Interface Classification Comments ------------------------------------------------------------------------------ ipadm down-addr Committed See section 5.6 of [1] ipadm up-addr Committed See section 5.7 of [1] ipadm reset-addrprop Committed See section 5.8 of [1] ipadm disable-if Committed See section 6.0 of [1] ipadm enable-if Committed See section 6.0 of [1] ipadm disable-addr Committed See section 6.0 of [1] ipadm enable-addr Committed See section 6.0 of [1] SIOCGLIFDADSTATE Consolidation Private See section 5.2 of [1] SIOCSLIFPREFIX Consolidation Private See section 5.1.2 of [1] IFF_NOLINKLOCAL Consolidation Private See section 4.1 of [1] 1.2 updates to 'show-if', 'show-addr', 'show-[if|addr]prop' parsable output --------------------------------------------------------------------------- * '-P' option has been removed from all of the 'show-*' subcommands. All the 'show-*' subcommands will always show both CURRENT and PERSISTENT values. 1.2.1 updates to 'show-if' parsable output ------------------------------------------ [For more details, see section 4.3 of [1] and 'ipadm show-if' in [2]] * MTU,FLAGS column has been removed * CURRENT and PERSISTENT column, which represents both current and persistent flags are added. 1.2.2 updates to 'show-addr' parsable output -------------------------------------------- [For more details, see section 5.2 of [1] and 'ipadm show-addr' in [2]] * Following column headers are renamed: ** s/OBJECT/ADDROBJ/ ** s/ORIGIN/TYPE/ * FLAGS column has been removed * Following changes are made to STATE column ** 'invalid' is renamed to 'down' ** 'unknown' and 'preferred' state is removed ** 'disabled' state is added. * New CURRENT and PERSISTENT columns, which represents current and persistent flags respectively are added. 1.3 updates to subcommand options ---------------------------------- [Refer to ipadm man page [2] for more details] * 'create-if' subcommand will not take '-f inet|inet6' option * 'delete-if' subcommand will not take '-t' or '-f inet|inet6' option * 'create-addr -T addrconf' takes '-i' option instead of '-I' * 'create-addr -T dhcp' will not take '-p' option * 'refresh-addr' will take -i option to perform DHCP inform. * 'delete-addr' will not take '-t' option * 'set-ifprop' and 'reset-ifprop' will not take '-f inet|inet6' option instead they take '-m protocol' option 1.4 Reduced set of ndd IP/TCP/UDP/SCTP/ICMP tunables ---------------------------------------------------- The number of protocol tunables that will be made public or Committed has been substantially reduced. The basic premise is to design a framework that provides persistence of protocol settings and improvement over the current ndd(1M). Once we have this framework, more and more tunables can be Committed through PSARC, after sufficient scrutiny. Following table lists the protocol properties that will be Committed. ------------------------------------------------------------------------------ Properties Protocol(s) Classification Comments ------------------------------------------------------------------------------ forwarding ipv4, ipv6 Committed See [2] ttl ipv4 Committed See [2] hoplimit ipv6 Committed See [2] ecn tcp Committed See [2] sack tcp Committed See [2] recv_maxbuf send_maxbuf tcp, udp, sctp icmp Committed See [2] extra_priv_ports largest_anon_port smallest_anon_port smallest_nonpriv_port tcp, udp, sctp Committed See [2] 1.5 Modifications to address and interface properties ----------------------------------------------------- * Two new address properties, broadcast[2] and deprecated[2] were added * 'xmit' address property was renamed to 'transmit' * 'reasm-timeout' interface property was removed * 'rtexchg' interface property was renamed to 'exchange_routes' 1.6 No need for /sbin/netstart binary -------------------------------------- PSARC 2009/306 proposed using /sbin/netstart to restore persistent protocol tunables during boot. This process would be started by init(1M), by reading /etc/inittab, before svc.startd(1M) comes up. The initial idea was to restore settings close to the execution of `soconfig(1M)' (soconfig(1M) maps sockets to service providers and networking applications are useless without the execution of soconfig(1M)) However, modifying /etc/inittab in the post-SMF world was something that was not well received and also with IPS obsoleting SVR4 post-install scripts, modifying /etc/inittab during the upgrade path was not possible. Therefore, we will now restore the persistent protocol tunables from a SMF script that starts the `ipmgmtd' daemon. Further `ipmgmtd' daemon is one of the first networking services to come up and it comes up even before network/loopback. That way the protocol properties would be re-instantiated before any of the IP interfaces are plumbed and before any of the networking applications starts. 1.7 non-contiguous netmask support removed ------------------------------------------ Non-contiguous netmasks are a relic of yesteryear architectures for which we still retain support in the kernel today, and which create more complications than they solve. Very few customers use these today, and when used, they only create confusion. This is a hindrance for this project, which strives for an API where addresses are input and displayed in the "address/prefixlen" CIDR format. Thus, even if ipadm itself will not allow non-contiguous netmasks, if ifconfig is used to add non-contiguous netmask, ipadm would be forced to either lie about the mask or otherwise mangle its output format to display it. Therefore, this project will be adding checks in the kernel to prevent such netmasks from being created. 1.8 Obsoleting routeadm(1M) forwarding interface ------------------------------------------------ The routeadm(1M) command is used to administer system-wide configuration for IP forwarding and routing. It currently uses ndd(1M) to enable IP forwarding. Since ndd(1M) does not provide persistence, the persistence is achieved using a SMF service, for ipv4 it is svc:/network/ipv4-forwarding:default and for ipv6 it is svc:/network/ipv6-forwarding:default. The whole purpose of this service, when enabled, is to execute `ndd -set /dev/ip ip_forwarding [0|1]`, in short provide persistence. The ipadm(1M) command, which provides persistence and allows setting of forwarding (ipadm set-prop -p forwarding=[on|off] ipv[4|6]) is an obvious fit for this feature. So this project will mark routeadm(1M) interfaces to enable/disable IPv4/IPv6 forwarding 'Obsolete' and will eventually EOF that feature. We have updated the routeadm(1M)[3] man page to reflect the same. Until that point in time, when both the tools continue to exist, we will modify the SMF script (/lib/svc/method/svc-forwarding) to invoke ipadm(1M). So that both routeadm(1M) and ipadm(1M) will be modifying the same repository and hence will have the same view. 2. References (enclosed in case directory) ========================================== [1] "Brussels II design document - brussels2_design.pdf [2] ipadm MAN page - ipadm.1m.txt [3] routeadm.1m.txt.diffs From gdamore@SUN.COM Wed Mar 3 09:22:47 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o23HMlqb028728 for ; Wed, 3 Mar 2010 09:22:47 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o23HMfgG020436 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 3 Mar 2010 11:22:46 -0600 (CST) 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 <0KYP007PQUXXHB60@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 03 Mar 2010 10:22:45 -0700 (MST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KYP008IMUGZ1R40@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 03 Mar 2010 10:12:35 -0700 (MST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o23HCYxk011360 for ; Wed, 03 Mar 2010 09:12:35 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KYP00C00UE69E00@fe-sfbay-10.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 03 Mar 2010 09:12:34 -0800 (PST) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KYP0084KUGJM210@fe-sfbay-10.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 03 Mar 2010 09:12:20 -0800 (PST) Date: Wed, 03 Mar 2010 09:12:18 -0800 From: "Garrett D'Amore" Subject: Re: Brussels II addendum [PSARC/2010/080 FastTrack timeout 03/09/2010] In-reply-to: <4B8D9CB6.8010700@sun.com> Sender: Garrett.Damore@SUN.COM To: Sebastien Roy Cc: psarc-ext@SUN.COM, Girish.Moodalbail@SUN.COM Message-id: <4B8E9872.1000008@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4B8D9CB6.8010700@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.5) Gecko/20100117 Lightning/1.0b1 Thunderbird/3.0 Status: RO Content-Length: 1101 On 03/ 2/10 03:18 PM, Sebastien Roy wrote: > > > 1.7 non-contiguous netmask support removed > ------------------------------------------ > > Non-contiguous netmasks are a relic of yesteryear architectures for > which we still retain support in the kernel today, and which create > more complications than they solve. Very few customers use these > today, and when used, they only create confusion. > > This is a hindrance for this project, which strives for an API where > addresses are input and displayed in the "address/prefixlen" CIDR > format. Thus, even if ipadm itself will not allow non-contiguous > netmasks, if ifconfig is used to add non-contiguous netmask, ipadm > would be forced to either lie about the mask or otherwise mangle its > output format to display it. > > Therefore, this project will be adding checks in the kernel to prevent > such netmasks from being created. > What is a non-contiguous netmask? Is this a mask where there are 0 bits between 1 bits, e.g. 255.0.255.0? (That would be an incredibly dangerous, and probably not useful, kind of setting.) - Garrett From Girish.Moodalbail@sun.com Wed Mar 3 09:35:19 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o23HZJcB029088 for ; Wed, 3 Mar 2010 09:35:19 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o23HZE7M006818 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 3 Mar 2010 11:35:19 -0600 (CST) 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 <0KYP0011VVIU8400@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 03 Mar 2010 09:35:18 -0800 (PST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KYP00M3AVIUIOC0@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 03 Mar 2010 09:35:18 -0800 (PST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o23HZHAa027480 for ; Wed, 03 Mar 2010 17:35:17 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KYP00I00URFQ300@mail-amer.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 03 Mar 2010 10:35:17 -0700 (MST) Received: from [129.148.174.49] ([unknown] [129.148.174.49]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KYP001Y7VIN3U70@mail-amer.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 03 Mar 2010 10:35:12 -0700 (MST) Date: Wed, 03 Mar 2010 12:28:05 -0500 From: Girish Moodalbail Subject: Re: Brussels II addendum [PSARC/2010/080 FastTrack timeout 03/09/2010] In-reply-to: <4B8E9872.1000008@sun.com> Sender: Girish.Moodalbail@sun.com To: "Garrett D'Amore" Cc: Sebastien Roy , psarc-ext@sun.com Reply-to: Girish.Moodalbail@sun.com Message-id: <4B8E9C25.2070100@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4B8D9CB6.8010700@sun.com> <4B8E9872.1000008@sun.com> User-Agent: Thunderbird 2.0.0.17 (X11/20081023) Status: RO Content-Length: 1261 On 03/03/10 12:12, Garrett D'Amore wrote: > On 03/ 2/10 03:18 PM, Sebastien Roy wrote: >> >> >> 1.7 non-contiguous netmask support removed >> ------------------------------------------ >> >> Non-contiguous netmasks are a relic of yesteryear architectures for >> which we still retain support in the kernel today, and which create >> more complications than they solve. Very few customers use these >> today, and when used, they only create confusion. >> >> This is a hindrance for this project, which strives for an API where >> addresses are input and displayed in the "address/prefixlen" CIDR >> format. Thus, even if ipadm itself will not allow non-contiguous >> netmasks, if ifconfig is used to add non-contiguous netmask, ipadm >> would be forced to either lie about the mask or otherwise mangle its >> output format to display it. >> >> Therefore, this project will be adding checks in the kernel to prevent >> such netmasks from being created. >> > > What is a non-contiguous netmask? Is this a mask where there are 0 bits > between 1 bits, e.g. 255.0.255.0? That is correct. > (That would be an incredibly > dangerous, and probably not useful, kind of setting.) Yes and that is why we want to prevent such setting going forward thanks ~Girish From carlsonj@workingcode.com Thu Mar 4 13:45:22 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o24LjM6D021162 for ; Thu, 4 Mar 2010 13:45:22 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o24LjDoe022051; Thu, 4 Mar 2010 15:45:18 -0600 (CST) 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 <0KYS00C011RHTL00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 04 Mar 2010 13:45:17 -0800 (PST) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KYS00MJT1RHR1E0@nwk-avmta-1.sfbay.Sun.COM>; Thu, 04 Mar 2010 13:45:17 -0800 (PST) Received: from relay11i.sun.com (ip121.net129179-4.block1.us.syntegra.com [129.179.4.121]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o24Lf32L012288; Thu, 04 Mar 2010 21:45:17 +0000 (GMT) Received: from mmp14es.mmp.us.syntegra.com ([160.41.208.14] [160.41.208.14]) by relay11i.sun.com with ESMTP id BT-MMP-787797; Thu, 04 Mar 2010 21:45:16 +0000 (Z) Received: from relay14i.sun.com (relay14i.sun.com [129.179.4.124]) by mmp14es.mmp.us.syntegra.com with ESMTP id BT-MMP-61227; Thu, 04 Mar 2010 21:45:16 +0000 (Z) Received: from carlson.workingcode.com ([75.150.68.97] [75.150.68.97]) by relay1i.sun.com with ESMTP id BT-MMP-7678187; Thu, 04 Mar 2010 21:45:16 +0000 (Z) Received: from [10.50.23.149] (gate.abinitio.com [65.170.40.132]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.3) with ESMTP id o24LjEi7000384 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 04 Mar 2010 16:45:15 -0500 (EST) Date: Thu, 04 Mar 2010 16:45:14 -0500 From: James Carlson Subject: Re: Brussels II addendum [PSARC/2010/080 FastTrack timeout 03/09/2010] In-reply-to: <4B8E9C25.2070100@Sun.COM> To: Girish.Moodalbail@sun.com Cc: "Garrett D'Amore" , psarc-ext@sun.com Message-id: <4B9029EA.8030409@workingcode.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-DCC-dmv.com-Metrics: carlson; whitelist X-Antispam: No, score=0.0/5.0, scanned in 0.239sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <4B8D9CB6.8010700@sun.com> <4B8E9872.1000008@sun.com> <4B8E9C25.2070100@Sun.COM> User-Agent: Thunderbird 2.0.0.22 (X11/20090605) Status: RO Content-Length: 729 Girish Moodalbail wrote: > On 03/03/10 12:12, Garrett D'Amore wrote: >> (That would be an incredibly dangerous, and probably not useful, kind >> of setting.) > > Yes and that is why we want to prevent such setting going forward At least historically, there have been people who do configure things this way. You're right that it's dangerous and technically not useful at all, but it's not unknown. (And I think that the sort of confusion that leads to this sort of configuration also causes a failure to understand why it's not useful. :-/) Except for possibly blowing those folks (deservedly) out of the water, I think it's a very good change. -- James Carlson 42.703N 71.076W From Sebastien.Roy@sun.com Thu Mar 11 06:31:01 2010 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 o2BEV1LV012212 for ; Thu, 11 Mar 2010 06:31:01 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o2BEUvZo054117 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Thu, 11 Mar 2010 07:31:01 -0700 (MST) 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 <0KZ400I4PGBOM100@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 11 Mar 2010 06:31:00 -0800 (PST) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KZ40047KGBLBUD0@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 11 Mar 2010 06:30:57 -0800 (PST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o2BEUutN021254 for ; Thu, 11 Mar 2010 14:30:56 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KZ400J00FSZVH00@mail-amer.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 11 Mar 2010 07:30:56 -0700 (MST) Received: from [129.148.174.103] ([unknown] [129.148.174.103]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KZ400D3RGBDQF50@mail-amer.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 11 Mar 2010 07:30:50 -0700 (MST) Date: Thu, 11 Mar 2010 09:28:03 -0500 From: Sebastien Roy Subject: Re: Brussels II addendum [PSARC/2010/080 FastTrack timeout 03/09/2010] In-reply-to: <4B8D9CB6.8010700@sun.com> Sender: Sebastien.Roy@sun.com To: Sebastien Roy Cc: psarc-ext@sun.com, Girish.Moodalbail@sun.com Message-id: <4B98FDF3.5020807@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4B8D9CB6.8010700@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Lightning/1.0b1 Thunderbird/3.0.1 Status: RO Content-Length: 288 On 03/ 2/10 06:18 PM, Sebastien Roy wrote: > I'm submitting the following fast-track for Girish Moodalbail, the timer > is set for 03/09/2010. This case depends on PSARC 2009/306, the release > binding is Minor. I've extended the timer for this case to 03/12/2010. Please review. -Seb From gdamore@sun.com Fri Mar 12 08:25:56 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o2CGPusE029779 for ; Fri, 12 Mar 2010 08:25:56 -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.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o2CGPtba014251 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Fri, 12 Mar 2010 08:25:56 -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 <0KZ600I0VGB50A00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 12 Mar 2010 09:25:53 -0700 (MST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KZ6008VHGB35Y70@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 12 Mar 2010 09:25:51 -0700 (MST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o2CGPpxa011945 for ; Fri, 12 Mar 2010 08:25:51 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KZ600H00G4COA00@fe-sfbay-09.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 12 Mar 2010 08:25:51 -0800 (PST) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KZ600918GB2QH90@fe-sfbay-09.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 12 Mar 2010 08:25:51 -0800 (PST) Date: Fri, 12 Mar 2010 08:25:50 -0800 From: "Garrett D'Amore" Subject: Re: Brussels II addendum [PSARC/2010/080 FastTrack timeout 03/09/2010] In-reply-to: <4B8D9CB6.8010700@sun.com> Sender: Garrett.Damore@sun.com To: Sebastien Roy Cc: psarc-ext@sun.com, Girish.Moodalbail@sun.com Message-id: <4B9A6B0E.4000802@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4B8D9CB6.8010700@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100131 Lightning/1.0b1 Thunderbird/3.0.1 Status: RO Content-Length: 8963 On 03/ 2/10 03:18 PM, Sebastien Roy wrote: > I'm submitting the following fast-track for Girish Moodalbail, the > timer is set for 03/09/2010. This case depends on PSARC 2009/306, the > release binding is Minor. I've finally reviewed the case materials -- I wish I had paid more attention to 2009/306, but my mind was occupied with other things at the time. (Its not that I had any specific objections, there were just some surprises here for me -- like the fact that apparently ipadm can only create or destroy both v4 and v6 interfaces at the same time.) Anyway, this addendum looks fairly straight-forward. +1. - Garrett > > 1. Introduction: > ================ > > In the course of completing the implementation of Brussels II - ipadm > and libipadm (PSARC 2009/306), few interface changes were made. They > are all documented below. > > 1.1 Following new interfaces were added since PSARC 2009/306. > ------------------------------------------------------------- > ------------------------------------------------------------------------------ > > Interface Classification Comments > ------------------------------------------------------------------------------ > > ipadm down-addr Committed See section 5.6 of [1] > ipadm up-addr Committed See section 5.7 of [1] > ipadm reset-addrprop Committed See section 5.8 of [1] > ipadm disable-if Committed See section 6.0 of [1] > ipadm enable-if Committed See section 6.0 of [1] > ipadm disable-addr Committed See section 6.0 of [1] > ipadm enable-addr Committed See section 6.0 of [1] > > SIOCGLIFDADSTATE Consolidation > Private See section 5.2 of [1] > > SIOCSLIFPREFIX Consolidation > Private See section 5.1.2 of [1] > > IFF_NOLINKLOCAL Consolidation > Private See section 4.1 of [1] > > 1.2 updates to 'show-if', 'show-addr', 'show-[if|addr]prop' parsable > output > --------------------------------------------------------------------------- > > > * '-P' option has been removed from all of the 'show-*' > subcommands. All the 'show-*' subcommands will always show both > CURRENT and PERSISTENT values. > > 1.2.1 updates to 'show-if' parsable output > ------------------------------------------ > [For more details, see section 4.3 of [1] and 'ipadm show-if' in [2]] > > * MTU,FLAGS column has been removed > * CURRENT and PERSISTENT column, which represents both current and > persistent flags are added. > > 1.2.2 updates to 'show-addr' parsable output > -------------------------------------------- > [For more details, see section 5.2 of [1] and 'ipadm show-addr' in [2]] > > * Following column headers are renamed: > ** s/OBJECT/ADDROBJ/ > ** s/ORIGIN/TYPE/ > * FLAGS column has been removed > * Following changes are made to STATE column > ** 'invalid' is renamed to 'down' > ** 'unknown' and 'preferred' state is removed > ** 'disabled' state is added. > * New CURRENT and PERSISTENT columns, which represents current and > persistent flags respectively are added. > > 1.3 updates to subcommand options > ---------------------------------- > [Refer to ipadm man page [2] for more details] > > * 'create-if' subcommand will not take '-f inet|inet6' option > * 'delete-if' subcommand will not take '-t' or '-f inet|inet6' > option > * 'create-addr -T addrconf' takes '-i' option instead of '-I' > * 'create-addr -T dhcp' will not take '-p' option > * 'refresh-addr' will take -i option to perform DHCP inform. > * 'delete-addr' will not take '-t' option > * 'set-ifprop' and 'reset-ifprop' will not take '-f inet|inet6' > option instead they take '-m protocol' option > > 1.4 Reduced set of ndd IP/TCP/UDP/SCTP/ICMP tunables > ---------------------------------------------------- > > The number of protocol tunables that will be made public or Committed > has been substantially reduced. The basic premise is to design a > framework that provides persistence of protocol settings and > improvement over the current ndd(1M). Once we have this framework, > more and more tunables can be Committed through PSARC, after > sufficient scrutiny. Following table lists the protocol properties > that will be Committed. > > ------------------------------------------------------------------------------ > > Properties Protocol(s) Classification Comments > ------------------------------------------------------------------------------ > > > forwarding ipv4, ipv6 Committed See [2] > ttl ipv4 Committed See [2] > hoplimit ipv6 Committed See [2] > > > ecn tcp Committed See [2] > sack tcp Committed See [2] > > recv_maxbuf > send_maxbuf tcp, udp, sctp > icmp Committed See [2] > > extra_priv_ports > largest_anon_port > smallest_anon_port > smallest_nonpriv_port tcp, udp, sctp Committed See [2] > > 1.5 Modifications to address and interface properties > ----------------------------------------------------- > > * Two new address properties, broadcast[2] and deprecated[2] were > added > * 'xmit' address property was renamed to 'transmit' > * 'reasm-timeout' interface property was removed > * 'rtexchg' interface property was renamed to 'exchange_routes' > > 1.6 No need for /sbin/netstart binary > -------------------------------------- > > PSARC 2009/306 proposed using /sbin/netstart to restore persistent > protocol tunables during boot. This process would be started by > init(1M), by reading /etc/inittab, before svc.startd(1M) comes up. The > initial idea was to restore settings close to the execution of > `soconfig(1M)' (soconfig(1M) maps sockets to service providers and > networking applications are useless without the execution of > soconfig(1M)) > > However, modifying /etc/inittab in the post-SMF world was something > that was not well received and also with IPS obsoleting SVR4 > post-install scripts, modifying /etc/inittab during the upgrade path > was not possible. Therefore, we will now restore the persistent > protocol tunables from a SMF script that starts the `ipmgmtd' > daemon. Further `ipmgmtd' daemon is one of the first networking > services to come up and it comes up even before network/loopback. That > way the protocol properties would be re-instantiated before any of the > IP interfaces are plumbed and before any of the networking > applications starts. > > 1.7 non-contiguous netmask support removed > ------------------------------------------ > > Non-contiguous netmasks are a relic of yesteryear architectures for > which we still retain support in the kernel today, and which create > more complications than they solve. Very few customers use these > today, and when used, they only create confusion. > > This is a hindrance for this project, which strives for an API where > addresses are input and displayed in the "address/prefixlen" CIDR > format. Thus, even if ipadm itself will not allow non-contiguous > netmasks, if ifconfig is used to add non-contiguous netmask, ipadm > would be forced to either lie about the mask or otherwise mangle its > output format to display it. > > Therefore, this project will be adding checks in the kernel to prevent > such netmasks from being created. > > 1.8 Obsoleting routeadm(1M) forwarding interface > ------------------------------------------------ > > The routeadm(1M) command is used to administer system-wide > configuration for IP forwarding and routing. It currently uses ndd(1M) > to enable IP forwarding. Since ndd(1M) does not provide persistence, > the persistence is achieved using a SMF service, for ipv4 it is > svc:/network/ipv4-forwarding:default and for ipv6 it is > svc:/network/ipv6-forwarding:default. The whole purpose of this > service, when enabled, is to execute `ndd -set /dev/ip ip_forwarding > [0|1]`, in short provide persistence. > > The ipadm(1M) command, which provides persistence and allows setting > of forwarding (ipadm set-prop -p forwarding=[on|off] ipv[4|6]) is an > obvious fit for this feature. So this project will mark routeadm(1M) > interfaces to enable/disable IPv4/IPv6 forwarding 'Obsolete' and will > eventually EOF that feature. We have updated the routeadm(1M)[3] man > page to reflect the same. Until that point in time, when both the > tools continue to exist, we will modify the SMF script > (/lib/svc/method/svc-forwarding) to invoke ipadm(1M). So that both > routeadm(1M) and ipadm(1M) will be modifying the same repository and > hence will have the same view. > > 2. References (enclosed in case directory) > ========================================== > [1] "Brussels II design document - brussels2_design.pdf > [2] ipadm MAN page - ipadm.1m.txt > [3] routeadm.1m.txt.diffs From sebastien.roy@oracle.com Tue Mar 16 08:14:42 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o2GFEgIw027110 for ; Tue, 16 Mar 2010 08:14:42 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o2GFEf4s021777; Tue, 16 Mar 2010 08:14:41 -0700 (PDT) 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 <0KZD0081HROF6000@nwk-avmta-1.sfbay.Sun.COM>; Tue, 16 Mar 2010 08:14:39 -0700 (PDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KZD00F6CROEOPF0@nwk-avmta-1.sfbay.Sun.COM>; Tue, 16 Mar 2010 08:14:38 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o2GFEcBD023532; Tue, 16 Mar 2010 15:14:38 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o2GEv1Ud022818; Tue, 16 Mar 2010 15:14:37 +0000 (GMT) Received: from abhmt018.oracle.com by acsmt353.oracle.com with ESMTP id 89608321268752417; Tue, 16 Mar 2010 08:13:37 -0700 Received: from [129.148.174.103] (/129.148.174.103) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 16 Mar 2010 08:13:36 -0700 Date: Tue, 16 Mar 2010 11:10:44 -0400 From: Sebastien Roy Subject: Re: Brussels II addendum [PSARC/2010/080 FastTrack timeout 03/09/2010] In-reply-to: <4B9A6B0E.4000802@sun.com> To: "Garrett D'Amore" Cc: psarc-ext@sun.com, Girish.Moodalbail@sun.com Message-id: <4B9F9F74.5000201@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090207.4B9FA05D.00F9:SCFMA4539814,ss=1,fgs=0 References: <4B8D9CB6.8010700@sun.com> <4B9A6B0E.4000802@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Lightning/1.0b1 Thunderbird/3.0.1 Status: RO Content-Length: 122 On 03/12/10 11:25 AM, Garrett D'Amore wrote: > +1. > The timer for this case has expired with a +1. It is approved. Seb