Subject: [IPsec] IPv6 Configuration

From: Julien Laganier <[email-masked]>
Date: Tue, 24 Feb 2009 15:53:59 +0100

Folks,

The ipsecme WG is chartered to deliver a standards-track extension to
IKEv2 that provides full IPv6 support for IPsec remote access clients
that use configuration payloads. There's a WG draft trying to fullfil
that available at:

<http://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-ipv6-config-00>

When we presented this draft during the Minneapolis meeting last
November some people said they felt there was a gap in IPv6 support
for IPsec in general, which wasn't limited to IKEv2 for IRAC and that
the current draft wasn't filling that gap.

It is true that the current draft as per our charter is focused on
extending IKEv2 for IPv6 support in IRAC scenarios. The following
solution requirements were identified so far (excerpt from the draft):

   o  A VPN client can obtain several addresses from a given prefix; the
      interface IDs can be selected by the client, and may depend on the
      prefix.

   o  A VPN client can be assigned multiple prefixes for use on the
      client-gateway link.  The client does not have to know beforehand
      how many prefixes are needed.

   o  The solution should avoid periodic messages over the VPN tunnel.

   o  The solution should avoid Duplicate Address Detection (DAD) over
      the VPN tunnel.

   o  Multicast works.  That is, the client is able to send multicast
      packets (tunneled to the gateway via unicast), join multicast
      groups using [MLDv2], and receive multicast packets (tunneled from
      the gateway to the client via unicast).

   o  It should be possible to share the VPN access over a local area
      network connection, without requiring anything special from other
      hosts in the local network (beyond minimal IPv6 node requirements
      specified in [RFC4294]).

   o  Re-authentication works: the client can start a new IKE SA and
      continue using the same "virtual link" (with same addresses,
      etc.).

   o  Compatibility with other IPsec uses: Configuring a virtual IPv6
      link should not prevent the peers from using IPsec/IKEv2 for other
      uses.

   o  Compatibility with current IPv6 configuration: Although the
      current IPv6 mechanism is not widely implemented, new solutions
      should not preclude its use (e.g., by defining incompatible
      semantics for the existing payloads).

   o  Compatibility with current IPv4 configuration: it should be
      possible to use the existing IPv4 configuration mechanism within
      the same IKE SA.

   o  (Optional/To be determined) When the client is also a router (to
      some local network), it should be able to use DHCPv6 prefix
      delegation [RFC3633] over the virtual link.

Since it seems some people think some IPsec generic requirements shall
be added to the list above to complete the IPv6 support, if they could
reply to that note to propose some, hopefully the WG could get some
insights on what they think is missing...

On my side the only thing I could come up with so far is how to deal
with link-local IPv6 addresses used as traffc selector for IPsec
transport mode. In that respect one might view RFC 4301 as
underspecified since a link-local address scope is limited to a link
(thus is likely to correspond to an interface on a host but could
correspond to more than one interface in some situations) but there is
no notion of link or interface in the definition of a traffic selector
as per RFC 4301. Quoting RFC 4301 " There is no requirement to
maintain SPDs on a per-interface basis, as was specified in RFC 2401".

We'd appreciate the view of the WG participants on the matter of IPv6
support for IPsec.

Best,

--julien