Re: CALL FOR DISCUSSION: DHCP over IKE vs Configuration Payload

[Michael Thomas <mat@cisco.com>]

Charlie_Kaufman@notesdev.ibm.com writes:
 > While it's attractive to reference DHCP rather than define a subset of it
 > in order to shorten the spec, Tero's drafts make it clear that using DHCP
 > won't shorten the spec because of the integration issues that would need to
 > be added. DHCP was designed to run over an unreliable datagram protocol
 > with broadcast capabilities for server discovery. IKE is a reliable
 > request/response protocol to a single peer. So running DHCP over IKE
 > requires that we specify how DHCP timeouts get handled and how to deal with
 > the case where the responder has a packet but it's not his turn to talk.
 > Tero's proposal describes how to deal with all these cases, but it's
 > awkward.

Charlie,

Neither of these seems like a big deal to me. In
fact, knowing the destination of the relay
*constrains* the problem space, not the other way
around. Also: many protocols which have both a
reliable and unreliable transport face these same
questions (DNS, SIP...), so the how-to doesn't
seem too hard to overcome.

 > So I continue to "not get it" in trying to understand the advantages of
 > DHCP. Do we envision using the advanced capabilities of DHCP to do things
 > like booting over the IPsec connection? If so, encapsulating all the
 > messages in IKE seems even more cumbersome. I would think the boot rom
 > would want to set up the IPsec connection, get an IP address, and then run
 > DHCP over ESP.


Well, there's that too, but I get the impression
that config-over-IKE is pretty well ingrained so
trying to excise that mindset at this point is
pretty hopeless. Thus to my mind, lesser of evils
is to beg, borrow and steal and punt as much work
as possible to other wg's that actually care about
this sort of thing...

	  Mike