idnits 2.17.1 draft-ietf-avtcore-rfc5764-mux-fixes-05.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC5764]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The draft header indicates that this document updates RFC5764, but the abstract doesn't seem to directly say this. It does mention RFC5764 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). (Using the creation date from RFC5764, updated by this document, for RFC5378 checks: 2007-07-03) -- 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.) -- The document date (January 26, 2016) is 3012 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 5245 (Obsoleted by RFC 8445, RFC 8839) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5389 (Obsoleted by RFC 8489) ** Obsolete normative reference: RFC 5766 (Obsoleted by RFC 8656) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) -- Obsolete informational reference (is this intentional?): RFC 6982 (Obsoleted by RFC 7942) == Outdated reference: A later version (-54) exists of draft-ietf-mmusic-sdp-bundle-negotiation-23 Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AVTCORE M. Petit-Huguenin 3 Internet-Draft Impedance Mismatch 4 Updates: 5764 (if approved) G. Salgueiro 5 Intended status: Standards Track Cisco Systems 6 Expires: July 29, 2016 January 26, 2016 8 Multiplexing Scheme Updates for Secure Real-time Transport Protocol 9 (SRTP) Extension for Datagram Transport Layer Security (DTLS) 10 draft-ietf-avtcore-rfc5764-mux-fixes-05 12 Abstract 14 This document defines how Datagram Transport Layer Security (DTLS), 15 Real-time Transport Protocol (RTP), Real-time Transport Control 16 Protocol (RTCP), Session Traversal Utilities for NAT (STUN), and 17 Traversal Using Relays around NAT (TURN) packets are multiplexed on a 18 single receiving socket. It overrides the guidance from SRTP 19 Extension for DTLS [RFC5764], which suffered from three issues 20 described and fixed in this document. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on July 29, 2016. 39 Copyright Notice 41 Copyright (c) 2016 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Implicit Allocation of Codepoints for New STUN Methods . . . 4 59 4. Implicit Allocation of New Codepoints for TLS ContentTypes . 4 60 5. Multiplexing of TURN Channels . . . . . . . . . . . . . . . . 5 61 6. RFC 5764 Updates . . . . . . . . . . . . . . . . . . . . . . 6 62 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 8 63 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 64 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 65 9.1. STUN Methods . . . . . . . . . . . . . . . . . . . . . . 8 66 9.2. TLS ContentType . . . . . . . . . . . . . . . . . . . . . 9 67 9.3. TURN Channel Numbers . . . . . . . . . . . . . . . . . . 9 68 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 69 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 11.1. Normative References . . . . . . . . . . . . . . . . . . 10 71 11.2. Informative References . . . . . . . . . . . . . . . . . 11 72 Appendix A. Release notes . . . . . . . . . . . . . . . . . . . 11 73 A.1. Modifications between draft-ietf-avtcore-rfc5764-mux- 74 fixes-05 and draft-ietf-avtcore-rfc5764-mux-fixes-04 . . 12 75 A.2. Modifications between draft-ietf-avtcore-rfc5764-mux- 76 fixes-04 and draft-ietf-avtcore-rfc5764-mux-fixes-03 . . 12 77 A.3. Modifications between draft-ietf-avtcore-rfc5764-mux- 78 fixes-03 and draft-ietf-avtcore-rfc5764-mux-fixes-02 . . 12 79 A.4. Modifications between draft-ietf-avtcore-rfc5764-mux- 80 fixes-02 and draft-ietf-avtcore-rfc5764-mux-fixes-01 . . 12 81 A.5. Modifications between draft-ietf-avtcore-rfc5764-mux- 82 fixes-01 and draft-ietf-avtcore-rfc5764-mux-fixes-00 . . 12 83 A.6. Modifications between draft-ietf-avtcore-rfc5764-mux- 84 fixes-00 and draft-petithuguenin-avtcore-rfc5764-mux- 85 fixes-02 . . . . . . . . . . . . . . . . . . . . . . . . 13 86 A.7. Modifications between draft-petithuguenin-avtcore-rfc5764 87 -mux-fixes-00 and draft-petithuguenin-avtcore-rfc5764 88 -mux-fixes-01 . . . . . . . . . . . . . . . . . . . . . . 13 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 91 1. Introduction 93 Section 5.1.2 of Secure Real-time Transport Protocol (SRTP) Extension 94 for DTLS [RFC5764] defines a scheme for a Real-time Transport 95 Protocol (RTP) [RFC3550] receiver to demultiplex Datagram Transport 96 Layer Security (DTLS) [RFC6347], Session Traversal Utilities for NAT 97 (STUN) [RFC5389] and Secure Real-time Transport Protocol 98 (SRTP)/Secure Real-time Transport Control Protocol (SRTCP) [RFC3711] 99 packets that are arriving on the RTP port. Unfortunately, this 100 demultiplexing scheme has created problematic issues: 102 1. It implicitly allocated codepoints for new STUN methods without 103 an IANA registry reflecting these new allocations. 105 2. It implicitly allocated codepoints for new Transport Layer 106 Security (TLS) ContentTypes without an IANA registry reflecting 107 these new allocations. 109 3. It did not take into account the fact that the Traversal Using 110 Relays around NAT (TURN) usage of STUN can create TURN channels 111 that also need to be demultiplexed with the other packet types 112 explicitly mentioned in Section 5.1.2 of RFC 5764. 114 Having overlapping ranges between different IANA registries becomes 115 an issue when a new codepoint is allocated in one of these registries 116 without carefully anyalyzing the impact it could have on the other 117 registries when that codepoint is demultiplexed. Even if a codepoint 118 is not initially thought to be useful in an RFC 5764 implementation, 119 the respective IANA registry expert should at least raise a flag when 120 the allocated codepoint irrevocably prevents multiplexing. 122 The first goal of this document is to make sure that future 123 allocations in any of the affected protocols are done with the full 124 knowledge of their impact on multiplexing. This is achieved by 125 modifying the IANA registries with instructions for coordination 126 between the protocols at risk. 128 A second goal is to permit the addition of new protocols to the list 129 of existing multiplexed protocols in a manner that does not break 130 existing implementations. 132 The flaws in the demultiplexing scheme were unavoidably inherited by 133 other documents, such as [RFC7345] and 134 [I-D.ietf-mmusic-sdp-bundle-negotiation]. So in addition, these and 135 any other affected documents will need to be corrected with the 136 updates this document provides. 138 2. Terminology 140 The key words "MUST", "MUST NOT", "REQUIRED", "MAY", and "OPTIONAL" 141 in this document are to be interpreted as described in [RFC2119] when 142 they appear in ALL CAPS. When these words are not in ALL CAPS (such 143 as "must" or "Must"), they have their usual English meanings, and are 144 not to be interpreted as RFC 2119 key words. 146 3. Implicit Allocation of Codepoints for New STUN Methods 148 The demultiplexing scheme in [RFC5764] states that the receiver can 149 identify the packet type by looking at the first byte. If the value 150 of this first byte is 0 or 1, the packet is identified to be STUN. 151 The problem that arises as a result of this implicit allocation is 152 that this restricts the codepoints for STUN methods (as described in 153 Section 18.1 of [RFC5389]) to values between 0x000 and 0x07F, which 154 in turn reduces the number of possible STUN method codepoints 155 assigned by IETF Review (i.e., the range from (0x000 - 0x7FF) from 156 2048 to only 128 and eliminating the possibility of having STUN 157 method codepoints assigned by Designated Expert (i.e., the range 158 0x800 - 0xFFF). 160 To preserve the Designated Expert range, this document allocates the 161 value 2 and 3 to also identify STUN methods. 163 The IANA Registry for STUN methods is modified to mark the codepoints 164 from 0x100 to 0xFFF as Reserved. These codepoints can still be 165 allocated, but require IETF Review with a document that will properly 166 evaluate the risk of an assignment overlapping with other registries. 168 In addition, this document also updates the IANA registry such that 169 the STUN method codepoints assigned in the 0x080-0x0FF range are also 170 assigned via Designated Expert. The proposed changes to the STUN 171 Method Registry are: 173 OLD: 175 0x000-0x7FF IETF Review 176 0x800-0xFFF Designated Expert 178 NEW: 180 0x000-0x07F IETF Review 181 0x080-0x0FF Designated Expert 182 0x100-0xFFF Reserved 184 4. Implicit Allocation of New Codepoints for TLS ContentTypes 186 The demultiplexing scheme in [RFC5764] dictates that if the value of 187 the first byte is between 20 and 63 (inclusive), then the packet is 188 identified to be DTLS. The problem that arises is that this 189 restricts the TLS ContentType codepoints (as defined in Section 12 of 190 [RFC5246]) to this range, and by extension implicitly allocates 191 ContentType codepoints 0 to 19 and 64 to 255. With respect to TLS 192 packet identification, this document simply explicitly reserves the 193 codepoints from 0 to 19 and from 64 to 255. These codepoints can 194 still be allocated, but require Standards Action with a document that 195 will properly evaluate the risk of an assignment overlapping with 196 other registries. The proposed changes to the TLS ContentTypes 197 Registry are: 199 OLD: 201 0-19 Unassigned 202 20 change_cipher_spec 203 21 alert 204 22 handshake 205 23 application_data 206 24 heartbeat 207 25-255 Unassigned 209 NEW: 211 0-19 Reserved (Requires coordination, see RFCXXXX) 212 20 change_cipher_spec 213 21 alert 214 22 handshake 215 23 application_data 216 24 heartbeat 217 25-63 Unassigned 218 64-255 Reserved (Requires coordination, see RFCXXXX) 220 5. Multiplexing of TURN Channels 222 When used with ICE [RFC5245], an RFC 5764 implementation can receive 223 packets on the same socket from three different paths, as shown in 224 Figure 1: 226 1. Directly from the source 228 2. Through a NAT 230 3. Relayed by a TURN server 231 +------+ 232 | TURN |<------------------------+ 233 +------+ | 234 | | 235 | +-------------------------+ | 236 | | | | 237 v v | | 238 NAT ----------- | | 239 | | +---------------------+ | | 240 | | | | | | 241 v v v | | | 242 +----------+ +----------+ 243 | RFC 5764 | | RFC 5764 | 244 +----------+ +----------+ 246 Figure 1: Packet Reception by an RFC 5764 Implementation 248 Even if the ICE algorithm succeeded in selecting a non-relayed path, 249 it is still possible to receive data from the TURN server. For 250 instance, when ICE is used with aggressive nomination the media path 251 can quickly change until it stabilizes. Also, freeing ICE candidates 252 is optional, so the TURN server can restart forwarding STUN 253 connectivity checks during an ICE restart. 255 TURN channels are an optimization where data packets are exchanged 256 with a 4-byte prefix, instead of the standard 36-byte STUN overhead 257 (see Section 2.5 of [RFC5766]). The problem is that the RFC 5764 258 demultiplexing scheme does not define what to do with packets 259 received over a TURN channel since these packets will start with a 260 first byte whose value will be between 64 and 127 (inclusive). If 261 the TURN server was instructed to send data over a TURN channel, then 262 the current RFC 5764 demultiplexing scheme will reject these packets. 263 Current implementations violate RFC 5764 for values 64 to 127 264 (inclusive) and they instead parse packets with such values as TURN. 266 In order to prevent future documents from assigning values from the 267 unused range to a new protocol, this document modifies the RFC 5764 268 demultiplexing algorithm to properly account for TURN channels by 269 allocating the values from 64 to 79 for this purpose. 271 6. RFC 5764 Updates 273 This document updates the text in Section 5.1.2 of [RFC5764] as 274 follows: 276 OLD TEXT 277 The process for demultiplexing a packet is as follows. The receiver 278 looks at the first byte of the packet. If the value of this byte is 279 0 or 1, then the packet is STUN. If the value is in between 128 and 280 191 (inclusive), then the packet is RTP (or RTCP, if both RTCP and 281 RTP are being multiplexed over the same destination port). If the 282 value is between 20 and 63 (inclusive), the packet is DTLS. This 283 process is summarized in Figure 3. 285 +----------------+ 286 | 127 < B < 192 -+--> forward to RTP 287 | | 288 packet --> | 19 < B < 64 -+--> forward to DTLS 289 | | 290 | B < 2 -+--> forward to STUN 291 +----------------+ 293 Figure 3: The DTLS-SRTP receiver's packet demultiplexing algorithm. 294 Here the field B denotes the leading byte of the packet. 296 END OLD TEXT 298 NEW TEXT 300 The process for demultiplexing a packet is as follows. The receiver 301 looks at the first byte of the packet. If the value of this byte is 302 in between 0 and 3 (inclusive), then the packet is STUN. If the 303 value is between 20 and 63 (inclusive), then the packet is DTLS. If 304 the value is between 64 and 79 (inclusive), then the packet is TURN 305 Channel. If the value is in between 128 and 191 (inclusive), then 306 the packet is RTP (or RTCP, if both RTCP and RTP are being 307 multiplexed over the same destination port). If the value does not 308 match any known range then the packet MUST be dropped and an alert 309 MAY be logged. This process is summarized in Figure 3. 311 +----------------+ 312 | [0..3] -+--> forward to STUN 313 | | 314 packet --> | [20..63] -+--> forward to DTLS 315 | | 316 | [64..79] -+--> forward to TURN Channel 317 | | 318 | [128..191] -+--> forward to RTP 319 +----------------+ 321 Figure 3: The DTLS-SRTP receiver's packet demultiplexing algorithm. 323 END NEW TEXT 325 7. Implementation Status 327 [[Note to RFC Editor: Please remove this section and the reference to 328 [RFC6982] before publication.]] 330 This section records the status of known implementations of the 331 protocol defined by this specification at the time of posting of this 332 Internet-Draft, and is based on a proposal described in [RFC6982]. 333 The description of implementations in this section is intended to 334 assist the IETF in its decision processes in progressing drafts to 335 RFCs. Please note that the listing of any individual implementation 336 here does not imply endorsement by the IETF. Furthermore, no effort 337 has been spent to verify the information presented here that was 338 supplied by IETF contributors. This is not intended as, and must not 339 be construed to be, a catalog of available implementations or their 340 features. Readers are advised to note that other implementations may 341 exist. 343 According to [RFC6982], "this will allow reviewers and working groups 344 to assign due consideration to documents that have the benefit of 345 running code, which may serve as evidence of valuable experimentation 346 and feedback that have made the implemented protocols more mature. 347 It is up to the individual working groups to use this information as 348 they see fit". 350 Note that there is currently no implementation declared in this 351 section, but the intent is to add RFC 6982 templates here from 352 implementers that support the modifications in this document. 354 8. Security Considerations 356 This document updates existing IANA registries, adds a new range for 357 TURN channels in the demuxing algorithm, and madates an ascending 358 order for testing the ranges in the demuxing algorithm. 360 These modifications do not introduce any specific security 361 considerations beyond those detailed in [RFC5764]. 363 9. IANA Considerations 365 9.1. STUN Methods 367 This specification contains the registration information for reserved 368 STUN Methods codepoints, as explained in Section 3 and in accordance 369 with the procedures defined in Section 18.1 of [RFC5389]. 371 Value: 0x100-0xFFF 372 Name: Reserved (MUST be allocated with IETF Review. For DTLS-SRTP 373 multiplexing collision avoidance see RFC XXXX) 375 Reference: RFC5764, RFCXXXX 377 This specification also reassigns the ranges in the STUN Methods 378 Registry as follow: 380 Range: 0x000-0x07F 382 Registration Procedures: IETF Review 384 Range: 0x080-0x0FF 386 Registration Procedures: Designated Expert 388 9.2. TLS ContentType 390 This specification contains the registration information for reserved 391 TLS ContentType codepoints, as explained in Section 4 and in 392 accordance with the procedures defined in Section 12 of [RFC5246]. 394 Value: 0-19 396 Description: Reserved (MUST be allocated with Standards Action. 397 For DTLS-SRTP multiplexing collision avoidance see RFC XXXX) 399 DTLS-OK: N/A 401 Reference: RFC5764, RFCXXXX 403 Value: 64-255 405 Description: Reserved (MUST be allocated with Standards Action. 406 For DTLS-SRTP multiplexing collision avoidance see RFC XXXX) 408 DTLS-OK: N/A 410 Reference: RFC5764, RFCXXXX 412 9.3. TURN Channel Numbers 414 This specification contains the registration information for reserved 415 TURN Channel Numbers codepoints, as explained in Section 5 and in 416 accordance with the procedures defined in Section 18 of [RFC5766]. 418 Value: 0x5000-0xFFFF 419 Name: Reserved (For DTLS-SRTP multiplexing collision avoidance see 420 RFC XXXX) 422 Reference: RFCXXXX 424 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 425 document.] 427 10. Acknowledgements 429 The implicit STUN Method codepoint allocations problem was first 430 reported by Martin Thomson in the RTCWEB mailing-list and discussed 431 further with Magnus Westerlund. 433 Thanks to Simon Perreault, Colton Shields, Cullen Jennings, Colin 434 Perkins, Magnus Westerlund, Paul Jones, Jonathan Lennox, Varun Singh, 435 Justin Uberti and Paul Kyzivat for the comments, suggestions, and 436 questions that helped improve this document. 438 11. References 440 11.1. Normative References 442 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 443 Requirement Levels", BCP 14, RFC 2119, 444 DOI 10.17487/RFC2119, March 1997, 445 . 447 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 448 Jacobson, "RTP: A Transport Protocol for Real-Time 449 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 450 July 2003, . 452 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 453 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 454 RFC 3711, DOI 10.17487/RFC3711, March 2004, 455 . 457 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 458 (ICE): A Protocol for Network Address Translator (NAT) 459 Traversal for Offer/Answer Protocols", RFC 5245, 460 DOI 10.17487/RFC5245, April 2010, 461 . 463 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 464 (TLS) Protocol Version 1.2", RFC 5246, 465 DOI 10.17487/RFC5246, August 2008, 466 . 468 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 469 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 470 DOI 10.17487/RFC5389, October 2008, 471 . 473 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 474 Security (DTLS) Extension to Establish Keys for the Secure 475 Real-time Transport Protocol (SRTP)", RFC 5764, 476 DOI 10.17487/RFC5764, May 2010, 477 . 479 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 480 Relays around NAT (TURN): Relay Extensions to Session 481 Traversal Utilities for NAT (STUN)", RFC 5766, 482 DOI 10.17487/RFC5766, April 2010, 483 . 485 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 486 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 487 January 2012, . 489 11.2. Informative References 491 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 492 Code: The Implementation Status Section", RFC 6982, 493 DOI 10.17487/RFC6982, July 2013, 494 . 496 [RFC7345] Holmberg, C., Sedlacek, I., and G. Salgueiro, "UDP 497 Transport Layer (UDPTL) over Datagram Transport Layer 498 Security (DTLS)", RFC 7345, DOI 10.17487/RFC7345, August 499 2014, . 501 [I-D.ietf-mmusic-sdp-bundle-negotiation] 502 Holmberg, C., Alvestrand, H., and C. Jennings, 503 "Negotiating Media Multiplexing Using the Session 504 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 505 negotiation-23 (work in progress), July 2015. 507 Appendix A. Release notes 509 This section must be removed before publication as an RFC. 511 A.1. Modifications between draft-ietf-avtcore-rfc5764-mux-fixes-05 and 512 draft-ietf-avtcore-rfc5764-mux-fixes-04 514 o Removed some remnants of the ordering from Section 6 516 o Moved Terminology from Section 5 to Section 2 518 A.2. Modifications between draft-ietf-avtcore-rfc5764-mux-fixes-04 and 519 draft-ietf-avtcore-rfc5764-mux-fixes-03 521 o Removed Section on "Demultiplexing Algorithm Test Order" 523 o Split the Introduction into separate sections 525 A.3. Modifications between draft-ietf-avtcore-rfc5764-mux-fixes-03 and 526 draft-ietf-avtcore-rfc5764-mux-fixes-02 528 o Revert to the RFC 5389, as the stunbis reference was needed only 529 for STUN over SCTP. 531 A.4. Modifications between draft-ietf-avtcore-rfc5764-mux-fixes-02 and 532 draft-ietf-avtcore-rfc5764-mux-fixes-01 534 o Remove any discussion about SCTP until a consensus emerges in 535 TRAM. 537 A.5. Modifications between draft-ietf-avtcore-rfc5764-mux-fixes-01 and 538 draft-ietf-avtcore-rfc5764-mux-fixes-00 540 o Instead of allocating the values that are common on each registry, 541 the specification now only reserves them, giving the possibility 542 to allocate them in case muxing is irrelevant. 544 o STUN range is now 0-3m with 2-3 being Designated Expert. 546 o TLS ContentType 0-19 and 64-255 are now reserved. 548 o Add SCTP over UDP value. 550 o If an implementation uses the source IP address/port to separate 551 TURN channels packets then the whole channel numbers are 552 available. 554 o If not the prefix is between 64 and 79. 556 o First byte test order is now by incremental values, so failure is 557 deterministic. 559 o Redraw the demuxing diagram. 561 A.6. Modifications between draft-ietf-avtcore-rfc5764-mux-fixes-00 and 562 draft-petithuguenin-avtcore-rfc5764-mux-fixes-02 564 o Adoption by WG. 566 o Add reference to STUNbis. 568 A.7. Modifications between draft-petithuguenin-avtcore-rfc5764-mux- 569 fixes-00 and draft-petithuguenin-avtcore-rfc5764-mux-fixes-01 571 o Change affiliation. 573 Authors' Addresses 575 Marc Petit-Huguenin 576 Impedance Mismatch 578 Email: marc@petit-huguenin.org 580 Gonzalo Salgueiro 581 Cisco Systems 582 7200-12 Kit Creek Road 583 Research Triangle Park, NC 27709 584 US 586 Email: gsalguei@cisco.com