idnits 2.17.1 draft-finlayson-umtp-01.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 (2024-04-25) 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) 2024 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 1 longer page, the longest (page 1) being 372 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 50 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** There are 124 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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: '1' is defined on line 347, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Obsolete normative reference: RFC 1889 (ref. '2') (Obsoleted by RFC 3550) -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' Summary: 12 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Ross Finlayson 2 Internet-Draft Live Networks 3 Expire in six months 1997/12/30 5 The UDP Multicast Tunneling Protocol 7 9 1. Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working 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 19 material 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 ftp.is.co.za (Africa) , nic.nordu.net (Europe), 24 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast ), or 25 ftp.isi.edu (US West Coast). 27 2. Abstract 29 Many Internet hosts - such as PCs - while capable of running multicast 30 applications, cannot access the MBone because (i) the router(s) that 31 connect them to the Internet do not yet support IP multicast routing, and 32 (ii) their operating systems cannot support a tunneled implementation of IP 33 multicast routing. 35 The ''UDP Multicast Tunneling Protocol'' (UMTP) enables such a host to 36 establish an 'ad hoc' connection to the MBone by tunneling multicast UDP 37 datagrams inside unicast UDP datagrams. By using UDP, this tunneling can 38 be implemented as a 'user level' application, without requiring changes to 39 the host's operating system. It is important to note, however, that this 40 tunneling mechanism is *not* a substitute for proper multicast routing, and 41 should be used *only* in environments where multicast routing cannot be 42 used instead. This document describes this protocol, as is currently 43 implemented by the liveGate multicast tunneling server 44 (http://www.lvn.com/liveGate). 46 3. Overview 48 UMTP operates using (unicast) UDP datagrams between pairs of nodes - each 49 pair forming the endpoints of a "tunnel". Each datagram is either a 50 "command" (e.g., instructing the destination endpoint to join or leave a 51 group address & port), or "data": an encapsulated multicast UDP datagram, 52 including a (group, port) tuple. 54 For each (group, port) being tunneled, a tunnel endpoint can act either as 55 a "master" or a "slave". A tunnel master (for a particular (group, port)) 56 periodically sends a JOIN_GROUP command to the remote endpoint (a slave), 57 instructing it that this (group, port) is still of interest, and should be 58 tunneled (or continue to be tunneled). A slave will stop tunneling a 59 (group, port) if it either (i) receives a LEAVE_GROUP command from the 60 master, or (ii) has not received any JOIN_GROUP commands for some period of 61 time (currently, 60 seconds). Typically, a host that is trying to access 62 the MBone (e.g., a PC) will be a master, and its remote endpoint (a host 63 already on the MBone) will be a slave. (It is also possible, however, for 64 both endpoints of a tunnel to be masters.) 66 Whenever a tunnel endpoint - whether a master or a slave - receives a 67 multicast UDP datagram addressed to a (group, port) that is currently being 68 tunneled, it encapsulates this datagram and sends it (as a unicast 69 datagram) to the other end of the tunnel. Conversely, whenever a tunnel 70 endpoint receives, over the tunnel, an encapsulated multicast datagram for 71 a (group, port) of interest, it decapsulates it and resends it as a 72 multicast datagram (with a TTL that was specified as a parameter in the 73 encapsulation). 75 A node (typically a slave server) can be the endpoint of several different 76 UMTP tunnels - i.e., each with a different endpoint master. Although, 77 superficially, such a system appears similar to a multicast<->unicast 78 reflector, it differs in two ways: 79 (i) The tunneling is application-independent, and handles any (UDP) 80 multicast packets 81 (ii) After traversing a tunnel, a decapsulated packet is delivered to the 82 endpoint's application(s) via multicast, not unicast. This allows regular 83 multicast-based applications to make use of a UMTP tunnels (subject to some 84 restrictions described below). 86 4. Restrictions 88 UMTP allows a multicast-capable - but otherwise non-MBone-connected - host 89 to run multicast-based applications. Such applications, however, must 90 satisfy the following conditions: 91 1/ Their multicast packets must all be UDP - not 'raw' IP 92 2/ The UMTP implementation (i.e., a tunnel endpoint) must have a way of 93 knowing each (group, port) that the application uses. 94 3/ The application must not rely upon the source address of its incoming 95 multicast packets being different for different original data sources. In 96 particular, the application must not use source addresses to identify these 97 original data sources. 99 Most multicast-based applications - especially those based on RTP [2] - 100 satisfy these requirements. If the multicast-based applications are 101 launched from a separate 'session directory' application, then the UMTP 102 implementation may be built into the session directory. For some multicast 103 applications, however, the (group, port) is not specified in advance, but 104 instead is determined by the application itself - e.g., by querying a 105 separate 'licensing' server. Depending on the host operating system, a 106 separate UMTP implementation might not be able to independently determine 107 this (group, port). In this case, UMTP could not be used, unless it were 108 incorporated into the application itself. 110 These application restrictions reinforce the point that UMTP should be used 111 *only* if full multicast routing cannot be provided instead. 113 5. Packet Format, and Command Codes 115 The payload of each UMTP datagram - i.e., excluding the outer UDP header - 116 consists of a 12-octet 'trailer' descriptor. For commands other than "DATA", 117 this descriptor makes up the entire UMTP payload. In the case of a "DATA" 118 command, however, this descriptor is also preceded by the data that is being 119 encapsulated (i.e., the original UDP payload). The format of the 'trailer' 120 descriptor is as follows: 122 0 1 2 3 123 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 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 |version|command| TTL | port | 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 | (IPv4) multicast address | 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 | source cookie | destination cookie | 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 Note that UMTP is defined only for IPv4. (In IPv6, native multicast routing 133 will be ubiquitous.) 135 "version" - the protocol version - is currently zero. 137 The following "command"s are currently defined: 138 0 (unused) 139 1 DATA 140 2 JOIN_GROUP 141 3 LEAVE_GROUP 142 4 TEAR_DOWN 143 5 PROBE 144 6 PROBE_ACK 145 7 PROBE_NACK 146 8-15 (unused) 148 "source cookie" and "destination cookie" are used to protect against IP 149 source address spoofing, as described below. 151 Note: The primary reason for having the encapsulated data appear *before* 152 the encapsulation descriptor is that the encapsulated data will often 153 be a RTP packet [2], and by retaining this data in its usual position, 154 IP/UDP/RTP header compression [3] - if present - will work properly. 155 A secondary reason is that this order may allow UMTP implementations 156 written in some type-safe programming languages - such as Java - to reduce 157 the amount of byte copying that they would otherwise have to perform. 158 Note that UMTP implementations must allow for the possibility of the 159 'trailer' descriptor not being aligned on a 4-byte boundary. 161 6. Protocol Operation 163 For the purposes of describing the protocol, a tunnel endpoint has the 164 following state: 165 - a set E of allowable remote endpoints (each defined by a unicast 166 address & port). Each such endpoint, e, is also tagged with: 167 - localCookie_e: a hard-to-guess (e.g., random) 16-bit value 168 - remoteCookie_e: a 16-bit value (initially, some arbitrary value) 169 - a set G of active (group, port) tuples. Each such tuple, g, is also 170 tagged with: 171 - a flag F_g with one of two values: {"master", "slave"} 172 - a subset E_g of E: the tunnels that are members of g 173 - a default TTL T_g (the TTL to use if one is not otherwise known) 175 Also, for each tunnel endpoint, the following events of note may occur: 176 1/ The local node requests the joining of a (group, port) g, 177 with default TTL t 178 2/ The local node requests the leaving of a (group, port) g 179 3/ The local node sends a multicast packet to a (group, port) g, with TTL t 180 4/ A (non-local) multicast packet arrives for a (group, port) g, 181 with source address s 182 5/ A 'JOIN_GROUP timeout' occurs on a (group, port) g 183 6/ A tunneled UMTP packet arrives, with source address s, 184 and containing 'cookies' (srcCookie, dstCookie) 186 Each of these events is handled as follows: 188 1/ The local node requests the joining of a (group, port) g, 189 with default TTL t 190 add g to G; set F_g to "master"; set T_g to t 191 for each tunnel endpoint e in E_g, 192 send, to e, at 15 second intervals, a command 193 JOIN_GROUP(group, port, t, 194 srcCookie<-localCookie_e, 195 dstCookie<-remoteCookie_e) 197 2/ The local node requests the leaving of a (group, port) g 198 ignore this if g is not a member of G; otherwise: 199 if F_g is "master" 200 for each tunnel endpoint e in E_g, 201 cancel the ongoing periodic JOIN_GROUP commands 202 send, to e, a command 203 LEAVE_GROUP(group, port, 204 srcCookie<-localCookie_e, 205 dstCookie<-remoteCookie_e) 206 (The TTL field in the packet is unused) 207 (optional: Repeat this send several times) 208 remove g from G 210 3/ The local node sends a multicast packet to a (group, port) g, with TTL t 211 ignore this if g is not a member of G; otherwise: 212 for each tunnel endpoint e in E_g, 213 send, to e, a command 214 DATA(group, port, t-1, 215 srcCookie<-localCookie_e, 216 dstCookie<-remoteCookie_e) 217 with the original packet's data prepended 219 4/ A (non-local) multicast packet arrives for a (group, port) g, 220 with source address s 221 IMPORTANT (see below): If s is one of the endpoints e in E: 222 send, to e, a command 223 TEAR_DOWN(srcCookie<-localCookie_e, 224 dstCookie<-remoteCookie_e) 225 (the address, port, TTL fields are unused) 226 remove e from E 227 otherwise: 228 ignore this if g is not a member of G; otherwise: 229 if the TTL t of the incoming packet is not known: 230 set t to T_g 231 for each tunnel endpoint e in E_g, 232 send, to e, a command 233 DATA(group, port, t-1, 234 srcCookie<-localCookie_e, 235 dstCookie<-remoteCookie_e) 236 with the original packet's data prepended 238 5/ A 'JOIN_GROUP timeout' occurs on a (group, port) g 239 ignore this if g is not a member of G; otherwise: 240 if F_g is "slave" 241 remove g from G 243 6/ A tunneled UMTP packet arrives, with source address s, 244 and containing 'cookies' (srcCookie, dstCookie) 245 If s is not one of the endpoints e in E, ignore this packet 246 *unless* the "command" is PROBE, in which case: 247 replace the packet's "command" field with PROBE_NACK, 248 swap the packet's source and destination cookie fields 249 send the resulting packet back to s 250 continue normal processing 251 If dstCookie does *not* equal localCookie_s [*] 252 send, to s, a command 253 PROBE_ACK(srcCookie<-localCookie_s, 254 dstCookie<-the srcCookie from the packet) 255 (the address, port, TTL fields are ignored; they 256 should be given the same values as those in the 257 incoming packet) 258 continue normal processing 259 [*] (Note: An implementation may omit this check if it is sure 260 that source addresses incoming packets cannot be spoofed.) 261 Set remoteCookie_s <- srcCookie 262 Process the packet, based on the "command" field: 263 DATA(group, port, t) 264 set g to (group, port) 265 (Note: It is not required that g be a member of G.) 266 multicast the encapsulated (prepended) data to g, with TTL t 267 (optional: Instead limit the TTL; see below) 268 for each tunnel endpoint e in E_g, EXCEPT for s 269 send, to e, a command 270 DATA(group, port, t-1, 271 srcCookie<-localCookie_e, 272 dstCookie<-remoteCookie_e) 273 with the original packet's data prepended 274 JOIN_GROUP(group, port, t) 275 set g to (group, port) 276 ignore this if g is not a multicast address; otherwise: 277 if g is not already a member of G: 278 add g to G; set F_g to "slave"; set T_g to t 279 if F_g is "slave": 280 set a 'JOIN_GROUP timeout' to occur in 60 seconds time 281 (replacing any existing such timeout) 282 LEAVE_GROUP(group, port) 283 set g to (group, port) 284 ignore this if g is not a member of G; otherwise: 285 if F_g is "slave" 286 remove g from G 287 TEAR_DOWN 288 remove e from E 289 PROBE 290 send, to s, a command 291 PROBE_ACK(srcCookie<-localCookie_s, 292 dstCookie<-remoteCookie_s) 293 (the address, port, TTL fields are ignored; they 294 should be given the same values as those in the 295 incoming packet) 296 PROBE_ACK, PROBE_NACK 297 Ignore this packet (unless we have recently sent a PROBE) 298 Note: The PROBE command is one that a node can (optionally) 299 use to determine whether a prospective endpoint 300 exists, and if so, whether it would accept us as an 301 endpoint in turn. A PROBE can also be used, by a 302 master, to obtain the correct "remoteCookie" - via 303 the subsequent PROBE_ACK - prior to sending its 304 first JOIN_GROUP. 306 7. Loop Detection and Avoidance 308 A data loop may occur if the two endpoints of a UMTP tunnel are connected 309 by multicast, or via another UMTP tunnel elsewhere. Each UMTP 310 implementation must take steps to prevent a loop from occurring: 311 - When multicasting a decapsulated DATA packet, a UMTP implementation 312 should choose a TTL that's no larger than necessary. It must also ensure 313 that if this packet is then re-received (via loop-back), it is not resent 314 back over the same tunnel. 315 - If a UMTP implementation receives a multicast packet whose source address 316 is also the endpoint of a tunnel, it must immediately shut down this tunnel 317 (& send a TEAR_DOWN command to the endpoint) 318 - If a UMTP implementation is running on a node for which no more than one 319 tunnel is expected (e.g., the node is a non-MBone-connected PC), then this 320 implementation should attempt to ensure that no more than one tunnel can 321 be started on this note. (For example, the implementation could use 322 operating system-level locking to prevent more than one copy of itself 323 from running simultaneously.) 324 - If loops in the tunneling topology remain possible, then each end of 325 the tunnel should periodically send a short 'status' packet - containing 326 its unicast address - to a common multicast address, and also listen on 327 this address, checking the contents of each received status packet. 328 Should these contents be the same as its original status packet, it must 329 immediately shut down all of its tunnels. 330 (Note: These are the same loop detection techniques used by "mTunnel" [4] - 331 a similar multicast tunneling system, developed independently.) 333 8. Security Considerations 335 Each UMTP implementation should specify, in advance, its set of allowable 336 endpoints (E), and thus should not permit arbitrary nodes to form tunnels. 338 Tunnels are authenticated by IP source address. However, the 'cookie' 339 mechanism protects against source address spoofing. To enhance this 340 protection, an implementation may choose to occasionally change its 341 'localCookies' while it is running. (This should be done immediately prior 342 to sending a packet across the tunnel, so that the remote endpoint can 343 learn about the new cookie immediately.) 345 9. References 347 [1] Live Networks, Inc., 348 The "liveGate" multicast tunneling server 349 http://www.lvn.com/liveGate/ 350 [2] Schulzrinne, H., Casner, S., Frederick, R., and Jacobson, V., 351 "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, 352 January, 1996. 353 [3] Jacobson, V., Casner, S., 354 "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links" 355 Work-in-Progress, Internet-Draft "draft-ietf-avt-crtp-04.txt" 356 December, 1997. 357 [4] Parnes, P., 358 "mTunnel" 359 http://www.cdt.luth.se/~peppar/progs/mTunnel/ 361 10. Author's Address 363 Ross Finlayson, 364 Live Networks, Inc., 365 650 Castro Street, suite 120-196, 366 Mountain View, 367 CA 94041, 368 United States. 369 email: finlayson@lvn.com