[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IKEV2: Issue #3: DHCP vs. Configuration Payload
- To: ipsec@xxxxxxxxxxxxxxxxx
- Subject: Re: IKEV2: Issue #3: DHCP vs. Configuration Payload
- From: Tero Kivinen <kivinen@xxxxxx>
- Date: 13 Feb 2003 02:34:26 +0200
- In-reply-to: email@example.com's message of "Sat, 8 Feb 2003 04:25:07 +0000 (UTC)"
- Organization: Helsinki University of Technology
- References: <>
- Sender: owner-ipsec@xxxxxxxxxxxxxxxxx
tytso@xxxxxxx ("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).
SSH Communications Security http://www.ssh.fi/
SSH IPSEC Toolkit http://www.ssh.fi/ipsec/