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.


Upgrade/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.

Using sysidcfg to control routeadm settings at boot time is
doable, but outside the scope of this project.  The issue is recorded
in this bugtraq entry:

5079745 sysidcfg could contain routeadm(1m) settings