--- 1/draft-ietf-dhc-vpn-option-04.txt 2006-02-04 23:06:52.000000000 +0100 +++ 2/draft-ietf-dhc-vpn-option-05.txt 2006-02-04 23:06:52.000000000 +0100 @@ -1,46 +1,45 @@ + Network Working Group R. Johnson Internet-Draft J. Kumarasamy -Expires: August 10, 2005 K. Kinnear +Expires: December 31, 2005 K. Kinnear M. Stapp Cisco - February 9, 2005 + June 29, 2005 Virtual Subnet Selection Option - draft-ietf-dhc-vpn-option-04.txt + draft-ietf-dhc-vpn-option-05.txt Status of this Memo - This document is an Internet-Draft and is subject to all provisions - of section 3 of RFC 3667. By submitting this Internet-Draft, each - author represents that any applicable patent or other IPR claims of - which he or she is aware have been or will be disclosed, and any of - which he or she become aware will be disclosed, in accordance with - RFC 3668. + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as - Internet-Drafts. + other groups may also distribute working documents as Internet- + Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on August 10, 2005. + This Internet-Draft will expire on December 31, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This memo defines a new DHCP option for passing Virtual Subnet Selection (VSS) information between the DHCP client and the DHCP server. It is intended for use primarily by DHCP proxy clients in @@ -180,23 +179,23 @@ Potential exposures to attack are discussed in section 7 of the DHCP protocol specification in [2]. The VSS Information option could be used by a client in order to obtain an IP address from a VSS other than the one where it should. DHCP relays MAY choose to remove the option before passing on DHCPDISCOVER packets. Another possible defense would be for the DHCP relay to insert a Relay option containing a VSS Information Suboption, which would override the DHCP VSS Information option. - This option would allow a client to perform a more complete - address-pool exhaustion attack since the client would no longer be - restricted to attacking address-pools on just its local subnet. + This option would allow a client to perform a more complete address- + pool exhaustion attack since the client would no longer be restricted + to attacking address-pools on just its local subnet. Servers that implement the VSS Information option MUST by default disable use of the feature; it must specifically be enabled through configuration. Moreover, a server SHOULD provide the ability to selectively enable use of the feature under restricted conditions, e.g., by enabling use of the option only from explicitly configured client-ids, enabling its use only by clients on a particular subnet, or restricting the VSSs from which addresses may be requested. 4. IANA Considerations @@ -211,79 +210,79 @@ Option. The type bytes and data formats of the VSS Information Option and VSS Information Suboption MUST always be identical. 5. Acknowledgements This document is the result of work done within Cisco Systems. Thanks to Kim Kinnear, Mark Stapp, and Jay Kumarasamy for their work on this option definition and the other related work for which this is necessary. -6 References +6. References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997. [2] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [3] Droms, R. and S. Alexander, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997. [4] Fox, B. and B. Gleeson, "Virtual Private Networks Identifier", RFC 2685, September 1999. - [5] Droms, R., "Authentication for DHCP Messages", RFC 3118, June - 2001. + [5] Droms, R., "Authentication for DHCP Messages", RFC 3118, + June 2001. [6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 2434, October 1998. [7] Volz, B., "Reclassifying Dynamic Host Configuration Protocol version 4 (DHCPv4) Options", RFC 3942, November 2004. Authors' Addresses Richard A. Johnson Cisco Systems 170 W. Tasman Dr. San Jose, CA 95134 US Phone: +1 408 526 4000 - EMail: raj@cisco.com + Email: raj@cisco.com Jay Kumarasamy Cisco Systems 170 W. Tasman Dr. San Jose, CA 95134 US Phone: +1 408 526 4000 - EMail: jayk@cisco.com + Email: jayk@cisco.com Kim Kinnear Cisco Systems 250 Apollo Drive Chelmsford, MA 01824 US Phone: +1 978 244 8000 - EMail: kkinnar@cisco.com + Email: kkinnar@cisco.com Mark Stapp Cisco Systems 250 Apollo Drive Chelmsford, MA 01824 US Phone: +1 978 244 8000 - EMail: mjs@cisco.com + Email: mjs@cisco.com Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be