> - 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? > - 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. > - 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. > - 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. > - 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. It would be hard to catch all of them because the udp DHCP DISCOVER could be sent in multiple ways (e.g. as a udp packet, via IP_HDRINCL etc.) > 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... ;) --Sowmini _______________________________________________ opensolaris-arc mailing list [email protected]
