idnits 2.17.1 draft-dmudric-sipcore-sipv6-addr-selection-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Found new IETF Trust Provisions of 12 Sep 2009 boilerplate, which is fine, but *also* found old boilerplate from RFC 2026, Section lax.claim on line 41. ** The document seems to lack a Notice of Compliance with BCP 78 and BCP 79 according to IETF Trust Provisions of 28 Dec 2009, Section 6.a or Provisions of 12 Sep 2009, Section 6.a. ** 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? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. == 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 21) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 34 instances of too long lines in the document, the longest one being 14 characters in excess of 72. ** The abstract seems to contain references ([RFC5220]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Hb SHOULD not only change the first hop router but also expire its 2000::102 address, and select its 3000::102 as the source address to reach Ha over SERd. -- The document date (January 2020) is 1557 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) -- Missing reference section? 'RFC5220' on line 17 looks like a reference -- Missing reference section? 'RFC8028' on line 203 looks like a reference -- Missing reference section? 'RFC6724' on line 258 looks like a reference -- Missing reference section? 'Internet' on line 515 looks like a reference -- Missing reference section? 'SITE-1' on line 527 looks like a reference -- Missing reference section? 'SITE-2' on line 527 looks like a reference -- Missing reference section? 'SITE 1' on line 414 looks like a reference -- Missing reference section? 'SITE 2' on line 414 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPCORE WG 3 Internet Draft D. Mudric 4 Avaya 5 D. Grebovich 6 Avaya 7 Expires: June 2020 January 2020 9 SIPv6 Headers and SDP Media Line Address Selection on Multihomed Hosts 10 draft-dmudric-sipcore-sipv6-addr-selection-00 12 Abstract 14 In the networks where multihomed hosts can have ULA and GUA addresses 15 from different ISPs, multiple SIP signaling and media connectivity 16 issues might arise due to inappropriate address selections. Some of 17 the problems are described in [RFC5220]. Since SIP and SDP allow IP 18 addresses to be embedded into their headers and lines, even if proper 19 addresses are selected initially, SIP is not equipped with the 20 mechanisms to respond to network events, and transition transport to 21 reachable addresses. As a result, SIP messages and media might be 22 filtered by routers, or discarded as unreachable destinations. 24 SIP protocol (RFC 3261) defines signaling messages and their headers. 25 This document describes how a multihomed host should select addresses 26 for SIP headers, like Contact and Via, to be reachable destinations. 27 Host SHOULD change a default router for uplink failures, remove 28 prefixes and addresses for unreachable ISP, and update contact 29 address list. 31 SDP protocol (RFC 3264) defines how participants in a session select 32 their parameters. This document describes how an offerer and answerer 33 on multihomed hosts should select their addresses. If one of the 34 selected addresses becomes unreachable, the document describes the 35 mechanism how a new one should be selected and renegotiated. 37 Status of this Memo 39 This document is an Internet-Draft and is in full conformance with 40 all provisions of Section 10 of RFC2026 except that the right to 41 produce derivative works is not granted. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF), its areas, and its working groups. Note that 45 other groups may also distribute working documents as Internet- 46 Drafts. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 The list of current Internet-Drafts can be accessed at 54 http://www.ietf.org/ietf/1id-abstracts.txt 55 The list of Internet-Draft Shadow Directories can be accessed at 56 http://www.ietf.org/shadow.html. 58 Copyright Notice 60 Copyright (c) 2019 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust’s Legal 63 Provisions Relating to IETF Documents 64 (https://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with respect 67 to this document. Code Components extracted from this document must 68 include Simplified BSD License text as described in Section 4.e of 69 the Trust Legal Provisions and are provided without warranty as 70 described in the Simplified BSD License. 72 Conventions used in this document 74 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 75 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 76 document are to be interpreted as described in RFC-2119 [i]. 78 Table of Contents 80 1. Introduction...................................................3 81 2. Terminology....................................................3 82 3. Problem Statement..............................................4 83 3.1 Network Topology...........................................4 84 3.1.1 Ingress filtered signaling source address & Non optimal data 85 path 6 86 3.1.2 Unreachable media destination address 7 87 3.1.3 Ingress filtered media source address 7 88 3.1.4 Unreachable listening media socket address8 89 3.1.5 Unreachable signaling ULA destination 8 90 3.1.6 Unreachable media ULA destination8 91 3.2 Background: Multi-Homed Hosts..............................8 92 3.3 Identified Problems........................................9 93 3.4 Multihomed Host Unreachable due to Uplink Failure..........9 94 3.5 Multihomed Host INVITE Via Header Address Selection Issue.12 95 3.6 Multihomed Host SDP Address Selection Issues..............14 96 4. SIP Headers Address Selection.................................17 97 4.1 REGISTER Contact Header Address Selection and Re-INVITE...18 98 5. SDP Address Selection.........................................19 99 6. Security Considerations.......................................21 100 7. IANA Considerations...........................................21 101 8. References....................................................21 102 9. Acknowledgments...............................................21 103 Author's Addresses...............................................21 105 1. 106 Introduction 108 It is common for enterprises to use two Internet Service Providers, 109 ISPs, to access the Internet. When IPv6 is enabled, host in those 110 networks have at least two IPv6 addresses, one for each ISP prefix. 111 IPv6 only SIP clients on these hosts register one IPv6 address at 112 which they can be reached. SIP Proxy forwards incoming INVITEs to the 113 registered contact address. The address should be reachable. If SIP 114 client registers all global IPv6 addresses, the list of addresses 115 should be ordered and SIP Proxy should check the reachability, 116 starting with the most preferred host IPv6 address. 118 When call sessions are initiated, the clients select one IPv6 address 119 for Via header, the address to which 200 OK response will be 120 delivered. When SIP Proxy forwards 200 OK to the offerers, the Via 121 address should be reachable. 123 During media parameters negotiation, offerer and answerer set IPv6 124 address on which they listen to the media. Media streams should be 125 able to reach these addresses. 127 2. 128 Terminology 130 IPv6-only: an entity that uses only Internet Protocol version 6, 131 IPv6, addresses 133 ISP: Internet Service Provider 135 SER: Site Edge Router. The router connecting a site to ISP uplink. 137 IPv6 Multihomed Host: Host with multiple IPv6 addresses 139 SASA: Source Address Selection (RFC 6724). Used by hosts to select 140 the best source IPv6 address, given IPv6 destination address. 142 DASA: Destination Address Selection (RFC 6724). Used to select the 143 best destination address, based on the available local addresses. 145 GUA: Global Unicast Address (RFC 3587). Enables hosts to be globally 146 reachable. 148 ULA: Unique Local Address (RFC 4193). It is used for local 149 communication and is not globally reachable. 151 SLAAC: Stateless Address Autoconfiguration (RFC 4862). An algorithm 152 to auto-configure IPv6 addresses on hosts. 154 SDP: Session Description Protocol (RFC 3264 and RFC 6157) 156 RA: Router Advertisement (RFC 4861). A message multicasted from 157 router to hosts. Used to assign IPv6 address prefixes to hosts for 158 SLAAC usage and to announce its presence to hosts, after SER to ISP 159 uplink recovery. 161 getsockname():socket API function to get the socket SASA address from 162 TCP or UDP socket. 164 connect(): socket API provides the remote IPv6 address to the socket 165 SASA. (RFC 3493 & RFC 6316) 167 3. 168 Problem Statement 170 A network topology, configuration and transient events can affect SIP 171 signaling and media reachability. The transport protocols (like TCP 172 or UDP) caring SIP signaling or RTP media might be unable to reach 173 SIP hosts. Multihomed SIP hosts can experience: 174 - Unreachable signaling ULA destination, 175 - Unreachable signaling destination address, 176 - Ingress filtered signaling source address, 177 - Unreachable media ULA destination, 178 - Unreachable media destination address, 179 - Ingress filtered media source address, 180 - Unreachable listening media socket address, or 181 - Non optimal data path, 182 if a wrong IPv6 address is selected or, registered and negotiated 183 addresses are not updated during network failures and recoveries. 185 3.1 186 Network Topology 188 The topology similar to https://tools.ietf.org/html/draft-ietf-rtgwg- 189 enterprise-pa-multihoming-12#section-4.2 Figure 3, depicts multihomed 190 SIP hosts Ha and Hb, SIP Proxy, and the IPv6 address assignment. The 191 impact of uplink failure on Ha source address selection will be 192 explained. Further analysis will show that algorithms for SIP and SDP 193 address selection are needed to avoid reachability issues. 195 SITE-1 and SITE-2 have the same ISP-A and ISP-B service providers. 196 ISPs assign their prefixes 2000::/64 and 3000::64. Ha, Hb, and SIP 197 Proxy have GUAs, created using ISP prefixes. R3 provides connectivity 198 to an isolated local segment (aka a private LAN segment) and 199 advertises ULA prefix. Ha and Hc have ULA addresses fc00::301 and 200 fc00::401. 202 SERa and SERb first-hop routers are selected based on the source 203 address prefixes [RFC8028]. The choice of Ha source address 204 determines the selection of the first hop (SERa or SERb) router and 205 ISP (ISP-A or ISP-B). If Ha selects 2000::201, packets would go over 206 SERa to ISP-A. If SERa and SERb use ingress filtering, they would 207 discard packets with source addresses that don't have their prefixes 208 (e.g. SERa would discard packets with 3000::/64 prefix). The figure 209 below can be further simplified, with Ha directly connected to SERa 210 and SERb, similar to SITE-2 topology. 212 When Ha needs to reach SIP Proxy at another site, it would use SASA 213 to select the source address, using SIP Proxy preferred address (e.g. 214 2000::101) as a destination. All traffic to SIP Proxy would leave 215 SITE-1 over the preferred ISP (e.g. ISP-A). 217 SITE-1: SITE-2: 219 ISP-A prefix 2000::/48 ISP-A prefix 2000::/48 220 ISP-B prefix 3000::/48 222 +--------- SITE-1 ----------+ +---- SITE-2 ----+ 223 | | | | 224 Ha addresses: 225 2000::201 -------- 226 3000::301 ,-----. / \ 227 fc00::301 +--+ +----+ ,' `. : : 228 +---|R1|---+---|SERa|-+ ISP-A +--+ : 229 | +--+ | +----+ `. ,' : : SIP Proxy 230 | | `-----' : Internet : 2000::101 231 | | 2000::/48 : : 3000::101 232 | | : : ,----. | 233 | | : : ,' `. +----+ | 234 Ha---+ +--+ : +--+ ISP-A +--+SERc+--+ 235 | |R7| : : `. ,' +----+ | 236 | +--+ : : `-----' | 237 | | : : | 238 | | ,-----. : : | 239 | +--+ | +-----+ ,' `. : : ,----. | 240 +---|R2|---+--|SERb |-+ ISP-B +--+ : ,' `. +----+ | 241 | +--+ +-----+ `. ,' : +--+ ISP-B +--+SERd+--+ 242 | `-----' : : `. ,' +----+ | 243 | 3000::/48 \ / `-----' | 244 | -------- Hb 245 +--+ 2000::102 246 Hc--|R3| ULA prefix fc00::/64 3000::102 247 +--+ 248 fc00::401 250 Figure 1: SIPv6 Address Selection Impact on Multihomed Hosts and 251 Proxy 253 3.1.1 Ingress filtered signaling source address & Non optimal 254 data path 256 In this scenario, SERa uplink to ISP-A fails on SITE-1. Ha uses SERa 257 as the first hop router, when reaching SIP Proxy 2000::101,[RFC8028]. 258 Ha source address is 2000::201, [RFC6724]. If uplink to ISP-A fails, 259 and SERa does not redirect packets to SERb, the SIP signaling link 260 breaks. To maintain the connectivity to SIP Proxy, Ha needs to use 261 SERb as the first hop router, since SIP Proxy is reachable via SERb, 262 and select 3000::301 source address to avoid ingress filtering on 263 SERb. If Ha changes the default route to SERb (when SERa detects the 264 uplink is down it sends RA with Router Lifetime of 0, indicating it 265 is no longer the default router) but selects ISP-A based 2000::201 266 source address (SERa sends RA with Valid Lifetime of 0, but some 267 hosts don't immediately remove the addresses with the expired 268 prefix), and ingress filtering is enabled on SERb, SERb would discard 269 the packets and send a Destination Unreachable message with Code 5 270 (Source address failed ingress/egress policy) back to Ha. Ha not only 271 needs to change the default router to SERb, but also to expire 272 2000::201 and select 3000::301 when reaching SIP Proxy 2000::101. 274 In the same scenario, SIP Proxy is not aware that the uplink to ISP-A 275 failed and attempts to send messages to the most preferred registered 276 contact 2000::201, using its 2000::101 source address. ISP-A is 277 unusable and would have to re-route packets over Internet to SERb, 278 taking non-optimal route. Optimal route would be if SIP messages are 279 sent over ISP-B, which would happen if SIP Proxy knows 2000::201 280 contact SHOULD NOT be used, and messages should be sent to the next 281 preferred contact, 3000::301, destination over SERd. The contact list 282 would be updated if, on the ISP-A uplink failure, Ha Re-REGISTERed 283 with the new contact list (e.g with 3000::301). 285 In another scenario, SERc to ISP-A uplink fails on SITE-2. SIP Proxy 286 does not know the uplink to ISP-A failed and would try to send 287 messages to the most preferred registered contact 2000::201, using 288 its 2000::101 source address, over SERc first hop router. The 289 signaling link is broken. If SIP Proxy changes the default route to 290 SERd (when it receives RA from SERc), but selects ISP-A based 291 2000::101 source address to reach 2000::201 contact, and ingress 292 filtering is enabled, ISP-B would apply ingress filtering to source 293 address prefix (e.g. 2000::/64) and SIP Proxy would not be able to 294 talk to Ha. 296 3.1.2 Unreachable media destination address 297 If SERc uplink fails, the RTP media from Hb might be lost. Hb would 298 not detect the uplink failure and would continue sending RTP packets 299 to SERc, using previously offered Ha address (e.g. 'c'=2000::201). 300 SERc would not be able to deliver UDP media packets to Ha and would 301 not notify Hb about the uplink failure. 303 3.1.3 Ingress filtered media source address 305 The ingress filtering might happen with Hb media, trying to reach Ha 306 via ISP-B (SERc uplink failed) while using ISP-A based address (e.g. 307 RTP SRC = 2000::102) for previously offered Ha address (e.g. 308 'c'=2000::201). When the uplink fails, SERc can send RA with Router 309 Lifetime of zero, and 2000::/64 prefix lifetime of zero. Hb can use 310 this event to change the first hop router to SERd and expire its 311 2000::/64 address. If Hb still uses SDP negotiated Ha destination 312 address 2000::201, selects its 2000::102 source address, and sends 313 RTP to SERd, SERd will ingress filter RTP media. 315 Hb SHOULD not only change the first hop router but also expire its 316 2000::102 address, and select its 3000::102 as the source address to 317 reach Ha over SERd. 319 3.1.4 Unreachable listening media socket address 321 Ha can open a listening socket using 2000::201 specific address and 322 offer SDP 'c'=3000::201. Hb media sent to 3000::201 would not be able 323 to reach the listening socket. 325 3.1.5 Unreachable signaling ULA destination 327 Ha can select fc00::301 for registration or Via header, and SIP Proxy 328 would not be able to send SIP INVITEs or 200 OK replies to ULA 329 destination address. 331 3.1.6 Unreachable media ULA destination 333 Ha can select fc00::301 for SDP 'c' line and Hb would not be able to 334 send media to ULA destination address. 336 3.2 337 Background: Multi-Homed Hosts 339 IPv6-only hosts can be assigned multiple IPv6 addresses, based on the 340 prefixes from multiple ISPs. Socket, sending a packet, uses Source 341 Address Selection, SASA, algorithm (RFC 6724), Rule 5.5, to select a 342 source address for the prefix advertised by a default router. RFC 343 8028 extends the reachability range by selecting the source address 344 based on the next hop router that can reach the destination. Based on 345 RFC 8028, by selecting a source address a multi-homed host selects a 346 first hop router to an ISP, using the source address prefix. 348 draft-ietf-rtgwg-enterprise-pa-multihoming recommends mechanisms to 349 detect an uplink to ISP failure and remove the prefix, default 350 router, and host addresses for unreachable ISP. 352 Unlike RFC 8028, where the source address selection was used to avoid 353 BCP 38 source address filtering, several use cases will be analyzed 354 to illustrate the problems when a wrong destination address is 355 selected, or unreachable address is still used. Use cases illustrate 356 how ISPs ingress filtering, or site uplink failures, can cause 357 signaling or media paths breakages. 359 3.3 360 Identified Problems 362 The Figure 2 below is used to illustrate SIPv6 signaling and media 363 filtering or packet loss. Packets might not be delivered to GUA, 364 Global Unicast Address, destination (a site uplink with ISP failed: 365 draft-ietf-rtgwg-enterprise-pa-multihoming, or ingress filtering) or 366 ULA destinations. 368 Multihomed HostA has at least two IPv6 addresses, each one based on 369 ISP prefixes. A wrong address selection during SDP negotiation might 370 cause RTP destination unreachability and ingress filtering. 372 3.4 373 Multihomed Host Unreachable due to Uplink Failure 375 In the Figure 2, When HostA registers to SIP Proxy in the same ISP1 376 domain (using RFC 3261), it selects IPv6 address for the Contact 377 header. For incoming calls, SIP Proxy forwards the incoming INVITEs 378 to the IPv6 contact address, provided during the registration. If 379 HostA registers IPv6 address based on ISP1 prefix (e.g. 2000::/64 in 380 Figure 1), SIP Proxy forwards INVITEs to HostA address (e.g. 381 2000::201). HostA can register a list of its preferred addresses, and 382 SIP Proxy should use the list starting from the most preferred 383 address. 385 | INVITE, 200 OK 386 [Internet] | to HostA 387 | | 388 +---------+ v 389 | | 390 +------| ISP1 |------+ 391 | |2000::/48| | 392 uplink X +---------+ | 393 failed | | 394 | | 395 | | 396 [SITE-1] [SITE-2] 397 | | INVITE, 200 OK 398 | | to 2000::201 399 | | <------------- 400 +----+----+ +----+----+ +---------+ 401 | | | +--+ |SIP Proxy| 402 +----| R1 | | R3 | | +---+2000::101| 403 +---------+ | |2000::/64| |2000::/64| | | |3000::101| 404 | | | +---------+ +---------+ +--+ +---------+ 405 | HostA |---+ | | HA Contact: 2000::201 406 |2000::201| | +---------+ +---------+ | | 407 |3000::301| | | | | | | 408 +--------+ +----| R2 | | R4 +--+ | 409 |3000::/64| |3000::/64| | +---------+ 410 +----+----+ +----+----+ +---| HostB | 411 REGISTER --> | | |2000::102| 412 Contact: 2000::201 | | |3000::102| 413 | | +---------+ 414 INVITE --> [SITE 1] [SITE 2] <--------- 415 Via: 2000::201 | +---------+ | 200 OK 416 | | | | 417 +------+ ISP2 |------+ 418 |3000::/48| 419 +----+----+ 420 | 421 | 422 [Internet] 424 Figure 2: SIPv6 INVITE to Failed Uplink 426 Figure 2 NOTE: HostA and SIP Proxy can be on different geographic 427 locations serviced by the same ISP1 and ISP2. In case preferred 428 message path from SIP Proxy to HostA is over ISP1, the destination 429 address might not be routable, if uplink to ISP1 fails and SIP Proxy 430 is still using HostA address with ISP1 prefix. Source address 431 filtering might apply if SIP Proxy changes the default router but not 432 the source address. 434 If HostA sends REGISTER over ISP1, using SASA selected ISP1 based 435 contact (e.g. 2000::201 is selected as the best source address for 436 SIP Proxy destination 2000::101), and the uplink R1-ISP1 fails after 437 the registration, INVITE to HostA will be routed over R3-ISP1 and 438 Internet to ISP1. The uplink R1-ISP1 failed and ISP1 would route 439 INVITE over Internet to ISP2. The path is not optimal but INVITE 440 would reach HostA over R2. 442 If uplink R3-ISP1 fails and SIP Proxy sends INVITE to R3, the INVITE 443 will be lost. 445 HostA R1 R2 ISP1 ISP2 R3 R4 Proxy HostB 446 | | | | | | | | | 447 | RA(2000::/64) | | | | | | | | 448 |<---------------+ | | | | | | | 449 | RA(3000::/64) | | | | | | | 450 |<-----------------------+ | | | | | | 451 | | | | | | | | 452 + SLAAC | | | | | | | 453 | (created 2000::201 & | | | | | | | 454 | 3000::301 ) | | | | | | | 455 | | | | | | | | 456 | REGISTER(Contact: 2000::201)| | | | | | 457 +--------------->+----------->+------->+-------->| | 458 | | | | | | | | | 459 | | | |<---X-->| | | | 460 | | | | | | | | INVITE | 461 | | | | | | |<-----------+ 462 | | | | | | INVITE | | 463 | | | X<-------+<--------+ | 464 | | | | DstIP: 2000::201 | | 466 Figure 3: SIPv6 INVITE to Failed Uplink Call Flow 468 If uplink R3-ISP1 fails and INVITE is to be sent to HostA, SIP Proxy 469 might be able to use RA notification from R3 and change the default 470 router to R4. If SIP Proxy still uses the old contact preference, it 471 will select 2000::101 source address and R4 might apply ingress 472 filtering to INVITE. 474 HostA R1 R2 ISP1 ISP2 R3 R4 Proxy HostB 475 | | | | | | | | | 476 | RA(2000::/64) | | | | | | | | 477 |<---------------+ | | | | | | | 478 | RA(3000::/64) | | | | | | | 479 |<-----------------------+ | | | | | | 480 | | | | | | | | 481 + SLAAC | | | | | | | 482 | (created 2000::201 & | | | | | | | 483 | 3000::301 ) | | | | | | | 484 | | | | | | | | 485 | REGISTER(Contact: 2000::201)| | | | | | 486 +--------------->+----------->+------->+-------->| | 487 | | | | | | | | | 488 | | | |<---X-->| | RA | | 489 | | | | | |-------->| | 490 | | | | | | | | INVITE | 491 | | | | | | X<----+<-----------+ 492 | | | | | | | DstIP: 2000::201 | 493 | | | | | | | SrcIP: 2000::101 | 494 | | | | | | |default via R4 | 496 Figure 4: SIPv6 INVITE Ingress Filtering Call Flow 498 The solution for these problems is explained in section 4.1, REGISTER 499 Contact Header Address Selection. 501 3.5 502 Multihomed Host INVITE Via Header Address Selection Issue 504 In some scenarios, R2 might provide connectivity to a private 505 network. R2 might use ULA, Unique Local Address, address prefix 506 0xFC00::/7 (RFC 4193) for SLAAC, Stateless Address Autoconfiguration, 507 assignments. Multihomed HostA would receive prefixes from both R1 and 508 R2, and create at least one SLAAC GUA address based on ISP1 prefix, 509 and at least one SLAAC ULA address, based on R2 prefix. When 510 communicating with the external hosts, with GUA address, HostA should 511 be able to select the ISP1 based global address. When talking to 512 devices in the private network, it should select ULA address. 514 | INVITE, 200 OK 515 [Internet] | to HostA 516 | | 517 +---------+ v 518 | | 519 +------------| ISP1 |----------+ 520 | |2000::/48| | 521 | +---------+ | 522 | X ULA | 523 | ^ ingress | 524 | | filtering | 525 | | | 526 | | | 527 [SITE-1] | [SITE-2] 528 | | | 529 +---------+ | +----------+ 530 | | | | | 531 +----| R1 | | | R3 | 532 +-------+ | |2000::/64| | | 2000::/64| 533 | | | +---------+ | +----------+ 534 | HostA |---+ | | ^ 535 | | | +---------+ | +-----+-----+ | 536 +-------+ | | | INVITE, 200 OK | | 200 537 2000::201 +----| R2 | to fc00::301 | | OK 538 fc00::301 |fc00::/64| +---------+ +-------+ 539 +---------+ | SIP | | HostB | 540 REGISTER --> | | Proxy | +-------+ 541 Contact: fc00::301 | |2000::101| 542 | +---------+ 543 INVITE --> |Black LAN HA Contact: fc00::301 544 Via: fc00::301 +----------+ 545 | | 546 | HostC | 547 | fc00::401| 548 +----------+ 550 Figure 5: SIPv6 ULA Filtering 552 If HostA makes a call to HostB, it adds its IPv6 address to INVITE 553 Via header (using RFC 3261). When HostB replies with 200 OK, SIP 554 Proxy forwards the message to the topmost address in Via header (see 555 RFC 3261). If HostA selects ULA address (e.g. fc00::301) for Via 556 header, SIP Proxy forwards 200 OK to SER R3, and the 200 OK gets 557 discarded sine ULA destination address is not globally routable. 559 HostA R1 R2 ISP1 ISP2 R3 R4 Proxy HostB 560 | | | | | | | | | 561 | RA(2000::/64) | | | | | | | | 562 |<---------------+ | | | | | | | 563 | RA(fc00::/64) | | | | | | | 564 |<-----------------------+ | | | | | | 565 | | | | | | | | 566 + SLAAC | | | | | | | 567 | (created 2000::201 & | | | | | | | 568 | fc00::301 ) | | | | | | | 569 | | | | | | | | 570 | INVITE(Via: fc00::301) | | | | | | | 571 +--------------->+----------->+------->+-------->+----------->| 572 | | | | | | | | | 573 | | | | | | | | 200 OK | 574 | | | X<-------+<--------+<-----------+ 575 | | | | (Via: fc00::301)| | 576 | | | | SrcIP: 2000::101| | 577 | | | | default via R3 | | 579 Figure 6: SIPv6 ULA Filtering Call Flow 581 3.6 582 Multihomed Host SDP Address Selection Issues 584 SDP, Session Description Protocol, (RFC 3264 and RFC 6157) Offerer 585 IPv6 address might not be the best selected address on a multihomed 586 host. 588 draft-gont-6man-address-usage-recommendation, section 3, recommends 589 to bind() a listening socket to a specific address of a given scope, 590 instead of to the unspecified address, to avoid attacks by narrowing 591 the address scope. The offerer might open a listening media socket 592 and selects the socket source address using the socket SASA to SIP 593 Proxy destination (e.g. listen on 2000::201, instead of listening on 594 any address). If the Offerer randomly select IPv6 address for SDP 'c' 595 line (e.g. 3000::301 in Figure 1 or fc00::301 in Figure 2), a 596 destination answerer might get a different IPv6 address in SDP 'c' 597 line than the one selected by the offerer's socket SASA, and the 598 offerer might become unreachable. 600 HostA R1 R2 Proxy HostB 601 | | | | | 602 | RA(2000::/64) | | | | 603 |<---------------+ | | | 604 | RA(3000::/64) | | | 605 |<-----------------------+ | | 606 | | | | 607 + SLAAC | | | 608 | (created 2000::201 & | | | 609 | 3000::301 ) | | | 610 | | | | 611 + open media socket | | 612 | (SASA for dest. Proxy) | | 613 | (listening IP=2000:2001) | | 614 | | | 615 | INVITE ('c'=3000::301) | | 616 +--------------->+------------->| | 617 | (Via: 2000::201) | | 618 | | | | INVITE | 619 | | | +----------->| 620 | | | | 200 OK | 621 | | | |<-----------+ 622 | 200 OK | 200 OK | (Via: 2000::201) 623 |<---------------+<-------------+ | 624 | ACK | ACK | | 625 +--------------->+------------->| | 626 | | | ACK | 627 | | | |----------->| 628 | | | | | 629 | | MEDIA | 630 X<===============+<==========================| 631 | (DstIP: 3000::301 | 633 Figure 7: Offerer Listening Socket Unreachable 635 Offerer's socket would apply SASA for SIP Proxy address (e.g. 636 2000::101 would be passed to the socket connect() API) and select 637 2000::201 for the socket source address. SDP protocol does not have 638 an algorithm for 'c' line address selection and might select 639 unreachable address (e.g. fc00::301) for the 'c' line. If the 640 answerer sends media to the offered address (e.g. fc00::301), media 641 might not reach the Offerer, since fc00::301 is not globally 642 routable. 644 HostA R1 R2 Proxy HostB 645 | | | | | 646 | RA(2000::/64) | | | | 647 |<---------------+ | | | 648 | RA(fc00::/64) | | | 649 |<-----------------------+ | | 650 | | | | 651 + SLAAC | | | 652 | (created 2000::201 & | | | 653 | fc00::301 ) | | | 654 | | | | 655 + open media socket | | 656 | (SASA for dest. Proxy) | | 657 | (listening IP=2000:2001) | | 658 | | | 659 | INVITE ('c'=fc00::301) | | 660 +--------------->+------------->| | 661 | (Via: 2000::201) | | 662 | | | | INVITE | 663 | | | +----------->| 664 | | | | 200 OK | 665 | | | |<-----------+ 666 | 200 OK | 200 OK | (Via: 2000::201) 667 |<---------------+<-------------+ | 668 | ACK | ACK | | 669 +--------------->+------------->| | 670 | | | ACK | 671 | | | |----------->| 672 | | | | | 673 | | MEDIA | 674 | X<==========================| 675 | | DstIP: fc00::301 | 677 Figure 8: Media to ULA Lost 679 In addition, if the offerer selects GUA SDP 'c' (e.g. 2000::201 on 680 Figure 1), the media packets sent from the answerer (e.g. HostB), to 681 HostA (e.g. 2000::201) address, might be filtered by ISP2. R3-ISP1 682 uplink fails, R3 sends RA to HB, telling the host R3 should not be 683 used as default router. If HB does not expire 2000::/64 prefix and 684 addresses, it might use SASA to select the source address for 685 'c'=2000::201 destination, and select 2000::102 address. R4 would 686 ingress filter the media with 2000::102 source address. 688 HostA R1 R2 ISP1 ISP2 R3 R4 Proxy HostB 689 | | | | | | | | | 690 | RA(2000::/64) | | | | | | | | 691 |<---------------+ | | | | | | | 692 | RA(3000::/64) | | | | | | | 693 |<-----------------------+ | | | | | | 694 | | | | | | | | 695 + SLAAC | | | | | | | 696 | (created 2000::201 & | | | | | | | 697 | 3000::301 ) | | | | | | | 698 | | | | | | | | 699 | INVITE('c'=2000::201) | | | | | | | 700 +--------------->+----------->+------->+-------->|----------->| 701 | | | | | | | | | 702 | | | | | | | | 200 OK | 703 +<---------------+<-----------+<-------+<--------|<-----------| 704 | | | |<---X-->| | ('c'=2000:102)| 705 | | | | | | | | | 706 | | | | | | RA(Router Lifetime=0)| 707 | | | | | |--------------------->| 708 | | | | | | | | media | 709 | | | | | | X<=================+ 710 | | | | | | | DstIP: 2000::201 | 711 | | | | | | | SrcIP: 2000::102 | 712 | | | | | | |default via R4 | 714 Figure 9: SIPv6 Media Ingress Filtering Call Flow 716 The solution to this problem is explained in detail in section 6, SDP 717 Address Selection. 719 4. 720 SIP Headers Address Selection 722 When a multi-homed host selects IPv6 address for a SIP header (e.g. 723 Contact or Via header), it is important to select the address that 724 will be reachable via the underlined network. SIP Signaling socket 725 (e.g. TCP socket) solves the reachability problem by using the Source 726 Address Selection, SASA, algorithm from RFC 6724, for a known 727 destination. 729 For the examples exercised on Figure 1 and Figure 2: 731 - SIP REGISTER message is sent from HostA to SIP Proxy destination 732 and the socket applies SASA to that destination, to select the packet 733 source address, and 734 - SIP INVITE is sent from HostA to SIP Proxy destination and the 735 socket applies SASA to that destination to select the packet source 736 address. 738 The same socket SASA SHOULD be used to select the addresses for SIP 739 headers, so SIP messages sent to the selected addresses will not be 740 filtered out. getsockname() socket API can be used to obtain the SASA 741 address for a known destination (passed in connect() socket API). 743 For the examples exercised on Figure 1 and Figure 2: 745 - SIP REGISTER message: HostA SHOULD use socket SASA to SIP Proxy 746 destination and set the selected SASA address to REGISTER Contact 747 header. 749 - SIP INVITE: HostA SHOULD use socket SASA to SIP Proxy destination 750 and set the selected SASA address to INVITE Via header. 752 For the second and third problem in section 3.1.1, SERc SHOULD expire 753 2000::/64 prefix, so SIP Proxy SHOULD stop using 2000::101 address, 754 change the default router to SERd, make 3000::301 the preferred Ha 755 contact, and use 3000::101 as the source address, to talk to Ha 756 3000::301 over SERd. 758 The details about SASA improvements and dynamic address updates are 759 in section 4.1. 761 4.1 762 REGISTER Contact Header Address Selection and Re-INVITE 764 Draft draft-ietf-rtgwg-enterprise-pa-multihoming recommends: 765 " A host is expected to be able respond 766 dynamically to the failure of an uplink to a given ISP by no longer 767 sending packets with the source address corresponding to that ISP." 769 The current SASA address selection does not solve this problem. The 770 solution SHOULD update SASA rule 5.5 to check for the reachability 771 and avoid using a prefix from the router over which destination is 772 not reachable. That would make HostA select ISP2 based address (e.g. 773 3000::301) for the REGISTER contact, when the uplink to ISP1 fails 774 and SIP Proxy address (based on ISP1 prefix) is the destination. 776 Another solution is provided by routers. When the reachability to a 777 preferred ISP1 is lost, RA will be received from SERa for the 778 unreachable ISP-A, with the preferred life time of zero, Router 779 Lifetime of 0, and HostA SHOULD remove SERa as a default router, 780 remove ISP1 based address (e.g. 2000::201) and send Re-REGISTER (to 781 update contact to 3000::301) and Re-INVITE (to renegotiate 3000::301 782 IPv6 address) over SERb, using ISP-B based source address (e.g. 784 3000::301). Upon the uplink recovery, the contact and media addresses 785 SHOULD be updated using SASA for the address selection. Next 786 paragraph describes in details media address selection and 787 renegotiation. 789 The first problem in the section 3.1.1 can be solved by SERa 790 detecting the uplink failure and instructing R1 to expire ISP-A 791 prefix. When RA message is received with the Router Lifetime of zero 792 and 2000::/64 prefix lifetime of zero, Ha SHOULD change the default 793 router to SERb, expire 2000::201 address, and use 3000::301 as the 794 source address, while talking to SIP Proxy 2000::101 over SERb. Ha 795 SHOULD Re-REGISTER the new contact 3000::301. SIP Proxy SHOULD 796 immediately update its contacts and stop using 2000::201 destination. 798 SIP messages SHOULD be sent from SIP Proxy address selected for the 799 HostA reachable destination. A solution might be for HostA to 800 register a prioritized list of contact addresses, based on SASA and 801 other policies. SIP Proxy SHOULD probe the contact addresses, 802 starting from the most preferable one, till it finds a reachable one. 803 SASA SHOULD be applied to the reachable destination address, and the 804 selected SASA address would determine the first hop router. Hosts 805 SHOULD be responsible to update the contact list based on network 806 failures (a link to the first hop router or uplink to ISP failure) 807 and recoveries. 809 5. 810 SDP Address Selection 812 SDP 'c' line address selection needs to be defined for the initial 813 offer from a multihomed host. Initially, the offerer does not have 814 the answerer address. The selected IPv6 address might not be the best 815 choice. A subsequent address selection might be needed to get the 816 right offerer address. 818 SASA from RFC 6724 SHOULD be used to select the IPv6 address for SDP 819 'c' lines. If SASA is used it becomes apparent that: 821 - A destination address needs to be chosen for the initial offer. 822 SASA SHOULD applied to that address and the result is used for 'c' 823 line. 825 - When the offerer receives 200 OK and learns the destination 826 address, the offerer might find the address selected during the 827 initial SASA is not the right address. 829 To reach a destination (SDP answerer), SIP offer must go via SIP 830 server. That is why SIP server IPv6 address SHOULD be used for the 831 initial SASA. 833 When SDP negotiation is done, the offerer learns the answerer IPv6 834 address. The offerer applies SASA to the answerer preferred address. 835 The initially offered IPv6 address might not be the best SASA 836 address. This might cause the source IPv6 socket address in the 837 subsequent media packets to be different than the initially offered 838 SDP 'c' line address. To prevent this, the offerer SHOULD do the 839 second SASA, using the answerer 'c' line address as the destination. 840 If SASA returns a different source address, the offerer SHOULD send 841 Re-INVITE to renegotiate media addresses and open a new socket, using 842 the newly selected source address. The initial socket SHOULD be 843 closed. 845 It is equally important for the answerer to apply SASA on the offered 846 IPv6 address, when selecting the 'c' line address in 200 OK SDP. 848 If SDP offer has two IPs of different address families (ALTC in RFC 849 6947), an address selection algorithm is needed to select the address 850 for the opposite address family. The second media line address SHOULD 851 be selected using: 853 - SASA, if the SIP Proxy IP of the opposite address family is known. 855 - Otherwise, the algorithm for the best 'guess' for the second 856 address SHOULD be applied: 858 -- Select the IP of the opposite address family from the same 859 interface from which the fist IP was selected 860 -- If the second address is IPv6, prefer an address with a bigger 861 scope. Prefer global over ULA address. 862 -- If the second address is IPv4, prefer a public over a private 863 address. 864 -- More rules can be added, like if there are multiple addresses of 865 the same scope, prefer manual over DHCP over stateless addresses. 867 - Upon receiving of the offer, the answerer responds to the offer 868 with the acceptance response (200 OK), using a preferred IP address 869 from the offered SDP (e.g. a preferred 'altc' line) as a destination 870 address for its SASA address selection. The selected address is set 871 into preferred 200 OK SDP media line. 873 - The offerer now has the IP address of the destination host. If the 874 source address, selected using the IP address from the acceptance 875 response from the answerer, is the same IP address selected for the 876 initial offer, the offerer address selection is completed. 878 - If the selected address in the previous step is different from the 879 address in the initial offer, the offerer sends Re-INVITE, using the 880 address selected in the previous step. The second media IP address, 881 if needed, is selected using the rules above. 883 The side effect of Re-INVITE is that media path might be different, 884 and more optimal, than the signaling path. 886 The offerer can advertise multiple IPv6 addresses in the initial SDP 887 offer (ICE RFC 5245). The SASA preferred address, for SIP Proxy 888 destination, SHOULD be the highest priority address. When the 889 answerer sets SDP media address, or the host candidates, it SHOULD 890 use Destination Address Selection, DASA, algorithm (RFC 6724) to 891 select the preferred destination address for a media stream. The 892 selected destination SHOULD be used during SASA to select the 893 answerer preferred address. The answerer can offer the preferred 894 address or the prioritized host candidate list. 896 6. 897 Security Considerations 899 This document recommends the use of existing standards to address the 900 SIP Signaling and Media address selection. The security 901 recommendations in outlined standards should be followed. 903 7. 904 IANA Considerations 906 There is no impact on existing SIP and IPv6 messages. 908 8. 909 References 911 9. 912 Acknowledgments 914 The author gratefully acknowledges the contributions of: Rifaat 915 Shekh-Yusef. 917 Author's Addresses 919 Dusan Mudric 920 Avaya 921 425 Legget Dr. 922 Ottawa, ON 923 K2K 3C9 924 Canada 925 Email: dmudric@avaya.com 927 Dragan Grebovich 928 Avaya 929 4655 Great America Parkway 930 Santa Clara, CA 931 95054 932 USA 933 Email: dgrebovich@avaya.com