Subject: [IPsec] Confirming response to ietf last call comments on draft-ietf-ipsecme-ikev2-ipv6-config

From: "Polk, William T." <[email-masked]>
Date: Mon, 5 Oct 2009 07:47:32 -0400

Folks,

In response to the Gen-ART review of draft-ietf-ipsecme-ikev2-ipv6-config,
Pasi has proposed adding a new, non-normative appendix.  I have entered the
new text as an RFC Editor Note, but wish to confirm that this text is
acceptable to the working group.  The note is appended to this message....

Thanks, 

Tim

RFC Editor Note

Please add the following as Appendix B:

Appendix B. Evaluation (Non-Normative)
 
   Section 3 described the goals and requirements for IPv6
   configuration in IKEv2. This appendix briefly summarizes how the
   solution specified in Sections 4 and 5 meets these goals.
 
   o  (3.1) Assigning addresses from multiple prefixes is supported,
      without requiring the client to know beforehand how many prefixes
      are needed.
   o  (3.2) Link-local addresses are assigned, and can be used for
      protocols between the VPN client and gateway.
   o  (3.3) The entire prefix is assigned to a single client, so
      the client can freely select any number of interface IDs (which
      may depend on the prefix).
   o  (3.4) This document does not specify how the VPN client would
      share the VPN connection with other devices. However, since the
      entire prefix is assigned to a single client, the client could
      further assign addresses from it without requiring coordination
      with the VPN gateway.
   o  (3.5) The solution does not add any new periodic messages over
      the VPN tunnel.
   o  (3.5) Re-authentication works (see Section 4.2).
   o  (3.5) The solution is compatible with other IPsec uses, since
      the LINK_ID notification makes it unambiguous which CHILD_SAs
      are related to the virtual link and which are not (see Sections
      4.3 and 5.3).
   o  (3.5) The new mechanisms do not prevent the VPN client and/or
      gateway from implementing the INTERNAL_IP6_ADDRESS configuration
      attribute as well; however, the two mechanisms are not intended
      to be used simultaneously (see Section 4.5).
   o  (3.5) Implementation dependencies are, obviously, implementation
      dependant (and their cleanliness somewhat subjective). Possible
      drawbacks of some alternative solutions are discussed in
      Appendix A.6.
   o  (3.5) The mechanism for configuring the prefixes (configuration
      payloads) is specific to IKEv2, for reasons described in Appendix
      A. However, Section 4.1 recommends using DHCPv6 Information-Request
      message for obtaining other configuration information (such as DNS
      server addresses).