One document matched: draft-boucadair-pcp-sip-ipv6-05.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="info" docName="draft-boucadair-pcp-sip-ipv6-05"
ipr="trust200902">
<front>
<title abbrev="PCP & SIP">PCP for SIP Deployments in Managed
Networks</title>
<author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
<organization>France Telecom</organization>
<address>
<postal>
<street></street>
<city>Rennes</city>
<region></region>
<code>35000</code>
<country>France</country>
</postal>
<email>mohamed.boucadair@orange.com</email>
</address>
</author>
<date />
<abstract>
<t>This document discusses how PCP (Port Control Protocol) can be used
in SIP deployments in managed networks. This document applies for both
IPv4 and IPv6.</t>
</abstract>
</front>
<middle>
<section anchor="introduction" title="Introduction">
<t>The base PCP specification allows to retrieve the external IP address
and external port to be conveyed in the SIP signaling messages <xref
target="RFC3261"></xref>. Therefore SIP Proxy Servers do not need to
support means to ease the NAT traversal of SIP messages (e.g., <xref
target="RFC5626"></xref>, <xref target="RFC6223"></xref>, etc.). Another
advantage of using the external IP address and port is this provides a
hint to the proxy server there is no need to return a small expire timer
(e.g., 60s). In addition, the outbound proxy does not need any further
feature to be supported in order to assist the remote endpoint to
successfully establish media sessions. In particular, ALGs are not
required in the NAT for this purpose and no dedicated functions at the
media gateway are needed.</t>
<t>This document discusses how PCP can be used in SIP deployments
(including IPv6 considerations).</t>
<t>The benefits of using PCP for SIP deployments are listed below:</t>
<t><list style="symbols">
<t>Avoid embedding an ALG in the middleboxes. Note, ALGs are not
recommended since the evolution of the service would depend on the
ALG maintenance.</t>
<t>Not require any Hosted NAT Traversal function (e.g., <xref
target="RFC7362"></xref>) to be embedded in the SIP server.
Intermediate NATs and firewalls are transparent to the SIP service
platform.</t>
<t>Avoid overloading the network with keepalive message to maintain
the mapping in intermediate middleboxes. <vspace
blankLines="1" />Note, mechanisms such as STUN do not allow to
discover the lifetime assigned by the middleboxes; frequent
keepalive messages are therefore generated to maintain binding
entries on those middleboxes. PCP is superior to those mechanisms as
it allows to retrieve the assigned lifetime, and to provide hints to
the middleboxes in order to decide which lifetime value is to be
assigned for that particular flow.</t>
<t>Work without requiring symmetric RTP/RTCP <xref
target="RFC4961"></xref>.</t>
<t>Not require symmetric SIP to work (i.e., rport <xref
target="RFC3581"></xref>).</t>
<t>Easily support unidirectional sessions.</t>
<t>Does not encounter issues with early media.</t>
<t>The combination of PCP and ALTC <xref target="RFC6947"></xref>
allows to optimize IPv4-IPv6 interworking function resources.</t>
<t>Because there is no need for connectivity checks, session
establishment delay is not impacted (pairs of ports can be
pre-reserved).</t>
<t>The binding entries maintained by a flow-aware device
(NAT/Firewall) can be associated with a textual description (<xref
target="RFC7220"></xref>).</t>
</list></t>
<t>Experimentation results, including SIP flow examples, are documented
in <xref target="I-D.boucadair-pcp-nat64-experiments"></xref>.</t>
<t>In deployments where ICE <xref target="RFC5245"></xref> is required,
PCP can be of great help as discussed in <xref
target="I-D.penno-rtcweb-pcp"></xref> for the WebRTC case. ICE can be
used in the context of SIP over WebSocket <xref target="RFC7118"></xref>
and WebRTC when deployed within managed networks. Because TURN suffers
from limitations in traversing NAT and firewalls over UDP, PCP is a
promising solution that can complement ICE in those deployment contexts
to soften the experienced high failure rate <xref
target="ICEFailure"></xref>. </t>
<t>The document targets SIP deployments in managed networks. It can also
be used as part of SIP-based services delivery in the context of
network-located residential gateway effort <xref
target="WT-317"></xref>. Typical deployment scenarios are shown in <xref
target="ref"></xref>.</t>
<t><figure align="center" anchor="ref"
title="Typical deployment scenarios">
<artwork><![CDATA[(a) SIP UA behind a NAT/FW communicating with a Proxy Server
__________
+----------+ +----------+ / \ +------------+
| SIP UA |___| NAT/FW |____| Network |___| SIP Proxy |
|PCP Client| |PCP Server| | | | Server |
+----------+ +----------+ \__________/ +------------+
(b) SIP UA behind a NAT/FW communicating with a remote SIP UA
__________
+----------+ +----------+ / \ +------------+
| SIP UA |___| NAT/FW |____| Network |___| SIP UA |
|PCP Client| |PCP Server| | | | |
+----------+ +----------+ \__________/ +------------+
(c) SIP UAs behind a NATs/FWs
__________
+----------+ +----------+ / \ +----------+ +----------+
| SIP UA |__| NAT/FW |__| Network |__| NAT/FW |__| SIP UA |
|PCP Client| |PCP Server| | | |PCP Server| |PCP Client|
+----------+ +----------+ \__________/ +----------+ +----------+
(d) SIP UA behind a CPE: PCP Proxy
+----------+ +---------+ +----------+
| SIP UA |____| CPE |__________| CGN/FW |
|PCP Client| |PCP Proxy| |PCP Server|
+----------+ +---------+ +----------+
]]></artwork>
</figure></t>
<t>The PCP server can be provisioned using a variety of means (e.g.,
<xref target="RFC7291"></xref>) or rely on the discovery method
specified in <xref target="RFC6887"></xref>.</t>
<t>This document does not make any assumption whether the PCP client is
implemented as an OS service or whether it is integrated in the SIP User
Agent (UA). Those considerations are implementation-service.</t>
</section>
<section title="PCP Features">
<t></t>
<section title="Learn External IP Address and Port Number">
<t>The PCP base specification allows to create mappings in
PCP-controlled devices and therefore prepare for receiving incoming
packets. A SIP UA can use PCP to create one mapping for SIP signalling
messages and other mappings for media session purposes.</t>
<t>The SIP UA uses the external IP address and port number to build
SIP headers. In particular, this information is used to build the VIA
and CONTACT headers.</t>
<t><xref target="ex1"></xref> shows an example of the flow exchange
that occurs to retrieve the external IP address and an external IP
address assigned by the NAT, while <xref target="ex1"></xref> provides
an excerpt of the SIP REGISTER message issued by the SIP UA; only the
assigned IP address and port number are present in the SIP
headers.</t>
<t><figure align="center" anchor="ex1" title="SIP REGISTER Call Flow">
<artwork><![CDATA[+---------+ +-------+ +------------+
| SIP UA | | NAT | | IPv4 SIP |
| PCP | |+ PCP | |Proxy Server|
| Client | |Server | | "Mysip.fr" |
+---------+ +-------+ +------------+
| (a) PCP MAP | |
|Suggested External IP@ | |
| ::ffff:0.0.0.0| |
|Suggested External Port| |
| 5060| |
|======================>| |
| (b) PCP MAP | |
|Suggested External IP@ | |
| ::ffff:192.0.2.1| |
|Suggested External Port| |
| 3938| |
|<======================| |
| (1)SIP REGISTER |(2)SIP REGISTER |
|======================>|===============>|
| (4) SIP 200 OK | (3) SIP 200 OK |
|<======================|<===============|
| | |
]]></artwork>
</figure></t>
<t><figure align="center" anchor="reg"
title="Example of REGISTER messager">
<artwork><![CDATA[ SIP Message:
REGISTER sip:mysip.fr SIP/2.0
Via: SIP/2.0/UDP 192.0.2.1:3938;branch=z9hG4bK1572043597
From: <sip:client4@mysip.fr:5070>;tag=893886783
To: <sip:client4@mysip.fr:5070>
Call-ID: 1271173454
CSeq: 2 REGISTER
Contact: <sip:client4@192.0.2.1:3938;line=b3433a7df33282d>
Authorization: Digest username="client4", realm="asterisk",
nonce="09f75e47", uri="sip:mysip.fr",
response="826fcff4c6e84ee45fbfa52c351e6316", algorithm=MD5
Max-Forwards: 70
User-Agent: Linphone/3.4.0 (eXosip2/unknown)
Expires: 3600]]></artwork>
</figure></t>
<t>The external IP address and port(s) instantiated for media streams,
are used to build the SDP offer/answer. In particular, the "c" line
and "m" lines.</t>
</section>
<section title="Learn and Set the Lifetime of Mapping Entries">
<t>PCP allows to discover and to set the lifetime of mapping
instantiated in intermediate middleboxes.</t>
<t>The discovery of the lifetime of a mapping avoids overloading the
network and SIP servers with frequent messages. This is in particular
important for cellular devices. According to <xref
target="Power"></xref>, the consumption of a cellular device with a
keep-alive interval equal to 20 seconds (that is the default value in
<xref target="RFC3948"></xref> for example) is 29 mA (2G)/34 mA (3G).
This consumption is reduced to 16 mA (2G)/24 mA (3G) when the interval
is increased to 40 seconds, to 9.1 mA (2G)/16 mA (3G) if the interval
is equal to 150 seconds, and to 7.3 mA (2G)/14 mA (3G) if the interval
is equal to 180 seconds. When no keep-alive is issued, the consumption
would be 5.2 mA (2G)/6.1 mA (3G). The impact of keepalive messages
would be more severe if multiple applications are issuing those
messages (e.g., SIP, IPsec, etc.).</t>
</section>
<section title="Allow Unidirectional Media Flows">
<t>As a consequence of instantiating mappings for media/session flows,
incoming packets can be successfully forwarded to the appropriate SIP
UA. Particularly, unidirectional media flows (e.g., announcement
server) will be forwarded accordingly.</t>
</section>
<section title="Preserve Port Parity">
<t>For deployments relying on classic RTP/RTCP odd/even port numbers
assignment scheme, PORT_SET option <xref
target="I-D.ietf-pcp-port-set"></xref> can be used by a SIP UA to
request port parity be preserved by the PCP server.</t>
<t>An example is depicted in <xref target="ex2"></xref>.</t>
</section>
<section title="Preserve Port Contiguity">
<t>For deployments assuming RTCP port number can be deduced from the
RTP port number, PORT_SET option <xref
target="I-D.ietf-pcp-port-set"></xref> can be used by a SIP UA to
retrieve a pair of contiguous ports from the PCP server.</t>
<t>A flow example is shown in <xref target="ex2"></xref>.</t>
<t><figure align="center" anchor="ex2"
title="Retrieve a pair of ports that preserves port parity">
<artwork><![CDATA[+---------+ +-------+ +------------+
| SIP UA | | NAT | | IPv4 SIP |
| PCP | |+ PCP | |Proxy Server|
| Client | |Server | | "Mysip.fr" |
+---------+ +-------+ +------------+
| (a) PCP MAP | |
|Suggested External IP@ | |
| ::ffff:192.0.2.1| |
|Suggested External Port| |
| 6000| |
| PORT_SET: | |
| "P" bit set to 1 | |
| Port Set Size=2 | |
|======================>| |
| (b) PCP MAP | |
|Assigned External IP@ | |
| ::ffff:192.0.2.1| |
|Assigned External Port | |
| 7076| |
| PORT_SET: | |
| "P" bit set to 1 | |
| Port Set Size=2 | |
|<======================| |
| | |
]]></artwork>
</figure></t>
</section>
<section title="Learn PREFIX64">
<t>If the SIP UA is located behind a NAT64 device <xref
target="RFC6146"></xref>, the option defined in <xref
target="RFC7225"></xref> can be used to retrieve the PREFIX64 used by
that NAT64 device.</t>
<t>The retrieved prefix will be used to locally build an
IPv6-converted IPv4 address (<xref target="RFC6052"></xref>)
corresponding to the IPv4 address included in the SDP message received
from a remote IPv4-enabled SIP UA; the SDP message can be an SDP offer
or an answer.</t>
<t><figure align="center" anchor="nat64"
title="Example of IPv6 to IPv4 SIP-Initiated Session">
<artwork><![CDATA[ +---------+ +-----+ +------------+ +---------+
|IPv6-only| |NAT64| | IPv4 SIP | |IPv4-only|
| SIP UA | | | |Proxy Server| | SIP UA |
+---------+ +-----+ +------------+ +---------+
| (a) PCP MAP Request | | |
|Suggested External IP@ | | |
| ::ffff:192.0.2.1| | |
|Suggested External Port| | |
| 6000| | |
| PORT_SET | | |
| PREFIX64 | | |
|======================>| | |
| (b) PCP MAP Response | | |
|Assigned External IP@ | | |
| ::ffff:192.0.2.1| | |
|Assigned External Port | | |
| 7076| | |
| PORT_SET | | |
| PREFIX64: | | |
| 2001:db8:122::/48 | | |
|<======================| | |
| (1) SIP INVITE | (2) SIP INVITE | (3) SIP INVITE |
|======================>|===============>|================>|
| (6) SIP 200 OK | (5) SIP 200 OK | (4) SIP 200 OK |
|<======================|<===============|<================|
| (7) SIP ACK | (8) SIP ACK | (9) SIP ACK |
|======================>|===============>|================>|
| | | |
|src port: dst port:|src port: dst port:|
|6000 port_B|7076 port_B|
|<======IPv6 RTP=======>|<============IPv4 RTP============>|
|<===== IPv6 RTCP======>|<============IPv4 RTCP===========>|
|src port: dst port:|src port: dst port:|
|6001 port_B+1|7077 port_B+1|
| | |
]]></artwork>
</figure><xref target="invite"></xref> shows the content of the SIP
INVITE message sent by the IPv6-only SIP UA. This message uses the
retrieved external IP address and external port numbers in SIP headers
and SDP lines. This message is translated by the NAT64 without
altering the SIP/SDP content.</t>
<t><figure align="center" anchor="invite"
title="Content of the INVITE message">
<artwork><![CDATA[ INVITE sip:13@mysip.fr:5070 SIP/2.0
Via: SIP/2.0/UDP 192.0.2.1:56252;branch=z9hG4bK1876803184
From: <sip:client4@mysip.fr:5070>;tag=631384602
To: <sip:13@mysip.fr:5070> Call-ID: 1377792765 CSeq: 21 INVITE
Contact: <sip:client4@192.0.2.1:56252>
Authorization: Digest username="client4", realm="asterisk",
nonce="3358d80b", uri="sip:13@mysip.fr:5070",
response="41442e94f6610e6f383a355a1bdf3e48", algorithm=MD5
Content-Type: application/sdp Allow: INVITE, ACK, CANCEL, OPTIONS,
BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
Max-Forwards: 70
User-Agent: Linphone/3.4.0 (eXosip2/unknown)
Subject: Phone call Content-Length: 443
v=0
o=client4 2487 2487 IN IP4 192.0.2.1
s=Talk c=IN IP4 192.0.2.1
b=AS:256
t=0 0
m=audio 7076 RTP/AVP 111 110 3 101
a=rtpmap:111 speex/16000
a=fmtp:111 vbr=on a=rtpmap:110 speex/8000
a=fmtp:110 vbr=on a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-11
m=video 9076 RTP/AVP 102 99
a=rtpmap:102 H264/90000
a=fmtp:102 profile-level-id=428014
a=rtpmap:99 MP4V-ES/90000
a=fmtp:99
profile-level-id=3
]]></artwork>
</figure></t>
</section>
<section title="Compliant with "a=rtcp" Attribute">
<t>The base PCP specification can be used to retrieve the port number
to be singled if "a=rtcp" attribute is in use <xref
target="RFC3550"></xref>.</t>
</section>
<section title="DSCP Marking Policy">
<t>PCP can be used to discover the DSCP value to be used when sending
real-time flows or to create a mapping that matches a DSCP marking.
This can be achieved using the DSCP option defined in <xref
target="I-D.boucadair-pcp-extensions"></xref>. DSCP setting value is
configured by the network and not the SIP UA.</t>
<t>This feature can be used as an input for DSCP marking in some
deployments such as <xref
target="I-D.ietf-tsvwg-rtcweb-qos"></xref>.</t>
</section>
</section>
<section title="Avoid Crossing CGNs">
<t></t>
<section title="Avoid NAT64">
<t>Because an IPv6-only SIP UA is not aware of the connectivity
capabilities of the remote UA, the IPv6-only SIP UA uses the ALTC
attribute <xref target="RFC6947"></xref> to signal the assigned IPv6
address and the IPv4 address learned via PCP.</t>
<t>If the remote SIP UA is IPv6-enabled, IPv6 transfer capabilities
will be used to place the session. If the remote SIP UA is IPv4-only,
IPv4 transfer capabilities will be used. NAT64 devices will be crossed
only if the remote UA is IPv4-only.</t>
<t><xref target="altc"></xref> provides an except of a SIP INVITE
message that encloses both the local IPv6 address and the IPv4
address/port number assigned by a NAT64 device.</t>
<t><figure align="center" anchor="altc"
title="Content of the INVITE message (with ALTC Attribute)">
<artwork align="center"><![CDATA[INVITE sip:13@mysip.fr:5070 SIP/2.0
Via: SIP/2.0/UDP 192.0.2.1:35011;branch=z9hG4bK702695557
From: <sip:client4@mysip.fr:5070>;tag=641336337
To: <sip:13@mysip.fr:5070>
Call-ID: 1532307201
CSeq: 20 INVITE
Contact: <sip:client4@192.0.2.1:35011>
Content-Type: application/sdp
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY,
MESSAGE, SUBSCRIBE, INFO
Max-Forwards: 70
User-Agent: Linphone/3.4.0 (eXosip2/unknown)
Subject: Phone call
Content-Length: 538
v=0
o=client4 3867 3867 IN IP4 192.0.2.1
s=Talk
c=IN IP4 192.0.2.1
b=AS:256
t=0 0
m=audio 7056 RTP/AVP 111 110 3 101
a=altc:1 IP6 2001:db8:1f94:3000:6c73:ea54:cef:2730 45678
a=altc:2 IP4 192.0.2.1 7056
]]></artwork>
</figure></t>
</section>
<section title="Avoid Crossing DS-Lite AFTR">
<t>SIP UAs co-located with the B4 <xref target="RFC6333"></xref> or
located behind the CPE can behave as dual-stack UAs:<list
style="symbols">
<t>Native IPv6 address is assigned locally.</t>
<t>The external IPv4 address and port is retrieved using PCP.</t>
</list>To avoid unnecessary invocation of AFTR resources, ALTC
attribute is used to signal both IPv4 and IPv6 addresses. If the
remote SIP UA is IPv6-enabled, IPv6 transfer capabilities will be used
to place the session (i.e., the flows will avoid crossing the DS-Lite
AFTR device). If the remote SIP UA is IPv4-only, IPv4 transfer
capabilities will be used. AFTR devices will be crossed only if the
remote UA is IPv4-only.</t>
</section>
</section>
<section anchor="security" title="Security Considerations">
<t>PCP-related security considerations are discussed in <xref
target="RFC6887"></xref>.</t>
<t>An attacker that wants to intercept media flows, without requiring
intercepting SIP signalling message, can insert a fake PCP server that
will influence the content of SIP messages so that an illegitimate node
is inserted in the media path. Such behavior is not desirable. Means to
prevent the PCP client from discovering illegitimate PCP servers must be
enforced. Within the context of this document, the network on which the
PCP messages are to be sent is fully trusted. For example, access
control lists (ACLs) can be installed on the PCP client, PCP server, and
the network between them, so those ACLs allow only communications from a
trusted PCP client to the PCP server.</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>This document does not require any action from IANA.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>Many thanks for T. Reddy, S. Kiesel, and R. Parthasarathi for their
review.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include='reference.RFC.3261'?>
<?rfc include='reference.RFC.3581'?>
<?rfc include='reference.RFC.6887'?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.5245"?>
<?rfc include='reference.RFC.3550'?>
<?rfc include='reference.RFC.5626'?>
<?rfc include='reference.RFC.7220'?>
<?rfc include='reference.RFC.6052'?>
<?rfc include='reference.RFC.4961'?>
<?rfc include='reference.RFC.6333'?>
<?rfc include='reference.RFC.6223'?>
<?rfc include='reference.RFC.7291'?>
<?rfc include='reference.RFC.6146'?>
<?rfc include='reference.I-D.ietf-pcp-port-set'?>
<?rfc include='reference.I-D.ietf-tsvwg-rtcweb-qos'?>
<?rfc include='reference.I-D.boucadair-pcp-extensions'?>
<?rfc include='reference.I-D.penno-rtcweb-pcp'?>
<?rfc include='reference.I-D.boucadair-pcp-nat64-experiments'?>
<?rfc include='reference.RFC.6947'?>
<?rfc include='reference.RFC.3948'?>
<?rfc include='reference.RFC.7118'?>
<?rfc include='reference.RFC.7362'?>
<?rfc include='reference.RFC.7225'?>
<reference anchor="Power"
target="http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=4212635">
<front>
<title>Energy Consumption of Always-On Applications in WCDMA
Networks</title>
<author fullname="Henry Haverinen" initials="H." surname="Haverinen">
<organization>Nokia Enterprise Solutions</organization>
</author>
<author fullname="Jonne Siren" initials="J." surname="Siren">
<organization>Nokia Enterprise Solutions</organization>
</author>
<author fullname="Pasi Eronen" initials="P." surname="Eronen">
<organization>Nokia Research Center</organization>
</author>
<date day="" month="April" year="2007" />
</front>
</reference>
<reference anchor="WT-317"
target="https://www.broadband-forum.org/technical/technicalwip.php">
<front>
<title>Network Enhanced Residential Gateway (NERG)</title>
<author fullname="" initials="" surname="">
<organization>Broadband Forum</organization>
</author>
<date day="" month="" year="2015" />
</front>
</reference>
<reference anchor="ICEFailure"
target="http://telemetry.mozilla.org/#filter=beta%2F36%2FWEBRTC_ICE_SUCCESS_RATE%2Fsaved_session%2FFirefox&aggregates=multiselect-all!Submissions&evoOver=Builds&locked=true&sanitize=true&renderhistogram=Graph">
<front>
<title>WEBRTC_ICE_SUCCESS_RATE</title>
<author fullname="" initials="" surname="">
<organization>Telemetry Dashboard</organization>
</author>
<date day="" month="March" year="2015" />
</front>
</reference>
<!---->
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 03:02:07 |