idnits 2.17.1 draft-ietf-dhc-dhcpv6-opt-rboot-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 : ---------------------------------------------------------------------------- No issues found here. 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 (Feb 2004) is 7375 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: '3' is defined on line 199, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3315 (ref. '1') (Obsoleted by RFC 8415) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Vijayabhaskar A Kalusivalingam 2 Internet-Draft Senthil K Balasubramanian 3 Expires: August 2004 Hewlett-Packard 4 Feb 2004 6 DHCPv6 Support for Remote Boot 7 draft-ietf-dhc-dhcpv6-opt-rboot-00.txt 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 August 2004. 32 Copyright Notice 34 Copyright (C) The Internet Society (2004). All Rights Reserved. 36 Abstract 38 This document provides new DHCPv6 (Dynamic Host Configuration 39 protocol version 6) options for clients, to obtain information about 40 FTP (Trivial File Transfer Protocol) servers and bootfiles needed 41 for booting. 43 1. Introduction 45 Network booting is widely used mechanism for booting up of the 46 clients. The clients contact the TFTP server to download the 47 bootfiles for bootup. The advantages of using network booting are; 48 softwares will be in central server and requires maintenance at only 49 one location rather than maintaining individual systems separately. 50 Also, switching between different operating systems becomes easy when 51 network booting is being used. In some cases, the nodes may need 52 multiple bootfiles also. The additional boot files may be used as 53 supporting software for the boot image. Different Operating System 54 vendors use different way of handling this. Single TFTP server for 55 huge number of diskless clients is prone to single point of failure. 56 So, Multiple TFTP servers are needed for high availability. 58 DHCPv6 (Dynamic Host Configuration Protocol Version 6) provides a 59 framework for passing configuration information for hosts on an IPv6 60 network. However, DHCPv6 does not provide a way to send information 61 about TFTP server address and bootfile names. This document defines 62 two options, Remote boot option and Remote Boot parameter option to 63 provide information about TFTP servers and bootfile names to the 64 clients. These options are required for the clients, which are 65 booting over a network. 67 2. Requirements 69 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 70 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 71 document, are to be interpreted as described in RFC 2119 [2] 73 3. Terminology 75 This document uses terminology specific to IPv6 and DHCPv6 as defined 76 in "Terminology" section of the DHCPv6 specification [1]. 78 4. Remote Boot Option 80 The Remote Boot Option is used to carry the parameters needed for 81 remote boot of the DHCPv6 clients. Using the information provided by 82 this option, the DHCPv6 clients will bootp up. This will be mainly 83 used by the clients, which are booting using remote boot server. 85 The format of the Remote Boot Option is as shown below: 87 0 1 2 3 88 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 89 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 90 | OPTION_REMOTE_BOOT | option-len | 91 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 92 | | 93 . Remote-Boot-options . 94 . . 95 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 97 option-code: OPTION_REMOTE_BOOT (tbd) 99 option-len: Length of the 'Remote-Boot-options' fields in octets; 101 Remote_Boot-options: Options associated with the Remote Boot Option. 103 The Remote Boot option encapsulates those options that are specific 104 to remote boot. This document defines one such option called 105 Remote Boot Parameters Option. Multiple Remote Boot Parameters 106 Options can appear in this option. This option is defined in the 107 Section 5. 109 5. Remote Boot Parameters Option 111 The Remote Boot Parameters Option is used by the server to convey 112 the client about the TFTP Server IPv6 address and list of boot files 113 needed for booting of the clients. The clients are supposed to 114 contact the TFTP Server, obtain the boot files one by one and boot up 115 using these files. 117 0 1 2 3 118 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 119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 120 | OPTION_REMOTE_BOOT_PARAMS | option-len | 121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 122 | | 123 | TFTP Server (IPv6 address) | 124 | | 125 | | 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 | | 128 . Boot Files . 129 . . 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 option-code: OPTION_REMOTE_BOOT_PARAMS (tbd) 134 option-len: Length of the 'TFTP Server' (16 bytes) + 'Boot Files' 135 in Octets; 137 Boot Files: One or more Boot File names in the NVT-ASCII string 138 format. Each file name should be NULL terminated. They 139 should be represented as fully qualified directory-path name. 141 If multiple boot files are provided by the server, then, they should 142 appear in the order of their execution in the client. The first 143 appearing boot file name should be downloaded and executed first for 144 boot up, then the next and so on. 146 This option MUST appear only in the Remote Boot Option. If multiple 147 Remote Boot Parameters Options are present in the Remote Boot Option, 148 then the clients MUST treat them as an ordered list. The server MAY 149 list them in the order of preference. 151 6. Appearance of these options 153 The Remote Boot Option MUST NOT appear in other than the following 154 messages: Solicit, Advertise, Request, Renew, Rebind, 155 Information-Request and Reply. 157 The option number of Remote Boot option MAY appear in the Option 158 Request Option [1] in the following messages: Solicit, Request, 159 Renew, Rebind, Information-Request and Reconfigure. 161 The Remote Boot Parameters Option MUST appear only in the Remote 162 Boot Option. 164 7. Security Considerations 166 The Remote Boot Option may be used by an intruder DHCPv6 server to 167 cause DHCPv6 clients to contact rogue TFTP server (or) to send 168 invalid file names. This will make booting up of DHCPv6 clients to 169 fail. This will have a greater impact, if the clients are running 170 some time critical applications. It has a direct impact on the 171 security of the networks, if the clients are running any security 172 applications. 174 To avoid attacks through this option, the DHCP client SHOULD use 175 authenticated DHCP (see section "Authentication of DHCP messages" in 176 the DHCPv6 specification [1]). 178 8. IANA Considerations 180 IANA is requested to assign an option code to the following options 181 from the option-code space defined in "DHCPv6 Options" section of the 182 DHCPv6 specification [1]. 184 Option Name Value Described in 185 OPTION_REMOTE_BOOT tbd Section 4 186 OPTION_REMOTE_BOOT_PARAMS tbd Section 5 188 9. Normative References 190 [1] Bound, J., Carney, M., Perkins, C., Lemon, T., Volz, B. and R. 191 Droms (ed.), "Dynamic Host Configuration Protocol for IPv6 192 (DHCPv6)", RFC 3315, July 2003. 194 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 195 Levels", BCP 14, RFC 2119, March 1997. 197 10. Informative References 199 [3] K. Sollins, The TFTP Protocol (Revision 2), RFC 1350, July 1992. 201 Authors' Addresses 203 Vijayabhaskar A Kalusivalingam 204 Hewlett-Packard STSD-I 205 29, Cunningham Road 206 Bangalore - 560052 207 India 209 Phone: +91-80-22053085 210 E-Mail: vijayak@india.hp.com 211 Senthil K Balasubramanian 212 Hewlett-Packard STSD-I 213 29, Cunningham Road 214 Bangalore - 560052 215 India 217 Phone: +91-80-22053103 218 E-Mail: ksenthil@india.hp.com 220 Intellectual Property Statement 222 The IETF takes no position regarding the validity or scope of any 223 intellectual property or other rights that might be claimed to 224 pertain to the implementation or use of the technology described in 225 this document or the extent to which any license under such rights 226 might or might not be available; neither does it represent that it 227 has made any effort to identify any such rights. Information on the 228 IETF's procedures with respect to rights in standards-track and 229 standards-related documentation can be found in BCP-11. Copies of 230 claims of rights made available for publication and any assurances of 231 licenses to be made available, or the result of an attempt made to 232 obtain a general license or permission for the use of such 233 proprietary rights by implementors or users of this specification can 234 be obtained from the IETF Secretariat. 236 The IETF invites any interested party to bring to its attention any 237 copyrights, patents or patent applications, or other proprietary 238 rights which may cover technology that may be required to practice 239 this standard. Please address the information to the IETF Executive 240 Director. 242 Full Copyright Statement 244 Copyright (C) The Internet Society (2003). All Rights Reserved. 246 This document and translations of it may be copied and furnished to 247 others, and derivative works that comment on or otherwise explain it 248 or assist in its implementation may be prepared, copied, published 249 and distributed, in whole or in part, without restriction of any 250 kind, provided that the above copyright notice and this paragraph are 251 included on all such copies and derivative works. However, this 252 document itself may not be modified in any way, such as by removing 253 the copyright notice or references to the Internet Society or other 254 Internet organizations, except as needed for the purpose of 255 developing Internet standards in which case the procedures for 256 copyrights defined in the Internet Standards process must be 257 followed, or as required to translate it into languages other than 258 English. 260 The limited permissions granted above are perpetual and will not be 261 revoked by the Internet Society or its successors or assigns. 263 This document and the information contained herein is provided on an 264 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 265 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 266 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 267 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 268 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 270 Acknowledgement 272 Funding for the RFC Editor function is currently provided by the 273 Internet Society.