idnits 2.17.1 draft-ietf-dhc-dhcpv6-opt-dstm-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 21 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 25, 2002) is 8008 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '4' is defined on line 225, but no explicit reference was found in the text -- Possible downref: Normative reference to a draft: ref. '3' ** Obsolete normative reference: RFC 2373 (ref. '4') (Obsoleted by RFC 3513) Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Volz 3 Internet-Draft Ericsson 4 Expires: October 24, 2002 J. Bound 5 Compaq Computer Corporation 6 R. Droms 7 Cisco Systems 8 T. Lemon 9 Nominum, Inc. 10 April 25, 2002 12 DSTM Options for DHCP 13 draft-ietf-dhc-dhcpv6-opt-dstm-01.txt 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on October 24, 2002. 38 Copyright Notice 40 Copyright (C) The Internet Society (2002). All Rights Reserved. 42 Abstract 44 The DSTM Global IPv4 Address option and the DSTM Tunnel Endpoint 45 Option provide DSTM (Dual Stack Transition Mechanism) configuration 46 information to DHCPv6 hosts. 48 1. Introduction 50 This document describes two options for DHCPv6 [2] that provide 51 information for hosts using the "Dual Stack Transition Mechanism" 52 (DSTM) [3]. 54 2. Requirements 56 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 57 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 58 document, are to be interpreted as described in RFC2119 [1]. 60 3. Terminology 62 This document uses terminology specific to IPv6 and DHCPv6 as defined 63 in section "Terminology" of the DHCPv6 specification. 65 4. Identity Association for DSTM Global IPv4 Addresses 67 The Identity Association for DSTM Global IPv4 Addresses (IA_DSTM) 68 option is used to carry an IA, the parameters associated with the IA 69 and the addresses associated with the IA. All of the addresses in 70 this option are used by the client as DSTM Global IPv4 Addresses [3]. 72 The format of the IA_DSTM option is: 74 0 1 2 3 75 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 76 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 77 | OPTION_IA_DSTM | option-len | 78 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 79 | IAID (4 octets) | 80 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 81 | T1 | 82 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 83 | T2 | 84 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 85 | | 86 . IA-options . 87 . . 88 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 90 option-code: OPTION_IA_DSTM (TBD) 92 option-len: 12 + length of IA-options field 94 IAID: The unique identifier for this IA; the IAID must be 95 unique among the identifiers for all of this client's IAs 97 T1: The time at which the client contacts the server from 98 which the addresses in the IA were obtained to extend the 99 lifetimes of the addresses assigned to the IA; T1 is a time 100 duration relative to the current time expressed in units of 101 seconds 103 T2: The time at which the client contacts any available 104 server to extend the lifetimes of the addresses assigned to the 105 IA; T2 is a time duration relative to the current time expressed 106 in units of seconds 108 IA-options: Options associated with this IA. 110 The IA-options field encapsulates those options that are specific to 111 this IA. For example, all of the Address Options carrying the 112 addresses associated with this IA are in the IA-options field. 114 An IA_DSTM option may only appear in the options area of a DHCP 115 message. A DHCP message may contain multiple IA_DSTM options. 117 The status of any operations involving this IA is indicated in a 118 Status Code option in the IA-options field. 120 Note that an IA has no explicit "lifetime" or "lease length" of its 121 own. When the lifetimes of all of the addresses in an IA have 122 expired, the IA can be considered as having expired. T1 and T2 are 123 included to give servers explicit control over when a client 124 recontacts the server about a specific IA. 126 In a message sent by a client to a server, values in the T1 and T2 127 fields indicate the client's preference for those parameters. The 128 client may send 0 if it has no preference for T1 and T2. In a 129 message sent by a server to a client, the client MUST use the values 130 in the T1 and T2 fields for the T1 and T2 parameters. The values in 131 the T1 and T2 fields are the number of seconds until T1 and T2. 133 The server selects the T1 and T2 times to allow the client to extend 134 the lifetimes of any addresses in the IA before the lifetimes expire, 135 even if the server is unavailable for some short period of time. 136 Recommended values for T1 and T2 are .5 and .8 times the shortest 137 preferred lifetime of the addresses in the IA, respectively. If the 138 server does not intend for a client to extend the lifetimes of the 139 addresses in an IA, the server sets T1 and T2 to 0. 141 T1 is the time at which the client begins the lifetime extension 142 process by sending a Renew message to the server that originally 143 assigned the addresses to the IA. T2 is the time at which the client 144 starts sending a Rebind message to any server. 146 T1 and T2 are specified as unsigned integers that specify the time in 147 seconds relative to the time at which the messages containing the 148 option is received. 150 A DSTM Tunnel End Point option (Section 5) MAY be encapsulated in an 151 IA_DSTM option to specify one or more tunnel endpoints. 153 5. DSTM Tunnel Endpoint Option 155 The DSTM Tunnel Endpoint option carries an IP address that is to be 156 used as a tunnel endpoint (TEP) to encapsulate IP datagrams within 157 IP. 159 The format of the DSTM Tunnel Endpoint option is: 161 0 1 2 3 162 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 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | OPTION_DSTM_TEP | option-length | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 . . 167 . tep . 168 . (16 octets) . 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 option-code: OPTION_DSTM_TEP (TBD) 173 option-length: 16 175 tep: Tunnel endpoint 177 A DSTM Tunnel EndPoint Option MUST NOT be used except when 178 encapsulated in an IA_DSTM option. 180 6. Appearance of these options 182 The IA_DSTM option may appear in the same messages as the IA option 183 and the IA_TA option [2]. 185 A server may send a Reconfigure with an IA_DSTM option number in the 186 Option Request option (see sections 19 and 22.7 of the DHCP 187 specification [2]) to request that the client send a IA_DSTM option, 188 with an IAID, in the Renew message the client subsequently sends to 189 the server. 191 The DSTM Tunnel Endpoint option MUST only appear as an encapsulated 192 option in an IA_DSTM option. 194 7. Security Considerations 196 The DSTM Global IPv4 Address option may be used by an intruder DHCP 197 server to assign an invalid IPv4-mapped address to a DHCPv6 client in 198 a denial of service attack. The DSTM Tunnel Endpoint option may be 199 used by an intruder DHCP server to configure a DHCPv6 client with an 200 endpoint that would cause the client to route packets thorugh an 201 intruder system. 203 To avoid these security hazards, a DHCPv6 client MUST use 204 authenticated DHCPv6 to confirm that it is exchanging the DSTM 205 options with an authorized DHCPv6 server. 207 8. IANA Considerations 209 IANA is requested to assign an option code to this option from the 210 option-code space defined in section "DHCPv6 Options" of the DHCPv6 211 specification [2]. 213 References 215 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 216 Levels", BCP 14, RFC 2119, March 1997. 218 [2] Bound, J., Carney, M., Perkins, C., Lemon, T., Volz, B. and R. 219 Droms (ed.), "Dynamic Host Configuration Protocol for IPv6 220 (DHCPv6)", draft-ietf-dhc-dhcpv6 (work in progress), April 2002. 222 [3] Bound, J., "Dual Stack Transition Mechanism (DSTM)", draft-ietf- 223 ngtrans-dstm (work in progress), November 2001. 225 [4] Hinden, R. and S. Deering, "IP Version 6 Addressing 226 Architecture", RFC 2373, July 1998. 228 Authors' Addresses 230 Bernie Volz 231 Ericsson 232 959 Concord Street 233 Framingham, MA 01701 234 USA 236 Phone: +1 508 875 3162 237 EMail: bernie.volz@ericsson.com 238 Jim Bound 239 Compaq Computer Corporation 240 ZK3-3/W20 241 110 Spit Brook Road 242 Nashua, NH 03062-2698 243 USA 245 Phone: +1 603 884 0062 246 EMail: Jim.Bound@compaq.com 248 Ralph Droms 249 Cisco Systems 250 250 Apollo Drive 251 Chelmsford, MA 01824 252 USA 254 Phone: +1 978 497 4733 255 EMail: rdroms@cisco.com 257 Ted Lemon 258 Nominum, Inc. 259 950 Charter Street 260 Redwood City, CA 94043 261 USA 263 EMail: mellon@nominum.com 265 Full Copyright Statement 267 Copyright (C) The Internet Society (2002). All Rights Reserved. 269 This document and translations of it may be copied and furnished to 270 others, and derivative works that comment on or otherwise explain it 271 or assist in its implementation may be prepared, copied, published 272 and distributed, in whole or in part, without restriction of any 273 kind, provided that the above copyright notice and this paragraph are 274 included on all such copies and derivative works. However, this 275 document itself may not be modified in any way, such as by removing 276 the copyright notice or references to the Internet Society or other 277 Internet organizations, except as needed for the purpose of 278 developing Internet standards in which case the procedures for 279 copyrights defined in the Internet Standards process must be 280 followed, or as required to translate it into languages other than 281 English. 283 The limited permissions granted above are perpetual and will not be 284 revoked by the Internet Society or its successors or assigns. 286 This document and the information contained herein is provided on an 287 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 288 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 289 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 290 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 291 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 293 Acknowledgement 295 Funding for the RFC Editor function is currently provided by the 296 Internet Society.