SIPCORE WG Internet Draft D. Mudric Avaya D. Grebovich Avaya Expires: June 2020 January 2020 SIPv6 Headers and SDP Media Line Address Selection on Multihomed Hosts draft-dmudric-sipcore-sipv6-addr-selection-00 Abstract In the networks where multihomed hosts can have ULA and GUA addresses from different ISPs, multiple SIP signaling and media connectivity issues might arise due to inappropriate address selections. Some of the problems are described in [RFC5220]. Since SIP and SDP allow IP addresses to be embedded into their headers and lines, even if proper addresses are selected initially, SIP is not equipped with the mechanisms to respond to network events, and transition transport to reachable addresses. As a result, SIP messages and media might be filtered by routers, or discarded as unreachable destinations. SIP protocol (RFC 3261) defines signaling messages and their headers. This document describes how a multihomed host should select addresses for SIP headers, like Contact and Via, to be reachable destinations. Host SHOULD change a default router for uplink failures, remove prefixes and addresses for unreachable ISP, and update contact address list. SDP protocol (RFC 3264) defines how participants in a session select their parameters. This document describes how an offerer and answerer on multihomed hosts should select their addresses. If one of the selected addresses becomes unreachable, the document describes the mechanism how a new one should be selected and renegotiated. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 except that the right to produce derivative works is not granted. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Mudric Standards Track Expires - July 2020 [Page 1] Internet-draft SIPv6 Address Selection on Multihomed Hosts January 2020 Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust’s Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [i]. Table of Contents 1. Introduction...................................................3 2. Terminology....................................................3 3. Problem Statement..............................................4 3.1 Network Topology...........................................4 3.1.1 Ingress filtered signaling source address & Non optimal data path 6 3.1.2 Unreachable media destination address 7 3.1.3 Ingress filtered media source address 7 3.1.4 Unreachable listening media socket address8 3.1.5 Unreachable signaling ULA destination 8 3.1.6 Unreachable media ULA destination8 3.2 Background: Multi-Homed Hosts..............................8 3.3 Identified Problems........................................9 3.4 Multihomed Host Unreachable due to Uplink Failure..........9 3.5 Multihomed Host INVITE Via Header Address Selection Issue.12 3.6 Multihomed Host SDP Address Selection Issues..............14 4. SIP Headers Address Selection.................................17 Mudric Expires - July 2020 [Page 2] Internet-draft SIPv6 Address Selection on Multihomed Hosts January 2020 4.1 REGISTER Contact Header Address Selection and Re-INVITE...18 5. SDP Address Selection.........................................19 6. Security Considerations.......................................21 7. IANA Considerations...........................................21 8. References....................................................21 9. Acknowledgments...............................................21 Author's Addresses...............................................21 1. Introduction It is common for enterprises to use two Internet Service Providers, ISPs, to access the Internet. When IPv6 is enabled, host in those networks have at least two IPv6 addresses, one for each ISP prefix. IPv6 only SIP clients on these hosts register one IPv6 address at which they can be reached. SIP Proxy forwards incoming INVITEs to the registered contact address. The address should be reachable. If SIP client registers all global IPv6 addresses, the list of addresses should be ordered and SIP Proxy should check the reachability, starting with the most preferred host IPv6 address. When call sessions are initiated, the clients select one IPv6 address for Via header, the address to which 200 OK response will be delivered. When SIP Proxy forwards 200 OK to the offerers, the Via address should be reachable. During media parameters negotiation, offerer and answerer set IPv6 address on which they listen to the media. Media streams should be able to reach these addresses. 2. Terminology IPv6-only: an entity that uses only Internet Protocol version 6, IPv6, addresses ISP: Internet Service Provider SER: Site Edge Router. The router connecting a site to ISP uplink. IPv6 Multihomed Host: Host with multiple IPv6 addresses SASA: Source Address Selection (RFC 6724). Used by hosts to select the best source IPv6 address, given IPv6 destination address. DASA: Destination Address Selection (RFC 6724). Used to select the best destination address, based on the available local addresses. GUA: Global Unicast Address (RFC 3587). Enables hosts to be globally reachable. Mudric Expires - July 2020 [Page 3] Internet-draft SIPv6 Address Selection on Multihomed Hosts January 2020 ULA: Unique Local Address (RFC 4193). It is used for local communication and is not globally reachable. SLAAC: Stateless Address Autoconfiguration (RFC 4862). An algorithm to auto-configure IPv6 addresses on hosts. SDP: Session Description Protocol (RFC 3264 and RFC 6157) RA: Router Advertisement (RFC 4861). A message multicasted from router to hosts. Used to assign IPv6 address prefixes to hosts for SLAAC usage and to announce its presence to hosts, after SER to ISP uplink recovery. getsockname():socket API function to get the socket SASA address from TCP or UDP socket. connect(): socket API provides the remote IPv6 address to the socket SASA. (RFC 3493 & RFC 6316) 3. Problem Statement A network topology, configuration and transient events can affect SIP signaling and media reachability. The transport protocols (like TCP or UDP) caring SIP signaling or RTP media might be unable to reach SIP hosts. Multihomed SIP hosts can experience: - Unreachable signaling ULA destination, - Unreachable signaling destination address, - Ingress filtered signaling source address, - Unreachable media ULA destination, - Unreachable media destination address, - Ingress filtered media source address, - Unreachable listening media socket address, or - Non optimal data path, if a wrong IPv6 address is selected or, registered and negotiated addresses are not updated during network failures and recoveries. 3.1 Network Topology The topology similar to https://tools.ietf.org/html/draft-ietf-rtgwg- enterprise-pa-multihoming-12#section-4.2 Figure 3, depicts multihomed SIP hosts Ha and Hb, SIP Proxy, and the IPv6 address assignment. The impact of uplink failure on Ha source address selection will be explained. Further analysis will show that algorithms for SIP and SDP address selection are needed to avoid reachability issues. SITE-1 and SITE-2 have the same ISP-A and ISP-B service providers. ISPs assign their prefixes 2000::/64 and 3000::64. Ha, Hb, and SIP Mudric Expires - July 2020 [Page 4] Internet-draft SIPv6 Address Selection on Multihomed Hosts January 2020 Proxy have GUAs, created using ISP prefixes. R3 provides connectivity to an isolated local segment (aka a private LAN segment) and advertises ULA prefix. Ha and Hc have ULA addresses fc00::301 and fc00::401. SERa and SERb first-hop routers are selected based on the source address prefixes [RFC8028]. The choice of Ha source address determines the selection of the first hop (SERa or SERb) router and ISP (ISP-A or ISP-B). If Ha selects 2000::201, packets would go over SERa to ISP-A. If SERa and SERb use ingress filtering, they would discard packets with source addresses that don't have their prefixes (e.g. SERa would discard packets with 3000::/64 prefix). The figure below can be further simplified, with Ha directly connected to SERa and SERb, similar to SITE-2 topology. When Ha needs to reach SIP Proxy at another site, it would use SASA to select the source address, using SIP Proxy preferred address (e.g. 2000::101) as a destination. All traffic to SIP Proxy would leave SITE-1 over the preferred ISP (e.g. ISP-A). Mudric Expires - July 2020 [Page 5] Internet-draft SIPv6 Address Selection on Multihomed Hosts January 2020 SITE-1: SITE-2: ISP-A prefix 2000::/48 ISP-A prefix 2000::/48 ISP-B prefix 3000::/48 +--------- SITE-1 ----------+ +---- SITE-2 ----+ | | | | Ha addresses: 2000::201 -------- 3000::301 ,-----. / \ fc00::301 +--+ +----+ ,' `. : : +---|R1|---+---|SERa|-+ ISP-A +--+ : | +--+ | +----+ `. ,' : : SIP Proxy | | `-----' : Internet : 2000::101 | | 2000::/48 : : 3000::101 | | : : ,----. | | | : : ,' `. +----+ | Ha---+ +--+ : +--+ ISP-A +--+SERc+--+ | |R7| : : `. ,' +----+ | | +--+ : : `-----' | | | : : | | | ,-----. : : | | +--+ | +-----+ ,' `. : : ,----. | +---|R2|---+--|SERb |-+ ISP-B +--+ : ,' `. +----+ | | +--+ +-----+ `. ,' : +--+ ISP-B +--+SERd+--+ | `-----' : : `. ,' +----+ | | 3000::/48 \ / `-----' | | -------- Hb +--+ 2000::102 Hc--|R3| ULA prefix fc00::/64 3000::102 +--+ fc00::401 Figure 1: SIPv6 Address Selection Impact on Multihomed Hosts and Proxy 3.1.1 Ingress filtered signaling source address & Non optimal data path In this scenario, SERa uplink to ISP-A fails on SITE-1. Ha uses SERa as the first hop router, when reaching SIP Proxy 2000::101,[RFC8028]. Ha source address is 2000::201, [RFC6724]. If uplink to ISP-A fails, and SERa does not redirect packets to SERb, the SIP signaling link breaks. To maintain the connectivity to SIP Proxy, Ha needs to use SERb as the first hop router, since SIP Proxy is reachable via SERb, and select 3000::301 source address to avoid ingress filtering on SERb. If Ha changes the default route to SERb (when SERa detects the uplink is down it sends RA with Router Lifetime of 0, indicating it Mudric Expires - July 2020 [Page 6] Internet-draft SIPv6 Address Selection on Multihomed Hosts January 2020 is no longer the default router) but selects ISP-A based 2000::201 source address (SERa sends RA with Valid Lifetime of 0, but some hosts don't immediately remove the addresses with the expired prefix), and ingress filtering is enabled on SERb, SERb would discard the packets and send a Destination Unreachable message with Code 5 (Source address failed ingress/egress policy) back to Ha. Ha not only needs to change the default router to SERb, but also to expire 2000::201 and select 3000::301 when reaching SIP Proxy 2000::101. In the same scenario, SIP Proxy is not aware that the uplink to ISP-A failed and attempts to send messages to the most preferred registered contact 2000::201, using its 2000::101 source address. ISP-A is unusable and would have to re-route packets over Internet to SERb, taking non-optimal route. Optimal route would be if SIP messages are sent over ISP-B, which would happen if SIP Proxy knows 2000::201 contact SHOULD NOT be used, and messages should be sent to the next preferred contact, 3000::301, destination over SERd. The contact list would be updated if, on the ISP-A uplink failure, Ha Re-REGISTERed with the new contact list (e.g with 3000::301). In another scenario, SERc to ISP-A uplink fails on SITE-2. SIP Proxy does not know the uplink to ISP-A failed and would try to send messages to the most preferred registered contact 2000::201, using its 2000::101 source address, over SERc first hop router. The signaling link is broken. If SIP Proxy changes the default route to SERd (when it receives RA from SERc), but selects ISP-A based 2000::101 source address to reach 2000::201 contact, and ingress filtering is enabled, ISP-B would apply ingress filtering to source address prefix (e.g. 2000::/64) and SIP Proxy would not be able to talk to Ha. 3.1.2 Unreachable media destination address If SERc uplink fails, the RTP media from Hb might be lost. Hb would not detect the uplink failure and would continue sending RTP packets to SERc, using previously offered Ha address (e.g. 'c'=2000::201). SERc would not be able to deliver UDP media packets to Ha and would not notify Hb about the uplink failure. 3.1.3 Ingress filtered media source address The ingress filtering might happen with Hb media, trying to reach Ha via ISP-B (SERc uplink failed) while using ISP-A based address (e.g. RTP SRC = 2000::102) for previously offered Ha address (e.g. 'c'=2000::201). When the uplink fails, SERc can send RA with Router Lifetime of zero, and 2000::/64 prefix lifetime of zero. Hb can use this event to change the first hop router to SERd and expire its 2000::/64 address. If Hb still uses SDP negotiated Ha destination Mudric Expires - July 2020 [Page 7] Internet-draft SIPv6 Address Selection on Multihomed Hosts January 2020 address 2000::201, selects its 2000::102 source address, and sends RTP to SERd, SERd will ingress filter RTP media. 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. 3.1.4 Unreachable listening media socket address Ha can open a listening socket using 2000::201 specific address and offer SDP 'c'=3000::201. Hb media sent to 3000::201 would not be able to reach the listening socket. 3.1.5 Unreachable signaling ULA destination Ha can select fc00::301 for registration or Via header, and SIP Proxy would not be able to send SIP INVITEs or 200 OK replies to ULA destination address. 3.1.6 Unreachable media ULA destination Ha can select fc00::301 for SDP 'c' line and Hb would not be able to send media to ULA destination address. 3.2 Background: Multi-Homed Hosts IPv6-only hosts can be assigned multiple IPv6 addresses, based on the prefixes from multiple ISPs. Socket, sending a packet, uses Source Address Selection, SASA, algorithm (RFC 6724), Rule 5.5, to select a source address for the prefix advertised by a default router. RFC 8028 extends the reachability range by selecting the source address based on the next hop router that can reach the destination. Based on RFC 8028, by selecting a source address a multi-homed host selects a first hop router to an ISP, using the source address prefix. draft-ietf-rtgwg-enterprise-pa-multihoming recommends mechanisms to detect an uplink to ISP failure and remove the prefix, default router, and host addresses for unreachable ISP. Unlike RFC 8028, where the source address selection was used to avoid BCP 38 source address filtering, several use cases will be analyzed to illustrate the problems when a wrong destination address is selected, or unreachable address is still used. Use cases illustrate Mudric Expires - July 2020 [Page 8] Internet-draft SIPv6 Address Selection on Multihomed Hosts January 2020 how ISPs ingress filtering, or site uplink failures, can cause signaling or media paths breakages. 3.3 Identified Problems The Figure 2 below is used to illustrate SIPv6 signaling and media filtering or packet loss. Packets might not be delivered to GUA, Global Unicast Address, destination (a site uplink with ISP failed: draft-ietf-rtgwg-enterprise-pa-multihoming, or ingress filtering) or ULA destinations. Multihomed HostA has at least two IPv6 addresses, each one based on ISP prefixes. A wrong address selection during SDP negotiation might cause RTP destination unreachability and ingress filtering. 3.4 Multihomed Host Unreachable due to Uplink Failure In the Figure 2, When HostA registers to SIP Proxy in the same ISP1 domain (using RFC 3261), it selects IPv6 address for the Contact header. For incoming calls, SIP Proxy forwards the incoming INVITEs to the IPv6 contact address, provided during the registration. If HostA registers IPv6 address based on ISP1 prefix (e.g. 2000::/64 in Figure 1), SIP Proxy forwards INVITEs to HostA address (e.g. 2000::201). HostA can register a list of its preferred addresses, and SIP Proxy should use the list starting from the most preferred address. Mudric Expires - July 2020 [Page 9] Internet-draft SIPv6 Address Selection on Multihomed Hosts January 2020 | INVITE, 200 OK [Internet] | to HostA | | +---------+ v | | +------| ISP1 |------+ | |2000::/48| | uplink X +---------+ | failed | | | | | | [SITE-1] [SITE-2] | | INVITE, 200 OK | | to 2000::201 | | <------------- +----+----+ +----+----+ +---------+ | | | +--+ |SIP Proxy| +----| R1 | | R3 | | +---+2000::101| +---------+ | |2000::/64| |2000::/64| | | |3000::101| | | | +---------+ +---------+ +--+ +---------+ | HostA |---+ | | HA Contact: 2000::201 |2000::201| | +---------+ +---------+ | | |3000::301| | | | | | | +--------+ +----| R2 | | R4 +--+ | |3000::/64| |3000::/64| | +---------+ +----+----+ +----+----+ +---| HostB | REGISTER --> | | |2000::102| Contact: 2000::201 | | |3000::102| | | +---------+ INVITE --> [SITE 1] [SITE 2] <--------- Via: 2000::201 | +---------+ | 200 OK | | | | +------+ ISP2 |------+ |3000::/48| +----+----+ | | [Internet] Figure 2: SIPv6 INVITE to Failed Uplink Figure 2 NOTE: HostA and SIP Proxy can be on different geographic locations serviced by the same ISP1 and ISP2. In case preferred message path from SIP Proxy to HostA is over ISP1, the destination address might not be routable, if uplink to ISP1 fails and SIP Proxy is still using HostA address with ISP1 prefix. Source address filtering might apply if SIP Proxy changes the default router but not the source address. Mudric Expires - July 2020 [Page 10] Internet-draft SIPv6 Address Selection on Multihomed Hosts January 2020 If HostA sends REGISTER over ISP1, using SASA selected ISP1 based contact (e.g. 2000::201 is selected as the best source address for SIP Proxy destination 2000::101), and the uplink R1-ISP1 fails after the registration, INVITE to HostA will be routed over R3-ISP1 and Internet to ISP1. The uplink R1-ISP1 failed and ISP1 would route INVITE over Internet to ISP2. The path is not optimal but INVITE would reach HostA over R2. If uplink R3-ISP1 fails and SIP Proxy sends INVITE to R3, the INVITE will be lost. HostA R1 R2 ISP1 ISP2 R3 R4 Proxy HostB | | | | | | | | | | RA(2000::/64) | | | | | | | | |<---------------+ | | | | | | | | RA(3000::/64) | | | | | | | |<-----------------------+ | | | | | | | | | | | | | | + SLAAC | | | | | | | | (created 2000::201 & | | | | | | | | 3000::301 ) | | | | | | | | | | | | | | | | REGISTER(Contact: 2000::201)| | | | | | +--------------->+----------->+------->+-------->| | | | | | | | | | | | | | |<---X-->| | | | | | | | | | | | INVITE | | | | | | | |<-----------+ | | | | | | INVITE | | | | | X<-------+<--------+ | | | | | DstIP: 2000::201 | | Figure 3: SIPv6 INVITE to Failed Uplink Call Flow If uplink R3-ISP1 fails and INVITE is to be sent to HostA, SIP Proxy might be able to use RA notification from R3 and change the default router to R4. If SIP Proxy still uses the old contact preference, it will select 2000::101 source address and R4 might apply ingress filtering to INVITE. Mudric Expires - July 2020 [Page 11] Internet-draft SIPv6 Address Selection on Multihomed Hosts January 2020 HostA R1 R2 ISP1 ISP2 R3 R4 Proxy HostB | | | | | | | | | | RA(2000::/64) | | | | | | | | |<---------------+ | | | | | | | | RA(3000::/64) | | | | | | | |<-----------------------+ | | | | | | | | | | | | | | + SLAAC | | | | | | | | (created 2000::201 & | | | | | | | | 3000::301 ) | | | | | | | | | | | | | | | | REGISTER(Contact: 2000::201)| | | | | | +--------------->+----------->+------->+-------->| | | | | | | | | | | | | | |<---X-->| | RA | | | | | | | |-------->| | | | | | | | | | INVITE | | | | | | | X<----+<-----------+ | | | | | | | DstIP: 2000::201 | | | | | | | | SrcIP: 2000::101 | | | | | | | |default via R4 | Figure 4: SIPv6 INVITE Ingress Filtering Call Flow The solution for these problems is explained in section 4.1, REGISTER Contact Header Address Selection. 3.5 Multihomed Host INVITE Via Header Address Selection Issue In some scenarios, R2 might provide connectivity to a private network. R2 might use ULA, Unique Local Address, address prefix 0xFC00::/7 (RFC 4193) for SLAAC, Stateless Address Autoconfiguration, assignments. Multihomed HostA would receive prefixes from both R1 and R2, and create at least one SLAAC GUA address based on ISP1 prefix, and at least one SLAAC ULA address, based on R2 prefix. When communicating with the external hosts, with GUA address, HostA should be able to select the ISP1 based global address. When talking to devices in the private network, it should select ULA address. Mudric Expires - July 2020 [Page 12] Internet-draft SIPv6 Address Selection on Multihomed Hosts January 2020 | INVITE, 200 OK [Internet] | to HostA | | +---------+ v | | +------------| ISP1 |----------+ | |2000::/48| | | +---------+ | | X ULA | | ^ ingress | | | filtering | | | | | | | [SITE-1] | [SITE-2] | | | +---------+ | +----------+ | | | | | +----| R1 | | | R3 | +-------+ | |2000::/64| | | 2000::/64| | | | +---------+ | +----------+ | HostA |---+ | | ^ | | | +---------+ | +-----+-----+ | +-------+ | | | INVITE, 200 OK | | 200 2000::201 +----| R2 | to fc00::301 | | OK fc00::301 |fc00::/64| +---------+ +-------+ +---------+ | SIP | | HostB | REGISTER --> | | Proxy | +-------+ Contact: fc00::301 | |2000::101| | +---------+ INVITE --> |Black LAN HA Contact: fc00::301 Via: fc00::301 +----------+ | | | HostC | | fc00::401| +----------+ Figure 5: SIPv6 ULA Filtering If HostA makes a call to HostB, it adds its IPv6 address to INVITE Via header (using RFC 3261). When HostB replies with 200 OK, SIP Proxy forwards the message to the topmost address in Via header (see RFC 3261). If HostA selects ULA address (e.g. fc00::301) for Via header, SIP Proxy forwards 200 OK to SER R3, and the 200 OK gets discarded sine ULA destination address is not globally routable. Mudric Expires - July 2020 [Page 13] Internet-draft SIPv6 Address Selection on Multihomed Hosts January 2020 HostA R1 R2 ISP1 ISP2 R3 R4 Proxy HostB | | | | | | | | | | RA(2000::/64) | | | | | | | | |<---------------+ | | | | | | | | RA(fc00::/64) | | | | | | | |<-----------------------+ | | | | | | | | | | | | | | + SLAAC | | | | | | | | (created 2000::201 & | | | | | | | | fc00::301 ) | | | | | | | | | | | | | | | | INVITE(Via: fc00::301) | | | | | | | +--------------->+----------->+------->+-------->+----------->| | | | | | | | | | | | | | | | | | 200 OK | | | | X<-------+<--------+<-----------+ | | | | (Via: fc00::301)| | | | | | SrcIP: 2000::101| | | | | | default via R3 | | Figure 6: SIPv6 ULA Filtering Call Flow 3.6 Multihomed Host SDP Address Selection Issues SDP, Session Description Protocol, (RFC 3264 and RFC 6157) Offerer IPv6 address might not be the best selected address on a multihomed host. draft-gont-6man-address-usage-recommendation, section 3, recommends to bind() a listening socket to a specific address of a given scope, instead of to the unspecified address, to avoid attacks by narrowing the address scope. The offerer might open a listening media socket and selects the socket source address using the socket SASA to SIP Proxy destination (e.g. listen on 2000::201, instead of listening on any address). If the Offerer randomly select IPv6 address for SDP 'c' line (e.g. 3000::301 in Figure 1 or fc00::301 in Figure 2), a destination answerer might get a different IPv6 address in SDP 'c' line than the one selected by the offerer's socket SASA, and the offerer might become unreachable. Mudric Expires - July 2020 [Page 14] Internet-draft SIPv6 Address Selection on Multihomed Hosts January 2020 HostA R1 R2 Proxy HostB | | | | | | RA(2000::/64) | | | | |<---------------+ | | | | RA(3000::/64) | | | |<-----------------------+ | | | | | | + SLAAC | | | | (created 2000::201 & | | | | 3000::301 ) | | | | | | | + open media socket | | | (SASA for dest. Proxy) | | | (listening IP=2000:2001) | | | | | | INVITE ('c'=3000::301) | | +--------------->+------------->| | | (Via: 2000::201) | | | | | | INVITE | | | | +----------->| | | | | 200 OK | | | | |<-----------+ | 200 OK | 200 OK | (Via: 2000::201) |<---------------+<-------------+ | | ACK | ACK | | +--------------->+------------->| | | | | ACK | | | | |----------->| | | | | | | | MEDIA | X<===============+<==========================| | (DstIP: 3000::301 | Figure 7: Offerer Listening Socket Unreachable Offerer's socket would apply SASA for SIP Proxy address (e.g. 2000::101 would be passed to the socket connect() API) and select 2000::201 for the socket source address. SDP protocol does not have an algorithm for 'c' line address selection and might select unreachable address (e.g. fc00::301) for the 'c' line. If the answerer sends media to the offered address (e.g. fc00::301), media might not reach the Offerer, since fc00::301 is not globally routable. Mudric Expires - July 2020 [Page 15] Internet-draft SIPv6 Address Selection on Multihomed Hosts January 2020 HostA R1 R2 Proxy HostB | | | | | | RA(2000::/64) | | | | |<---------------+ | | | | RA(fc00::/64) | | | |<-----------------------+ | | | | | | + SLAAC | | | | (created 2000::201 & | | | | fc00::301 ) | | | | | | | + open media socket | | | (SASA for dest. Proxy) | | | (listening IP=2000:2001) | | | | | | INVITE ('c'=fc00::301) | | +--------------->+------------->| | | (Via: 2000::201) | | | | | | INVITE | | | | +----------->| | | | | 200 OK | | | | |<-----------+ | 200 OK | 200 OK | (Via: 2000::201) |<---------------+<-------------+ | | ACK | ACK | | +--------------->+------------->| | | | | ACK | | | | |----------->| | | | | | | | MEDIA | | X<==========================| | | DstIP: fc00::301 | Figure 8: Media to ULA Lost In addition, if the offerer selects GUA SDP 'c' (e.g. 2000::201 on Figure 1), the media packets sent from the answerer (e.g. HostB), to HostA (e.g. 2000::201) address, might be filtered by ISP2. R3-ISP1 uplink fails, R3 sends RA to HB, telling the host R3 should not be used as default router. If HB does not expire 2000::/64 prefix and addresses, it might use SASA to select the source address for 'c'=2000::201 destination, and select 2000::102 address. R4 would ingress filter the media with 2000::102 source address. Mudric Expires - July 2020 [Page 16] Internet-draft SIPv6 Address Selection on Multihomed Hosts January 2020 HostA R1 R2 ISP1 ISP2 R3 R4 Proxy HostB | | | | | | | | | | RA(2000::/64) | | | | | | | | |<---------------+ | | | | | | | | RA(3000::/64) | | | | | | | |<-----------------------+ | | | | | | | | | | | | | | + SLAAC | | | | | | | | (created 2000::201 & | | | | | | | | 3000::301 ) | | | | | | | | | | | | | | | | INVITE('c'=2000::201) | | | | | | | +--------------->+----------->+------->+-------->|----------->| | | | | | | | | | | | | | | | | | 200 OK | +<---------------+<-----------+<-------+<--------|<-----------| | | | |<---X-->| | ('c'=2000:102)| | | | | | | | | | | | | | | | RA(Router Lifetime=0)| | | | | | |--------------------->| | | | | | | | | media | | | | | | | X<=================+ | | | | | | | DstIP: 2000::201 | | | | | | | | SrcIP: 2000::102 | | | | | | | |default via R4 | Figure 9: SIPv6 Media Ingress Filtering Call Flow The solution to this problem is explained in detail in section 6, SDP Address Selection. 4. SIP Headers Address Selection When a multi-homed host selects IPv6 address for a SIP header (e.g. Contact or Via header), it is important to select the address that will be reachable via the underlined network. SIP Signaling socket (e.g. TCP socket) solves the reachability problem by using the Source Address Selection, SASA, algorithm from RFC 6724, for a known destination. For the examples exercised on Figure 1 and Figure 2: - SIP REGISTER message is sent from HostA to SIP Proxy destination and the socket applies SASA to that destination, to select the packet source address, and Mudric Expires - July 2020 [Page 17] Internet-draft SIPv6 Address Selection on Multihomed Hosts January 2020 - SIP INVITE is sent from HostA to SIP Proxy destination and the socket applies SASA to that destination to select the packet source address. The same socket SASA SHOULD be used to select the addresses for SIP headers, so SIP messages sent to the selected addresses will not be filtered out. getsockname() socket API can be used to obtain the SASA address for a known destination (passed in connect() socket API). For the examples exercised on Figure 1 and Figure 2: - SIP REGISTER message: HostA SHOULD use socket SASA to SIP Proxy destination and set the selected SASA address to REGISTER Contact header. - SIP INVITE: HostA SHOULD use socket SASA to SIP Proxy destination and set the selected SASA address to INVITE Via header. For the second and third problem in section 3.1.1, SERc SHOULD expire 2000::/64 prefix, so SIP Proxy SHOULD stop using 2000::101 address, change the default router to SERd, make 3000::301 the preferred Ha contact, and use 3000::101 as the source address, to talk to Ha 3000::301 over SERd. The details about SASA improvements and dynamic address updates are in section 4.1. 4.1 REGISTER Contact Header Address Selection and Re-INVITE Draft draft-ietf-rtgwg-enterprise-pa-multihoming recommends: " A host is expected to be able respond dynamically to the failure of an uplink to a given ISP by no longer sending packets with the source address corresponding to that ISP." The current SASA address selection does not solve this problem. The solution SHOULD update SASA rule 5.5 to check for the reachability and avoid using a prefix from the router over which destination is not reachable. That would make HostA select ISP2 based address (e.g. 3000::301) for the REGISTER contact, when the uplink to ISP1 fails and SIP Proxy address (based on ISP1 prefix) is the destination. Another solution is provided by routers. When the reachability to a preferred ISP1 is lost, RA will be received from SERa for the unreachable ISP-A, with the preferred life time of zero, Router Lifetime of 0, and HostA SHOULD remove SERa as a default router, remove ISP1 based address (e.g. 2000::201) and send Re-REGISTER (to update contact to 3000::301) and Re-INVITE (to renegotiate 3000::301 IPv6 address) over SERb, using ISP-B based source address (e.g. Mudric Expires - July 2020 [Page 18] Internet-draft SIPv6 Address Selection on Multihomed Hosts January 2020 3000::301). Upon the uplink recovery, the contact and media addresses SHOULD be updated using SASA for the address selection. Next paragraph describes in details media address selection and renegotiation. The first problem in the section 3.1.1 can be solved by SERa detecting the uplink failure and instructing R1 to expire ISP-A prefix. When RA message is received with the Router Lifetime of zero and 2000::/64 prefix lifetime of zero, Ha SHOULD change the default router to SERb, expire 2000::201 address, and use 3000::301 as the source address, while talking to SIP Proxy 2000::101 over SERb. Ha SHOULD Re-REGISTER the new contact 3000::301. SIP Proxy SHOULD immediately update its contacts and stop using 2000::201 destination. SIP messages SHOULD be sent from SIP Proxy address selected for the HostA reachable destination. A solution might be for HostA to register a prioritized list of contact addresses, based on SASA and other policies. SIP Proxy SHOULD probe the contact addresses, starting from the most preferable one, till it finds a reachable one. SASA SHOULD be applied to the reachable destination address, and the selected SASA address would determine the first hop router. Hosts SHOULD be responsible to update the contact list based on network failures (a link to the first hop router or uplink to ISP failure) and recoveries. 5. SDP Address Selection SDP 'c' line address selection needs to be defined for the initial offer from a multihomed host. Initially, the offerer does not have the answerer address. The selected IPv6 address might not be the best choice. A subsequent address selection might be needed to get the right offerer address. SASA from RFC 6724 SHOULD be used to select the IPv6 address for SDP 'c' lines. If SASA is used it becomes apparent that: - A destination address needs to be chosen for the initial offer. SASA SHOULD applied to that address and the result is used for 'c' line. - When the offerer receives 200 OK and learns the destination address, the offerer might find the address selected during the initial SASA is not the right address. To reach a destination (SDP answerer), SIP offer must go via SIP server. That is why SIP server IPv6 address SHOULD be used for the initial SASA. Mudric Expires - July 2020 [Page 19] Internet-draft SIPv6 Address Selection on Multihomed Hosts January 2020 When SDP negotiation is done, the offerer learns the answerer IPv6 address. The offerer applies SASA to the answerer preferred address. The initially offered IPv6 address might not be the best SASA address. This might cause the source IPv6 socket address in the subsequent media packets to be different than the initially offered SDP 'c' line address. To prevent this, the offerer SHOULD do the second SASA, using the answerer 'c' line address as the destination. If SASA returns a different source address, the offerer SHOULD send Re-INVITE to renegotiate media addresses and open a new socket, using the newly selected source address. The initial socket SHOULD be closed. It is equally important for the answerer to apply SASA on the offered IPv6 address, when selecting the 'c' line address in 200 OK SDP. If SDP offer has two IPs of different address families (ALTC in RFC 6947), an address selection algorithm is needed to select the address for the opposite address family. The second media line address SHOULD be selected using: - SASA, if the SIP Proxy IP of the opposite address family is known. - Otherwise, the algorithm for the best 'guess' for the second address SHOULD be applied: -- Select the IP of the opposite address family from the same interface from which the fist IP was selected -- If the second address is IPv6, prefer an address with a bigger scope. Prefer global over ULA address. -- If the second address is IPv4, prefer a public over a private address. -- More rules can be added, like if there are multiple addresses of the same scope, prefer manual over DHCP over stateless addresses. - Upon receiving of the offer, the answerer responds to the offer with the acceptance response (200 OK), using a preferred IP address from the offered SDP (e.g. a preferred 'altc' line) as a destination address for its SASA address selection. The selected address is set into preferred 200 OK SDP media line. - The offerer now has the IP address of the destination host. If the source address, selected using the IP address from the acceptance response from the answerer, is the same IP address selected for the initial offer, the offerer address selection is completed. - If the selected address in the previous step is different from the address in the initial offer, the offerer sends Re-INVITE, using the address selected in the previous step. The second media IP address, if needed, is selected using the rules above. Mudric Expires - July 2020 [Page 20] Internet-draft SIPv6 Address Selection on Multihomed Hosts January 2020 The side effect of Re-INVITE is that media path might be different, and more optimal, than the signaling path. The offerer can advertise multiple IPv6 addresses in the initial SDP offer (ICE RFC 5245). The SASA preferred address, for SIP Proxy destination, SHOULD be the highest priority address. When the answerer sets SDP media address, or the host candidates, it SHOULD use Destination Address Selection, DASA, algorithm (RFC 6724) to select the preferred destination address for a media stream. The selected destination SHOULD be used during SASA to select the answerer preferred address. The answerer can offer the preferred address or the prioritized host candidate list. 6. Security Considerations This document recommends the use of existing standards to address the SIP Signaling and Media address selection. The security recommendations in outlined standards should be followed. 7. IANA Considerations There is no impact on existing SIP and IPv6 messages. 8. References 9. Acknowledgments The author gratefully acknowledges the contributions of: Rifaat Shekh-Yusef. Author's Addresses Dusan Mudric Avaya 425 Legget Dr. Ottawa, ON K2K 3C9 Canada Email: dmudric@avaya.com Dragan Grebovich Avaya 4655 Great America Parkway Santa Clara, CA Mudric Expires - July 2020 [Page 21] Internet-draft SIPv6 Address Selection on Multihomed Hosts January 2020 95054 USA Email: dgrebovich@avaya.com Mudric Expires - July 2020 [Page 22]