Renee Danson wrote:
> We talked about this on nwam-discuss a few months back; that
> discussion resulted in section 4.7 of the design doc
> (opensolaris.org/os/project/nwam/design). The mail threads
> were "NWAM and routing" (started late October) and "routing
> redux" (started early November).
>
> I'm still not entirely comfortable with what we have; and
> this has come up in several recent discussions. Additional
> feedback on the current proposal would be appreciated.
Thanks for the pointer. I finally read most of the document.
Perhaps I've been conflating two very different things that should be
kept separate:
1. Different sources of routes - dhcpagent, routed, etc.
2. punchin creating its own default route as some "overlay".
For #1 I think what is in section 4.7 is sufficient. (It might be nice
if we don't need an extra daemon to handle that, but that is an
optimization.)
The argument for #2 being different is that what punchin (and any
similar VPN solution) wants is to use the underlying routing, static or
dynamic, and just have a tunnel on top. The way we can express this
today is by changing the original default route to be a route solely to
reach the punchin/VPN server, and adding a new default route which sends
all packets over the tunnel.
A different way to think of that case would be to separate the two. For
instance, with IP Instances we could have one zone which is on the
Internet - runs dhcpagent, routing daemons, etc. The routing can change
as it wants. The lower part of the VPN tunnel lives in that IP Instance.
But the upper part of the VPN tunnel is wired into an IP instance that
is inside the VPN. punchin can have a default route in the latter
without any conflict with dhcpagent or a routing daemon changing routing
in the "lower" IP instance.
(In such a model the upper instance could even run a routing protocol
over the tunnel. Might make sense if we have multiple VPN tunnels to
different VPN servers and want to use a routing protocol to failover
between the tunnels!)
Thus I now think we should separate out VPN/punchin routing issues from
the normal management of routing. And the document seems fine on the
latter point.
I had one question on DHCP as I read the document though.
Are we assuming/requiring that the first packet from the DHCP server
(the offer in DHCPv4 - I don't know if the packet is called something
else in DHCPv6) includes the domain name? In order to use the domain
name to determine what to do next we would need this. But are DHCP
servers required to include it in the offer, or can they wait to supply
it until the second packet (the ack in DHCPv4)?
Erik
