Network Working Group B. Volz Internet-Draft Ericsson Expires: October 24, 2002 J. Bound Compaq Computer Corporation R. Droms Cisco Systems T. Lemon Nominum, Inc. April 25, 2002 DSTM Options for DHCP draft-ietf-dhc-dhcpv6-opt-dstm-01.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. 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 October 24, 2002. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract The DSTM Global IPv4 Address option and the DSTM Tunnel Endpoint Option provide DSTM (Dual Stack Transition Mechanism) configuration information to DHCPv6 hosts. Volz, et al. Expires October 24, 2002 [Page 1] Internet-Draft DSTM Options April 2002 1. Introduction This document describes two options for DHCPv6 [2] that provide information for hosts using the "Dual Stack Transition Mechanism" (DSTM) [3]. 2. Requirements The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in RFC2119 [1]. 3. Terminology This document uses terminology specific to IPv6 and DHCPv6 as defined in section "Terminology" of the DHCPv6 specification. 4. Identity Association for DSTM Global IPv4 Addresses The Identity Association for DSTM Global IPv4 Addresses (IA_DSTM) option is used to carry an IA, the parameters associated with the IA and the addresses associated with the IA. All of the addresses in this option are used by the client as DSTM Global IPv4 Addresses [3]. The format of the IA_DSTM option is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_IA_DSTM | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IAID (4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | T1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | T2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . IA-options . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code: OPTION_IA_DSTM (TBD) option-len: 12 + length of IA-options field IAID: The unique identifier for this IA; the IAID must be unique among the identifiers for all of this client's IAs Volz, et al. Expires October 24, 2002 [Page 2] Internet-Draft DSTM Options April 2002 T1: The time at which the client contacts the server from which the addresses in the IA were obtained to extend the lifetimes of the addresses assigned to the IA; T1 is a time duration relative to the current time expressed in units of seconds T2: The time at which the client contacts any available server to extend the lifetimes of the addresses assigned to the IA; T2 is a time duration relative to the current time expressed in units of seconds IA-options: Options associated with this IA. The IA-options field encapsulates those options that are specific to this IA. For example, all of the Address Options carrying the addresses associated with this IA are in the IA-options field. An IA_DSTM option may only appear in the options area of a DHCP message. A DHCP message may contain multiple IA_DSTM options. The status of any operations involving this IA is indicated in a Status Code option in the IA-options field. Note that an IA has no explicit "lifetime" or "lease length" of its own. When the lifetimes of all of the addresses in an IA have expired, the IA can be considered as having expired. T1 and T2 are included to give servers explicit control over when a client recontacts the server about a specific IA. In a message sent by a client to a server, values in the T1 and T2 fields indicate the client's preference for those parameters. The client may send 0 if it has no preference for T1 and T2. In a message sent by a server to a client, the client MUST use the values in the T1 and T2 fields for the T1 and T2 parameters. The values in the T1 and T2 fields are the number of seconds until T1 and T2. The server selects the T1 and T2 times to allow the client to extend the lifetimes of any addresses in the IA before the lifetimes expire, even if the server is unavailable for some short period of time. Recommended values for T1 and T2 are .5 and .8 times the shortest preferred lifetime of the addresses in the IA, respectively. If the server does not intend for a client to extend the lifetimes of the addresses in an IA, the server sets T1 and T2 to 0. T1 is the time at which the client begins the lifetime extension process by sending a Renew message to the server that originally assigned the addresses to the IA. T2 is the time at which the client starts sending a Rebind message to any server. Volz, et al. Expires October 24, 2002 [Page 3] Internet-Draft DSTM Options April 2002 T1 and T2 are specified as unsigned integers that specify the time in seconds relative to the time at which the messages containing the option is received. A DSTM Tunnel End Point option (Section 5) MAY be encapsulated in an IA_DSTM option to specify one or more tunnel endpoints. 5. DSTM Tunnel Endpoint Option The DSTM Tunnel Endpoint option carries an IP address that is to be used as a tunnel endpoint (TEP) to encapsulate IP datagrams within IP. The format of the DSTM Tunnel Endpoint option is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_DSTM_TEP | option-length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . tep . . (16 octets) . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code: OPTION_DSTM_TEP (TBD) option-length: 16 tep: Tunnel endpoint A DSTM Tunnel EndPoint Option MUST NOT be used except when encapsulated in an IA_DSTM option. 6. Appearance of these options The IA_DSTM option may appear in the same messages as the IA option and the IA_TA option [2]. A server may send a Reconfigure with an IA_DSTM option number in the Option Request option (see sections 19 and 22.7 of the DHCP specification [2]) to request that the client send a IA_DSTM option, with an IAID, in the Renew message the client subsequently sends to the server. The DSTM Tunnel Endpoint option MUST only appear as an encapsulated option in an IA_DSTM option. Volz, et al. Expires October 24, 2002 [Page 4] Internet-Draft DSTM Options April 2002 7. Security Considerations The DSTM Global IPv4 Address option may be used by an intruder DHCP server to assign an invalid IPv4-mapped address to a DHCPv6 client in a denial of service attack. The DSTM Tunnel Endpoint option may be used by an intruder DHCP server to configure a DHCPv6 client with an endpoint that would cause the client to route packets thorugh an intruder system. To avoid these security hazards, a DHCPv6 client MUST use authenticated DHCPv6 to confirm that it is exchanging the DSTM options with an authorized DHCPv6 server. 8. IANA Considerations IANA is requested to assign an option code to this option from the option-code space defined in section "DHCPv6 Options" of the DHCPv6 specification [2]. References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Bound, J., Carney, M., Perkins, C., Lemon, T., Volz, B. and R. Droms (ed.), "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", draft-ietf-dhc-dhcpv6 (work in progress), April 2002. [3] Bound, J., "Dual Stack Transition Mechanism (DSTM)", draft-ietf- ngtrans-dstm (work in progress), November 2001. [4] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998. Authors' Addresses Bernie Volz Ericsson 959 Concord Street Framingham, MA 01701 USA Phone: +1 508 875 3162 EMail: bernie.volz@ericsson.com Volz, et al. Expires October 24, 2002 [Page 5] Internet-Draft DSTM Options April 2002 Jim Bound Compaq Computer Corporation ZK3-3/W20 110 Spit Brook Road Nashua, NH 03062-2698 USA Phone: +1 603 884 0062 EMail: Jim.Bound@compaq.com Ralph Droms Cisco Systems 250 Apollo Drive Chelmsford, MA 01824 USA Phone: +1 978 497 4733 EMail: rdroms@cisco.com Ted Lemon Nominum, Inc. 950 Charter Street Redwood City, CA 94043 USA EMail: mellon@nominum.com Volz, et al. Expires October 24, 2002 [Page 6] Internet-Draft DSTM Options April 2002 Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Volz, et al. Expires October 24, 2002 [Page 7]