idnits 2.17.1 draft-cheshire-edns0-owner-option-01.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 (July 2, 2017) is 2487 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) ** Obsolete normative reference: RFC 2671 (Obsoleted by RFC 6891) == Outdated reference: A later version (-03) exists of draft-sekar-dns-ul-01 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Cheshire 3 Internet-Draft M. Krochmal 4 Intended status: Standards Track Apple Inc. 5 Expires: January 3, 2018 July 2, 2017 7 EDNS0 OWNER Option 8 draft-cheshire-edns0-owner-option-01.txt 10 Abstract 12 The DNS-SD Sleep Proxy Service uses a message format identical to 13 that used by standard DNS Update, with two additional pieces of 14 information: the identity of the sleeping server to which the records 15 belong, and the Wake-on-LAN Magic Packet bit pattern which should be 16 used to wake the sleeping server. This document specifies the EDNS0 17 option used to carry that additional information. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on January 3, 2018. 36 Copyright Notice 38 Copyright (c) 2017 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 1. Introduction 53 The EDNS0 'Owner' Option is used by the DNS-SD Sleep Proxy Service. 54 The DNS-SD Sleep Proxy Service [RFC6762] [RFC6763] uses a message 55 format identical to that used by standard DNS Update [RFC2136] 56 [RFC3007], with two additional pieces of information: the identity of 57 the sleeping server to which the records belong, and the Wake-on-LAN 58 Magic Packet [WoL] bit pattern which should be used to wake the 59 sleeping server. This document specifies the EDNS0 option [RFC2671] 60 used to carry that additional information. 62 The EDNS0 'Owner' Option is specified here with reference to the 63 DNS-SD Sleep Proxy Service, but could also be used for other purposes 64 not related to the Sleep Proxy Service. 66 2. Conventions and Terminology Used in this Document 68 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 69 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 70 "OPTIONAL" in this document are to be interpreted as described in 71 "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119]. 73 3. EDNS0 'Owner' Option 75 When a server that supports the DNS-SD Sleep Proxy protocol goes to 76 sleep, it communicates relevant DNS records, which describe its role 77 on the network, to the Sleep Proxy, in one or more DNS Update 78 messages [RFC2136] [RFC3007]. Typically these record registrations 79 with the Sleep Proxy do not last forever; they have a finite 80 lifetime, communicated using EDNS0 option 2 "DNS Update Lease" 81 [DNS-UL]. 83 When the Sleep Proxy observes traffic on the network which warrants 84 waking the sleeping server, it does so by sending a Wake-on-LAN 85 "Magic Packet" [WoL]. 87 A Wake-on-LAN "Magic Packet" consists of the following bit-pattern: 89 o Sync sequence: 48 binary 1s (i.e. 6 bytes of 0xFF) 91 o Sixteen repetitions of the 48-bit MAC address of the sleeping 92 server's network interface 94 o Optional 32-bit or 48-bit 'password' 95 When the Sleep Proxy determines that the sleeping server has awoken, 96 it can cease proxying for that server. 98 The Sleep Proxy needs to know the 48-bit MAC address (and possibly 99 32-bit or 48-bit 'password') to use to wake the sleeping server. 101 It also needs a way to determine when the sleeping server has awoken. 102 Because, when a sleeping server wakes it may be attached to the 103 network via a different interface (e.g. 802.11 wireless instead of 104 Ethernet), merely observing the source MAC address in the packets it 105 sends may not be sufficient to identify that this server on wireless 106 is the same server that moments earlier went to sleep while attached 107 via Ethernet. Also, merely observing packets apparently originating 108 from the sleeping server may not be sufficient to conclude reliably 109 that it has woken -- since these could be old packets, from before it 110 slept, that were delayed in transit. 112 The necessary information is communicated in the EDNS0 'Owner' 113 option: 115 o The 48-bit MAC address of the sleeping server's network interface 117 o Optional 32-bit or 48-bit 'password' 119 o A 48-bit value that uniquely identifies this machine regardless of 120 which interface it is using. Typically the MAC address of the 121 machine's 'primary' interface is used for this purpose. 123 o A sleep/wake sequence number. Each time the server wakes and 124 begins a new period of wakefulness, this sequence number is 125 incremented. If the Sleep Proxy observes the server send a packet 126 with the same sleep/wake sequence number as it saw in the proxy 127 registration, this is an old packet delayed in the network and 128 does not constitute evidence that the server has awoken. If the 129 Sleep Proxy observes the server send a packet with a different 130 sleep/wake sequence number then the Sleep Proxy can conclude that 131 the server has awoken and the proxy need not continue answering 132 for it. 134 3.1. EDNS0 'Owner' Option Format 136 A full EDNS0 'Owner' option has the following format: 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 |Opt|Len|V|S|Primary MAC|Wakeup MAC |Password | 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 The two-byte EDNS0 Option code 'Opt' for the 'Owner' option is 4. 144 The two-byte length field 'Len' for this option is 24 in the full- 145 length case, or less when using the "compact" variants described 146 below. 148 The one-byte version field 'V' is currently zero. In the current 149 version of the protocol, senders MUST set this field to zero on 150 transmission, and receivers receiving an EDNS0 option 4 where the 151 version field is not zero MUST ignore the entire option. 153 The one-byte sequence number field 'S' is set to zero the first time 154 this option is used after boot, and then after that incremented each 155 time the machine awakens from sleep. 157 The six-byte Primary MAC field identifies the machine. Typically, 158 the MAC address of the machine's 'primary' interface is used for this 159 purpose. 161 The six-byte pattern to be repeated 16 times in the wakeup packet. 162 This SHOULD be the MAC address of the interface through which the 163 packet containing this 'Owner' option is being sent. 165 The six-byte 'password' to be appended after the sixteen repetitions 166 of the MAC address. 168 3.2. Compact EDNS0 'Owner' Option Formats 170 Where the 'password' is only four bytes, a shorter format is used, 171 identified by the length field 'Len' having the value 22: 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 |Opt|Len|V|S|Primary MAC|Wakeup MAC |Passwd | (Len = 22) 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 When the 'password' is not required, it can be omitted entirely, 178 identified by the length field 'Len' having the value 18: 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 |Opt|Len|V|S|Primary MAC|Wakeup MAC | (Len = 18) 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 In the common case where the 'password' is not required and the 185 Primary MAC and Wakeup MAC are the same, both Wakeup MAC and password 186 may be omitted, identified by the length field 'Len' having the value 187 12: 189 +-+-+-+-+-+-+-+-+-+-+-+-+ 190 |Opt|Len|V|S|Primary MAC| (Len = 12) 191 +-+-+-+-+-+-+-+-+-+-+-+-+ 193 4. Acknowledgements 195 Thanks to Rory McGuire for his work Bonjour Sleep Proxy and 196 contributions to this document. 198 5. Security Considerations 200 When a Wake-on-LAN Magic Packet is sent to wake a machine up, it is 201 sent in the clear, making it vulnerable to eavesdropping. 203 6. IANA Considerations 205 The EDNS0 OPTION CODE 4 has been assigned for this DNS extension. 206 No additional IANA services are required by this document. 208 7. References 210 7.1. Normative References 212 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 213 Requirement Levels", BCP 14, RFC 2119, 214 DOI 10.17487/RFC2119, March 1997, 215 . 217 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", 218 RFC 2671, DOI 10.17487/RFC2671, August 1999, 219 . 221 7.2. Informative References 223 [DNS-UL] Sekar, K., "Dynamic DNS Update Leases", draft-sekar-dns- 224 ul-01 (work in progress), August 2006. 226 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 227 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 228 RFC 2136, DOI 10.17487/RFC2136, April 1997, 229 . 231 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic 232 Update", RFC 3007, DOI 10.17487/RFC3007, November 2000, 233 . 235 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 236 DOI 10.17487/RFC6762, February 2013, 237 . 239 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 240 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 241 . 243 [WoL] "Wake-on-LAN Magic Packet", 244 http://en.wikipedia.org/wiki/Wake-on-LAN, April 1997. 246 Authors' Addresses 248 Stuart Cheshire 249 Apple Inc. 250 1 Infinite Loop 251 Cupertino, California 95014 252 USA 254 Phone: +1 408 974 3207 255 Email: cheshire@apple.com 256 Marc Krochmal 257 Apple Inc. 258 1 Infinite Loop 259 Cupertino, California 95014 260 USA 262 Phone: +1 408 974 4368 263 Email: marc@apple.com