In muc.lists.netbsd.tech.net Hubert Feyrer wrote:

>Initially, you have no address at all.
>Then, you ask for one ip address (via DHCP, autoconfiguration, whatever)
>That's the standard 'laptop' case so far.

>When you want your 'laptop' to become a router all of a sudden, you 
>basically need more address space. I wonder why not just ask for it, as 
>you do in the first case (DHCP, ...), and then advertize it on the 
>"internal" network/interface, and just route it.

You can do that with DHCP prefix delegation - but it requires an
"upstream" router (on the "external" network) that is willing to hand
out prefixes, not just single addresses, and subsequently route them
to you.

I have seen this done on Cisco gear over serial lines (customer site
router requesting prefix for the customer LAN via DHCP prefix delegation),
and I think it should work over Ethernet links as well.

Configuration on the customer router is far from "automatic", though - it
needs to know where to get the "external" prefix from, on which "internal"
network to advertise it (RA) (there might be multiple "internal" networks,
potentially each of them needing a different DHCP prefix), etc.

All of this could be done with a NetBSD router, of course, but not in the
current framework.


Regarding the "router or host" thing: mosts routers are hosts *anyway*
(for management purposes, and if only to ping the router's IP) - the 
difference is "will this box forward packets not for one of it's own
IP addresses?".  

Further, to my knowledge, you can't tell NetBSD "route packets between 
interfaces 3, 4, 5 and do not route packets received on interface 1 and 2", 
at least not without reverting to packet filters.  So the whole idea
"be a router on some interface and a host on others" is sort of missing
the point.

gert
-- 
I've got a signature breakdown! Anybody got a spare one?

Gert Doering - Munich, Germany                             gert@greenie.muc.de
fax: +49-89-3243328                         gert.doering@physik.tu-muenchen.de