idnits 2.17.00 (12 Aug 2021) /tmp/idnits47073/draft-ietf-mboned-sntp-heart-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2022-05-14) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 6 longer pages, the longest (page 2) being 66 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 6 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 111 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 164 instances of too long lines in the document, the longest one being 3 characters in excess of 72. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == There are 5 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 12 has weird spacing: '...), its areas...' == Line 13 has weird spacing: '... its worki...' == Line 17 has weird spacing: '... and may ...' == Line 18 has weird spacing: '...afts as refer...' == Line 21 has weird spacing: '... To learn...' == (106 more instances...) -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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: '2' is defined on line 271, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1769 (ref. '1') (Obsoleted by RFC 2030, RFC 4330) == Outdated reference: draft-ietf-idmr-igmp-mib has been published as RFC 2933 Summary: 13 errors (**), 0 flaws (~~), 13 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MBONE Deployment Working Group Bernard Aboba 3 INTERNET-DRAFT Microsoft Corporation 4 Thomas Pfenning 5 23 October 1996 Microsoft Corporation 7 The Use of SNTP as a Multicast Heartbeat 9 1. Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working docu- 12 ments of the Internet Engineering Task Force (IETF), its areas, and 13 its working groups. Note that other groups may also distribute work- 14 ing documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference mate- 19 rial or to cite them other than as ``work in progress.'' 21 To learn the current status of any Internet-Draft, please check the 22 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 23 Directories on ds.internic.net (US East Coast), nic.nordu.net 24 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 26 The distribution of this memo is unlimited. It is filed as , and expires May 1, 1997. Please send 28 comments to the authors. 30 2. Abstract 32 This document describes how the Simple Network Time Protocol (SNTP) 33 can be used to provide a multicast heartbeat. Given the current state 34 of the art in multicast diagnostics, use of a heartbeat may prove a 35 useful diagnostic tool for operators as well as for applications 36 developers. Operators may use the heartbeat to alert themselves to 37 losses of multicast connectivity in portions of the network. Applica- 38 tions developers may use the heartbeat to determine whether to enable 39 multicast features or to default to unicast operation. In the long 40 term, better solutions (such as improved IGMP diagnostics) are likely 41 to become available, so that a multicast heartbeat is unlikely to have 42 long-term utility. 44 3. Introduction 46 3.1. Problem statement 48 Today an increasing number of applications support both multicast and 49 unicast modes of operation. Typically these applications default to 50 unicast mode, switching to multicast mode on explicit instructions 51 from the user. However, it is also possible to initially put an 52 application into multicast mode, join a group, then wait to receive 53 packets on the group. If packets arrive, then the application is left 54 in multicast mode; otherwise, after a suitable timeout interval, the 55 application is switched to unicast mode. However, this approach is 56 usually not satisfactory since join latencies of several minutes are 57 common. 59 Another issue arises with multicast applications running over dialup 60 connections. In this case, applications are typically unaware of the 61 state of the dialup interface; it is possible for the dialup connec- 62 tion to go down or come up again, possibly with a new IP address 63 assignment, without the application being notified. In such a case, 64 the IGMP state of the dialup interface may be cleared, leaving the 65 dialup interface without any group memberships. Thus the host will not 66 respond to subsequent IGMP membership queries on the dialup interface, 67 even though the application believes that its group memberships per- 68 sist. 70 3.2. Alternative solutions 72 The problems described above have several solutions, including: 74 Use of a multicast heartbeat 75 IGMP membership query detection 76 Use of multicast diagnostic tools, such as mtrace 77 SNMP queries 78 Additional IGMP messages 80 3.2.1. Use of a multicast heartbeat group 82 Both of the problems described above can be addressed by use of a mul- 83 ticast heartbeat. A heartbeat group is a group to which routers and 84 NAS devices are continually subscribed, providing low join latencies. 85 On startup, routers and applications looking to determine whether they 86 have multicast connectivity can listen to the heartbeat group. Since 87 the gateway router or NAS device is already subscribed to the heart- 88 beat group, a host joining the group will experience low join latency, 89 allowing an application to quickly determine whether to enable multi- 90 cast features. Once it has determined that multicast connectivity is 91 available, the application can close the connection, which (assuming 92 the host is IGMP v2 capable) may result in the host leaving the heart- 93 beat group. 95 Similarly, in the case where a dialup interface goes down and the 96 application stops receiving packets on the multicast group, after a 97 suitable interval, the application can listen for the presence of the 98 multicast heartbeat. If it does not receive the heartbeat, it may 99 then conclude that IGMP membership state has been lost, and should 100 close and reopen multicast sockets. 102 3.2.2. IGMP membership query detection 104 While IGMP membership queries do not provide information on the state 105 of multicast connectivity, they do provide an indication that a multi- 106 cast-capable router is present on the network. This information, were 107 it to be made available to an application, could be used to determine 108 whether to enable multicast features. 110 Unfortunately for applications developers, current programming inter- 111 faces do not provide applications with this information. 113 3.2.3. Use of multicast diagnostics 115 Application-initiated mtrace queries could readily be used by applica- 116 tions to determine connectivity to specific groups. Alternatively, 117 periodic mtrace queries with a multicast response address could be 118 used to provide a heartbeat on the mtrace group 224.0.1.32, 119 mtrace.mcast.net. However, these responses would take up considerably 120 more bandwidth than SNTP, and it is doubtful that the additional 121 information provided by mtrace would be useful in this context. 123 3.2.4. SNMP queries 125 The IGMP MIB, described in [3] provides access to the IGMP Interface 126 Table as well as to the IGMP Cache Table. This could be used to deter- 127 mine whether a router is multicast-capable. 129 However, while SNMP information is typically available to a management 130 station operated by a NOC, it is usually not made available to appli- 131 cations running on arbitrary hosts. 133 3.2.5. Additional IGMP messages 135 Today the Internet gets along quite well without a unicast heartbeat. 136 So we would do well to ask ourselves "why do we not need a unicast 137 heartbeat?" The answer is that we have ICMP messages to indicate when 138 a host, network or port is unreachable. As a result, applications 139 receive timely indications of connectivity problems, and can respond 140 appropriately. 142 Not only are there no equivalent ICMP error messages for multicast, 143 but it is expressly forbidden to generate ICMP messages in response to 144 a packet with a multicast destination. As a result, a host has no 145 immediate way of determining that its join request is being sent on a 146 non-multicast capable network. 148 However, it may be desirable to provide for additional diagnostic 149 capabilities within IGMP. Such facilities could include a means for 150 retrieving the IGMP Interface Table as well as the IGMP Cache Table. 151 Were such facilities to be required of all multicast-capable routers, 152 then a host could determine the state of multicast connectivity via an 153 IGMP query. It is believed that this is the best long-term solution to 154 the problem. 156 4. Use of SNTP as a multicast heartbeat 158 While it is likely that better diagnostic methods will become avail- 159 able in the long term, given the current state of the art, use of a 160 multicast heartbeat may prove useful. If such a heartbeat is needed, 161 then the Simple Network Time Protocol (SNTP) appears ideal for this 162 purpose. 164 SNTP was created in order to support synchronization of clocks on the 165 Internet in situations where the high precision of the Network Time 166 Protocol (NTP) is not required. SNTP supports unicast, broadcast, and 167 multicast modes. Unicast mode provides for clock synchronization via a 168 client/server interaction, and is typically used prior to initiation 169 of multicast mode. In multicast mode, the SNTP server periodically 170 sends the time to a designated multicast group, and clients listen to 171 the messages, but do not reply. Existing SNTP implementations typi- 172 cally support all three modes, and allow for adjusting both the send- 173 ing interval as well as the destination port. 175 With SNTP it is possible to multicast to an address with global scope 176 or to an administratively scoped address. For example, reference [1] 177 describes SNTP use of the group address 224.0.1.1 as well as UDP port 178 123 for both the source and destination ports. In addition, use of an 179 address in the administratively scoped region may also be desirable. 180 The use of separate heartbeats for global and administratively scoped 181 addresses allows an application to determine if multicast connectivity 182 is available, and if so, whether it is global or exists only within 183 the administratively scoped region. 185 Today we face a scarcity of multicast diagnostic tools suitable for 186 use by Network Operations Centers. By enabling routers as SNTP listen- 187 ers, and adding one or more SNMP MIB variables, the ability to monitor 188 multicast connectivity on a network-wide basis can be enhanced. 190 5. Implementation issues 192 5.1. Address allocation and group announcements 194 In cases where a firewall is used, multicast connectivity may be 195 restricted to the administratively scoped region. In this case, lis- 196 tening to the SNTP multicast group (224.0.1.1) will not allow an 197 application or device to determine whether it has multicast connectiv- 198 ity. It will also need to listen to an equivalent group within the 199 administratively scoped region. 201 Currently there is no static multicast group allocated for use of SNTP 202 within the administratively scoped region. As a result, an announce- 203 ment mechanism (such as that provided by SAP) can be used to announce 204 the heartbeat group in the administratively scoped region. 206 5.2. Use by clients and network devices 208 In order to provide the desired heartbeats, an SNTP server will typi- 209 cally be operated within the administratively scoped region, as well 210 as on the global Internet. On startup, network devices such as routers 211 or NASes will join 224.0.1.1 as well as the administratively scoped 212 SNTP group, and will listen to SNTP multicasts on UDP port 123. Having 213 routers and NASes as perennial members of the heartbeat group is nec- 214 essary in order to guarantee low latency for host join requests. 216 On startup, host applications will typically join both the 224.0.1.1 217 group as well as the administratively scoped heartbeat group, and will 218 listen on UDP port 123. Should they not receive the expected SNTP 219 multicasts within 15 seconds (three heartbeat periods), they may then 220 conclude that multicast connectivity is not available, and take action 221 accordingly. These actions could include defaulting to unicast opera- 222 tion, or presenting a dialog indicating the failure to detect multi- 223 cast connectivity. If multicast connectivity is detected, the applica- 224 tion may then close the connection. 226 Similarly, after not receiving packets on a multicast group for at 227 least 30 seconds, an application may once again listen for the multi- 228 cast heartbeat. If it does not receive the expected SNTP multicasts 229 within 15 seconds, it may conclude that multicast connectivity has 230 been lost, and take action accordingly. These actions could include 231 closing and reopening multicast sockets (in case dialup connectivity 232 was lost), or presenting a dialog indicating the loss of signal. 234 5.3. Security issues 236 The use of SNTP as a multicast heartbeat makes it a target for mali- 237 cious individuals interested in disrupting network operation. As noted 238 in [1], it is possible for any SNTP server to send to the 224.0.1.1 239 group address. As a result, client implementations will need to check 240 the authenticity of the source. This should be accomplished by check- 241 ing the source IP address, as well as by taking advantage of the 242 authenticator field within SNTP. 244 5.4. Bandwidth consumption 246 A major concern with implementation of a heartbeat capability is the 247 resulting bandwidth consumption, and CPU utilization. Since the SNTP 248 heartbeat described in this document would be implemented by a variety 249 of network devices, it will consume bandwidth on an Internet-wide 250 basis. In addition, determining the authenticity of the SNTP multicast 251 heartbeat requires use of public-key cryptography, and can take as 252 long as several hundred milliseconds. 254 As defined in [1], the SNTP packet is 60 octets in length. This when 255 added to the 28 octet IP/UDP header gives a total packet size of 88 256 octets. In order to keep bandwidth consumption to an minimum, we rec- 257 ommend that the interval between SNTP multicasts be set to 5 seconds 258 or greater. Keeping to these guidelines will keep the SNTP bandwidth 259 consumption under 200 bps. 261 6. Acknowledgements 263 Thanks to Tom Blank of Microsoft and Louis Mamakos of UUNET for many 264 useful discussions of this problem space. 266 7. References 268 [1] D. Mills. "Simple Network Time Protocol." RFC 1769, University 269 of Delaware, March 1995. 271 [2] S.E. Deering. "Host Extensions for IP Multicasting." RFC 1112, 272 Stanford University, August, 1989. 274 [3] K. McCloughrie, D. Farinacci. "Internet Group Management Proto- 275 col MIB." draft-ietf-idmr-igmp-mib-03.txt, cisco Systems, June 1996. 277 8. Authors' Addresses 279 Bernard Aboba 280 Microsoft Corporation 281 One Microsoft Way 282 Redmond, WA 98052 284 Phone: 206-936-6605 285 EMail: bernarda@microsoft.com 287 Thomas Pfenning 288 Microsoft Corporation 289 One Microsoft Way 290 Redmond, WA 98052 292 Phone: 206-703-4830 293 EMail: thomaspf@microsoft.com