> 
> # time sh -c 'for i in $(jot 100); do ifconfig tun0 create ; ifconfig tun0 destroy ; done'
> 0.012u 0.043s 0:00.25 20.0%     0+0k 0+0io 0pf+0w
> 
> there.  i just bumped it by 100 in a quarter of a second.  by
> extrapolation, that's 65536 in about three minutes.  32 bits would
> take over four months at that rate, but i could easily write a c
> program that just called SIOCIFCREATE and SIOCIFDESTROY repeatedly and
> avoided the fork/exec/parse command line overhead, as well as all the
> other associated system calls.

Once the numbers have wrapped, the kernel has to start doing further
checks to ensure the numbers are unique.  Not to reallocating numbers
immediately stops code doing things to a later incarnation of the same
interface.  (eg if you are writing code that meddles with a big dial-in
RAS server, a modem can get disconnected and reconnected at any moment,
any decisions about the port (including routing rules) then change.)

Whether 16 bits is enough to guarantee a reasonable 'dead' time is
questionable - is it even enough interfaces?
32 bits might wrap - so the kernel must take steps to ensure uniqueness.
64 bits won't wrap.

All this discussion shows that any code that assumes these values are
'small' integers is going to be in serios truoble!

    David