idnits 2.17.1 draft-finlayson-umtp-03.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-19) 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 420 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction 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 48 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** There are 135 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 396, 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' -- Possible downref: Non-RFC (?) normative reference: ref. '5' Summary: 13 errors (**), 0 flaws (~~), 3 warnings (==), 6 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.COM 3 Expire in six months 1998/09/29 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. Revision History 48 September 1998: draft-finlayson-umtp-03.txt 49 Added descriptions of two new commands: JOIN_RTP_GROUP 50 and LEAVE_RTP_GROUP, for optimizing the control of 51 RTP/RTCP sessions. 53 February 1998: draft-finlayson-umtp-02.txt 54 Rearranged the fields in the "encapsulation trailer" to allow for 55 possible variable-sized trailers in the future. 57 December 1997: draft-finlayson-umtp-01.txt 58 Changed the "encapsulation header" into an "encapsulation trailer". 59 Added 'cookie' fields to prevent source address spoofing. 61 December 1997: draft-finlayson-umtp-01.txt 62 Original draft. 64 4. Overview 66 UMTP operates using (unicast) UDP datagrams between pairs of nodes - each 67 pair forming the endpoints of a "tunnel". Each datagram is either a 68 "command" (e.g., instructing the destination endpoint to join or leave a 69 group address & port), or "data": an encapsulated multicast UDP datagram, 70 including a (group, port) tuple. 72 For each (group, port) being tunneled, a tunnel endpoint can act either as 73 a "master" or a "slave". A tunnel master (for a particular (group, port)) 74 periodically sends a JOIN_GROUP command to the remote endpoint (a slave), 75 instructing it that this (group, port) is still of interest, and should be 76 tunneled (or continue to be tunneled). A slave will stop tunneling a 77 (group, port) if it either (i) receives a LEAVE_GROUP command from the 78 master, or (ii) has not received any JOIN_GROUP commands for some period of 79 time (currently, 60 seconds). Typically, a host that is trying to access 80 the MBone (e.g., a PC) will be a master, and its remote endpoint (a host 81 already on the MBone) will be a slave. (It is also possible, however, for 82 both endpoints of a tunnel to be masters.) 84 Whenever a tunnel endpoint - whether a master or a slave - receives a 85 multicast UDP datagram addressed to a (group, port) that is currently being 86 tunneled, it encapsulates this datagram and sends it (as a unicast 87 datagram) to the other end of the tunnel. Conversely, whenever a tunnel 88 endpoint receives, over the tunnel, an encapsulated multicast datagram for 89 a (group, port) of interest, it decapsulates it and resends it as a 90 multicast datagram (with a TTL that was specified as a parameter in the 91 encapsulation). 93 A node (typically a slave server) can be the endpoint of several different 94 UMTP tunnels - i.e., each with a different endpoint master. Although, 95 superficially, such a system appears similar to a multicast<->unicast 96 reflector, it differs in two ways: 97 (i) The tunneling is application-independent, and handles any (UDP) 98 multicast packets 99 (ii) After traversing a tunnel, a decapsulated packet is delivered to the 100 endpoint's application(s) via multicast, not unicast. This allows regular 101 multicast-based applications to make use of a UMTP tunnels (subject to some 102 restrictions described below). 104 5. Restrictions 106 UMTP allows a multicast-capable - but otherwise non-MBone-connected - host 107 to run multicast-based applications. Such applications, however, must 108 satisfy the following conditions: 109 1/ Their multicast packets must all be UDP - not 'raw' IP 110 2/ The UMTP implementation (i.e., a tunnel endpoint) must have a way of 111 knowing each (group, port) that the application uses. 112 3/ The application must not rely upon the source address of its incoming 113 multicast packets being different for different original data sources. In 114 particular, the application must not use source addresses to identify these 115 original data sources. 117 Most multicast-based applications - especially those based on RTP [2] - 118 satisfy these requirements. If the multicast-based applications are 119 launched from a separate 'session directory' application, then the UMTP 120 implementation may be built into the session directory. For some multicast 121 applications, however, the (group, port) is not specified in advance, but 122 instead is determined by the application itself - e.g., by querying a 123 separate 'licensing' server. Depending on the host operating system, a 124 separate UMTP implementation might not be able to independently determine 125 this (group, port). In this case, UMTP could not be used, unless it were 126 incorporated into the application itself. 128 These application restrictions reinforce the point that UMTP should be used 129 *only* if full multicast routing cannot be provided instead. 131 6. Packet Format, and Command Codes 133 The payload of each UMTP datagram - i.e., excluding the outer UDP header - 134 consists of a 12-octet 'trailer' descriptor. For commands other than "DATA", 135 this descriptor makes up the entire UMTP payload. In the case of a "DATA" 136 command, however, this descriptor is also preceded by the data that is being 137 encapsulated (i.e., the original UDP payload). The format of the 'trailer' 138 descriptor is as follows: 140 0 1 2 3 141 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 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 | source cookie | destination cookie | 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 | (IPv4) multicast address | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | port | TTL |version|command| 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 Note that UMTP is defined only for IPv4. (In IPv6, native multicast routing 151 will be ubiquitous.) 153 "version" - the protocol version - is currently zero. 155 The following "command"s are currently defined: 156 0 (unused) 157 1 DATA 158 2 JOIN_GROUP 159 3 LEAVE_GROUP 160 4 TEAR_DOWN 161 5 PROBE 162 6 PROBE_ACK 163 7 PROBE_NACK 164 8 JOIN_RTP_GROUP 165 9 LEAVE_RTP_GROUP 166 10-15 (unused) 168 "source cookie" and "destination cookie" are used to protect against IP 169 source address spoofing, as described below. 171 Notes: 172 - The primary reason for having the encapsulated data appear *before* 173 the encapsulation descriptor is that the encapsulated data will 174 often be a RTP packet [2], and by retaining this data in its usual 175 position, IP/UDP/RTP header compression [3] - if present - will 176 work properly. A secondary reason is that this order may allow 177 UMTP implementations written in some type-safe programming 178 languages - such as Java - to reduce the amount of byte copying that 179 they would otherwise have to perform. Note that UMTP implementations 180 must allow for the possibility of the 'trailer' descriptor not being 181 aligned on a 4-byte boundary. 182 - The version/command fields always occupy the last byte of the data 183 payload. This allows for the possibility of having different-sized 184 encapsulation trailers (e.g., for trailer compression) in future 185 versions of this protocol. 187 7. Protocol Operation 189 For the purposes of describing the protocol, a tunnel endpoint has the 190 following state: 191 - a set E of allowable remote endpoints (each defined by a unicast 192 address & port). Each such endpoint, e, is also tagged with: 193 - localCookie_e: a hard-to-guess (e.g., random) 16-bit value 194 - remoteCookie_e: a 16-bit value (initially, some arbitrary value) 195 - a set G of active (group, port) tuples. Each such tuple, g, is also 196 tagged with: 197 - a flag F_g with one of two values: {"master", "slave"} 198 - a subset E_g of E: the tunnels that are members of g 199 - a default TTL T_g (the TTL to use if one is not otherwise known) 201 Also, for each tunnel endpoint, the following events of note may occur: 202 1/ The local node requests the joining of a (group, port) g, 203 with default TTL t 204 2/ The local node requests the leaving of a (group, port) g 205 3/ The local node sends a multicast packet to a (group, port) g, with TTL t 206 4/ A (non-local) multicast packet arrives for a (group, port) g, 207 with source address s 208 5/ A 'JOIN_GROUP timeout' occurs on a (group, port) g 209 6/ A tunneled UMTP packet arrives, with source address s, 210 and containing 'cookies' (srcCookie, dstCookie) 212 Each of these events is handled as follows: 214 1/ The local node requests the joining of a (group, port) g, 215 with default TTL t 216 add g to G; set F_g to "master"; set T_g to t 217 for each tunnel endpoint e in E_g, 218 send, to e, at 15 second intervals, a command 219 JOIN_GROUP(group, port, t, 220 srcCookie<-localCookie_e, 221 dstCookie<-remoteCookie_e) 223 2/ The local node requests the leaving of a (group, port) g 224 ignore this if g is not a member of G; otherwise: 225 if F_g is "master" 226 for each tunnel endpoint e in E_g, 227 cancel the ongoing periodic JOIN_GROUP commands 228 send, to e, a command 229 LEAVE_GROUP(group, port, 230 srcCookie<-localCookie_e, 231 dstCookie<-remoteCookie_e) 232 (The TTL field in the packet is unused) 233 (optional: Repeat this send several times) 234 remove g from G 236 3/ The local node sends a multicast packet to a (group, port) g, with TTL t 237 ignore this if g is not a member of G; otherwise: 238 for each tunnel endpoint e in E_g, 239 send, to e, a command 240 DATA(group, port, t-1, 241 srcCookie<-localCookie_e, 242 dstCookie<-remoteCookie_e) 243 with the original packet's data prepended 245 4/ A (non-local) multicast packet arrives for a (group, port) g, 246 with source address s 247 IMPORTANT (see below): If s is one of the endpoints e in E: 248 send, to e, a command 249 TEAR_DOWN(srcCookie<-localCookie_e, 250 dstCookie<-remoteCookie_e) 251 (the address, port, TTL fields are unused) 252 remove e from E 253 otherwise: 254 ignore this if g is not a member of G; otherwise: 255 if the TTL t of the incoming packet is not known: 256 set t to T_g 257 for each tunnel endpoint e in E_g, 258 send, to e, a command 259 DATA(group, port, t-1, 260 srcCookie<-localCookie_e, 261 dstCookie<-remoteCookie_e) 262 with the original packet's data prepended 264 5/ A 'JOIN_GROUP timeout' occurs on a (group, port) g 265 ignore this if g is not a member of G; otherwise: 266 if F_g is "slave" 267 remove g from G 269 6/ A tunneled UMTP packet arrives, with source address s, 270 and containing 'cookies' (srcCookie, dstCookie) 271 If s is not one of the endpoints e in E, ignore this packet 272 *unless* the "command" is PROBE, in which case: 273 replace the packet's "command" field with PROBE_NACK, 274 swap the packet's source and destination cookie fields 275 send the resulting packet back to s 276 continue normal processing 277 If dstCookie does *not* equal localCookie_s [*] 278 send, to s, a command 279 PROBE_ACK(srcCookie<-localCookie_s, 280 dstCookie<-the srcCookie from the packet) 281 (the address, port, TTL fields are ignored; they 282 should be given the same values as those in the 283 incoming packet) 284 continue normal processing 285 [*] (Note: An implementation may omit this check if it is sure 286 that source addresses incoming packets cannot be spoofed.) 287 Set remoteCookie_s <- srcCookie 288 Process the packet, based on the "command" field: 289 DATA(group, port, t) 290 set g to (group, port) 291 (Note: It is not required that g be a member of G.) 292 multicast the encapsulated (prepended) data to g, with TTL t 293 (optional: Instead limit the TTL; see below) 294 for each tunnel endpoint e in E_g, EXCEPT for s 295 send, to e, a command 296 DATA(group, port, t-1, 297 srcCookie<-localCookie_e, 298 dstCookie<-remoteCookie_e) 299 with the original packet's data prepended 300 JOIN_GROUP(group, port, t) 301 set g to (group, port) 302 ignore this if g is not a multicast address; otherwise: 303 if g is not already a member of G: 304 add g to G; set F_g to "slave"; set T_g to t 305 if F_g is "slave": 306 set a 'JOIN_GROUP timeout' to occur in 60 seconds time 307 (replacing any existing such timeout) 308 LEAVE_GROUP(group, port) 309 set g to (group, port) 310 ignore this if g is not a member of G; otherwise: 311 if F_g is "slave" 312 remove g from G 313 TEAR_DOWN 314 remove e from E 315 PROBE 316 send, to s, a command 317 PROBE_ACK(srcCookie<-localCookie_s, 318 dstCookie<-remoteCookie_s) 319 (the address, port, TTL fields are ignored; they 320 should be given the same values as those in the 321 incoming packet) 322 PROBE_ACK, PROBE_NACK 323 Ignore this packet (unless we have recently sent a PROBE) 324 Note: The PROBE command is one that a node can (optionally) 325 use to determine whether a prospective endpoint 326 exists, and if so, whether it would accept us as an 327 endpoint in turn. A PROBE can also be used, by a 328 master, to obtain the correct "remoteCookie" - via 329 the subsequent PROBE_ACK - prior to sending its 330 first JOIN_GROUP. 332 8. Relaying RTP/RTCP Sessions 334 RTP/RTCP sessions [2] use two ports: an even numbered port for RTP, and 335 an odd-numbered port (the next highest) for RTCP. These sessions could 336 be relayed using two separate JOIN_GROUP commands - one for each port. 338 As an alternative, the single command JOIN_RTP_GROUP can be used. 339 This command works exactly like JOIN_GROUP, except that it implicitly 340 specifies a pair of ports: the port in the command, and that port +1. 341 Similarly, the command LEAVE_RTP_GROUP can be used to stop relaying a 342 RTP/RTCP session, as an alternative to using two separate LEAVE_GROUPs. 344 A UMTP master should use JOIN_RTP_GROUP and LEAVE_RTP_GROUP only for 345 RTP/RTCP sessions - not for other kinds of sessions that also happen 346 to use port pairs. A UMTP implementation may handle these commands 347 especially, based upon the knowledge that they represent RTP/RTCP 348 sessions. For example, an implementation might wish to perform 349 RTP/RTCP-specific monitoring or statistics gathering, or to check the 350 RTP SSRC ("synchronization source") field in each incoming multicast 351 packet for possible collisions (i.e., in case two separate multicast 352 sources happen to be using the same SSRC, but have not yet detected 353 and corrected this themselves) [4]. 355 9. Loop Detection and Avoidance 357 A data loop may occur if the two endpoints of a UMTP tunnel are connected 358 by multicast, or via another UMTP tunnel elsewhere. Each UMTP 359 implementation must take steps to prevent a loop from occurring: 360 - When multicasting a decapsulated DATA packet, a UMTP implementation 361 should choose a TTL that's no larger than necessary. It must also ensure 362 that if this packet is then re-received (via loop-back), it is not resent 363 back over the same tunnel. 364 - If a UMTP implementation receives a multicast packet whose source address 365 is also the endpoint of a tunnel, it must immediately shut down this tunnel 366 (& send a TEAR_DOWN command to the endpoint) 367 - If a UMTP implementation is running on a node for which no more than one 368 tunnel is expected (e.g., the node is a non-MBone-connected PC), then this 369 implementation should attempt to ensure that no more than one tunnel can 370 be started on this note. (For example, the implementation could use 371 operating system-level locking to prevent more than one copy of itself 372 from running simultaneously.) 373 - If loops in the tunneling topology remain possible, then each end of 374 the tunnel should periodically send a short 'status' packet - containing 375 its unicast address - to a common multicast address, and also listen on 376 this address, checking the contents of each received status packet. 377 Should these contents be the same as its original status packet, it must 378 immediately shut down all of its tunnels. 379 (Note: These are the same loop detection techniques used by "mTunnel" [5] - 380 a similar multicast tunneling system, developed independently.) 382 10. Security Considerations 384 Each UMTP implementation should specify, in advance, its set of allowable 385 endpoints (E), and thus should not permit arbitrary nodes to form tunnels. 387 Tunnels are authenticated by IP source address. However, the 'cookie' 388 mechanism protects against source address spoofing. To enhance this 389 protection, an implementation may choose to occasionally change its 390 'localCookies' while it is running. (This should be done immediately prior 391 to sending a packet across the tunnel, so that the remote endpoint can 392 learn about the new cookie immediately.) 394 11. References 396 [1] LIVE.COM, 397 The "liveGate" multicast tunneling server 398 http://www.live.com/liveGate/ 399 [2] Schulzrinne, H., Casner, S., Frederick, R., and Jacobson, V., 400 "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, 401 January, 1996. 402 [3] Jacobson, V., Casner, S., 403 "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links" 404 Work-in-Progress, Internet-Draft "draft-ietf-avt-crtp-04.txt" 405 December, 1997. 406 [4] Casner, S., 407 Personal communication, December, 1997. 408 [5] Parnes, P., 409 "mTunnel" 410 http://www.cdt.luth.se/~peppar/progs/mTunnel/ 412 12. Author's Address 414 Ross Finlayson, 415 Live Networks, Inc. (LIVE.COM) 416 email: finlayson@live.com 417 WWW: http://www.live.com/