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]