amcnabb at mcnabbs.org
Tue Jul 5 15:11:26 MDT 2005
On Tue, Jul 05, 2005 at 02:45:27PM -0600, Hans Fugal wrote:
> Dynamic DNS was one example. Consistent IP assignment as Von explained
> is another. There are many other esoteric DHCP capabilities that can
> be brought to bear as well, but those two are the most useful in my
> experience. In case you or someone else is still confused, here is how
> it works. I plug in my laptop at home and I get a DHCP address, my
> client ID is reported to the DHCP server which then does a little
> dance with BIND and now gandalf.lan resolves to my IP address. That's
> really neat. Consistent IP assignment from the DHCP server is less
> complicated but serves the same function if you can remember that
> gandalf always get 172.17.0.37. (Note, to get this you need to have a
> dhcp client that supports passing client id, or a persistent tap
> interface with a fixed mac address)
Thanks for the clarification on dynamic DNS (from you and Michael). In
the past, I've always done DDNS on the client side.
> > OpenVPN does not emulate DHCP in any way. It gives you a dynamic IP
> > address, but that has nothing to do with DHCP.
> Of course it does. That is DHCPs primary job! 90% of all small DHCP
> setups are for that very reason - give me an IP address automatically.
> Usually nameservers are thrown in there too, but most people ignore the
> other DHCP niceties. In the case that OpenVPN's emulation of "DHCP"
> (automatic network configuration) fits what you need, you don't need
Once again, it comes down to whether you're doing tun or tap. All of
your comments make sense when they apply to tap, but they are impossible
to understand by someone who is thinking in tun mode. With IP over VPN,
my comment about OpenVPN having nothing to do with DHCP still stands.
> My own assumptions are shining through here - DHCP doesn't make sense
> in a tun setup, unless you have openvpn dhcp relay integration that
> doesn't (yet) exist. The limitation of which you speak actually is
> that windows can't do tun natively, so it's all tap underneath. If you
> do tap, windows can do dhcp over openvpn quite happily, and you are
> only using one IP.
> > With an OpenVPN connection, the peers know enough about each other
> > that a start-from-scratch protocol like DHCP is inefficient.
> Yes, but they don't know enough about other things that DHCP is designed
> to know about. If it were just a matter of assigning IP addresses,
> there would be no problem. The issue is that sometimes we want to do
> more, and to do that we need DHCP.
Once again, this is true when you're talking about tap.
> I disagree. DHCP may not at first seem like it fits, it may seem an
> odd choice, but it could be useful. If it seems useful enough to
> someone, that someone will hack OpenVPN to allow it to act as a dhcp
> relay client on behalf of the peer and you will get all of the
> benefits of DHCP without a lot of code. In hindsight, my own opinion
> is that this is how it should have been done to begin with. If the
> openvpn author doesn't believe that, in the end he is going to have to
> write in the ability for openvpn to dole out persistent IP addresses
> like DHCP does because people are always asking for that (or for how
> to use DHCP so they can get that benefit). That would be a crying
> shame, I think, especially when you get all the other DHCP goodies for
> free just by being a dhcp relay client.
It all comes back to what your network architecture is.
In the beginning, I was objecting to the blanket statement that OpenVPN
is duplicating the work of DHCP. You have made it clear, in my opinion,
that this is true in tap (ethernet bridging), but in tun, which works
ideally for my network architecture, DHCP is entirely inappropriate (at
least in this architecture).
Once again, it comes down to using the right tool for the right job.
The main point I would like to leave is that DHCP isn't automatically
the right tool for automatic network configuration in every situation.
In the case of IP tunneling, it is important to remember that setting up
dynamic IP addresses isn't automatically the same thing as setting up a
PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 186 bytes
Desc: not available
Url : http://plug.org/pipermail/plug/attachments/20050705/7819c55e/attachment.bin
More information about the PLUG