idnits 2.17.00 (12 Aug 2021) /tmp/idnits7367/draft-vyncke-v6ops-ipv6-only-thin-clients-00.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 : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 26, 2015) is 2514 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Operations E. Vyncke 3 Internet-Draft A. Yourtchenko 4 Intended status: Informational Cisco 5 Expires: December 28, 2015 D. Valenkamp 6 ETH Zurich 7 June 26, 2015 9 IPv6-Only for Wired Thin-Clients 10 draft-vyncke-v6ops-ipv6-only-thin-clients-00 12 Abstract 14 While IPv6-only (no IPv4 at all) is becoming an objective, there are 15 remaining issues on this road for the wired thin clients. This 16 document enumerates of couple of them; each with a short description, 17 followed by a description of the issue in IPv6-only networks then 18 some solutions. 20 It is expected that this document will grow by collecting other 21 roadblocks and suggestions to remove them. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on December 28, 2015. 40 Copyright Notice 42 Copyright (c) 2015 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Wake-on-Lan . . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Description . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.2. Issue . . . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.3. Mitigation . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Preboot Execution Environment . . . . . . . . . . . . . . . . 3 62 2.1. Description . . . . . . . . . . . . . . . . . . . . . . . 3 63 2.2. Issue . . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 2.3. Mitigation . . . . . . . . . . . . . . . . . . . . . . . 4 65 3. 3rd issue . . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 68 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 69 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 7.1. Normative References . . . . . . . . . . . . . . . . . . 4 71 7.2. Informative References . . . . . . . . . . . . . . . . . 5 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 74 1. Wake-on-Lan 76 1.1. Description 78 Wake-on-Lan also known as WOL is specified in [WOL]. It allows for a 79 remote operator to wake a sleeping host in order to trigger software 80 update while the host is sleeping (for example during the night of 81 the week-end). It consists of sending a specially formatted frame 82 for a specific host. This is called the magic packet: with the 83 Ethernet payload having somewhere 6 bytes containing 0xFF followed by 84 16 times the network interface datalink-layer address. 86 1.2. Issue 88 As the host is sleeping, it does not transmit any packets and will 89 not reply to neither ARP request nor Neighbor Solicitations. This 90 means that the adjacent routers have lost the binding between 91 datalink and network address and also that all layer-2 switches have 92 lost the binding between the datalink-layer address and the port/ 93 interface. So, it is not possible to send a unicast IPv4 or IPv6 94 packet containing this magic packet as it will be dropped by the 95 router (no adjacency information). In IPv4, a local configuration 96 can allow the 'directed broadcast' (see RFC2644 [RFC2644])such that 97 the magic packet can be sent to an IPv4 directed broadcast which will 98 be sent to a datalink-layer broadcast, i.e. forwarded on all ports of 99 all routers and switches in the same layer-2 domain. Therefore, the 100 magic packet will reach all hosts including the sleeping one. 102 In IPv6, there is no directed broadcast for good reason. Only a 103 link-local multicast group such as ff02::1 for all link-local hosts. 104 So, the magic packet for a single host could be sent to this 105 multicast group, reaching all link-local hosts (as switches and 106 routers will forward this packet to all ports/interfaces) and waking 107 up the sleeping node. But, there is no solution for a remote 108 operator to send this magic packet... 110 1.3. Mitigation 112 A trivial solution would be to hard code in the router configuration 113 a specific global or ULA address to the broadcast data-link layer 114 address. For example, to reach all nodes in 2001:db8::/64, let's 115 configure a static Neighbor Cache entry for 2001:db8::cafe:c0:ffee as 116 ff-ff-ff-ff-ff-ff. Then a remote operator can send the magic packet 117 to this destination, it will be routed across the layer-3 network, 118 will be addressed to the data-link layer broadcast address which will 119 be flooded by all layer-2 switches on all their ports, finally 120 reaching the sleeping host. 122 This approach has two drawbacks: 124 1. provisioning of all those mappings in all routers 126 2. opening a door to a denial of service attack: a remote hostile 127 party could keep sending packets this is specific unicast address 128 forcing all hosts to stay awake, hence wasting electrical energy. 129 As this address is a unicast address which does not belong to any 130 physical host on the layer-2 domain, then all nodes will silently 131 discard this packet at the layer-3. 133 Another approach would be to have a management plane command (SNMP or 134 Netconf) to send the magic packet directly to the Ethernet broadcast 135 using any ethertype. 137 2. Preboot Execution Environment 139 2.1. Description 141 Preboot Execution Environment also known as PXE is specified in 142 [PXE21]. It allows for any host to boot a complete viable operating 143 system and file system via the use of Dynamic Host Configuration 144 Protocol and ancilliary protocols such as Trivial File Transfer 145 Protocol and HyperText Transfer Protocol. 147 2.2. Issue 149 The specification has no mention of IPv6 and while DHCP and TFTP 150 support IPv6, there are differences between DHCP for IPv4 and for 151 IPV6. This lack of IPv6 support is addressed in RFC5970 [RFC5970] 152 but there are little to no implementation for this IPv6-enabled PXE. 153 This makes impossible for a thin-client host to boot its complete 154 operating system and file system over an IPv6-only network. 156 2.3. Mitigation 158 It is mainly an implementation issue in the boot PROM + DHCPv6 159 servers. Some of the boot PROMS use flash technology so they could 160 be reprogrammed to fully support RFC5970 [RFC5970] 162 On the other hand, PXE boot over IPv6 is possible: see [Zimmer2013], 163 relying on Unified Extensible Firmware Interface [UEFI]. 165 3. 3rd issue 167 Placeholder for any further issue to be described later. 169 4. IANA Considerations 171 This document contains no IANA considerations. 173 5. Security Considerations 175 The security considerations are detailed in previous sections. 177 6. Acknowledgements 179 The author would like to thank Armin Wittman, Alain Fiocco, Steve 180 Simlo, Stig Venaas for some discussions on this topic. 182 7. References 184 7.1. Normative References 186 [PXE21] Intel, , "Preboot Execution Environment (PXE) 187 Specification", 1999, 188 . 191 [RFC5970] Huth, T., Freimann, J., Zimmer, V., and D. Thaler, "DHCPv6 192 Options for Network Boot", RFC 5970, September 2010. 194 [UEFI] "Unified Extensible Firmware Interface Specification", 195 April 2015, 196 . 199 [WOL] AMD, , "Magic Packet Technology", 1995, 200 . 202 [Zimmer2013] 203 Zimmer, V., "Configuring an IPV6 network boot", October 204 2013, . 207 7.2. Informative References 209 [RFC2644] Senie, D., "Changing the Default for Directed Broadcasts 210 in Routers", BCP 34, RFC 2644, August 1999. 212 Authors' Addresses 214 Eric Vyncke 215 Cisco 216 De Kleetlaan 6a 217 Diegem 1831 218 Belgium 220 Phone: +32 2 778 4677 221 Email: evyncke@cisco.com 223 Andrew Yourtchenko 224 Cisco 225 De Kleetlaan 6a 226 Diegem 1831 227 Belgium 229 Phone: +32478681281 230 Email: ayourtch@cisco.com 231 Derk-Jan Valenkamp 232 ETH Zurich 233 Weinbergstrasse 43 234 Zurich 8092 235 Switzerland 237 Phone: +41 44 632 50 86 238 Email: derk-jan.valenkamp@id.ethz.ch