tunnel interface names

[dev at cyphermonks.org]

>> the fact that ssh insists on tap* and tun* tun/tap-device-names is a
>> real nag and prevents from nice and easy solutions in some cases.
> 
> Could you offer some examples?

some client:
ssh -o "Tunnel Ethernet" -w any office

next client:
ssh -o "Tunnel Ethernet" -w any office
...and so forth.

interface configuration on the hub for all clients:
allow-hotplug /tap*=tap
iface tap inet manual
	bridge hub

now some other client needs a specific config on the server or there happens to be something else wanting to use a tap-interface for something else => every single client's interface has to be configured specifically, all interfaces have to be statically assigned to clients, clients have to reserve every single interface they might want to use in advance.

similar can be true for the client side:
ssh -b 1.2.3.4 -w any office
ssh -b 2.3.4.5 -w any office

allow-hotplug /tun*=tun
iface tun inet manual
	up route add default dev "$IFACE"

will also soon have to end up with specific single-interfaces nondynamic config.

imagine mixing this: the office knows several bridges and possibly even other uses of tun/tap. might be the same for clients.
now tun/tap interfaces do not have to be named tun* or tap*. namespaces can be used. so:

clients:
ssh -o "Tunnel Ethernet" -w officebridge1:officebridge1-alice office-hub

on the hub:
allow-hotplug /officebridge1-*=officebridge1-port
iface officebridge1-port inet manual
	 bridge officebridge1

and

client:
ssh -b 1.2.3.4 -w office1:office-alice1 office
ssh -b 2.3.4.5 -w office2:office-alice2 office

allow-hotplug /office*=office
iface office inet manual
	up route add default dev "$IFACE"

and server:
allow-hotplug /office-alice*=office-alice
iface office-alice inet manual
	up route add 3.4.5.0/24 dev "$IFACE"


what is the point of artificially restricting names to just tun\d+ and tap\d+ ?