Subject: [IPsec] WG Last Call for IPv6 Configuration in IKEv2

From: Paul Hoffman <[email-masked]>
Date: Mon, 22 Jun 2009 18:54:35 -0700

Greetings again. This document has been kicked around a bit, but it is not clear what level of interest there in in the WG. Thus, I am initiating WG Last Call to see:

- Do people think it is in good enough shape for the WG to put out as an Experimental (not Standards Track) RFC?

- Is there is more interest than from just the document authors? Ideally, it would be good to hear five or more WG participants who are not authors on the document say that they have read it and think it is worthy of being an Experimental RFC. We will consider doing it with fewer people, but such a poor turnout is not a good sign for the value of the document.

Please comment on the list. Thanks!

--Paul Hoffman

	Title           : IPv6 Configuration in IKEv2
	Author(s)       : P. Eronen, et al.
	Filename        : draft-ietf-ipsecme-ikev2-ipv6-config-01.txt
	Pages           : 33
	Date            : 2009-06-17

When IKEv2 is used for remote VPN access (client to VPN gateway), the
gateway assigns the client an IP address from the internal network
using IKEv2 configuration payloads.  The configuration payloads
specified in RFC 4306 work well for IPv4, but make it difficult to
use certain features of IPv6.  This document specifies new
configuration attributes for IKEv2 that allows the VPN gateway to
assign IPv6 prefixes to clients, enabling all features of IPv6 to be
used with the client-gateway "virtual link".

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ikev2-ipv6-config-01.txt

---

From: Yoav Nir <[email-masked]>
Date: Wed, 24 Jun 2009 09:53:03 +0300

Hi.

IMO the CFG payloads are the last place where there will ever be a shortage of IPv4 addresses. The addresses distributed through CFG payloads in IKEv2 or through extensions to IKEv1 are almost always non-routable addresses, and even for extremely large organizations, there are plenty of those.

The time when we'll actually need to distribute IPv6 addresses for this use, is only when IPv6 has become so ubiquitous, that we're actually trying to get rid of all kinds of NAT and 4-in-6 solutions, which is not for several years.  I think this accounts for why there has been relatively little interest in IPv6 configuration.

Having said that, the discussion in the draft shows that the IPv6 configuration, as it exists in RFC 4306, is faulty and since it's already there, it really should be fixed. OTOH we can't expect to see lots of interoperable implementations soon.

So I agree that the document is in good enough shape, and interesting enough to be published as Experimental.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Hoffman
Sent: Tuesday, June 23, 2009 4:55 AM
To: IPsecme WG
Subject: [IPsec] WG Last Call for IPv6 Configuration in IKEv2

--Paul Hoffman

_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

Scanned by Check Point Total Security Gateway.

Email secured by Check Point