idnits 2.17.1 draft-wing-behave-nat64-referrals-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 130: '... An IPv6 node SHOULD also be able t...' RFC 2119 keyword, line 131: '...if it cannot, it SHOULD support STUN r...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 19, 2009) is 5301 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-11) exists of draft-ietf-behave-turn-ipv6-07 == Outdated reference: A later version (-15) exists of draft-ietf-sipping-nat-scenarios-09 -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BEHAVE Working Group D. Wing 3 Internet-Draft Cisco 4 Intended status: Informational October 19, 2009 5 Expires: April 22, 2010 7 Referrals Across an IPv6/IPv4 Translator 8 draft-wing-behave-nat64-referrals-01 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on April 22, 2010. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 This document describes several scenarios where an IP address is 47 referred across an IPv6/IPv4 translator. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Application Referrals Across IP Address Families . . . . . . . 3 53 2.1. SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2.1.1. SIP using a Media Relay . . . . . . . . . . . . . . . 4 55 2.1.2. SIP without a Media Relay . . . . . . . . . . . . . . 7 56 2.2. BitTorrent . . . . . . . . . . . . . . . . . . . . . . . . 9 57 2.3. SMTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 58 3. Security Considerations . . . . . . . . . . . . . . . . . . . 10 59 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 60 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 61 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 62 6.1. Normative References . . . . . . . . . . . . . . . . . . . 10 63 6.2. Informative References . . . . . . . . . . . . . . . . . . 10 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 66 1. Introduction 68 Historically, NATs (and firewalls) have been accused of "breaking 69 referrals". Several IPv4 protocols that perform referrals are 70 discussed, including SIP, BitTorrent, and HTTP. It is important to 71 understand how referrals can work across an address family translator 72 considering that existing IPv4 nodes do not understand IPv6 73 addresses, referrals to IPv6 nodes behind an IPv6/IPv4 translator 74 will not cause a DNS64 query, and other factors. 76 This document describes how referrals work in BEHAVE's "An IPv6 77 network to the IPv4 Internet" scenario. In this BEHAVE scenario, an 78 IPv6-only host utilizes a translator and a DNS64 address rewriter to 79 communicate to an IPv4-only host on the Internet. After this 80 communication is established, the document examines IPv6-only host 81 refers the IPv4-only host to a variety of other hosts that are 82 connected to the Internet. 84 This document is intended to assist the IETF community to understand 85 the scenarios where referrals across an IPv6/IPv4 translator are 86 successful. This document is not expected to be published as an RFC. 87 This document is part of the consideration for the IPv6 prefix 88 [I-D.xli-behave-v4v6-prefix] [I-D.baker-behave-v4v6-framework]. 90 2. Application Referrals Across IP Address Families 92 This section describes how some applications perform referrals 93 between IPv6 and IPv4, and between IPv4 and IPv6. 95 2.1. SIP 97 A SIP call involves two the SIP signaling, sent to SIP proxies, and 98 the media, sent directly between the SIP hosts. This is often 99 referred to as the SIP "trapezoid", as shown in the following figure. 101 This section shows that IPv4 addresses can be successfully referred 102 to both IPv4 hosts and to IPv6 hosts, if those IPv6 hosts support the 103 IPv6 transition strategy for SIP [I-D.ietf-sipping-v6-transition]. 104 Because an IPv6 address is not referred, the success is not dependent 105 on the IPv6/IPv4 translator's prefix (well-known prefix versus LIR 106 prefix). 108 SIP signaling 109 sip-proxy.example.com-------------------------sip-proxy.example.net 110 / \ 111 / \ 112 / SIP signaling SIP signaling \ 113 / \ 114 / \ 115 Host-A-----------------------------------------Host-B 116 media path 118 Figure 1: SIP Trapezoid 120 It is the media path which is interesting for SIP referrals and is 121 the subject of this section. The SIP signaling messages are 122 exchanged on the upper part of the trapezoid and is not the subject 123 of this section. The SIP signaling messages contain SDP [RFC4566] 124 which conveys the IP address and UDP port of the hosts as well as 125 other information (e.g., audio codec). 127 The IPv6 transition strategy for SIP [I-D.ietf-sipping-v6-transition] 128 states the requirements for the IPv6 transition: 130 An IPv6 node SHOULD also be able to send and receive media using 131 IPv4 addresses, but if it cannot, it SHOULD support STUN relay 132 usage [I-D.ietf-behave-turn-ipv6]. Such a relay allows the IPv6 133 node to indirectly send and receive media using IPv4. 135 Thus, all IPv6 nodes running SIP are expected to support ICE 136 [I-D.ietf-mmusic-ice] which allows simultaneous referral of multiple 137 IP addresses, even from different IP address families. IPv4-only 138 endpoints do not have to support ICE, although such support assists 139 both hosts by choosing the most optimal path (e.g., avoiding a media 140 relay). 142 There are two documented mechanisms for SIP endpoints to communicate 143 across IP address families. The first mechanism uses uses media 144 relays (TURN servers [I-D.ietf-behave-turn]) and is described in 145 Section 2.1.1. The second documented mechanism uses IPv6/IPv4 146 translators, does not use media relays, and is described in 147 Section 2.1.2. 149 2.1.1. SIP using a Media Relay 151 Section 4.2 of [I-D.ietf-sipping-v6-transition] documents how an 152 IPv6-only SIP endpoint can use a media relay (a TURN-IPv6 server) to 153 exchange media with an IPv4-only SIP endpoint. This can be 154 accomplished using two methods. 156 The first method is shown in Figure 2, where the Host-A (IPv6-only) 157 communicates with a TURN-IPV6 [I-D.ietf-behave-turn-ipv6] server 158 directly (that is, using IPv6). In this communication, Host-A 159 allocates a relayed-transport-address from the TURN server. This 160 relayed-transport-address is an IPv4 address. Host-A learned 161 Host-B's IPv4 address via SIP signaling. 163 +------------+ ------ +------------+ 164 | Host-A | +---------+ / IPv4 \ | Host-B | 165 |SIP endpoint+---+TURN-IPv6+-----|SIP endpoint| 166 | IPv6-only | | server | \______/ | IPv4-only | 167 +------------+ +---------+ +------------+ 169 <--IPv6----------------><---------- IPv4 ---------------> 171 Figure 2: SIP using IPv6-capable Media Relay 173 The second method is shown in Figure 3. This method is not mentioned 174 in Section 4.2 of [I-D.ietf-sipping-v6-transition] because NAT-PT was 175 deprecated at the time and IPv6/IPv4 translation was not yet on the 176 horizon. So it is discussed in this document. In this method, 177 Host-A (IPv6-only) communicates across an IPv6/IPv4 translator to an 178 TURN server. This TURN server might be IPv4-only. Host-A allocates 179 a relayed-transport-address IPv4 IPv4 address from the TURN server 180 and uses that IPv4 address to communicate with Host-B. Host-A 181 learned Host-B's IPv4 address via SIP signaling. 183 +-------+ 184 | IPv4 | 185 +------------+ | media | ------ +------------+ 186 | Host-A | +-----+ + relay | / IPv4 \ | Host-B | 187 |SIP endpoint+---+ 6/4 +--+ (TURN +-----|SIP endpoint| 188 | IPv6-only | +-----+ |server)| \______/ | IPv4-only | 189 +------------+ +-------+ +------------+ 191 <--IPv6------------><---------- IPv4 -------------------------> 193 Figure 3: SIP using IPv6/IPv4 Translator and IPv4 Media Relay 195 In both Figure 2 and Figure 3 Host-A (IPv6-only) obtains the IPv4 196 address of Host-B via SIP signaling and uses that address for any 197 later referrals. Media is exchanged between Host-A and Host-B 198 through the TURN server, which functions as a media relay. 200 The following sections detail what occurs when Host-A refers Host-B's 201 IP address to different hosts. These hosts are connected to the 202 Internet in different ways: to the IPv6 internet (both with and 203 without an IPv6/IPv4 translator) and to the IPv4 network. In a SIP 204 referral, Host-A sends a SIP message through SIP proxies to another 205 host. As with most SIP messages, this SIP message contains an SDP 206 [RFC4566] bodypart. The SDP has the IP address and UDP port of 207 Host-B which is used to exchange media with Host-B. 209 Note that, prior to the referral, Host-A does not know (and cannot 210 learn) how other hosts are connected to the Internet. 212 2.1.1.1. Referring to IPv4-only host (Host-D) 214 In both methods above, Host-A knows Host-B's IPv4 address. 216 If Host-A (IPv6-only) refers Host-B's IPv4 address to an IPv4-only 217 host, the referral will be successful. 219 2.1.1.2. Referring to IPv6-only or dual-stack host with Translator 220 (Host-B) 222 If Host-A (IPv6-only) refers Host-B's IPv4 address to an IPv6-only 223 host, the referral will succeed if Host-A's SIP stack understands 224 IPv4 addresses and can obtain an IPv4 address from a media relay 225 (similar to shown in Figure 3). 227 As part of the IPv6 transition, IPv6-only SIP implementations need to 228 understand IPv4 addresses, as already required (SHOULD) by IPv6 229 transition strategy for SIP [I-D.ietf-sipping-v6-transition]. 231 Thus, this referral is also successful. 233 2.1.1.3. Referring to IPv6-only or dual-stack host without Translator 235 If Host-A (IPv6-only) refers Host-B's IPv4 address to an IPv6-only 236 host, the referral will succeed if Host-A's SIP stack understands 237 IPv4 addresses and can obtain an IPv4 address from a media relay 238 (similar to shown in Figure 2). 240 As part of the IPv6 transition, IPv6-only SIP implementations need to 241 understand IPv4 addresses, as already required (SHOULD) by IPv6 242 transition strategy for SIP [I-D.ietf-sipping-v6-transition]. 244 Thus, this referral is also successful. 246 If Host-A (IPv6-only) refers Host-B's IPv4 address to an dual-stack 247 host, it will succeed because the dual-stack host will be able to 248 successfully use Host-B's IPv4 address. 250 2.1.2. SIP without a Media Relay 252 Section 6.2 of [I-D.ietf-sipping-nat-scenarios] describes an IPv6- 253 only SIP endpoint using an IPv6/IPv4 translator to exchange media 254 with an IPv4-only SIP endpoint. To do this, the IPv6-only SIP 255 endpoint implements ICE [I-D.ietf-mmusic-ice] and is configured with 256 a STUN server on the IPv4 side of the IPv6/IPv4 translator (that is, 257 on the IPv4 Internet). 259 This section analyzes how such an IPv6-only SIP endpoint, exchanging 260 media across an IPv6/IPv4 translator with an IPv4-only SIP endpoint, 261 would refer the synthesized IPv6 address to another SIP endpoint. 263 [[Editor's note: which of the two diagrams, below, is clearer?]] 265 In the following diagram all of the hosts belong to different ISPs: 266 Host-A Host-B 267 IPv6 only IPv6 only 268 | | 269 +----+----+ +-----+-----+ 270 | IPv6 | | IPv6 | 271 | Service | | Service | 272 | Provider| | Provider | 273 +-+--6/4--+ +--6/4----+-+ 274 | | | | 275 | +---------+ | | 276 | IPv4| |IPv4 | 277 IPv6| IPv6 | | | 278 | +-------------------+ 279 | | | | 280 | | | | 281 +--+---+-+ +---+-+---+ 282 | IPv6 | | IPv4 | 283 |Internet| | Internet| 284 +-+----+-+ +-+-+---+-+ 285 | | | | | 286 | | +------+ | +---+ 287 | | | | | 288 Host-F | | Host-C Host-D 289 IPv6-only | | IPv4-only IPv4-only 290 | | 291 Host-E 292 dual-stack 294 In the following diagram all of the hosts belong to different ISPs: 295 : 296 IPv6 Internet : IPv4 Internet 297 : 298 : 299 Host-A-------6/4 Translator Host-C 300 IPv6-only : IPv4-only 301 : 302 Host-B-------6/4 Translator Host-D 303 IPv6-only : IPv4-only 304 : 305 Host-F : 306 IPv6-only : 307 Host-E 308 dual-stack 309 : 311 In the following scenarios, Host-A (IPv6-only) is communicating with 312 Host-C through the IPv6/IPv4 translator device. Host-A knows 313 Host-C's synthetic IPv6 address (because it is sending traffic to it) 314 and Host-C's IPv4 address (because it received Host-C's IPv4 address 315 in SIP signaling). The following scenarios describe how referrals to 316 other nodes would function. 318 Note that, prior to the referral, Host-A does not know (and cannot 319 learn) how other hosts are connected to the Internet. 321 2.1.2.1. Referring to IPv4-only host (Host-D) 323 If Host-A refers to Host-D (IPv4-only), only the IPv4 address can be 324 successfully referred. The IPv6 address cannot be successfully 325 referred (no matter if well-known prefix or LIR prefix). 327 Thus, this referral is successful. 329 2.1.2.2. Referring to IPv6-only or dual-stack host with Translator 330 device (Host-B) 332 If it refers to Host-B (IPv6-only, using a different IPv6/IPv4 333 translator device) or to a dual-stack host (not shown) with an IPv6/ 334 IPv4 translator device in the service provider, the IPv4 referral is 335 also successful. It is successful because the IPv6-only host (with a 336 IPv6/IPv4 translator device) or the dual-stack host both have to be 337 able to communicate with IPv4 hosts, as required by IPv6 transition 338 strategy for SIP [I-D.ietf-sipping-v6-transition]. 340 2.1.2.3. Referring to IPv6-only or dual-stack host without Translator 341 device (Host-F) 343 If it refers to Host-F (IPv6-only, with no IPv6/IPv4 translator 344 device), the referral fails because Host-F cannot communicate with 345 any IPv4 hosts. This failure is expected, because not only would a 346 referral fail, but two hosts in two different IP address families 347 cannot initiate their own communication -- they need an address 348 family translator (or media relay) or one host needs to be dual- 349 stack. 351 If it refers to Host-E (dual-stack), the IPv4 address can be 352 successfully referred. 354 2.2. BitTorrent 356 BitTorrent trackers use HTTP URIs and DNS names. Thus, if an IPv6- 357 only host running a web browser can connect to an IPv4-only web site 358 using a translator (e.g., using IPv6/IPv4 translator and DNS64), that 359 same IPv6-only host running a BitTorrent client can connect to an 360 IPv4-only BitTorrent tracker. While some BitTorrent trackers are 361 beginning to track IPv6 addresses of BitTorrent peers, most trackers 362 only track IPv4 peers. Most content is only available on IPv4. 364 When an IPv6-only BitTorrent peer obtains IPv4 addresses from its 365 tracker, it cannot use those IPv4 addresses. To do so, the 366 BitTorrent client software would need to prefix the IPv4 address with 367 the prefix of a IPv6/IPv4 translator that will perform the necessary 368 address family translation on behalf of the IPv6-only BitTorrent 369 client. This could be done with updates to BitTorrent clients to 370 prefix the IPv4 address with the IPv6 prefix of a IPv6/IPv4 371 translator which will both authorize and route the communication to 372 the IPv4 BitTorrent peer. BitTorrent clients do not perform this 373 function today. 375 2.3. SMTP 377 A minority of SMTP [RFC5321] clients and SMTP servers support 551 to 378 redirect mail to another host, 380 551 User not local; please try . 382 If the includes an IPv4 address literal, the IPv6 host 383 will need to know how to formulate an IPv6 packet that will traverse 384 its IPv6/IPv4 translator. 386 3. Security Considerations 388 It is anticipated that an ISP would not allow non-customers to 389 utilize the ISP's IPv6/IPv4 translator device. 391 4. IANA Considerations 393 There are no IANA considerations for this document. 395 5. Acknowledgements 397 This draft was fostered by discussion with Marcelo Bagnulo Braun and 398 discussions on the BEHAVE mailing list. 400 Thanks to Mohamed Boucadair and Philip Matthews for their review 401 comments. Thanks to Scott Brim for suggesting HTTP redirect and 402 SMTP. 404 6. References 406 6.1. Normative References 408 [I-D.baker-behave-v4v6-framework] 409 Baker, F., Li, X., and C. Bao, "Framework for IPv4/IPv6 410 Translation", draft-baker-behave-v4v6-framework-02 (work 411 in progress), February 2009. 413 6.2. Informative References 415 [I-D.ietf-behave-turn] 416 Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using 417 Relays around NAT (TURN): Relay Extensions to Session 418 Traversal Utilities for NAT (STUN)", 419 draft-ietf-behave-turn-16 (work in progress), July 2009. 421 [I-D.ietf-behave-turn-ipv6] 422 Perreault, S., Camarillo, G., and O. Novo, "Traversal 423 Using Relays around NAT (TURN) Extension for IPv6", 424 draft-ietf-behave-turn-ipv6-07 (work in progress), 425 October 2009. 427 [I-D.ietf-mmusic-ice] 428 Rosenberg, J., "Interactive Connectivity Establishment 429 (ICE): A Protocol for Network Address Translator (NAT) 430 Traversal for Offer/Answer Protocols", 431 draft-ietf-mmusic-ice-19 (work in progress), October 2007. 433 [I-D.ietf-sipping-nat-scenarios] 434 Boulton, C., Rosenberg, J., Camarillo, G., and F. Audet, 435 "Best Current Practices for NAT Traversal for Client- 436 Server SIP", draft-ietf-sipping-nat-scenarios-09 (work in 437 progress), September 2008. 439 [I-D.ietf-sipping-v6-transition] 440 Camarillo, G., "IPv6 Transition in the Session Initiation 441 Protocol (SIP)", draft-ietf-sipping-v6-transition-07 (work 442 in progress), August 2007. 444 [I-D.xli-behave-v4v6-prefix] 445 Bao, C., Baker, F., and X. Li, "IPv4/IPv6 Translation 446 Prefix Recommendation", draft-xli-behave-v4v6-prefix-00 447 (work in progress), April 2009. 449 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 450 Description Protocol", RFC 4566, July 2006. 452 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 453 October 2008. 455 Author's Address 457 Dan Wing 458 Cisco Systems, Inc. 459 170 West Tasman Drive 460 San Jose, CA 95134 461 USA 463 Email: dwing@cisco.com