One document matched: draft-boucadair-mmusic-altc-03.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="std" docName="draft-boucadair-mmusic-altc-03.txt"
ipr="trust200902">
<front>
<title abbrev="SDP Alternate Connectivity Attribute">Session Description
Protocol (SDP) Alternate Connectivity (ALTC) Attribute</title>
<author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
<organization>France Telecom</organization>
<address>
<postal>
<street></street>
<city>Rennes</city>
<code>35000</code>
<country>France</country>
</postal>
<email>mohamed.boucadair@orange-ftgroup.com</email>
</address>
</author>
<author fullname="Hadriel Kaplan" initials="H." surname="Kaplan">
<organization>Acme Packet</organization>
<address>
<postal>
<street>71 Third Ave.</street>
<city>Burlington</city>
<region>MA</region>
<code>01803</code>
<country>USA</country>
</postal>
<email>hkaplan@acmepacket.com</email>
</address>
</author>
<author fullname="Robert R Gilman " initials="R. " surname="Gilman">
<organization>Independent</organization>
<address>
<postal>
<street></street>
</postal>
<email>bob_gilman@comcast.net</email>
<uri></uri>
</address>
</author>
<author fullname="Simo Veikkolainen" initials="S." surname="Veikkolainen">
<organization>Nokia</organization>
<address>
<postal>
<street></street>
</postal>
<email>Simo.Veikkolainen@nokia.com</email>
<uri></uri>
</address>
</author>
<date day="16" month="September" year="2011" />
<abstract>
<t>This document proposes a mechanism which allows to carry multiple IP
addresses, of different address families (e.g., IPv4, IPv6), in the same
SDP offer. The proposed attribute solves the backward compatibility
problem which plagued ANAT, due to its syntax.</t>
</abstract>
<note title="Requirements Language">
<t>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 <xref
target="RFC2119">RFC 2119</xref>.</t>
</note>
</front>
<middle>
<section title="Introduction">
<t></t>
<section title="Overall Context">
<t>Due to the IPv4 address exhaustion problem, IPv6 deployment is
becoming an urgent need, along with the need to properly handle IPv6
and IPv4 co-existence. The reality of IPv4-IPv6 co-existence
introduces heterogeneous scenarios with combinations of IPv4 and IPv6
nodes, some of which are capable of supporting both IPv4 and IPv6
dual-stack (DS) and some of which are capable of supporting only IPv4
or only IPv6. In this context, Session Initiation Protocol (SIP <xref
target="RFC3261"></xref>) User Agents (UAs) need to be able to
indicate their available IP capabilities in order to increase the
ability to establish successful SIP sessions, and also to avoid
invocation of adaptation functions such as Application Layer Gateways
(ALGs) and IPv4-IPv6 interconnection functions (e.g., NAT64 <xref
target="RFC6146"></xref>), and to avoid using private IPv4 addresses
through consumer NATs or Carrier Grade NATs (CGN <xref
target="I-D.ietf-behave-lsn-requirements"></xref>).</t>
<t>In the meantime, service providers are investigating scenarios to
upgrade their service offering to be IPv6-capable. The current
strategies involve either offering IPv6 only, for example to mobile
devices, or providing both IPv4 and IPv6 but with private IPv4
addresses which are NAT'ed by CGNs. In the latter case the end device
may be using "normal" IPv4 and IPv6 stacks and interfaces, or it may
tunnel the IPv4 packets though a DS-Lite stack integrated into the
host; in either case the device has both address families available
from a SIP and media perspective.</t>
<t>Regardless of the IPv6 transition strategy being used, it is
obvious that there will be a need for dual-stack SIP devices to
communicate with IPv4-only legacy UAs, and IPv6-only UAs, and other
dual-stack UAs. It may not, for example, be possible for a dual-stack
UA to communicate with an IPv6-only UA unless the dual-stack UA had a
means of providing the IPv6-only UA with its IPv6 local address for
media, while clearly it needs to provide a legacy IPv4-only device its
local IPv4 address. The communication must be possible in a
backwards-compatible fashion, such that IPv4-only SIP devices need not
support the new mechanism to communicate with dual-stack UAs.</t>
<t>The current means by which multiple address families can be
communicated are through ANAT <xref target="RFC4091"></xref> or ICE
<xref target="RFC5245"></xref>. ANAT has serious
backwards-compatibility problems as described in <xref
target="RFC4092"></xref>, which effectively make it unusable, and it
is deprecated by the IETF <xref target="RFC5245"></xref>. ICE at least
allows interoperability with legacy devices, by not doing ICE in such
cases, but it is a complicated and processing intensive mechanism, and
has seen limited deployment and implementation in SIP applications. In
some deployment models (e.g., closed networks), ICE is not usable at
all.</t>
<t>The use of the ALTC solution is compliant with <xref
target="RFC6157"></xref> which states:<list style="empty">
<t>"The use of ICE can be avoided for signaling messages that stay
within such managed networks."</t>
</list></t>
</section>
<section title="Purpose">
<t>This document proposes a new alternative: a backwards-compatible
syntax for indicating multiple media connection addresses and ports in
an SDP offer, which can immediately be selected from and used in an
SDP answer.</t>
<t>The proposed mechanism is independent of the model described in
<xref target="RFC5939"></xref> and does not require implementation of
sdp-capabilities-negotiations (a.k.a., sdp-cap-neg) to function. When
sdp-cap-neg is supported, the CCAP attribute defined in <xref
target="I-D.garcia-mmusic-sdp-misc-cap"></xref> should be used.</t>
<t>It should be noted that "backwards-compatible" in this document
generally refers to working with legacy IPv4-only devices. The choice
has to be made, one way or the other, because to interoperate with
legacy devices requires constructing SDP bodies which they would
understand and support, such that they detect their local address
family in the SDP connection line. It is not possible to support
interworking with both legacy IPv4-only and legacy IPv6-only devices
with the same SDP offer. Clearly, there are far more legacy IPv4-only
devices in existence, and thus those are the ones assumed in this
document. However, the syntax allows for a UA to choose which address
family to be backwards-compatible with, in case it has some means of
determining it.</t>
<t>Furthermore, even for cases where both sides support the same
address family, there should be a means by which the "best" address
family transport is used, based on what the UAs decide. The address
family which is "best" for a particular session cannot always be known
a priori. For example, in some cases the IPv4 transport may be better,
even if both UAs support IPv6.</t>
<t>The proposed solution provides the following benefits:</t>
<t><list style="symbols">
<t>Allows a UA to signal more than one IP address (type) in the
same SDP offer/answer;</t>
<t>Is backwards compatible. No parsing or semantic errors will be
experienced by a legacy UA or intermediary SIP nodes which do not
understand this new mechanism;</t>
<t>Is as lightweight as possible to achieve the goal, while still
allowing and interoperating with nodes which support other similar
or related mechanisms;</t>
<t>Is easily deployable in managed networks;</t>
<t>Requires minimal increase of the length of the SDP offer (I.e.,
minimizes fragmentation risks).</t>
</list></t>
</section>
<section title="Scope">
<t>This document proposes an alternative scheme, as replacement to the
ANAT procedure, to carry several IP address types in the same SDP
offer/answer while preserving backward compatibility.</t>
<t>While clearly two UAs communicating directly at a SIP layer need to
be able to support the same address family for SIP itself, current SIP
deployments almost always have Proxy Servers or B2BUA's in the SIP
signaling path, which can provide the necessary interworking of the IP
address family at the SIP layer. SIP-layer address family interworking
is out of scope of this document (see <xref
target="I-D.boucadair-sipping-ipv6-atypes"></xref> for a solution
candidate). Instead, this document focuses on the problem of
communicating media address family capabilities in a
backwards-compatible fashion. Since media can go directly between two
UAs, without a priori knowledge by the UAC of which address family the
far-end UAS supports, it has to offer both, in a backwards-compatible
fashion.</t>
</section>
</section>
<section title="Use Cases">
<t>Although the ALTC mechanism defined in this document is meant for
general use, the following use cases were explicitly considered:</t>
<t><list style="symbols">
<t>A dual-stack UAC initiating a SIP session without knowing the
address family of the ultimate target UAS.</t>
<t>A UA receiving a SIP session request with SDP offer and wishes to
avoid using IPv4, or to avoid IPv6.</t>
<t>An IPv6-only UA wishes to avoid using a NAT64 <xref
target="RFC6146"></xref>.</t>
<t>A SIP UA behind a Dual-Stack Lite CGN <xref
target="RFC6333"></xref>.</t>
<t>A SIP Service Provider or Enterprise domain of IPv4-only and/or
IPv6-only UA, which provides interworking by invoking IPv4-IPv6
media relays, wishes to avoid invoking such functions and let media
go end-to-end as much as possible.</t>
<t>A SIP Service Provider or Enterprise domain of a UA, which
communicates with other domains and wishes to either avoid invoking
IPv4-IPv6 interworking or let media go end-to-end as much as
possible.</t>
<t>A SIP Service Provider providing transit peering services for SIP
sessions, which may need to modify SDP in order to provide IPv4-IPv6
interworking, but would prefer to avoid such interworking or avoid
relaying media in general, as much as possible.</t>
<t>SIP sessions using the new mechanism crossing legacy SDP-aware
middleboxes which may not understand this new mechanism.</t>
</list></t>
</section>
<section title="Overview of the ALTC Mechanism">
<t></t>
<section title="Overview">
<t>The ALTC mechanism relies solely on the SDP offer/answer mechanism,
with specific syntax to indicate alternative connection addresses. The
basic concept is to use a new SDP attribute "altc", to indicate the IP
addresses for potential alternative connection addresses. The address
which is most likely to get chosen for the session is in the normal
'c=' line. Typically in current operational networks this would be an
IPv4 address. The “a=altc” lines contain, in preference
order, the alternative addresses offered for this session. This way, a
dual-stack UA might encode its IPv4 address in the “c=”
line, while possibly preferring to use an IPv6 address by indicating
this by the “a=altc” attribute line ordering. One of the
“a=altc” lines duplicates the address contained in the
“c=” line, for reasons explained in <xref
target="syntax"></xref>). The SDP answerer would indicate its chosen
address, by simply using that address family in the “c=”
line of its response.</t>
<t>An example of an SDP offer using this mechanism is as follows when
IPv4 is considered most likely to be used for the session, but IPv6 is
preferred:</t>
<t><figure>
<artwork><![CDATA[v=0
o=- 25678 753849 IN IP4 192.0.2.1
s=
c=IN IP4 192.0.2.1
t=0 0
m=audio 12340 RTP/AVP 0 8
a=altc IP6 2001:db8::1 45678
a=altc IP4 192.0.2.1 12340]]></artwork>
</figure></t>
<t>If IPv6 was considered most likely to be used for the session, the
SDP offer would be as follows:</t>
<t><figure>
<artwork><![CDATA[v=0
o=- 25678 753849 IN IP6 2001:db8::1
s=
c=IN IP6 2001:db8::1
t=0 0
m=audio 12340 RTP/AVP 0 8
a=altc IP6 2001:db8::1 45678
a=altc IP4 192.0.2.1 12340
]]></artwork>
</figure></t>
<t>Since an alternative address is likely to require an alternative
TCP/ UDP port number as well, the new “altc” attribute
includes both an IP address and a receive transport port number (or
multiple port numbers). The ALTC mechanism does not itself support
offering a different transport type (i.e., UDP vs. TCP), codec, nor
any other attribute. It is only intended for offering an alternative
IP address and port number.</t>
</section>
<section anchor="syntax" title="Rationale for the Chosen Syntax">
<t>The use of an 'a=' attribute line is, according to <xref
target="RFC4566"></xref>, the primary means for extending SDP and
tailoring it to particular applications or media. A compliant SDP
parser will ignore any session description that contains attribute
lines it does not support.</t>
<t>The rationale for encoding the same address and port in the
“a=altc” line as in the “m=” and
“c=” lines is to provide detection of legacy SDP-changing
middleboxes. Such systems may change the connection address and media
transport port numbers, but not support this new mechanism, and thus
two UAs supporting this mechanism would try to connect to the wrong
addresses. Therefore, the rules detailed in this document require the
SDP processor to check for matching altc and connection line addresses
and media ports, before choosing one of the alternatives.</t>
</section>
</section>
<section title="Alternate Connectivity Attribute">
<t></t>
<section title="ALTC Syntax">
<t>The altc attribute adheres to the <xref target="RFC4566"></xref>
"attribute" production. The ABNF syntax <xref target="RFC5234"></xref>
of altc is provided below:</t>
<t><figure align="center" anchor="Connectivity-ABNF"
suppress-title="true"
title="Connectivity Capability Attribute ABNF">
<artwork><![CDATA[altc-attr = "altc" att-value
att-value = addrtype SP connection-address SP port ["/" integer]]]></artwork>
</figure></t>
<t>The meaning of the fields are listed hereafter:</t>
<t><list style="symbols">
<t>addrtype: the addrtype field as defined in <xref
target="RFC4566"></xref> for connection data.</t>
<t>connection-address: a network address as defined in <xref
target="RFC4566"></xref> corresponding to the address type
specified by addrtype.</t>
<t>port: the port number to be used, as defined in <xref
target="RFC4566"></xref>. Distinct port numbers may be used per IP
address type. If the specified address type does not require a
port number, a value defined for that address type should be
used.</t>
</list></t>
<t>The “altc” attribute is only applicable in an SDP
offer. The “altc” attribute is a media-level-only
attribute, and MUST NOT appear at the SDP session level (since it
defines a port number, it is inherently tied to the media level).
There MUST NOT be more than one “altc” attribute per
addrtype within each media description. This restriction is necessary
in order that the addrtype of the reply may be used by the offerer to
determine which alternative was accepted.</t>
<t>The <addrtype>'s of the altc MUST correspond to the
<nettype> of the current connection (c=) line.</t>
<t>A media description MUST contain at least two “altc”
attributes: the alternative address and port as well as an address and
port which "duplicates" the address/port information from the current
'c=' and 'm=' lines. Each media level MUST contain at least one such
duplicate altc attribute, of the same IP address family, address, and
transport port number as those in the SDP connection and media lines
of its level. In particular, if a 'c=' line appears within a media
description, the addr-type and connection-address from that 'c=' line
MUST be used in the duplicate “altc” attribute for that
media description. If a 'c=' line appears only at the session level
and a given media description does not have its own connection line,
then the duplicate “altc” attribute for that media
description MUST be the same as the session-level address
information.</t>
<t>The “altc” attributes appearing within a media
description MUST be prioritized in order of appearance, with the first
altc given highest priority and the following altc attributes
prioritized in decending order. Given this rule, and the requirement
that the address information provided in the “m=” line and
“o=” line must be provided in an “altc”
attribute as well, it is possible that the address in the
“m=” line and “o=” line are not the preferred
choice.</t>
<t>If the addrtype of an “altc” attribute is not
compatible with the transport protocol or media format specified in
the media description, that altc attribute MUST be ignored.</t>
<t>Note that “a=altc” lines describe alternative
connection addresses, NOT addresses for parallel connections. When
several altc lines are present, multiple sessions establishment MUST
be avoided. Only one session is to be maintained with the remote party
for the associated media description.</t>
</section>
<section title="Usage and Interaction">
<t></t>
<section title="Usage">
<t>In an SDP offer/answer model, the SDP offer includes
“altc” attributes to indicate alternative connection
information (i.e., address type, address and port number(s)),
including the "duplicate" connection information already identified
in the 'c=' and 'm=' lines.</t>
<t>Additional, subsequent offers MAY include “altc”
attributes again, and may change the IP address, port numbers, and
order of preference; but they MUST include a duplicate
“altc” attribute for the connection and media lines in
that specific subsequent offer. In other words, every offered SDP
media description with an alternative address offer with an
“altc” attribute has at least two of them:</t>
<t><list style="empty">
<t>- one duplicating the 'c=' and 'm=' line information for that
media description, and</t>
<t>- one for each of the alternatives,</t>
</list></t>
<t>even though these need not be the same as the original SDP
offer.</t>
<t>The purpose of encoding a duplicate “altc” attribute
is to allow receivers of the SDP offer to detect if a legacy
SDP-changing middle box has modified the 'c=' and/or 'm=' line
address/port information. If the SDP answerer does not find a
duplicate “altc” attribute value for which the address
and port match exactly those in the 'c=' line and 'm=' line, the SDP
answerer MUST ignore the “altc” attributes and use the
'c=' and 'm=' offered address/ports for the entire SDP instead, as
if no “altc” attributes were present. The rationale for
this is that many SDP-changing middleboxes will end the media
sessions if they do not detect media flowing through them; if a
middlebox modified the SDP addresses, media MUST be sent using the
modified information.</t>
<t>Note that for RTCP, if applicable for the given media types, each
side would act as if the chosen “altc” attribute's port
number was in the 'm=' media line. Typically, this would mean RTCP
is sent to the odd +1 of the port number, unless some other
attribute determines otherwise.</t>
</section>
<section title="Usage of ALTC in an SDP Answer">
<t>The SDP answer SHOULD NOT contain “altc” attributes,
as the answer's 'c=' line implicitly and definitively chooses the
address family from the offer and includes it in “c=”
and “m=” lines of the answer. Furthermore, this avoids
establishing several sessions simultaneously between the
participating peers.</t>
<t>Any solution requiring the use of ALTC in SDP answer SHOULD
document its usage, in particular how sessions are established
between the participating peers.</t>
</section>
<section title="Interaction with ICE">
<t>Since ICE also includes address and port number information in
its candidate attributes, a potential problem arises: which one
wins. Since ICE also includes specific ICE attributes in the SDP
answer, the problem is easily avoided: if the SDP offerer supports
both ALTC and ICE, it may include both sets of attributes in the
same SDP offer. A legacy ICE-only answerer will simply ignore the
ALTC attributes, and use ICE. An ALTC-only answerer will ignore the
ICE attributes and reply without them. An answerer which supports
both MUST choose one and only one of the mechanisms to use: either
ICE or ALTC (unless the 'm=' or 'c=' lines were changed by a
middlebox, in which case the rules for both ALTC and ICE would make
the answerer revert to basic SDP semantics).</t>
</section>
<section title="Interaction with SDP-Cap-Neg">
<t>The ALTC mechanism is orthogonal to sdp-cap-neg. If the offerer
supports both ALTC and sdp-cap-neg, it may offer both.</t>
<t>A method based on sdp-cap-neg is described in <xref
target="I-D.garcia-mmusic-sdp-misc-cap"></xref> and may be used to
specify different connectivity for alternative configurations.</t>
</section>
</section>
</section>
<section title="The ALTC Option Tag">
<t>This document defines a new SIP option-tag for use in the "Supported"
SIP header field called "altc". This option-tag is for the purpose of
indicating that a UA supports the ALTC mechanism defined in this
document AND actually has multiple address family addresses available,
in order to improve troubleshooting, and in some cases provide a hint to
other nodes that the UA is capable of both IPv4 and IPv6 and ALTC.</t>
<t>A UA MUST NOT include this option tag unless it both (1) supports the
ALTC mechanism AND (2) has both an IPv4 and IPv6 address available for
media use. The reason it only includes the "altc" option-tag if it
actually has both addresses, is that having only a single address family
available implies the UA cannot truly perform ALTC in an offer; it may
have the necessary logic to, but it does not have the addresses to do
so. (remember one does not include the "altc" attribute in SDP unless
one has both address families available)</t>
<t>A UA SHOULD include the ALTC option-tag in a "Supported" SIP header
field in SIP REGISTER, OPTIONS, and INVITE requests and related
responses, if it has both address-family addresses available and
supports the ALTC mechanism. A UA MUST NOT include the ALTC option- tag
in the "Require" or "Proxy-Require" SIP header fields under any
conditions.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>If this document moves forward, it requests a new SDP attribute name
"altc", as defined earlier; and a new SIP option-tag be reserved, named
"altc", for the purposes described earlier.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>The security implications for ALTC are effectively the same as they
are for SDP in general <xref target="RFC4566"></xref>.</t>
</section>
<section title="Acknowledgements">
<t>Many thanks to T. Taylor for his review and comments.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc ?>
<?rfc include='reference.RFC.3261'?>
<?rfc include='reference.RFC.4566'?>
<?rfc include='reference.RFC.5234'?>
</references>
<references title="Informative References">
<?rfc include='reference.RFC.5245'?>
<?rfc include='reference.RFC.5939'?>
<?rfc include='reference.I-D.boucadair-sipping-ipv6-atypes'?>
<?rfc include='reference.I-D.garcia-mmusic-sdp-misc-cap'?>
<?rfc include='reference.RFC.6146'?>
<?rfc include='reference.RFC.6157'?>
<?rfc include='reference.RFC.6333'?>
<?rfc include='reference.RFC.4091'?>
<?rfc include='reference.RFC.4092'?>
<?rfc include='reference.I-D.ietf-behave-lsn-requirements'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 07:30:33 |