a few comments / questions.
- this bit seems odd to me:
---8<---
... Note that IPv4
and IPv6 are considered as independent resources, so that
specification of an IPv4 address via zonecfg(1m) does not place any
constraints on permissible IPv6 addresses, and vice-versa.
---8<---
ipv4 and ipv6 addresses are considered independent resources from a
zonecfg(1m) perspective, but from a systems management perspective
they don't seem that different to me. to me, it seems that once an
admin decides to restrict what addresses can be used on a given
interface, that restriction should apply to both ipv4 and ipv6
addresses. for example, with the current mechanism, if an admin want
to prevent the zone from configuring any ipv6 address, how do they go
about doing this?
- does the existence of a zonecfg(1m) defrouter property on an interface
prevent a zone from changing the default router for that given
interface? if so, will that change persist across reboots?
- does the existence of a zonecfg(1m) defrouter property on an interface
prevent a zone from adding additional routes on a given interface?
- can exclusive stack zones manipulate arp tables? if so, does use of
the zonecfg(1m) defrouter property restrict arp table manipulation in
any way? (i'm wondering if arp table manipulation could be used to
step around any potential routing limitations placed on an interface.)
- can exclusive stack zones manipulate mac addresses on network
interfaces? if so, does the use of the zonecfg(1m) address property
restrict this in any way?
- the currently proposed DHCP time-out failure isn't that great. is
there a way to improve this failure? say by returning EPERM for
whatever operation it is that's used to initiate DHCP configuration on
an interface. if not it isn't that big of an issue, but as long as we
know we're going to fail it's usually nicer not to keep the user
waiting... ;)
ed
On Wed, May 12, 2010 at 12:56:06PM -0700, Sebastien Roy wrote:
> I'm submitting this fast-track for Sowmini Varadhan. The release
> binding is Minor and new zonecfg(1M) properties are Committed.
>
> Summary:
> -------
> This case proposes a solution for
>
> 6944327 need to support address and defrouter resources for
> exclusive-IP zones
>
> Problem Description
> --------------------
>
> Typical zone deployments that exist today use shared-IP zones to run
> applications and services like Apache or Weblogic in the contained
> environment provided by the shared-IP zone. In these use-cases, the
> Administrator in the global zone has full control over the networking
> resources used by the non-global zone. In the common case, networking
> is simply configured by specifying the IP interface, IP addresses and,
> optionally, the default routers from zonecfg(1m). The configuration
> resources thus supplied are then applied for the non-global zone when
> it is booted, and the non-global zone itself may not modify any of
> these configuration parameters.
>
> However, there is no such simple configuration mechanism for the
> simple networking use-case in place for exclusive IP zones, which must
> be configured through sysidcfg, ifconfig, and an assortment of other
> methods, all of which are not controllable from the global zone, and
> may not be managed through zonecfg(1m).
>
> The addition of many new virtualization and resource management
> features to Solaris (PSARC 2006/357, PSARC 2005/132 and associated
> cases) makes Exclusive-IP zones a cleaner and more powerful Zone model
> than shared-IP zones. Thus, bridging any gaps in the configuration
> methods for the simple use cases between shared- and exlusive-IP zones
> is important to ease the transition of shared-IP customer
> configurations to exclusive-IP.
>
> In addition, there are many ongoing projects in the "Zones Networking"
> effort [ZONES-NET] to facilitate the consolidation of existing Solaris
> 10 host installations as Solaris 10 Containers. These efforts would
> leverage from the ability to specify networking resource values for
> address and default router uniformly for zones using zonecfg(1m).
>
> This case proposes support in zonecfg(1m) for 'address' and
> 'defrouter' properties in the 'net' resource for exclusive-IP zones.
> The semantics of the values will be the same as with the shared-IP
> zone definitions that exist today ([PSARC/2002/174], [PSARC/2003/621],
> [PSARC/2008/057])
>
> When the global-zone specifies the 'address' for an interface via
> zonecfg(1m), the non-global zone may not use any other addresses for
> the specified IP Version on that interface. The address information
> provided via zonecfg(1m) will be used to set up Layer-3 protection
> [PSARC/2009/436] for the non-global zone during zone-boot to filter
> out all other addresses for the selected interface. For instance,
> when zonecfg(1m) has been used in the global-zone to set one or more
> IPv4 addresses on an interface, an attempt to set an IPv4 address on
> the interface that is outside the globally defined set will encounter
> the EPERM failure. Thus ifconfig(1m), ipadm(1m), and associated
> ioctls will receive this error if they are used within the non-global
> zone to set addresses that are not in the set that is permitted from
> the global-zone, and attempts by the non-global zone to turn on
> forwarding on the interface will also encounter EPERM. Note that IPv4
> and IPv6 are considered as independent resources, so that
> specification of an IPv4 address via zonecfg(1m) does not place any
> constraints on permissible IPv6 addresses, and vice-versa.
>
> Attempts to boot a zone that has already been configured for IP, or
> has previously customized values for Layer-3 protection
> [PSARC/2009/436] will fail.
>
> Implementation Overview:
> ------------------------
> A brief overview of the implementation is provided here. Note that all
> interfaces between zoneadmd(1m) and the kernel/zonecfg(1m), are
> Private interfaces, subject to change in the future.
>
> When the non-global zone is booted, zoneadmd(1m) will store the
> information specified by the 'address' and 'defrouter' properties as
> nvlists in the kernel following a mechanism similar to that in use
> today for other zonecfg(1m) resources such as the "physical"
> datalink. At the same time, the zone boot process will also ensure
> 'ip-nospoof' protection for the datalink with the specified addresses
> used as input to the 'allowed-ips' property. The stored nvlist
> information for 'address' and 'defrouter' will be retrieved and
> re-applied in the non-global zone by the daemon associated with the
> ip-interface-management service before any other IP configuration is
> applied.
>
> The GLDv3 layer communicates the set of "allowed-ips" to the IP layer
> through DLPI notifications. The notification sent is a DL_NOTIFY_IND
> message of (Project Private) type DL_NOTE_ALLOWED_IPS, sent to the IP
> clients that have registered for this notification. The payload of
> the DL_NOTE_ALLOWED_IPS message is the mac_protect_t data-structure
> introduced by PSARC 2009/436. Receipt of this notification enables
> the IP layer to track the current set of permitted IP addresses per
> interface, so that the IP layer can return informative error
> diagnostics if an attempt is made to enable forwarding or set
> addresses on the interface that are outside the permitted set.
>
> All configuration state, including datalink properties like
> protection, allowed-ips and zone, and associated nvlist information,
> that is created during zone boot will be reset to the default values
> when the zone is halted.
>
> Relationship to other configuration mechanisms
> ----------------------------------------------
>
> sysidcfg:
> The Solaris Install team is currently working in conjunction with
> the Network Configuration team [INSTALL] on the implementation of a
> framework to replace sysidcfg(4) that will provide configuration
> profiles to be processed by startup scripts when a system
> boots. However this configuration information is only applied on
> the first boot of the zone, and unlike zonecfg, may not be easily
> modified in the global zone across reboot. Moreover, there is no
> mechanism in place to prevent the non-global zone from modifying
> the configuration provided via profiles.
>
> As mentioned earlier, the global-zone is the authoritative source
> of IP configuration information for the "secure container"
> use-case. This implies that attempts to use boot profiles in the
> non-global zone to add addresses other than those mandated in the
> global-zone will fail with EINVAL erors.
>
> Note that the profiles defined in [INSTALL] may still be applied to
> interfaces for which 'net' resource properties have not been
> defined in the global-zone, i.e., this proposal is fully
> backward-compatible.
>
> svc:/network/physical:{default, nwam}
> Configuration specified via zonecfg(1m) in the global-zone
> overrides any information specified via /etc/hostname.intf,
> ipadm(1m) or nwam. Thus if the IP address information specified by
> these other methods is not a subset of the globally managed
> information, attempts to apply it within the non-global zone will
> encounter an error.
>
> DHCP:
> It is assumed that when IP resources for an IP interface have been
> set up in the global-zone using zonecfg(1m), then that interface
> has been marked for static IP configuration only, and attempts to
> send out outgoing DHCP DISCOVER packets will be dropped in
> GLDv3. Thus attempts to start DHCP on these interfaces in the
> non-global zone will time out.
>
> Examples
> --------
> r...@gz# zonecfg -z tz1
> zonecfg:tz1> info
> zonename: tz1
> zonepath: /rpool/zones/tz1
> brand: ipkg
> autoboot: false
> bootargs:
> pool:
> limitpriv:
> scheduling-class:
> ip-type: exclusive
> hostid:
> net:
> address: 11.1.1.1/24
> physical: vnic0
> defrouter: 11.1.1.2
> net:
> address: taddr2
> physical: vnic0
> defrouter not specified
> net:
> address not specified
> physical: vnic1
> defrouter not specified
>
> In this example, the zone 'tz1' has been assigned 2 interfaces: vnic0
> and vnic1.
>
> The vnic1 interface does not have any IP address or default router
> assigned to it, so that it may be configured in any desired way from
> within the zone using ifconfig(1m), ipadm(1m), NWAM etc.
>
> The vnic0 interface has 2 addresses assigned: 11.1.1.1/24 (with
> default router 11.1.1.2 on the 11.1.1.0/24 subnet) and the address
> 'taddr2' whose numeric value and netmask will be resolved when the
> zone boots. Thus, if, at the time of zone boot, the global-zone is
> also configured as:
>
> r...@gz# egrep 'hosts|netmask' /etc/nsswitch.conf
> hosts: files nis dns
> netmasks: files nis
>
> r...@gz# grep taddr2 /etc/hosts
> 12.2.3.4 taddr2
>
> r...@gz# grep 12 /etc/netmasks
> 12.2.0.0 255.255.0.0
>
> tz1 will be booted as
>
> r...@gz# zoneadm -z tz1 boot
>
> r...@gz# zlogin tz1 ipadm show-addr
> ADDROBJ TYPE STATE ADDR
> vnic0/? static ok 11.1.1.1/24
> vnic0/? static ok 12.2.3.4/16
> lo0/v4 static ok 127.0.0.1/8
> lo0/v6 static ok ::1/128
>
> r...@gz# zlogin tz1 netstat -rn
> Routing Table: IPv4
> Destination Gateway Flags Ref Use
> Interface
> -------------------- -------------------- ----- ----- ----------
> ---------
> default 11.1.1.2 UG 2 2
> vnic0
> 11.1.1.0 11.1.1.1 U 3 2
> vnic0
> 12.2.0.0 12.2.3.4 U 2 0
> vnic0
> 127.0.0.1 127.0.0.1 UH 2 0
> lo0
>
> Routing Table: IPv6
> Destination/Mask Gateway Flags Ref
> Use If
> --------------------------- ---------------------- ----- ---
> ------- -----
> ::1 ::1 UH 2 0
> lo0
>
>
> Proposed man page changes:
> --------------------------
> --- zonecfg.1m.orig Thu Apr 22 11:22:12 2010
> +++ zonecfg.1m.new Thu Apr 22 11:27:48 2010
> @@ -676,8 +676,13 @@
> for the interface should be specified here.
>
> For an exclusive-IP zone, the physical property must be
> - set and the address and default router properties cannot
> - be set.
> + set and the address and default router properties may
> + be set. The interface specifed for the physical property
> + must not be in use in the global zone. If an address and
> + default router are specified via zonecfg(1m), these will be
> + applied to the interface when the non-global zone is booted,
> + and the non-global zone will not be able to apply any other
> + addresses to that interface.
>
> zhadum(866)% diff -wub dladm.1m.txt dladm.1m.txt.new
> --- dladm.1m.txt Mon May 10 15:24:49 2010
> +++ dladm.1m.txt.new Mon May 10 15:28:09 2010
> @@ -4176,7 +4176,17 @@
> option's link layer address must match the
> link's MAC address.
>
> + When a datalink has been protected by setting allowed-ips
> + to a set of one or more IPv4 addresses, any attempts to
> + configure IPv4 addresses that are not in this set will
> + fail with an EPERM error being returned to the user.
> + Moreover, the interface may not be used for forwarding
> + IPv4 packets, and attempts to set the ipadm(1m) forwarding
> + property on the interface will encounter EPERM error.
> + Analogous constraints on address configuration and
> + forwarding settings also apply for IPv6 packets.
>
> +
> dhcp-nospoof
>
> DHCP client ID (DUID for DHCPv6) and hardware
>
>
>
> References:
> ----------
> [PSARC/2002/174] Virtualization and Namespace Isolation in Solaris,
> aka "Zones"
> [PSARC/2003/621] Zone Administration Updates
> [PSARC/2008/057] Default Route For Zones
> [PSARC/2009/436] Anti-spoofing Link Protection
> [INSTALL]
> http://solaris-networking.sfbay/index.php/Network_Configuration:install
> [ZONES-NET] http://solaris-networking.sfbay/index.php/Zones_Networking
_______________________________________________
opensolaris-arc mailing list
[email protected]
