Network Working Group | C. Qin, Ed. |
Internet-Draft | Y. Xi |
Intended status: Standards Track | W. Xu |
Expires: August 24, 2019 | Alibaba-Inc |
February 20, 2019 |
IPv6 Router Advertisement Option for Network Boot
draft-qin-6man-nb-option-03
This document specifies an IPv6 Router Advertisement (RA) option (called "Boot File URL option") to allow IPv6 routers to advertise configuration information for booting a node from the network.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on August 24, 2019.
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
This document describes an IPv6 Neighbor Discovery (ND) option (called BFURL option) that can be used to provide configuration information for nodes to be booted from network instead of local media.
IPv6 Stateless Address Autoconfiguration (SLAAC) [RFC4862] and IPv6 Neighbor Discovery (ND) [RFC4861] define ways to configure IPv6 addresses, on-link prefix list, default routers and other parameters.
The existing ND message (RA) is used to carry this network boot information. Nodes can get the boot file url and parameters through RA messages via BFRUL option. A boot file can be a boot-loader program or a minimal OS kernel. The node firmware needs to download the boot file and execute it.
This approach is useful in networks with no DHCPv6 infrastructure. The intention is to simplify the implementation of first-stage communicating functionalities of the nodes (i.e. PXE firmware), and network. The distribution of additional information and subsequent communications between the node and network side (e.g., an install server) should be handled by applications built in the boot file.
The configuration of a Boot-File-URL would be required onto routers sending RA messages. The configuration mechanism (manual or automatic) is out of scope of this document.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
The option formats comply with ND options per [RFC4861].
Routers send this option to nodes with a URL to a boot file.
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | P-Len | Reserved1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Boot-File-URL (variable length) ~ | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+ Padding-Data (optional, 0-7 octets) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1
Fields description:
In the current format of BFURL option (Section 2.1), there is no field defined to identify the architectures of nodes to be booted from network. Implementers should be aware of the details of their deployment environment and tailor the boot file to accommodate the network booting nodes of different types.
A new IPv6 Router Solicitation (RS) option can be defined in the future for nodes to send the information of architecture types they support to the network side for the selection of appropriate boot file.
Also, there is no field defined in the BFURL option nor any individual option specified in this document for the network booting parameters. We recommend that, the basic parameters required should be embedded in the boot file itself. That can ease the configuration of network booting functionality on the network devices. After the boot file or the built-in application is successfully executed, they should take the responsibility of guiding the subsequent phases of installation.
This document puts no constraints on the protocols used to download the boot file. While it is possible that the downloading protocol is specified in the URL by syntax.
Domain names may be used in the boot file URL rather than an IPv6 address. That requires the network booting nodes to support DNS implementation. The DNS server information can be also distributed by RA options per [RFC8106].
This document requires a new ND option type to be allocated.
Rogue RA messages with wrong URL information may be received in the untrusted environment and direct the network booting nodes to download boot file from an attacker's file server. The Secure Neighbor Discovery (SEND) protocol [RFC3971] is designed to allow all ND options including the BFURL option specified in this document to be sent with digital signature, which prevent this kind of attack.
To protect the boot file downloading process, using protocols like HTTPS is recommended. Further, security mechanisms can be implemented within the built-in application or the boot file to be executed, to secure the communications in the later stage.
The authors would like to thank Jinhui, He Qiang for their comments and inputs.
[RFC3315] | Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2003. |
[RFC4578] | Johnston, M. and S. Venaas, "Dynamic Host Configuration Protocol (DHCP) Options for the Intel Preboot eXecution Environment (PXE)", RFC 4578, DOI 10.17487/RFC4578, November 2006. |
[RFC5970] | Huth, T., Freimann, J., Zimmer, V. and D. Thaler, "DHCPv6 Options for Network Boot", RFC 5970, DOI 10.17487/RFC5970, September 2010. |