Experimental RFC Proposal Internet-Draft Anil Reddy Document: draft-reddy-dhcpv6-opt-dstm-exp-00.txt Hewlett-Packard Expires: October 22, 2005 Jim Bound Hewlett-Packard April 22, 2005 Dual Stack Transition Mechanism (DSTM) Options for DHCPv6 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html" This Internet-Draft will expire on October 22, 2005. Abstract The DSTM Global IPv4 Address option and the DSTM Tunnel Endpoint Option provide DSTM (Dual Stack Transition Mechanism) configuration information to DHCPv6 hosts. 1. Introduction This document describes two options for DHCPv6 [DHCPV6] that provide information for hosts using the "Dual Stack Transition Mechanism" (DSTM) [DSTM]. 2. Requirements Anil Reddy Expires October 22, 2005 [Page 1] Internet-Draft DSTM Options for DHCPv6 April 2005 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 [RFC2119]. 3. Terminology This document uses terminology specific to IPv6 and DHCPv6 as defined in section "Terminology" of the DHCPv6 specification [DHCPV6]. 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 [DSTM]. 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 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 Anil Reddy Expires October 22, 2005 [Page 2] Internet-Draft DSTM Options for DHCPv6 April 2005 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 IA-DSTM 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_DSTM has no explicit "lifetime" or "lease length" of its own. When the valid lifetimes of all of the addresses in an IA_DSTM have expired, the IA_DSTM 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_DSTM. 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. 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. 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 sets T1 and T2 to 0 if it has no preference for those values. 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, unless those values in those fields are 0. 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_DSTM 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_DSTM that the server is willing to extend, respectively. If the "shortest" preferred lifetime is 0xffffffff ("infinity"), the recommended T1 and T2 values are also 0xffffffff. If the time at which the addresses in an IA_DSTM are to be renewed is to be left to the discretion of the client, the server sets T1 and T2 to 0. If a server receives an IA_DSTM with T1 greater than T2, and both T1 and T2 are greater than 0, the server ignores the invalid values of T1 and T2 and processes the IA_DSTM as though the client had set T1 and T2 to 0. If a client receives an IA_DSTM with T1 greater than T2, and both T1 and T2 are greater than 0, the client discards the IA_DSTM option and processes the remainder of the message as though the server had not Anil Reddy Expires October 22, 2005 [Page 3] Internet-Draft DSTM Options for DHCPv6 April 2005 included the invalid IA_DSTM option. Care should be taken in setting T1 or T2 to 0xffffffff ("infinity"). A client will never attempt to extend the lifetimes of any addresses in an IA with T1 set to 0xffffffff. A client will never attempt to use a Rebind message to locate a different server to extend the lifetimes of any addresses in an IA with T2 set to 0xffffffff. 5. IA-DSTM Address Option The IA-DSTM Address (IA_DSTMADDR) option is used to specify IPv4 addresses associated with an IA_DSTM. The IA-DSTM Address option must be encapsulated in the Options field of an IA_DSTM option. The format of the IA-DSTM Address 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_DSTMADDR | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | preferred-lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | valid-lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . IA-DSTM-addr-options . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code OPTION_IA_DSTMADDR (TBD) option-len 12 + length of IA-DSTM-addr-options field. IPv4 address An IPv4 address. preferred-lifetime The preferred lifetime for the IPv6 address in the option, expressed in units of seconds. valid-lifetime The valid lifetime for the IPv6 address in the option, expressed in units of seconds. IA-DSTM-addr-options Options associated with this address. In a message sent by a client to a server, values in the preferred and valid lifetime fields indicate the client's preference for those parameters. The client may send 0 if it has no preference for the preferred and valid lifetimes. In a message sent by a server to a client, the client MUST use the values in the preferred and valid lifetime fields for the preferred and valid lifetimes. The values in the preferred and valid lifetimes are the number of seconds remaining in each lifetime. Anil Reddy Expires October 22, 2005 [Page 4] Internet-Draft DSTM Options for DHCPv6 April 2005 A client discards any addresses for which the preferred lifetime is greater than the valid lifetime. A server ignores the lifetimes set by the client if the preferred lifetime is greater than the valid lifetime and ignores the values for T1 and T2 set by the client if those values are greater than the preferred lifetime. Care should be taken in setting the valid lifetime of an address to 0xffffffff ("infinity"), which amounts to a permanent assignment of an address to a client. The status of any operations involving this IA_DSTM Address is indicated in a Status Code option in the IA-DSTM-addr-options field. An IA_DSTMADDR option may appear only in an IA_DSTM option. More than one IA_DSTMADDR Option can appear in an IA_DSTM option. 6. DSTM Tunnel Endpoint Option The DSTM Tunnel Endpoint option carries an IPv6 address that is to be used as a tunnel endpoint (TEP) to encapsulate IPv4 datagrams within IPv6. 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 address A client may request OPTION_DSTM_TEP option in an Option Request Option (ORO) of DHCPv6 [DHCPV6]. 7. Appearance of these options The IA_DSTM option may appear in the same messages as the IA_NA option and the IA_TA option [DHCPV6]. 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 [DHCPV6]) to request that the client send a IA_DSTM option, with an IAID, in the Renew message the client subsequently Anil Reddy Expires October 22, 2005 [Page 5] Internet-Draft DSTM Options for DHCPv6 April 2005 sends to the server. An IA_DSTMADDR option may appear only in an IA_DSTM option. The DSTM Tunnel Endpoint option may appear in an ORO option [DHCPV6]. 8. 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. 9. IANA Considerations IANA is requested to assign option codes to these options from the option-code space of the DHCPv6 specification [DHCPV6]. 10. References 10.1 Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [DHCPV6] Bound, J., Carney, M., Perkins, C., Lemon, T., Volz, B. and R. Droms (ed.), "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [IP6ADDR] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 3513, April 2003. 10.2 Non-Normative References [DSTM] Bound, J., "Dual Stack Transition Mechanism (DSTM)", draft-bound-dstm-exp (work in progress), June 2005. [DSTMTEP] Lee, J., Bound, J. and Shin, M., "Multiple TEP Extension to DSTM", draft-jaehwoon-dstm-exp (work in progress), August 2005. 11. Acknowledgements This draft is an enhanced version of previous IETF draft authored by Bernie Volz, Jim Bound, Ralph Droms and Ted Lemon. Anil Reddy Expires October 22, 2005 [Page 6] Internet-Draft DSTM Options for DHCPv6 April 2005 Authors' Addresses Anil Kumar Reddy Hewlett-Packard ISO Pvt. Ltd. 29, Cunningham Road, Bangalore - 560 052 INDIA Phone: +91 80 2205 3093 EMail: anil.kumar.reddy@hp.com Jim Bound Hewlett-Packard Company ZK3-3/W20 110 Spit Brook Road Nashua, NH 03062-2698 USA Phone: +1 603 884 0062 EMail: Jim.Bound@hp.com Anil Reddy Expires October 22, 2005 [Page 7] Internet-Draft DSTM Options for DHCPv6 April 2005 Full Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78 and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Intellectual Property 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 found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Anil Reddy Expires October 22, 2005 [Page 8]