idnits 2.17.1 draft-ietf-dhc-dhcpv6-opt-tz-00.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 == The page length should not exceed 58 lines per page, but there was 5 longer pages, the longest (page 6) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 7 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** There are 3 instances of lines with control characters in the document. 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 (Nov 2003) is 7467 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) -- Looks like a reference, but probably isn't: 'Offset' on line 81 ** Obsolete normative reference: RFC 3315 (ref. '1') (Obsoleted by RFC 8415) 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 Vijayabhaskar A Kalusivalingam 3 Internet-Draft Hewlett-Packard 4 Expires: May 2004 Nov 2003 6 Timezone Specifier Option for DHCPv6 7 draft-ietf-dhc-dhcpv6-opt-tz-00 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on May, 2004. 32 Copyright Notice 34 Copyright (C) The Internet Society (2003). All Rights Reserved. 36 Abstract 38 This document describes a new DHCPv6 option for passing the client's 39 timezone information. 41 1. Introduction 43 This document describes a new option called Timezone option for 44 passing the client's timezone information information in DHCPv6 [1]. 46 2. Requirements 48 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 49 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 50 document, are to be interpreted as described in RFC 2119 [2] 52 3. Terminology 54 This document uses terminology specific to IPv6 and DHCPv6 as defined 55 in "Terminology" section of the DHCPv6 specification. 57 4. Timezone option 59 The Timezone option is used by the server to convey the timezone 60 in which the client resides. The client is expected to set the 61 timezone in its system on receiving this option from the server. 63 The format of the Timezone option is: 65 0 1 2 3 66 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 67 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 68 | OPTION_TIME_ZONE | option-len | 69 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 70 | time-zone | 71 | ... | 72 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 74 option-code: OPTION_TIME_ZONE (tbd) 76 option-len: Length of the 'time-zone' field in octets 78 time-zone: Time zone of the client in the NVT-ASCII string format. 79 The format of this string is explained below: 81 Std[Offset[Dst[Offset],[Start[/Time],End[/Time]]]] 83 where '[' and ']' enclose optional fields, '|' indicates choice 84 of exactly one of the alternatives, ',' and '/' represent literal 85 characters present in the string. 87 If "Offset" is specified, then the time-zone is represented in the 88 IEEE 1003.1 POSIX timezone format [3]. 90 Std Three or more octets for the standard timezone (Std). 91 Any character (or case) except a leading colon, digits, 92 comma, minus or plus sign is allowed. If there is no 93 Offset followed by the Std, then the timezone is not 94 represented in IEEE 1003.1 format. In this case, the 95 Std is treated as the index to the timezone database, for 96 example, a file name, from where additional information 97 about the timezone may be obtained. 99 Offset Indicates the value one must add to local time to 100 arrive at UTC, of the form: [+|-]hh[:mm[:ss]]. Offset 101 following Std is required, if the timezone is represented 102 in IEEE 1003.1 POSIX timezone format. Digits are always 103 interpreted as decimal number. If preceded by a '-', the 104 timezone is east of the Prime Meridian, otherwise it is 105 west ('+' is optional) The permissible values for 106 hh[:mm[:ss]] are as follows: 108 hh 0 <= hh <= 23 110 mm 0 <= mm <= 60 112 ss 0 <= ss <= 60 114 Dst Three or more octets for the daylight savings timezone. 115 If Dst is missing, then daylight savings time does not 116 apply in this locale. If no Offset follows Dst, then 117 Dst is assumed to be one hour ahead of standard time. 118 Any character (or case) except a leading colon, digits, 119 comma, minus or plus sign is allowed. 121 Start Indicates the day of the year, in one of the formats 122 indicated below, when to change to daylight savings time. 123 The ``Time'' field (which follows immediately after a 124 ``/'' character, if present) indicates when the change is 125 made, in local time. 127 End Indicates the day of the year, in one of the formats 128 indicated below, when to change back from daylight 129 savings time. The ``Time'' field (which follows 130 immediately after a ``/'' character, if present) 131 indicates when the change is made, in local time. 133 Time Time has the same format as Offset, except that no 134 leading ``-'' or ``+'' is permitted. The default is 135 02:00:00. 137 The day of the year needs to be given in any of the following 138 formats: 140 Jn The julian day n, (1 <= n <= 365). Leap days are not 141 counted. 143 n Zero-based julian day, (0 <= n <= 365). Leap days are 144 counted so it is possible to refer to Feb 29. 146 Mm.n.d The ``d''th day, (0 <= d <= 6) of week ``n'' of month 147 ``m'' of the year (1 <= n <= 5, 1 <= m <= 12, where week 148 5 means last ``d'' day in month ``m'' which may occur in 149 either the fourth or the fifth week. Week ``1'' is the 150 first week in which the ``d'' day occurs. Day ``0'' refers 151 Sunday, day ``1'' refers Monday and so on. 153 Examples: 155 i) Indian Standard Time zone is represented as: 157 IST-5:30 159 Here, ``IST'' refers the standard timezone and ``-5:30'' is the 160 offset. `-' sign in the offset says that the timezone is 5 hours and 161 30 minutes ahead of UTC. Absence of ``Dst'' says that daylight savings 162 doesn't apply to this locale. 164 ii) For Eastern USA time zone, 1986, the timezone string is as shown 165 below: 167 EST5EDT4,116/02:00:00,298/02:00:00 169 It says: 171 The standard time zone is in 5 hours behind UTC. The Daylight Savings 172 Timezone is 4 hours behind UTC. Day light savings starts at 116 day, 173 i.e., April 27 02:00 AM standard time and ends at 298th day, i.e., 174 October 26 02:00 AM daylight time. 176 It can also represented as: 177 EST5EDT,116/02:00:00,298/02:00:00 179 Since no offset follows the ``Dst'', daylight savings time is 1 hour 180 ahead of standard time, thus, it is 4 hours behind UTC. 182 iii) Representing ii) in the non POSIX standard way is: 184 America/New-York 186 It says that the locale belongs to New-York timezone in America, 187 which will be used as the index in to a timezone database to get 188 more information of the timezone. 190 5. Usage of Timezone option 192 The Timezone option has the flexibility of providing timezone 193 information in formats other than POSIX timezone, because 194 some vendor specific databases can provide more information than 195 POSIX Timezone string. The server SHOULD be configurable to send any 196 of the format specified in Section 5. 198 The timezone option can be used along with the Vendor Class 199 Option [1] to make sure that the client and server agree upon the 200 meaning of the string. For example, the clients running in different 201 OS expect the string in different formats. Here, the Vendor Class 202 Option [1] sent by clients can be used by the server to distinguish 203 between the clients to return the proper timezone string. 205 If the client is not able to interpret the timezone option sent 206 by the server, then it SHOULD ignore the option. It MAY contact 207 alternative DHCPv6 servers to obtain the timezone information. 209 6. Appearance of these options 211 The Timezone option MUST NOT appear in other than the following the 212 following messages: Solicit, Advertise, Request, Renew, Rebind, 213 Information-Request and Reply. 215 The option number for these options MAY appear in the Option Request 216 Option [1] in the following messages: Solicit, Request, Renew, Rebind, 217 Information-Request and Reconfigure. 219 7. Security Considerations 221 The Timezone option may be used by an intruder DHCPv6 server to 222 assign invalid time zones, leading to timing issues for the 223 applications running on the client machine. For example, because of 224 wrongly configured timezone, there is a possibility that some critical 225 applications, which are supposed to start at a particular time don't 226 get started at that time. A delayed start of OS security update will 227 leave the client's machine vulnerable to security attacks. 229 To avoid attacks through these options, the DHCPv6 client SHOULD use 230 authenticated DHCPv6 (see "Authentication of DHCP messages" section 231 in the DHCPv6 specification [1]). 233 8. IANA Considerations 235 IANA is requested to assign an option code to the following options 236 from the option-code space defined in "DHCPv6 Options" section of the 237 DHCPv6 specification [1]. 239 Option Name Value Described in 240 OPTION_TIME_ZONE tbd Section 4. 242 9. Normative References 244 [1] Bound, J., Carney, M., Perkins, C., Lemon, T., Volz, B. and R. 245 Droms (ed.), "Dynamic Host Configuration Protocol for IPv6 246 (DHCPv6)", RFC 3315, July 2003. 248 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 249 Levels", BCP 14, RFC 2119, March 1997. 251 10. Informative References 253 [3] IEEE, "1003.1 POSIX Timezone Specification", 1988. 255 Author's Address 257 Vijayabhaskar A Kalusivalingam 258 Hewlett-Packard STSD-I 259 29, Cunningham Road 260 Bangalore - 560052 261 India 263 Phone: +91-80-2053085 264 E-Mail: vijayak@india.hp.com 266 Full Copyright Statement 268 Copyright (C) The Internet Society (2003). All Rights Reserved. 270 This document and translations of it may be copied and furnished to 271 others, and derivative works that comment on or otherwise explain it 272 or assist in its implementation may be prepared, copied, published 273 and distributed, in whole or in part, without restriction of any 274 kind, provided that the above copyright notice and this paragraph are 275 included on all such copies and derivative works. However, this 276 document itself may not be modified in any way, such as by removing 277 the copyright notice or references to the Internet Society or other 278 Internet organizations, except as needed for the purpose of 279 developing Internet standards in which case the procedures for 280 copyrights defined in the Internet Standards process must be 281 followed, or as required to translate it into languages other than 282 English. 284 The limited permissions granted above are perpetual and will not be 285 revoked by the Internet Society or its successors or assigns. 287 This document and the information contained herein is provided on an 288 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 289 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 290 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 291 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 292 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 294 Acknowledgement 296 Funding for the RFC Editor function is currently provided by the 297 Internet Society. Thanks to the DHC Working Group for their time and 298 input into the specification. In particular, thanks to (in 299 alphabetical order) Bernie Volz, Jim Bound, Margaret Wasserman, Ralph 300 Droms, Robert Elz and Thomas Narten for their thorough review. Special 301 thanks to Robert Elz for his suggestions and help in making this 302 document more readable. Thanks to Mike Carney for his abstract 303 on Timezone option.