On Wed, May 12, 2010 at 07:23:13PM -0700, [email protected] wrote: > > - 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 > > I could go either way on this.. one interpretation of specifying > only ipv4 addresses in zonecfg would be "ipv6-addrs are dont-cares". > Another is that "ipv6-addrs are forbidden". I've somewhat arbitrarily > selected the former interpretation, but could just as easily go with > the latter. > > > 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? > > Currently, none, though the "only ipv4 specified implies ipv6-addrs > are forbidden" approach solves that. In retrospect, that choices > seems simpler and cleaner. Is that preferable? >
i think so. > > - does the existence of a zonecfg(1m) defrouter property on an interface > > prevent a zone from changing the default router for that given > > interface? > > No. > > > - does the existence of a zonecfg(1m) defrouter property on an interface > > prevent a zone from adding additional routes on a given interface? > > No. > > Note that, even though a shared-IP zone cannot add routes today, there's > really nothing that constrains it to using the routes specified in the > routing table- it could easily circumvent the routing table by using > IP source-routes, or by using IP*NEXTHOP or IP*PKTINFO socket options. > So preventing the addition of routes doesn't actually achieve any > limitations. > ok. so this really isn't much of an issue. > > - can exclusive stack zones manipulate arp tables? > yes. > > > > 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.) > > there are many ways to step around routing limitations even with shared-IP > today, so not sure what limitations you have in mind. > Basically, regardless of what the routing table has, a node can always > send a packet to any onlink router. > > If what we want, is to prevent the NGZ from DOSing some router(s), then > bandwidth controls are a more reliable way to achieve that. > this last question only really made since in a context where we might try to restrict the routing configuration in a zone. given that shared stack zones have always had the ability to circumvent any predefined routing configuration i see no reason to need to limit arp table manipulation. > > - can exclusive stack zones manipulate mac addresses on network > > interfaces? > > yes- they can use 'ifconfig .. ether <..>'. > > > if so, does the use of the zonecfg(1m) address property > > restrict this in any way? > > no, it does not - the address property only clamps dow the IP address, > and makes no promises about the mac address associated with the IP address. > given that one of the motivation for this work is to prevent zones from using addresses they shouldn't (and there by being capable of DOS-ing hosts using those addresses) it seems like we should have a zonecfg mechanism that prevents mac address manipulation. i don't know if that should be bundled in with this proposed IP limiting mechanism (ie. if a user specifies an IP address the mac would automatically be locked down) or if there should be a seperate knob to control this. thoughts? ed _______________________________________________ opensolaris-arc mailing list [email protected]
