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

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). _______________________________________________ IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

• This message: [ Message body ]
• Next message: Internet-Drafts_at_nospam: "[IPsec] I-D Action:draft-ietf-ipsecme-ikev2bis-05.txt"
• Previous message: Internet-Drafts_at_nospam: "[IPsec] I-D Action:draft-ietf-ipsecme-roadmap-04.txt"

• Contemporary messages sorted: [ By Date ] [ By Thread ] [ By Subject ] [ By Author ]