idnits 2.17.1 draft-finlayson-umtp-02.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 379 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 48 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** There are 125 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 353, 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 1998/02/15 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 | source cookie | destination cookie | 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 | (IPv4) multicast address | 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 | port | TTL |version|command| 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 Notes: 152 - The primary reason for having the encapsulated data appear *before* 153 the encapsulation descriptor is that the encapsulated data will 154 often be a RTP packet [2], and by retaining this data in its usual 155 position, IP/UDP/RTP header compression [3] - if present - will 156 work properly. A secondary reason is that this order may allow 157 UMTP implementations written in some type-safe programming 158 languages - such as Java - to reduce the amount of byte copying that 159 they would otherwise have to perform. Note that UMTP implementations 160 must allow for the possibility of the 'trailer' descriptor not being 161 aligned on a 4-byte boundary. 162 - The version/command fields always occupy the last byte of the data 163 payload. This allows for the possibility of having different-sized 164 encapsulation trailers (e.g., for trailer compression) in future 165 versions of this protocol. 167 6. Protocol Operation 169 For the purposes of describing the protocol, a tunnel endpoint has the 170 following state: 171 - a set E of allowable remote endpoints (each defined by a unicast 172 address & port). Each such endpoint, e, is also tagged with: 173 - localCookie_e: a hard-to-guess (e.g., random) 16-bit value 174 - remoteCookie_e: a 16-bit value (initially, some arbitrary value) 175 - a set G of active (group, port) tuples. Each such tuple, g, is also 176 tagged with: 177 - a flag F_g with one of two values: {"master", "slave"} 178 - a subset E_g of E: the tunnels that are members of g 179 - a default TTL T_g (the TTL to use if one is not otherwise known) 181 Also, for each tunnel endpoint, the following events of note may occur: 182 1/ The local node requests the joining of a (group, port) g, 183 with default TTL t 184 2/ The local node requests the leaving of a (group, port) g 185 3/ The local node sends a multicast packet to a (group, port) g, with TTL t 186 4/ A (non-local) multicast packet arrives for a (group, port) g, 187 with source address s 188 5/ A 'JOIN_GROUP timeout' occurs on a (group, port) g 189 6/ A tunneled UMTP packet arrives, with source address s, 190 and containing 'cookies' (srcCookie, dstCookie) 192 Each of these events is handled as follows: 194 1/ The local node requests the joining of a (group, port) g, 195 with default TTL t 196 add g to G; set F_g to "master"; set T_g to t 197 for each tunnel endpoint e in E_g, 198 send, to e, at 15 second intervals, a command 199 JOIN_GROUP(group, port, t, 200 srcCookie<-localCookie_e, 201 dstCookie<-remoteCookie_e) 203 2/ The local node requests the leaving of a (group, port) g 204 ignore this if g is not a member of G; otherwise: 205 if F_g is "master" 206 for each tunnel endpoint e in E_g, 207 cancel the ongoing periodic JOIN_GROUP commands 208 send, to e, a command 209 LEAVE_GROUP(group, port, 210 srcCookie<-localCookie_e, 211 dstCookie<-remoteCookie_e) 212 (The TTL field in the packet is unused) 213 (optional: Repeat this send several times) 214 remove g from G 216 3/ The local node sends a multicast packet to a (group, port) g, with TTL t 217 ignore this if g is not a member of G; otherwise: 218 for each tunnel endpoint e in E_g, 219 send, to e, a command 220 DATA(group, port, t-1, 221 srcCookie<-localCookie_e, 222 dstCookie<-remoteCookie_e) 223 with the original packet's data prepended 225 4/ A (non-local) multicast packet arrives for a (group, port) g, 226 with source address s 227 IMPORTANT (see below): If s is one of the endpoints e in E: 228 send, to e, a command 229 TEAR_DOWN(srcCookie<-localCookie_e, 230 dstCookie<-remoteCookie_e) 231 (the address, port, TTL fields are unused) 232 remove e from E 233 otherwise: 234 ignore this if g is not a member of G; otherwise: 235 if the TTL t of the incoming packet is not known: 236 set t to T_g 237 for each tunnel endpoint e in E_g, 238 send, to e, a command 239 DATA(group, port, t-1, 240 srcCookie<-localCookie_e, 241 dstCookie<-remoteCookie_e) 242 with the original packet's data prepended 244 5/ A 'JOIN_GROUP timeout' occurs on a (group, port) g 245 ignore this if g is not a member of G; otherwise: 246 if F_g is "slave" 247 remove g from G 249 6/ A tunneled UMTP packet arrives, with source address s, 250 and containing 'cookies' (srcCookie, dstCookie) 251 If s is not one of the endpoints e in E, ignore this packet 252 *unless* the "command" is PROBE, in which case: 253 replace the packet's "command" field with PROBE_NACK, 254 swap the packet's source and destination cookie fields 255 send the resulting packet back to s 256 continue normal processing 257 If dstCookie does *not* equal localCookie_s [*] 258 send, to s, a command 259 PROBE_ACK(srcCookie<-localCookie_s, 260 dstCookie<-the srcCookie from the packet) 261 (the address, port, TTL fields are ignored; they 262 should be given the same values as those in the 263 incoming packet) 264 continue normal processing 265 [*] (Note: An implementation may omit this check if it is sure 266 that source addresses incoming packets cannot be spoofed.) 267 Set remoteCookie_s <- srcCookie 268 Process the packet, based on the "command" field: 269 DATA(group, port, t) 270 set g to (group, port) 271 (Note: It is not required that g be a member of G.) 272 multicast the encapsulated (prepended) data to g, with TTL t 273 (optional: Instead limit the TTL; see below) 274 for each tunnel endpoint e in E_g, EXCEPT for s 275 send, to e, a command 276 DATA(group, port, t-1, 277 srcCookie<-localCookie_e, 278 dstCookie<-remoteCookie_e) 279 with the original packet's data prepended 280 JOIN_GROUP(group, port, t) 281 set g to (group, port) 282 ignore this if g is not a multicast address; otherwise: 283 if g is not already a member of G: 284 add g to G; set F_g to "slave"; set T_g to t 285 if F_g is "slave": 286 set a 'JOIN_GROUP timeout' to occur in 60 seconds time 287 (replacing any existing such timeout) 288 LEAVE_GROUP(group, port) 289 set g to (group, port) 290 ignore this if g is not a member of G; otherwise: 291 if F_g is "slave" 292 remove g from G 293 TEAR_DOWN 294 remove e from E 295 PROBE 296 send, to s, a command 297 PROBE_ACK(srcCookie<-localCookie_s, 298 dstCookie<-remoteCookie_s) 299 (the address, port, TTL fields are ignored; they 300 should be given the same values as those in the 301 incoming packet) 302 PROBE_ACK, PROBE_NACK 303 Ignore this packet (unless we have recently sent a PROBE) 304 Note: The PROBE command is one that a node can (optionally) 305 use to determine whether a prospective endpoint 306 exists, and if so, whether it would accept us as an 307 endpoint in turn. A PROBE can also be used, by a 308 master, to obtain the correct "remoteCookie" - via 309 the subsequent PROBE_ACK - prior to sending its 310 first JOIN_GROUP. 312 7. Loop Detection and Avoidance 314 A data loop may occur if the two endpoints of a UMTP tunnel are connected 315 by multicast, or via another UMTP tunnel elsewhere. Each UMTP 316 implementation must take steps to prevent a loop from occurring: 317 - When multicasting a decapsulated DATA packet, a UMTP implementation 318 should choose a TTL that's no larger than necessary. It must also ensure 319 that if this packet is then re-received (via loop-back), it is not resent 320 back over the same tunnel. 321 - If a UMTP implementation receives a multicast packet whose source address 322 is also the endpoint of a tunnel, it must immediately shut down this tunnel 323 (& send a TEAR_DOWN command to the endpoint) 324 - If a UMTP implementation is running on a node for which no more than one 325 tunnel is expected (e.g., the node is a non-MBone-connected PC), then this 326 implementation should attempt to ensure that no more than one tunnel can 327 be started on this note. (For example, the implementation could use 328 operating system-level locking to prevent more than one copy of itself 329 from running simultaneously.) 330 - If loops in the tunneling topology remain possible, then each end of 331 the tunnel should periodically send a short 'status' packet - containing 332 its unicast address - to a common multicast address, and also listen on 333 this address, checking the contents of each received status packet. 334 Should these contents be the same as its original status packet, it must 335 immediately shut down all of its tunnels. 336 (Note: These are the same loop detection techniques used by "mTunnel" [4] - 337 a similar multicast tunneling system, developed independently.) 339 8. Security Considerations 341 Each UMTP implementation should specify, in advance, its set of allowable 342 endpoints (E), and thus should not permit arbitrary nodes to form tunnels. 344 Tunnels are authenticated by IP source address. However, the 'cookie' 345 mechanism protects against source address spoofing. To enhance this 346 protection, an implementation may choose to occasionally change its 347 'localCookies' while it is running. (This should be done immediately prior 348 to sending a packet across the tunnel, so that the remote endpoint can 349 learn about the new cookie immediately.) 351 9. References 353 [1] Live Networks, Inc., 354 The "liveGate" multicast tunneling server 355 http://www.lvn.com/liveGate/ 356 [2] Schulzrinne, H., Casner, S., Frederick, R., and Jacobson, V., 357 "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, 358 January, 1996. 359 [3] Jacobson, V., Casner, S., 360 "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links" 361 Work-in-Progress, Internet-Draft "draft-ietf-avt-crtp-04.txt" 362 December, 1997. 363 [4] Parnes, P., 364 "mTunnel" 365 http://www.cdt.luth.se/~peppar/progs/mTunnel/ 367 10. Author's Address 369 Ross Finlayson, 370 Live Networks, Inc., 371 650 Castro Street, suite 120-196, 372 Mountain View, 373 CA 94041, 374 United States. 375 email: finlayson@lvn.com 376 WWW: http://www.lvn.com/