idnits 2.17.1 draft-qin-6man-nb-option-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 6, 2018) is 2059 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: 'UEFI23' is defined on line 243, but no explicit reference was found in the text == Unused Reference: 'RFC3315' is defined on line 249, but no explicit reference was found in the text == Unused Reference: 'RFC4578' is defined on line 254, but no explicit reference was found in the text == Unused Reference: 'RFC5970' is defined on line 260, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'UEFI23' -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Qin, Ed. 3 Internet-Draft Y. Xi 4 Intended status: Standards Track W. Xu 5 Expires: March 10, 2019 Alibaba-Inc 6 September 6, 2018 8 IPv6 Router Advertisement Option for Network Boot 9 draft-qin-6man-nb-option-02 11 Abstract 13 This document specifies an IPv6 Router Advertisement (RA) option 14 (called "Boot File URL option") to allow IPv6 routers to advertise 15 configuration information for booting a node from the network. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on March 10, 2019. 34 Copyright Notice 36 Copyright (c) 2018 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 53 2. Option . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2.1. Boot File Uniform Resource Locator (URL) Option . . . . . 3 55 3. Implementation Considerations . . . . . . . . . . . . . . . . 4 56 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 57 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 58 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 59 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 61 7.2. Informative References . . . . . . . . . . . . . . . . . 6 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 64 1. Introduction 66 This document describes an IPv6 Neighbor Discovery (ND) option 67 (called BFURL option) that can be used to provide configuration 68 information for nodes to be booted from network instead of local 69 media. 71 IPv6 Stateless Address Autoconfiguration (SLAAC) [RFC4862] and IPv6 72 Neighbor Discovery (ND) [RFC4861] define ways to configure IPv6 73 addresses, on-link prefix list, default routers and other parameters. 75 The existing ND message (RA) is used to carry this network boot 76 information. Nodes can get the boot file url and parameters through 77 RA messages via BFRUL option. A boot file can be a boot-loader 78 program or a minimal OS kernel. The node firmware needs to download 79 the boot file and execute it. 81 This approach is useful in networks with no DHCPv6 infrastructure. 82 The intention is to simplify the implementation of first-stage 83 communicating functionalities of the nodes (i.e. PXE firmware), and 84 network. The distribution of additional information and subsequent 85 communications between the node and network side (e.g., an install 86 server) should be handled by applications built in the boot file. 88 The configuration of a Boot-File-URL would be required onto routers 89 sending RA messages. The configuration mechanism (manual or 90 automatic) is out of scope of this document. 92 1.1. Requirements Language 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in RFC 2119 [RFC2119]. 98 2. Option 100 The option formats comply with ND options per [RFC4861]. 102 2.1. Boot File Uniform Resource Locator (URL) Option 104 Routers send this option to nodes with a URL to a boot file. 106 0 1 2 3 107 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 108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 109 | Type | Length | P-Len | Reserved1 | 110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 111 | Reserved2 | 112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 113 | | 114 ~ Boot-File-URL (variable length) ~ 115 | | 116 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 117 | | | 118 +-+-+-+-+-+-+-+-+ Padding-Data (optional, 0-7 octets) + 119 | | 120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 122 Figure 1 124 Fields description: 126 Type TBD. 128 Length 8-bit unsigned integer. The length of this 129 option (including the Type and Length fields) 130 in units of 8 octets. 132 P-Len 4-bit unsigned integer. The length of 133 Padding-Data field in units of octets. 135 Reserved1 This field is unused. It MUST be initialized 136 to zero and MUST be ignored by the receiver. 138 Reserved2 This field is unused. It MUST be initialized 139 to zero and MUST be ignored by the receiver. 141 Boot-File-URL The URL for a boot file in string. Its 142 format MUST comply with [RFC3986]. 144 Padding-Data 0-7 octets of zeros for padding the encoding 145 of Boot-File-URL if required. Since the 146 length of option MUST be a multiple of 8 147 octets, for the minimum multiple, the 148 remaining octets following the encoding part 149 of Boot-File-URL MUST be padded with zeros. 151 3. Implementation Considerations 153 In the current format of BFURL option (Section 2.1), there is no 154 field defined to identify the architectures of nodes to be booted 155 from network. Implementers should be aware of the details of their 156 deployment environment and tailor the boot file to accommodate the 157 network booting nodes of different types. 159 A new IPv6 Router Solicitation (RS) option can be defined in the 160 future for nodes to send the information of architecture types they 161 support to the network side for the selection of appropriate boot 162 file. 164 Also, there is no field defined in the BFURL option nor any 165 individual option specified in this document for the network booting 166 parameters. We recommend that, the basic parameters required should 167 be embedded in the boot file itself. That can ease the configuration 168 of network booting functionality on the network devices. After the 169 boot file or the built-in application is successfully executed, they 170 should take the responsibility of guiding the subsequent phases of 171 installation. 173 This document puts no constraints on the protocols used to download 174 the boot file. While it is possible that the downloading protocol is 175 specified in the URL by syntax. 177 Domain names may be used in the boot file URL rather than an IPv6 178 address. That requires the network booting nodes to support DNS 179 implementation. The DNS server information can be also distributed 180 by RA options per [RFC8106]. 182 4. IANA Considerations 184 This document requires a new ND option type to be allocated. 186 Option Name Type 188 Boot-File-URL TBD. 190 5. Security Considerations 192 Rogue RA messages with wrong URL information may be received in the 193 untrusted environment and direct the network booting nodes to 194 download boot file from an attacker's file server. The Secure 195 Neighbor Discovery (SEND) protocol [RFC3971] is designed to allow all 196 ND options including the BFURL option specified in this document to 197 be sent with digital signature, which prevent this kind of attack. 199 To protect the boot file downloading process, using protocols like 200 HTTPS is recommended. Further, security mechanisms can be 201 implemented within the built-in application or the boot file to be 202 executed, to secure the communications in the later stage. 204 6. Acknowledgements 206 The authors would like to thank Jinhui, He Qiang for their comments 207 and inputs. 209 7. References 211 7.1. Normative References 213 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 214 Requirement Levels", BCP 14, RFC 2119, 215 DOI 10.17487/RFC2119, March 1997, 216 . 218 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 219 "SEcure Neighbor Discovery (SEND)", RFC 3971, 220 DOI 10.17487/RFC3971, March 2005, 221 . 223 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 224 Resource Identifier (URI): Generic Syntax", STD 66, 225 RFC 3986, DOI 10.17487/RFC3986, January 2005, 226 . 228 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 229 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 230 DOI 10.17487/RFC4861, September 2007, 231 . 233 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 234 Address Autoconfiguration", RFC 4862, 235 DOI 10.17487/RFC4862, September 2007, 236 . 238 [RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 239 "IPv6 Router Advertisement Options for DNS Configuration", 240 RFC 8106, DOI 10.17487/RFC8106, March 2017, 241 . 243 [UEFI23] UEFI Forum, "Unified Extensible Firmware Interface (UEFI) 244 Specification, Version 2.7 Errata A", August 2017, 245 . 247 7.2. Informative References 249 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 250 C., and M. Carney, "Dynamic Host Configuration Protocol 251 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 252 2003, . 254 [RFC4578] Johnston, M. and S. Venaas, Ed., "Dynamic Host 255 Configuration Protocol (DHCP) Options for the Intel 256 Preboot eXecution Environment (PXE)", RFC 4578, 257 DOI 10.17487/RFC4578, November 2006, 258 . 260 [RFC5970] Huth, T., Freimann, J., Zimmer, V., and D. Thaler, "DHCPv6 261 Options for Network Boot", RFC 5970, DOI 10.17487/RFC5970, 262 September 2010, . 264 Authors' Addresses 266 Chao Qin (editor) 267 Alibaba-Inc 268 P.R.China 270 Email: jacni@jacni.com 272 Yongqing Xi 273 Alibaba-Inc 274 P.R.China 276 Email: yongqing.xyq@alibaba-inc.com 278 Wei Xu 279 Alibaba-Inc 280 P.R.China 282 Email: arthur.xw@alibaba-inc.com