IPv6 Configuration in Internet Key Exchange Protocol Version 2 (IKEv2)
RFC 5739

[Ballot comment]
> This approach complicates the use of Cryptographically Generates
> Addresses [CGA].

s/Generates/Generated/

> The original 3GPP standards for IPv6 assigned a single IPv6 address
> to each mobile phone, resembling current IKEv2 payloads.

Was this really a standard at the time? I do not remember this far
back, but I was under the impression that there were only proposals
on the table, and after discussion with the IETF the eventual standard
came to be what it is today.

> The LINK_ID notification is included in CREATE_CHILD_SA requests to
> indicate that the SA being created is related to the virtual link.
> If this notification is not included, the CREATE_CHILD_SA requests is
> related to the real interface.

How does this relationship show up on the wire? I.e., are the bits
any different if a packet is sent over the virtual link as opposed
to being sent over the real (IPsec) interface? I'm trying to understand
why this distinction matters...

> o Prefix Length (1 octets) - The length of the prefix in bits;
>  usually 64.

Question. Does this specification allow the use of < 64 bit prefixes?
Do current address autoconfiguration mechanisms allow such prefixes
to be used as a basis for assigning addresses? Do you envision the use
of a short prefix as opposed to prefix delegation when the device
needs multiple /64s?

[Ballot discuss]
This is an excellent document and I fully support its publication.
I was prepared to ballot yes, but I think the following may need
a small correction:

> Duplicate Address Detection is not needed, because this is a point-
> to-point link, where the VPN gateway does not assign any addresses
> from the global unicast prefixes, and link-local interface identifier
> is negotiated separately.

However, some specifications call out the use of DAD. For instance,
RFC 4941 says:

  The node MUST perform duplicate address detection (DAD) on the
  generated temporary address.

perhaps you could make it clearer that DAD is allowed and may be
needed as a part of some other specifications, but running it on
the ptp link is fine.

[Ballot comment]
> This approach complicates the use of Cryptographically Generates
> Addresses [CGA].

s/Generates/Generated/

> The original 3GPP standards for IPv6 assigned a single IPv6 address
> to each mobile phone, resembling current IKEv2 payloads.

Was this really a standard at the time? I do not remember this far
back, but I was under the impression that there were only proposals
on the table, and after discussion with the IETF the eventual standard
came to be what it is today.

> The LINK_ID notification is included in CREATE_CHILD_SA requests to
> indicate that the SA being created is related to the virtual link.
> If this notification is not included, the CREATE_CHILD_SA requests is
> related to the real interface.

How does this relationship show up on the wire? I.e., are the bits
any different if a packet is sent over the virtual link as opposed
to being sent over the real (IPsec) interface? I'm trying to understand
why this distinction matters...

> Duplicate Address Detection is not needed, because this is a point-
> to-point link, where the VPN gateway does not assign any addresses
> from the global unicast prefixes, and link-local interface identifier
> is negotiated separately.

However, some specifications call out the use of DAD. For instance,
RFC 4941 says:

  The node MUST perform duplicate address detection (DAD) on the
  generated temporary address.

perhaps you could make it clearer that DAD is allowed and may be
needed as a part of some other specifications, but running it on
the ptp link is fine.

[Ballot comment]
> This approach complicates the use of Cryptographically Generates
> Addresses [CGA].

s/Generates/Generated/

> The original 3GPP standards for IPv6 assigned a single IPv6 address
> to each mobile phone, resembling current IKEv2 payloads.

Was this really a standard at the time? I do not remember this far
back, but I was under the impression that there were only proposals
on the table, and after discussion with the IETF the eventual standard
came to be what it is today.

> The LINK_ID notification is included in CREATE_CHILD_SA requests to
> indicate that the SA being created is related to the virtual link.
> If this notification is not included, the CREATE_CHILD_SA requests is
> related to the real interface.

How does this relationship show up on the wire? I.e., are the bits
any different if a packet is sent over the virtual link as opposed
to being sent over the real (IPsec) interface? I'm trying to understand
why this distinction matters...

[Ballot comment]
> This approach complicates the use of Cryptographically Generates
> Addresses [CGA].

s/Generates/Generated/

> The original 3GPP standards for IPv6 assigned a single IPv6 address
> to each mobile phone, resembling current IKEv2 payloads.

Was this really a standard at the time? I do not remember this far
back, but I was under the impression that there were only proposals
on the table, and after discussion with the IETF the eventual standard
came to be what it is today.

[Ballot comment]
The Gen-ART Review by Avshalom Houri on 2009-09-24 suggested a
  section describing how the requirements in section 3 are being
  addressed by the solution.

[Ballot discuss]
The Gen-ART Review by Avshalom Houri on 2009-09-24 raised a concern
  about authentication and re-authentication.  In particular, I think
  that a bit more discussion of this paragraph is needed:

  The gateway uses the Link ID to look up relevant local state,
  verifies that the authenticated peer identity associated with
  the link is correct, and continues the handshake as usual.

  Based on the discussion following the posting of the Gen-ART Review,
  I expected an updated Internet-Draft.

[Ballot comment]
The Gen-ART Review by Avshalom Houri on 2009-09-24 suggested a
  section describing how the requirements in section 3 are being
  addressed by the solution.

[Ballot discuss]
The Gen-ART Review by Avshalom Houri on 2009-09-24 raised a concern
  about authentication and re-authentication.  In particular, I think
  that a bit more discussion of this paragraph is needed:

  The gateway uses the Link ID to look up relevant local state,
  verifies that the authenticated peer identity associated with
  the link is correct, and continues the handshake as usual.

IANA comments:

Upon approval of this document, IANA will make the following
assignments at
http://www.iana.org/assignments/ikev2-parameters


ACTION 1:

Registry Name: IKEv2 Configuration Payload Attribute Types

Value Attribute Type Multi-Valued Length Reference
----------- ------------- ------------ ------------ ---------
TBD1 INTERNAL_IP6_LINK NO 8 or more
[RFC-ipsecme-ikev2-ipv6-config-02]
TBD2 INTERNAL_IP6_PREFIX YES 17 octets
[RFC-ipsecme-ikev2-ipv6-config-02]


ACTION 2:

Registry Name: IKEv2 Notify Message Types - Status Types

Value NOTIFY MESSAGES - STATUS TYPES Reference
------------ -------------------------------- ---------
TBD3 LINK_ID [RFC-ipsecme-ikev2-ipv6-config-02]

Here is my document shepherd write-up for "IPv6 Configuration in IKEv2" (draft-ietf-ipsecme-ikev2-ipv6-config-01.txt). Please consider it for publication.

--Paul Hoffman

I am the document shepherd for this document, inasmuch as I am the co-chair of the IPsecME WG. I have personally reviewed this version of the document and, in particular, believe this version is ready for forwarding to the IESG for publication as an Experimental RFC.

The document was reviewed in the WG, but only lightly, even though we asked a few times for review. I asked for reviews on the ipv6ops WG and an IPv6 mailing list, but do not think anyone took me up on it. I do not have concern that it needs more review before IETF LC, although I would love it if there was more review during it. I know of no IPR statements on the work.

Because of the little review, the WG consensus for this work can only be called "weak", but there was no one who objected to publication. The authors and WG decided to ask for Experimental status because the protocol here has been thinly implemented (if that), and thinly reviewed.

The draft mostly passes I-D nits (there are lots of instances of non-RFC3849-compliant addresses, but they really are needed to make the examples clear). Yes, the references are sane and no downrefs are needed. The IANA considerations shows two sets of new entries need to be added to already-existing registries, and no new registries are needed.

Technical Summary

This document describes new IKEv2 configuration attributes that let an IPsec security gateway assign IPv6 prefixes to a VPN client clients. This is needed because IKEv2 currently does not handle all features of IPv6 that it should, such as enabling a virtual link.

Working Group Summary

The document has light consensus of the IPsecME WG with no objections to publication as an Experimental RFC.

Document Quality

There was initial interest in this protocol from many participants, but only a few seem to have done an in-depth review. Despite that, the document has no obvious problems and could turn out to be quite useful as there is greater deployment of IPsec in IPv6 environments. This document should be revisited as more implementations of remote access IPv6 IPsec are created and deployed.