From sacadmin Wed Jul 28 11:38:40 2004 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 28 Jul 2004 14:38:25 -0400 From: James Carlson To: psarc@sac.sfbay.sun.com cc: Sebastien.Roy@Sun.COM Subject: 2004/590 IP Forwarding Default Off Content-Length: 4053 I'm sponsoring this fast-track request for Sebastien Roy. The timer is set to 08/04/2004. The file that's being marked Obsolete is effectively Stable. The behavior that changes (incompatibly) is arguably Evolving, in that we've changed it several recent minor releases. The submitter plans to deal with the notification issue via release notes. A diff-marked routeadm(1M) man page entry is in the case directory as routeadm.1m.txt. Release Binding: Minor Summary: ------- This case fixes the default routeadm(1m) setting for IPv4 and IPv6 forwarding to disabled. This setting is the default setting and can be overridden using the routeadm(1m) command. The setting is independent of all other system configuration including the number of IP interfaces configured on the system. This fast-track addresses the following bug: 4433263 Solaris breaks RFC 1122 by defaulting to gateway mode on multihome systems Details: ------- RFC 1122 Section 3.1 of RFC 1122, "Requirements for Internet Hosts -- Communication Layers", says the following: "An Internet host that includes embedded gateway code MUST have a configuration switch to disable the gateway function, and this switch MUST default to the non-gateway mode. In this mode, a datagram arriving through one interface will not be forwarded to another host or gateway (unless it is source-routed), regardless of whether the host is single- homed or multihomed. The host software MUST NOT automatically move into gateway mode if the host has more than one interface, as the operator of the machine may neither want to provide that service nor be competent to do so." Solaris currently automatically defaults to "gateway mode" when more than one interface is configured, which is exactly what RFC 1122 states MUST NOT be done. The reason given in the RFC for this requirement is also the reason why many customers are negatively impacted by the Solaris behavior. By defaulting to gateway mode, customers' systems automatically start forwarding IP packets and advertising routes when the customer didn't intend to configure the system that way. To quote an internal customer, "We have lost a substantial amount of time and effort in our own in-house labs when machines erroneously decide to be routers because someone forgets /etc/notrouter. This has caused labs and machines to go unavailable and generally causes chaos. Every time someone reinstalls one of these machines, chaos ensues." The solution proposed here is to simply always default to "non-gateway mode" when the customer has not configured the system otherwise. In practice, this means that routeadm's ipv4-forwarding and ipv6-forwarding settings will be disabled out of the box leaving the customer with the responsibility to enable them when intended. A side-effect of this solution is that the /etc/notrouter file becomes obsolete and is no longer used, as routeadm(1m) along with the new system defaults for IPv4 forwarding completely subsumes its functionality. Dynamic Routing Settings This change affects the default values for routeadm(1m)'s ipv4-routing and ipv6-routing, as these settings are currently tied to the forwarding settings. The default setting for ipv4-routing will remain unchanged. As described in routeadm(1m), "IPv4 routing is disabled if /etc/defaultrouter is non-empty, and enabled otherwise." Since the default IPv6 routing daemon (in.ripngd) only functions when IPv6 forwarding is enabled, the default setting for ipv6-routing will now be disabled. It will require explicit enabling. Customer Implications This solution imposes an extra configuration step on customers who install systems intended to have IP forwarding enabled. Prior to this case, forwarding would automatically be enabled with multiple network interfaces were configured. With this case, customers would also need to do the following: # routeadm -e ipv4-forwarding and/or # routeadm -e ipv6-forwarding This would persistently enable IPv4 and/or IPv6 forwarding on the affected system. From sacadmin Wed Jul 28 11:51:48 2004 Subject: Re: 2004/590 IP Forwarding Default Off From: Darren J Moffat To: Sebastien.Roy@Sun.COM Cc: psarc@sac.sfbay.sun.com Content-Type: text/plain Mime-Version: 1.0 Date: Wed, 28 Jul 2004 11:50:27 -0700 Content-Transfer-Encoding: 7bit Content-Length: 580 On Wed, 2004-07-28 at 11:38, James Carlson wrote: > Customer Implications > > This solution imposes an extra configuration step on customers who > install systems intended to have IP forwarding enabled. Prior to this > case, forwarding would automatically be enabled with multiple network > interfaces were configured. With this case, customers would also need > to do the following: What is the impact on upgrade rather than fresh install ? Should there be a sysidcfg entry for setting the behaviour of routing (all of the routeadm policies in fact) ? -- Darren J Moffat From sacadmin Wed Jul 28 12:37:32 2004 Date: Wed, 28 Jul 2004 15:36:28 -0400 From: Sebastien Roy Subject: Re: 2004/590 IP Forwarding Default Off To: Darren J Moffat Cc: psarc@sac.sfbay.sun.com MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 0.6 (X11/20040509) Content-Length: 1463 Darren J Moffat wrote: > >>Customer Implications >> >>This solution imposes an extra configuration step on customers who >>install systems intended to have IP forwarding enabled. Prior to this >>case, forwarding would automatically be enabled with multiple network >>interfaces were configured. With this case, customers would also need >>to do the following: > > > What is the impact on upgrade rather than fresh install ? There is no difference between upgrade and fresh install because the last state of the machine isn't stored anywhere on disk. There is no good way to know if IP forwarding was enabled or disabled when the machine was last running. We could have preserved that setting if there was a way to retrieve it. Unfortunately, it was (in the past) dynamically configured in the inetinit boot script based on potentially transient conditions. One thing we could do would be to see if the system had an /etc/notrouter file, in which case we could assert to a degree of certainty that forwarding was disabled. This could still result in mistakes, however, since customers could have enabled forwarding manually using ndd regardless of what the boot scripts were doing. > > Should there be a sysidcfg entry for setting the behaviour of routing > (all of the routeadm policies in fact) ? That's a good idea, but I think it's somewhat unrelated to this particular case. Would you agree? Would you like me to file an RFE? -Seb From sacadmin Wed Jul 28 13:11:20 2004 Subject: Re: 2004/590 IP Forwarding Default Off From: Darren J Moffat To: Sebastien Roy Cc: psarc@Sun.COM Content-Type: text/plain Mime-Version: 1.0 Date: Wed, 28 Jul 2004 13:10:07 -0700 Content-Transfer-Encoding: 7bit Content-Length: 452 On Wed, 2004-07-28 at 12:36, Sebastien Roy wrote: > There is no difference between upgrade and fresh install because the Good to know. Thanks. > > Should there be a sysidcfg entry for setting the behaviour of routing > > (all of the routeadm policies in fact) ? > > That's a good idea, but I think it's somewhat unrelated to this > particular case. Would you agree? Would you like me to file an RFE? Agreed and yes please. -- Darren J Moffat From sacadmin Wed Jul 28 13:21:13 2004 Date: Wed, 28 Jul 2004 16:20:08 -0400 From: Sebastien Roy Subject: Re: 2004/590 IP Forwarding Default Off To: Darren J Moffat Cc: psarc@sun.com MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 0.6 (X11/20040509) Content-Length: 384 Darren J Moffat wrote: >>>Should there be a sysidcfg entry for setting the behaviour of routing >>>(all of the routeadm policies in fact) ? >> >>That's a good idea, but I think it's somewhat unrelated to this >>particular case. Would you agree? Would you like me to file an RFE? > > Agreed and yes please. Done: 5079745 sysidcfg could contain routeadm(1m) settings Thanks, -Seb From sacadmin Wed Aug 4 10:52:49 2004 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 4 Aug 2004 13:52:25 -0400 From: James Carlson To: psarc@sac.sfbay.sun.com cc: Sebastien.Roy@Sun.COM Subject: 2004/590 IP Forwarding Default Off Content-Length: 379 This fast-track request was approved during ARC business at today's meeting. A final version of the specification is in the case directory as 'spec.txt'. -- James Carlson, IP Systems Group Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From sacadmin Mon Aug 16 05:51:41 2004 Date: Mon, 16 Aug 2004 08:47:28 -0400 From: Sebastien Roy Subject: 2004/590 IP Forwarding Default Off and notrouter(4) manpage To: psarc@sac.sfbay.sun.com MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 0.7.1 (X11/20040630) Content-Length: 482 The subject of creating a notrouter(4) manpage to communicate the obsolecense of the /etc/notrouter file came up on s10-users, and I thought I'd run this by the ARC to see if there are opinions on this. There is currently no notrouter(4) manpage, and this case is making the /etc/notrouter file obsolete. Does anyone have objections to creating this manpage with contents explaining that the file is no longer used with an appropriate pointer to routeadm(1M)? Thanks, -Seb From sacadmin Mon Aug 16 06:03:12 2004 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 16 Aug 2004 09:02:51 -0400 From: James Carlson To: Sebastien Roy Cc: psarc@sac.sfbay.sun.com Subject: Re: 2004/590 IP Forwarding Default Off and notrouter(4) manpage Content-Length: 864 Sebastien Roy writes: > The subject of creating a notrouter(4) manpage to communicate the > obsolecense of the /etc/notrouter file came up on s10-users, and I > thought I'd run this by the ARC to see if there are opinions on this. > > There is currently no notrouter(4) manpage, and this case is making the > /etc/notrouter file obsolete. Does anyone have objections to creating > this manpage with contents explaining that the file is no longer used > with an appropriate pointer to routeadm(1M)? Sounds reasonable to me. ip(7P), defaultrouter(4), and in.routed(1M) all reference that file as well and should probably be updated. -- James Carlson, IP Systems Group Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From sacadmin Mon Aug 16 06:15:46 2004 Date: Mon, 16 Aug 2004 09:11:31 -0400 From: Sebastien Roy Subject: Re: 2004/590 IP Forwarding Default Off and notrouter(4) manpage To: James Carlson Cc: psarc@sac.sfbay.sun.com MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 0.7.1 (X11/20040630) Content-Length: 403 James Carlson wrote: > Sounds reasonable to me. > > ip(7P), defaultrouter(4), and in.routed(1M) all reference that file as > well and should probably be updated. Yes, and the list of man page bugs associated with this case is in the Evaluation section of BugId 4433263. The man pages affected are: routeadm(1M) ip(7P) ip6(7P) ndpd.conf(4) in.routed(1M) defaultrouter(4) and now notrouter(4) -Seb From sacadmin Mon Aug 16 10:35:18 2004 Date: Mon, 16 Aug 2004 07:38:39 -1000 (HST) From: "Joseph E. Kowalski III" Subject: Re: 2004/590 IP Forwarding Default Off and notrouter(4) manpage To: psarc@sac.sfbay.sun.com, Sebastien.Roy@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: YlRDiG7WuEMARCTOhdSSOQ== Content-Length: 611 > The subject of creating a notrouter(4) manpage to communicate the > obsolecense of the /etc/notrouter file came up on s10-users, and I > thought I'd run this by the ARC to see if there are opinions on this. > > There is currently no notrouter(4) manpage, and this case is making the > /etc/notrouter file obsolete. Does anyone have objections to creating > this manpage with contents explaining that the file is no longer used > with an appropriate pointer to routeadm(1M)? I certainly have no objection to this, but my *opinion* is that a NOTE on the routeadm(1M) page would be sufficient. - jek3