Hi Xiang, Thanks for making the changes.
On Fri, 2009-04-24 at 15:18 +0800, Xiang Zhou wrote: > On 04/15/09 01:34, Sebastien Roy wrote: > > * admin-dladm/create-iptun/test14 > > > > This assertion is now obsolete as the type is mandatory. > > > Right, but I'd like to keep it for creating iptun using hostnames. Okay. > > * delete-iptun/test04 > > > > A test04 should be added to verify that delete-iptun fails if an IP > > interface is plumbed on the tunnel. > > > Plumbed iptun deletion failure is verified in > admin-dladm/delete-iptun/test03. Ah, okay. > > * admin-ifconfig/test08 > > > > I'm not convinced that this is the correct behavior. I know that this > > assertion currently fails, but I'm not sure that fixing it is the > > correct thing to do. If there's an old /etc/hostname.<tunnel> file with > > stale configuration, overriding that configuration with dladm masks the > > fact that there is stale configuration around that may unexpectedly take > > effect if the "dladm" tunnel link is ever deleted or renamed. I'm > > tempted to flip this one on its head and make the design (and this > > assertion) adhere to the current implementation. > > > You mean this assertion should be described like this: "The permenant > configuration (i.e. dladm(1M) command line parameters) *doesn't* > overrides contents in /etc/hostname*.ip*.tun*."? Is current > implementation ok when iptun integrated? Exactly, yes. This way, stale and conflicting configuration information in hostname.* files will be obvious and it will give administrators a chance to clean that up immediately before it bites them. > > * functional/test02 > > > > I'm glad this assertion is here. MTU calculation is by far the most > > complicated aspect of IP tunneling. > > > > In general, there also seem to be MTU-related tests further down in this > > category (test07 and test08). It might make sense to create a > > subsection named "functional/mtu" and place these three tests in there. > > > Well, I broke functional tests into 3 categories: basic, 6to4 and mtu. Okay. > > * functional/test03 > > > > I'd suggest breaking down the functional category further, placing 6to4 > > functional tests into their own subcategory (functional/6to4). There > > are a lot of potential tests related to 6to4 that could be added, and > > they could clutter the functional category. For example, here are a few > > security-related tests that would be very valuable: > > > > - When receiving a tunneled packet, if the IPv6 destination isn't in > > the site, then the packet is dropped. > > > I'd like to know how to verify the packet is dropped? From user space > point of view, ping will give "100% loss" at stdout when sending icmp > request, would it be ok to verify that the packet is dropped? Certainly, not receiving a reply from ping is important. In addition to that, you could verify that the ierrors kstat gets bumped for the tunneling interface. > > - When receiving a tunneled packet, if the IPv4 source and embedded > > IPv4 address in the 6to4 IPv6 source don't match, then the packet is > > dropped. > > > > - Only accept packets from a relay router (IPv6 source isn't 6to4) if > > we've configured a relay router. > > > > - Don't tunnel packets with non-6to4 source addresses (we don't > > implement relay router functionality). > > > > - Don't tunnel a packet if the embedded IPv4 address in the IPv6 > > source doesn't match the IPv4 tunnel address. > > > > - Nothing bad happens (the packet is dropped) when sending to a global > > destination and a relay router hasn't been configured. > > > Fine, I am considering the strategy on how to implement these > assertions. I will add these 6to4 tunnel test cases. I've tried to answer your related questions in the private message you sent me. Let me know if these make more sense now. > > > > * functional/test07 > > > > The strategy should say that Host A's routing table results in packets > > being transmitted to Host B via tun1, and that Host B's routing table > > results in packets being transmitted to Host A via tun2. In other > > words, packets that Host A sends go through tun1, and Host B attempts to > > forward them through tun2, but can't because tun2's MTU is too small > > (correct?). > > > Right, but we need only configure route table on Host A, for Host B will > auto-forward the packet though tun2 because creation of tun2 will auto > add the entry to route table. Okay. > > The verification step should ensure that the MTU value in the ICMP > > packet-too-bit message is correct. > > > > This test has four variants: ipv4-over ipv6, ipv6-over-ipv6, > > ipv4-over-ipv4, and ipv6-over-ipv4. Each of these cases needs to be > > tested. In the ipv6-over-<foo> cases, you're looking at ICMPv6 > > packet-too-big messages. In the ipv4-over-<foo> cases, you're looking > > at ICMPv4 fragmentation-needed messages. > > > Make sense. I'll apply the test to ipv[4|6]-over-ipv[4|6] tunnels. Excellent. Thanks, and good work. -Seb
