Darren.Reed at Sun.COM wrote: > If you could connect your laptop to SWAN via both ethernet and > WLAN using punchin, is there any reason why the command to > create tunnel should be any different (aside from the IP addresses)?
No, there wouldn't be. > > Ideally I'd be able to have the same IP address for both the LAN > and WLAN connection (maybe it would be assigned to me by an > 802.1x box) but that's probably wishful thinking. But it would > allow the tunnel to survive while I change from one network > medium to another. Okay. > > The latter is something that's perhaps more easily done at > home, if you have the same box issuing DHCP addresses for > your WLAN as well as LAN, where you might desire to use the > same IP address for both MAC addresses as they belong to > the same laptop. > > I'd almost go so far as to say that having any hard wired > association between a tunnel and a link device, whether it > is in the kernel or supplied by the user, is likely to get > in the way of making things easy to use in the future. But I don't see what this has to do with this discussion... > > Which leads me to wonder if there will be a functionality > regression here by requiring that there be a fixed association > between a link device and a tunnel? There is no such association on the table, and I wouldn't suggest that there be one. The question is whether or not to allow something like: dladm create-iptun -s <src> -d <dst> and have dladm create a tunnel named "ip.tun0" or "ip.tun1" (or whatever unused name it chooses is appropriate), or whether the administrator should be required to type: dladm create-iptun -s <src> -d <dst> <name> ... where <name> is "punchin0" or "mytunnel3", or whatever the administrator wants to name his tunnel. Same question goes for create-vlan. -Seb
