Re: IKEV2: Issue #3: DHCP vs. Configuration Payload

[Tero Kivinen <kivinen@iki.fi>]

tytso@mit.edu ("Theodore Ts'o") writes:
> Hence, we suggest that as a path forward, that the Configuration payload
> be left in ikev2-04.txt, and that people who believe that a richer
> feature set is necessary should be encouraged to update RFC 3456 for use
> with IKEv2 as an alternative mechanism.  Since an implementation is

I do not really think it is good idea to force everybody to implement
both RFC 3456 and configuration payload. The client will need to
implement both, because if the server replies with empty CFG_REPLY
then it needs to retry with RFC 3456 or similar. 

> allowed to respond with an empty CFG_REPLY packet, this should not prove
> to be an onerous implementation burden for those who are determined to
> only support DHCP 3456-style configuration.  While this could
> potentially cause interoperability problems, the fact that most deployed
> implementations already support modecfg suggests that for the simple
> (common?) case where only a single IP address needs to be returned by
> the IPSEC gateway, it is extremely likely that most VPN-style
> implementations will support the Configuration payload.

Allowing two things to do the same thing is bad. 

How about the mcr's proposal of having dhcp over IKE, i.e take dhcp
payload and put it inside the some IKE payload (we can name it to be
configuration payload, so the configuration payload people will be
happy too, just change the format to follow the dhcp packet). 
-- 
kivinen@ssh.fi
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/