idnits 2.17.1 draft-wing-dispatch-v6-migration-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 27, 2010) is 4990 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 3484 (Obsoleted by RFC 6724) == Outdated reference: A later version (-09) exists of draft-boucadair-mmusic-altc-00 == Outdated reference: A later version (-02) exists of draft-hutton-mmusic-icemicrolite-01 == Outdated reference: A later version (-07) exists of draft-ietf-mmusic-media-path-middleboxes-03 -- Obsolete informational reference (is this intentional?): RFC 4091 (Obsoleted by RFC 5245) -- Obsolete informational reference (is this intentional?): RFC 5245 (Obsoleted by RFC 8445, RFC 8839) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DISPATCH working group D. Wing 3 Internet-Draft A. Yourtchenko 4 Intended status: Standards Track Cisco 5 Expires: February 28, 2011 August 27, 2010 7 Migrating SIP to IPv6 Media Without Connectivity Checks 8 draft-wing-dispatch-v6-migration-00 10 Abstract 12 During the migration from IPv4 to IPv6, it is anticipated that an 13 IPv6 path might be broken for a variety of reasons, causing endpoints 14 to not receive RTP data. Connectivity checks would detect and avoid 15 the user noticing such a problem, but there is industry reluctance to 16 implement connectivity checks. 18 This document describes a mechanism allowing dual-stack SIP endpoints 19 to attempt communications over IPv6 and fall back to IPv4 if the IPv6 20 path is not working. The mechanism does not require connectivity 21 checks. 23 Status of this Memo 25 This Internet-Draft is submitted to IETF in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 This Internet-Draft will expire on February 28, 2011. 46 Copyright Notice 48 Copyright (c) 2010 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3 65 3. Operation for connectionless media (RTP over UDP) . . . . . . . 3 66 4. Operation, connection-oriented media (TCP) . . . . . . . . . . 4 67 5. Considerations for recvonly/sendonly/inactive . . . . . . . . . 5 68 6. Bandwidth, Delay, and Asymmetric Results . . . . . . . . . . . 5 69 7. Session Description Protocol . . . . . . . . . . . . . . . . . 5 70 8. Sending SIP Re-Invite . . . . . . . . . . . . . . . . . . . . . 6 71 9. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 72 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 73 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 74 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 75 12.1. Normative References . . . . . . . . . . . . . . . . . . . 7 76 12.2. Informational References . . . . . . . . . . . . . . . . . 7 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 79 1. Introduction 81 During the deployment of a dual-stack network and dual-stack SIP 82 endpoints, the IPv4 network is likely to remain more robust and 83 reliable than the newly-deployed IPv6 network. An IPv6 network might 84 be a disconnected island (not connected to another IPv6 network) or 85 due to human error a firewall rule or routing error might prevent two 86 IPv6 networks from communicating. Non-SIP applications and their 87 underlying hosts typically follow IPv6 address selection [RFC3484] 88 which prefers IPv6 over IPv4, but will try IPv4 after timing out 89 connection attempts to the IPv6 address. This timeout obvious 90 negative effects on the user's experience to such a degree that IPv6 91 has been avoided by many large content providers on the Internet 92 [whitelist]. 94 To achieve a similar function on the media plane, SIP endpoints are 95 expected to use connectivity checks [RFC5245] to ensure there is IPv6 96 (or IPv4) connectivity. ICE has an advantage over the technique 97 currently used by web browser, in that ICE does not wait for a user- 98 noticeable timeout before trying other addresses. However, ICE is 99 considered overkill for the problem of migrating to IPv6 because of 100 the overhead of timers, interaction with existing media state 101 machines, and CPU impact of SHA1 on large devices processing many 102 sessions and on small devices. 104 The mechanism described in this document avoids these problems by 105 combining the idea of "media-latching" (commonly used by SBCs, 106 [I-D.ietf-mmusic-media-path-middleboxes]) with the preference for 107 IPv6, while allowing dual-stack hosts the ability to fall back to 108 IPv4. In this way, dual-stack endpoints do not suffer broken media 109 if the IPv6 network between two endpoints is down. 111 2. Notational Conventions 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in [RFC2119]. 117 3. Operation for connectionless media (RTP over UDP) 119 Offers and Answers are constructed containing both IPv6 and IPv4 120 addresses, using an agreed-upon SDP syntax (see Section 7). When a 121 dual-stack SIP UA has media to send, it sends the media over IPv6, 122 while at the same time simultaneously sending T milliseconds worth of 123 data (Section 6) of the media over IPv4 using the same RTP sequence 124 numbers and timestamps as thats RTP data sent over IPv6. 126 Note: an alternative is for y% of packets to be sent over IPv6, 127 and x% of packets to be sent over IPv4 (x+y=100%). For example, 128 50%/50%, 90%/10%, or 10%/90%. This has an advantage that we don't 129 double the bandwidth used; however, it has the drawback that if 130 IPv6 is broken, it is noticeable to the user. 132 With two endpoints, Alice and Bob, there are four situations: 134 1. IPv6 from Alice to Bob is working and IPv6 from Bob to Alice is 135 working. This is the only situation handled by other proposed 136 techniques which do not perform connectivity checks. 138 2. IPv6 from Alice to Bob is working, but IPv6 from Bob to Alice is 139 failing 141 3. IPv6 from Alice to Bob is failing, but IPv6 from Bob to Alice is 142 working 144 4. IPv6 from Alice to Bob is failing, and IPv6 from Bob to Alice is 145 failing 147 The success scenario (1) is straightforward. To deal with the 148 failure scenarios (2-4), the following procedures are followed by the 149 endpoints: 151 If a SIP endpoints has received T/2 milliseconds worth of RTP data 152 over IPv4, and no packets over IPv6, it knows the IPv6 path from its 153 peer is not working (it is the receiving peer in scenario 2, 3, or 4, 154 above). It assumes the IPv6 path to its peer is also not working, 155 and assumes the IPv4 path to its peer is working. So, it ceases 156 sending RTP (and RTCP) over IPv6 and sends all subsequent RTP (and 157 RTCP) over IPv4. 159 If a SIP endpoint is sending RTP over IPv6 and receives ICMP hard or 160 soft errors, it immediately stops sending RTP over IPv6 and starts 161 sending RTP (and RTCP) over IPv4. ICMP errors received from sending 162 IPv4 are processed normally (they are usually ignored). 164 Both endpoints MUST support Symmetric RTP and RTCP [RFC4961], which 165 is already widely implemented and also a requirement of SBC 'media 166 latching' [I-D.ietf-mmusic-media-path-middleboxes]. 168 4. Operation, connection-oriented media (TCP) 170 First completed TCP handshake wins. [[To be completed.]] 172 5. Considerations for recvonly/sendonly/inactive 174 An endpoint only sends RTP when it normally needs to send RTP. Thus, 175 if an endpoint is currently in 'recvonly' or 'inactive', it won't 176 send RTP. However, it may of course be receiving RTP over IPv6 or 177 over IPv4. This provides an indication to the receiver that the 178 (incoming) IPv6 or IPv4 path is working. Just as if it was sending 179 RTP, the receipt of only IPvX indicates the IPvY path is broken. 180 Thus, when it does eventually need to send RTP packets, it SHOULD 181 only send using the working (IPvX) path. 183 6. Bandwidth, Delay, and Asymmetric Results 185 If IPv6 is not working and a switchover to IPv4 occurs, there will be 186 an audible artifact (or visible artifact, if using video). This can 187 be avoided by sending data simultaneously over IPv4 and over IPv6 188 until both ends see IPv6 traffic and both ends stop sending over 189 IPv4. However, this causes twice the bandwidth consumption at the 190 beginning of the phone call and is undesirable. That is why only "T" 191 milliseconds of traffic are proposed to be sent. 193 It is possible that IPv6 works in one direction but not the other. 194 This can result in a false positive on one endpoint. When this 195 occurs, the other endpoint will have received no IPv6 packets (but 196 will have received IPv4 packets), and will thus switch over to IPv4. 197 So, this is self correcting and the traffic will be sent over IPv4. 199 7. Session Description Protocol 201 A new SDP session-level attribute, happy-eardrums, is defined. It 202 contains one value, T, expressed in milliseconds. Presence of this 203 attribute indicates the endpoint supports the mechanism described in 204 this document. The happy-eardrums attribute adheres to the RFC 4566 205 "attribute" production. The ABNF syntax of happy-eardrums is 206 provided below: 208 he-attribute = "a=happy-eardrums=" he-value 209 he-value = 1*5DIGIT 211 Additionally, it is necessary to have SDP which encodes the IPv6 212 address and port. ANAT [RFC4091] has poor backwards compatibility 213 with devices that do not understand ANAT, thus it SHOULD NOT be used. 214 Superior to ANAT are the encodings described in 215 [I-D.hutton-mmusic-icemicrolite], [I-D.boucadair-mmusic-altc], and 216 [I-D.ietf-mmusic-sdp-capability-negotiation]. 218 However, for the mechanism in this draft to function, the Answer MUST 219 include both IPv6 and IPv4 addresses in its answer. All of the 220 existing mechanisms (enumerated above) do not provide this 221 functionality. For example, ANAT recommends the answerer set the 222 port number to 0 in the answer, and [I-D.hutton-mmusic-icemicrolite] 223 has the answer only include the candidate address family. Thus, 224 existing O/A procedures for communicating IPv6 address do not work, 225 as-is, with the mechanism proposed in this document. 227 Note: this draft is not dependent on any particular SDP encoding 228 of IPv6. But, of course, it does require that all end nodes use 229 the same SDP encoding of IPv6. A consensus on backwards- 230 compatible IPv6 SDP encoding still needs to be reached. 232 8. Sending SIP Re-Invite 234 To provide information to on-path devices that elevate the QoS for 235 certain flows, and to release resources on the other endpoint, an 236 endpoint MUST send a SIP re-INVITE after it has decided which IP 237 address family to use. [[details to be added.]] 239 9. Security Considerations 241 An attacker, sending UDP data on IPv6 to a newly-starting endpoint 242 within the negotiated T time, could cause the endpoint to think IPv6 243 is working when IPv6 is failing. 245 10. Acknowledgements 247 This idea was inspired from discussions with attendees and invitees 248 to the SIP/IPv6 Bar BoF at IETF78. 250 Thanks to Simon Perreault for his review. Thanks to Marc Petit- 251 Huguenin for his review, and for suggesting the 90%/10% media split. 252 Thanks to Muthu Perumal for suggesting re-invite after deciding which 253 address family works, and explaining problem with semantics of 254 current mechanisms to exchange IPv6 address in SDP. 256 The nickname of this draft is derived from Happy Eyeballs, which 257 provides quick delivery of IPv6 or IPv4 content to HTTP browsers 258 [I-D.wing-http-new-tech]. 260 11. IANA Considerations 262 Register new SDP attribute. 264 12. References 266 12.1. Normative References 268 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 269 Requirement Levels", BCP 14, RFC 2119, March 1997. 271 [RFC3484] Draves, R., "Default Address Selection for Internet 272 Protocol version 6 (IPv6)", RFC 3484, February 2003. 274 [RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", 275 BCP 131, RFC 4961, July 2007. 277 12.2. Informational References 279 [I-D.boucadair-mmusic-altc] 280 Boucadair, M., Kaplan, H., Gilman, R., and S. 281 Veikkolainen, "Session Description Protocol (SDP) 282 Alternate Connectivity (ALTC) Attribute", 283 draft-boucadair-mmusic-altc-00 (work in progress), 284 February 2010. 286 [I-D.hutton-mmusic-icemicrolite] 287 Hutton, A. and J. Elwell, "A mechanism for conveying 288 alternate addresses using ICE syntax", 289 draft-hutton-mmusic-icemicrolite-01 (work in progress), 290 March 2010. 292 [I-D.ietf-mmusic-media-path-middleboxes] 293 Stucker, B. and H. Tschofenig, "Analysis of Middlebox 294 Interactions for Signaling Protocol Communication along 295 the Media Path", 296 draft-ietf-mmusic-media-path-middleboxes-03 (work in 297 progress), July 2010. 299 [I-D.ietf-mmusic-sdp-capability-negotiation] 300 Andreasen, F., "SDP Capability Negotiation", 301 draft-ietf-mmusic-sdp-capability-negotiation-13 (work in 302 progress), March 2010. 304 [I-D.wing-http-new-tech] 305 Wing, D., Yourtchenko, A., and P. Natarajan, "Happy 306 Eyeballs: Trending Towards Success (IPv6 and SCTP)", 307 draft-wing-http-new-tech-01 (work in progress), 308 August 2010. 310 [RFC4091] Camarillo, G. and J. Rosenberg, "The Alternative Network 311 Address Types (ANAT) Semantics for the Session Description 312 Protocol (SDP) Grouping Framework", RFC 4091, June 2005. 314 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 315 (ICE): A Protocol for Network Address Translator (NAT) 316 Traversal for Offer/Answer Protocols", RFC 5245, 317 April 2010. 319 [whitelist] 320 Google, "Google IPv6 DNS Whitelist", March 2008, 321 . 323 Authors' Addresses 325 Dan Wing 326 Cisco Systems, Inc. 327 170 West Tasman Drive 328 San Jose, CA 95134 329 USA 331 Email: dwing@cisco.com 333 Andrew Yourtchenko 334 Cisco Systems, Inc. 335 6a de Kleetlaan 336 Diegem 1831 337 Belgium 339 Email: ayourtch@cisco.com