doc: Add RFC documents

1 files changed, 1347 insertions, 0 deletions

diff --git a/doc/rfc/rfc6947.txt b/doc/rfc/rfc6947.txt
new file mode 100644
index 0000000..954376a
--- /dev/null
+++ b/doc/rfc/rfc6947.txt
@@ -0,0 +1,1347 @@
+
+
+
+
+
+
+Independent Submission                                      M. Boucadair
+Request for Comments: 6947                                France Telecom
+Category: Informational                                        H. Kaplan
+ISSN: 2070-1721                                              Acme Packet
+                                                               R. Gilman
+                                                             Independent
+                                                         S. Veikkolainen
+                                                                   Nokia
+                                                                May 2013
+
+
+                 The Session Description Protocol (SDP)
+                Alternate Connectivity (ALTC) Attribute
+
+Abstract
+
+   This document proposes a mechanism that allows the same SDP offer to
+   carry multiple IP addresses of different address families (e.g., IPv4
+   and IPv6).  The proposed attribute, the "altc" attribute, solves the
+   backward-compatibility problem that plagued Alternative Network
+   Address Types (ANAT) due to their syntax.
+
+   The proposed solution is applicable to scenarios where connectivity
+   checks are not required.  If connectivity checks are required,
+   Interactive Connectivity Establishment (ICE), as specified in RFC
+   5245, provides such a solution.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This is a contribution to the RFC Series, independently of any other
+   RFC stream.  The RFC Editor has chosen to publish this document at
+   its discretion and makes no statement about its value for
+   implementation or deployment.  Documents approved for publication by
+   the RFC Editor are not a candidate for any level of Internet
+   Standard; see Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6947.
+
+
+
+
+
+
+
+
+
+Boucadair, et al.             Informational                     [Page 1]
+
+RFC 6947          SDP Alternate Connectivity Attribute          May 2013
+
+
+Copyright Notice
+
+   Copyright (c) 2013 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
+   (http://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.
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
+     1.1.  Overall Context . . . . . . . . . . . . . . . . . . . . .   3
+     1.2.  Purpose . . . . . . . . . . . . . . . . . . . . . . . . .   4
+     1.3.  Scope . . . . . . . . . . . . . . . . . . . . . . . . . .   5
+     1.4.  Requirements Language . . . . . . . . . . . . . . . . . .   5
+   2.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   5
+   3.  Overview of the ALTC Mechanism  . . . . . . . . . . . . . . .   6
+     3.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .   6
+     3.2.  Rationale for the Chosen Syntax . . . . . . . . . . . . .   7
+   4.  Alternate Connectivity Attribute  . . . . . . . . . . . . . .   8
+     4.1.  ALTC Syntax . . . . . . . . . . . . . . . . . . . . . . .   8
+     4.2.  Usage and Interaction . . . . . . . . . . . . . . . . . .   9
+       4.2.1.  Usage . . . . . . . . . . . . . . . . . . . . . . . .   9
+       4.2.2.  Usage of ALTC in an SDP Answer  . . . . . . . . . . .  11
+       4.2.3.  Interaction with ICE  . . . . . . . . . . . . . . . .  11
+       4.2.4.  Interaction with SDP-Cap-Neg  . . . . . . . . . . . .  11
+   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
+   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
+   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  12
+   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
+     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  12
+     8.2.  Informative References  . . . . . . . . . . . . . . . . .  12
+   Appendix A.  ALTC Use Cases . . . . . . . . . . . . . . . . . . .  15
+     A.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .  15
+     A.2.  Multicast Use Case  . . . . . . . . . . . . . . . . . . .  16
+     A.3.  Introducing IPv6 into SIP-Based Architectures . . . . . .  17
+       A.3.1.  Avoiding Crossing CGN Devices . . . . . . . . . . . .  17
+       A.3.2.  Basic Scenario for IPv6 SIP Service Delivery  . . . .  17
+       A.3.3.  Avoiding IPv4/IPv6 Interworking . . . . . . . . . . .  18
+       A.3.4.  DBE Bypass Procedure  . . . . . . . . . . . . . . . .  20
+       A.3.5.  Direct Communications between IPv6-Enabled User
+               Agents  . . . . . . . . . . . . . . . . . . . . . . .  22
+
+
+
+
+
+Boucadair, et al.             Informational                     [Page 2]
+
+RFC 6947          SDP Alternate Connectivity Attribute          May 2013
+
+
+1.  Introduction
+
+1.1.  Overall Context
+
+   Due to the IPv4 address exhaustion problem, IPv6 deployment is
+   becoming an urgent need, along with the need to properly handle the
+   coexistence of IPv6 and IPv4.  The reality of IPv4-IPv6 coexistence
+   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)
+   [RFC3261] User Agents (UAs) need to be able to indicate their
+   available IP capabilities in order to increase the ability to
+   establish successful SIP sessions, to avoid invocation of adaptation
+   functions such as Application Layer Gateways (ALGs) and IPv4-IPv6
+   interconnection functions (e.g., NAT64 [RFC6146]), and to avoid using
+   private IPv4 addresses through consumer NATs or Carrier-Grade NATs
+   (CGNs) [RFC6888].
+
+   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 that are NATed 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 Dual-Stack Lite (DS-Lite) stack that
+   is integrated into the host [RFC6333].  In either case, the device
+   has both address families available from a SIP and media perspective.
+
+   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, IPv6-only UAs, and other dual-stack UAs.
+   It may not be possible, for example, for a dual-stack UA to
+   communicate with an IPv6-only UA unless the dual-stack UA has a means
+   of providing the IPv6-only UA with an IPv6 address, while clearly it
+   needs to provide a legacy IPv4-only device an IPv4 address.  The
+   communication must be possible in a backward-compatible fashion, such
+   that IPv4-only SIP devices need not support the new mechanism to
+   communicate with dual-stack UAs.
+
+   The current means by which multiple address families can be
+   communicated are through ANAT [RFC4091] or ICE [RFC5245].  ANAT has
+   serious backward-compatibility problems, as described in [RFC4092],
+   which effectively make it unusable, and it has been deprecated by the
+   IETF [RFC5245].  ICE at least allows interoperability with legacy
+   devices.  But, ICE is a complicated and processing-intensive
+   mechanism and has seen limited deployment and implementation in SIP
+   applications.
+
+
+
+Boucadair, et al.             Informational                     [Page 3]
+
+RFC 6947          SDP Alternate Connectivity Attribute          May 2013
+
+
+   ALTC has been implemented as reported in [NAT64-EXP].  No issues have
+   been reported in that document.
+
+1.2.  Purpose
+
+   This document proposes a new alternative: a backward-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.
+
+   The proposed mechanism is independent of the model described in
+   [RFC5939] and does not require implementation of SDP Capability
+   Negotiations (a.k.a., SDPCapNeg) to function.
+
+   It should be noted that "backward-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 that 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 backward-compatible with, in case it has
+   some means of determining it.
+
+   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
+   that 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.
+
+   The proposed solution provides the following benefits:
+
+   o  Allows a UA to signal more than one IP address (type) in the same
+      SDP offer.
+
+   o  Is backward compatible.  No parsing or semantic errors will be
+      experienced by a legacy UA or by intermediary SIP nodes that do
+      not understand this new mechanism.
+
+   o  Is as lightweight as possible to achieve the goal, while still
+      allowing and interoperating with nodes that support other similar
+      or related mechanisms.
+
+   o  Is easily deployable in managed networks.
+
+
+
+Boucadair, et al.             Informational                     [Page 4]
+
+RFC 6947          SDP Alternate Connectivity Attribute          May 2013
+
+
+   o  Requires minimal increase of the length of the SDP offer (i.e.,
+      minimizes fragmentation risks).
+
+   ALTC may also be useful for the multicast context (e.g., Section 3.4
+   of [MULTRANS-FW] or Section 3.3 of [ADDR-ACQ]).
+
+   More detailed information about ALTC use cases is provided in
+   Appendix A.
+
+1.3.  Scope
+
+   This document proposes an alternative scheme, as a replacement to the
+   ANAT procedure [RFC4091], to carry several IP address types in the
+   same SDP offer while preserving backward compatibility.
+
+   While two UAs communicating directly at a SIP layer clearly need to
+   be able to support the same address family for SIP itself, current
+   SIP deployments almost always have proxy servers or back-to-back user
+   agents (B2BUAs) in the SIP signaling path, which can provide the
+   necessary interworking of the IP address family at the SIP layer
+   (e.g., [RFC6157]).  SIP-layer address family interworking is out of
+   scope of this document.  Instead, this document focuses on the
+   problem of communicating media address family capabilities in a
+   backward-compatible fashion.  Because media can go directly between
+   two UAs, without a priori knowledge by the User Agent Client (UAC) of
+   which address family the far-end User Agent Server (UAS) supports, it
+   has to offer both, in a backward-compatible fashion.
+
+1.4.  Requirements Language
+
+   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 [RFC2119].
+
+2.  Use Cases
+
+   The ALTC mechanism defined in this document is primarily meant for
+   managed networks.  In particular, the following use cases were
+   explicitly considered:
+
+   o  A dual-stack UAC that initiates a SIP session without knowing the
+      address family of the ultimate target UAS.
+
+   o  A UA that receives a SIP session request with SDP offer and that
+      wishes to avoid using IPv4 or IPv6.
+
+   o  An IPv6-only UA that wishes to avoid using a NAT64 [RFC6146].
+
+
+
+
+Boucadair, et al.             Informational                     [Page 5]
+
+RFC 6947          SDP Alternate Connectivity Attribute          May 2013
+
+
+   o  A SIP UA behind a DS-Lite CGN [RFC6333].
+
+   o  A SIP service provider or enterprise domain of an IPv4-only and/or
+      IPv6-only UA that provides interworking by invoking IPv4-IPv6
+      media relays and that wishes to avoid invoking such functions and
+      to let media go end to end as much as possible.
+
+   o  A SIP service provider or enterprise domain of a UA that
+      communicates with other domains and that wishes either to avoid
+      invoking IPv4-IPv6 interworking or to let media go end to end as
+      much as possible.
+
+   o  A SIP service provider that provides transit peering services for
+      SIP sessions that may need to modify SDP in order to provide
+      IPv4-IPv6 interworking, but would prefer to avoid such
+      interworking or to avoid relaying media in general, as much as
+      possible.
+
+   o  SIP sessions that use the new mechanism when crossing legacy SDP-
+      aware middleboxes, but that may not understand this new mechanism.
+
+3.  Overview of the ALTC Mechanism
+
+3.1.  Overview
+
+   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 that 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 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 explicitly indicating the preference order
+   in the corresponding "a=altc" line.  One of the "a=altc" lines
+   duplicates the address contained in the "c=" line, for reasons
+   explained in Section 3.2.  The SDP answerer would indicate its chosen
+   address by simply using that address family in the "c=" line of its
+   response.
+
+
+
+
+
+
+
+
+
+
+
+Boucadair, et al.             Informational                     [Page 6]
+
+RFC 6947          SDP Alternate Connectivity Attribute          May 2013
+
+
+   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:
+
+   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:1 IP6 2001:db8::1 45678
+   a=altc:2 IP4 192.0.2.1 12340
+
+   If IPv6 were considered more likely to be used for the session, the
+   SDP offer would be as follows:
+
+   v=0
+   o=- 25678 753849 IN IP6 2001:db8::1
+   s=
+   c=IN IP6 2001:db8::1
+   t=0 0
+   m=audio 45678 RTP/AVP 0 8
+   a=altc:1 IP6 2001:db8::1 45678
+   a=altc:2 IP4 192.0.2.1 12340
+
+   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 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, or any other attribute.
+   It is intended only for offering an alternative IP address and port
+   number.
+
+3.2.  Rationale for the Chosen Syntax
+
+   The use of an "a=" attribute line is, according to [RFC4566], the
+   primary means for extending SDP and tailoring it to particular
+   applications or media.  A compliant SDP parser will ignore the
+   unsupported attribute lines.
+
+   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, this document requires
+   the SDP processor to proceed to the matching rules defined in Section
+   4.2.1.
+
+
+
+Boucadair, et al.             Informational                     [Page 7]
+
+RFC 6947          SDP Alternate Connectivity Attribute          May 2013
+
+
+4.  Alternate Connectivity Attribute
+
+4.1.  ALTC Syntax
+
+   The "altc" attribute adheres to the [RFC4566] "attribute" production.
+   The ABNF syntax [RFC5234] of altc is provided below.
+
+      altc-attr = "altc" ":" att-value
+      att-value = altc-num SP addrtype SP connection-address SP port
+                  ["/" rtcp-port]
+      altc-num  = 1*DIGIT
+      rtcp-port = port
+
+             Figure 1: Connectivity Capability Attribute ABNF
+
+   The meaning of the fields are as follows:
+
+   o  altc-num: digit to uniquely refer to an address alternative.  It
+      indicates the preference order, with "1" indicated the most
+      preferred address.
+
+   o  addrtype: the addrtype field as defined in [RFC4566] for
+      connection data.
+
+   o  connection-address: a network address as defined in [RFC4566]
+      corresponding to the address type specified by addrtype.
+
+   o  port: the port number to be used, as defined in [RFC4566].
+      Distinct port numbers may be used for each IP address type.  If
+      the specified address type does not require a port number, a value
+      defined for that address type should be used.
+
+   o  rtcp-port: including an RTP Control Protocol (RTCP) port is
+      optional.  An RTCP port may be indicated in the alternative "c="
+      line when the RTCP port cannot be derived from the RTP port.
+
+   The "altc" attribute is applicable only in an SDP offer.  The "altc"
+   attribute is a media-level-only attribute and MUST NOT appear at the
+   SDP session level.  (Because 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 so that the addrtype of the reply may be
+   used by the offerer to determine which alternative was accepted.
+
+   The "addrtype"s of the altc MUST correspond to the "nettype" of the
+   current connection ("c=") line.
+
+
+
+
+
+Boucadair, et al.             Informational                     [Page 8]
+
+RFC 6947          SDP Alternate Connectivity Attribute          May 2013
+
+
+   A media description MUST contain two "altc" attributes: the
+   alternative address and an alternative port.  It must also contain an
+   address and a port that "duplicate" 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 addrtype 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.
+
+   The "altc" attributes appearing within a media description MUST be
+   prioritized.  The explicit preference order is indicated in each line
+   ("1" indicates the address with the highest priority).  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 addresses in the "m=" line and "o="
+   line are not the preferred choice.
+
+   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.
+
+   Note that "a=altc" lines describe alternative connection addresses,
+   NOT addresses for parallel connections.  When several "altc" lines
+   are present, establishing multiple sessions MUST be avoided.  Only
+   one session is to be maintained with the remote party for the
+   associated media description.
+
+4.2.  Usage and Interaction
+
+4.2.1.  Usage
+
+   In an SDP offer/answer model, the SDP offer includes "altc"
+   attributes to indicate alternative connection information (i.e.,
+   address type, address and port numbers), including the "duplicate"
+   connection information already identified in the "c=" and "m=" lines.
+
+   Additional, subsequent offers MAY include "altc" attributes again,
+   and they 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 two "altc" attributes:
+
+
+
+Boucadair, et al.             Informational                     [Page 9]
+
+RFC 6947          SDP Alternate Connectivity Attribute          May 2013
+
+
+      - one duplicating the "c=" and "m=" line information for that
+        media description
+
+      - one for the alternative
+
+   These need not be the same as the original SDP offer.
+
+   The purpose of encoding a duplicate "altc" attribute is to allow
+   receivers of the SDP offer to detect if a legacy SDP-changing
+   middlebox 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 exactly match 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.
+
+   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 that RTCP is sent to
+   the port number equal to "RTP port + 1", unless some other attribute
+   determines otherwise.  For example, the RTP/RTCP multiplexing
+   mechanism defined in [RFC5761] can still be used with ALTC, such that
+   if both sides support multiplexing, they will indicate so using the
+   "a=rtcp-mux" attribute, as defined in [RFC5761], but the IP
+   connection address and port they use may be chosen using the ALTC
+   mechanism.
+
+   If the SDP offerer wishes to use the RTCP attribute defined in
+   [RFC3605], a complication can arise, since it may not be clear which
+   address choice the "a=rtcp" attribute applies to, relative to the
+   choices offered by ALTC.  Technically, RFC 3605 allows the address
+   for RTCP to be indicated explicitly in the "a=rtcp" attribute itself,
+   but this is optional and rarely used.  For this reason, this document
+   recommends using the "a=rtcp" attribute for the address choice
+   encoded in the "m=" line and including an alternate RTCP port in the
+   "a=altc" attribute corresponding to the alternative address.  In
+   other words, if the "a=rtcp" attribute explicitly encodes an address
+   in its attribute, that address applies for ALTC, as per [RFC3605].
+   If it does not, then ALTC assumes that the "a=rtcp" attribute is for
+   the address in the "m=" line, and the alternative "altc" attribute
+   includes an RTCP alternate port number.
+
+
+
+
+
+
+Boucadair, et al.             Informational                    [Page 10]
+
+RFC 6947          SDP Alternate Connectivity Attribute          May 2013
+
+
+4.2.2.  Usage of ALTC in an SDP Answer
+
+   The SDP answer SHOULD NOT contain "altc" attributes, because 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.
+
+   Any solution requiring the use of ALTC in the SDP answer SHOULD
+   document its usage, in particular how sessions are established
+   between the participating peers.
+
+4.2.3.  Interaction with ICE
+
+   Since ICE [RFC5245] 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 that supports both
+   MUST choose one and only one of the mechanisms to use: either ICE or
+   ALTC.  However, if the "m=" or "c=" line was changed by a middlebox,
+   the rules for both ALTC and ICE would make the answerer revert to
+   basic SDP semantics.
+
+4.2.4.  Interaction with SDP-Cap-Neg
+
+   The ALTC mechanism is orthogonal to SDPCapNeg [RFC5939].  If the
+   offerer supports both ALTC and SDPCapNeg, it may offer both.
+
+5.  IANA Considerations
+
+   Per this document, the following new SDP attribute has been assigned.
+
+      SDP Attribute ("att-field"):
+
+         Attribute name      altc
+         Long form           Alternate Connectivity
+         Type of name        att-field
+         Type of attribute   Media level only
+         Subject to charset  No
+         Purpose             See Sections 1.2 and 3
+         Specification       Section 4
+
+   The contact person for this registration is Mohamed Boucadair (email:
+   mohamed.boucadair@orange.com; phone: +33 2 99 12 43 71).
+
+
+
+Boucadair, et al.             Informational                    [Page 11]
+
+RFC 6947          SDP Alternate Connectivity Attribute          May 2013
+
+
+6.  Security Considerations
+
+   The security implications for ALTC are effectively the same as they
+   are for SDP in general [RFC4566].
+
+7.  Acknowledgements
+
+   Many thanks to T. Taylor, F. Andreasen, and G. Camarillo for their
+   review and comments.
+
+8.  References
+
+8.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
+              A., Peterson, J., Sparks, R., Handley, M., and E.
+              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
+              June 2002.
+
+   [RFC3605]  Huitema, C., "Real Time Control Protocol (RTCP) attribute
+              in Session Description Protocol (SDP)", RFC 3605, October
+              2003.
+
+   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
+              Description Protocol", RFC 4566, July 2006.
+
+   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
+              Specifications: ABNF", STD 68, RFC 5234, January 2008.
+
+   [RFC5761]  Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
+              Control Packets on a Single Port", RFC 5761, April 2010.
+
+8.2.  Informative References
+
+   [ADDR-ACQ]
+              Tsou, T., Clauberg, A., Boucadair, M., Venaas, S., and Q.
+              Sun, "Address Acquisition For Multicast Content When
+              Source and Receiver Support Differing IP Versions", Work
+              in Progress, January 2013.
+
+   [ADDR-FORMAT]
+              Boucadair, M., Ed., Qin, J., Lee, Y., Venaas, S., Li, X.,
+              and M. Xu, "IPv6 Multicast Address With Embedded IPv4
+              Multicast Address", Work in Progress, April 2013.
+
+
+
+
+Boucadair, et al.             Informational                    [Page 12]
+
+RFC 6947          SDP Alternate Connectivity Attribute          May 2013
+
+
+   [MULTRANS-FW]
+              Venaas, S., Li, X., and C. Bao, "Framework for IPv4/IPv6
+              Multicast Translation", Work in Progress, June 2011.
+
+   [MULTRANS-PS]
+              Jacquenet, C., Boucadair, M., Lee, Y., Qin, J., Tsou, T.,
+              and Q. Sun, "IPv4-IPv6 Multicast: Problem Statement and
+              Use Cases", Work in Progress, March 2013.
+
+   [NAT64-EXP]
+              Abdesselam, M., Boucadair, M., Hasnaoui, A., and J.
+              Queiroz, "PCP NAT64 Experiments", Work in Progress,
+              September 2012.
+
+   [RFC2871]  Rosenberg, J. and H. Schulzrinne, "A Framework for
+              Telephony Routing over IP", RFC 2871, June 2000.
+
+   [RFC4091]  Camarillo, G. and J. Rosenberg, "The Alternative Network
+              Address Types (ANAT) Semantics for the Session Description
+              Protocol (SDP) Grouping Framework", RFC 4091, June 2005.
+
+   [RFC4092]  Camarillo, G. and J. Rosenberg, "Usage of the Session
+              Description Protocol (SDP) Alternative Network Address
+              Types (ANAT) Semantics in the Session Initiation Protocol
+              (SIP)", RFC 4092, June 2005.
+
+   [RFC5245]  Rosenberg, J., "Interactive Connectivity Establishment
+              (ICE): A Protocol for Network Address Translator (NAT)
+              Traversal for Offer/Answer Protocols", RFC 5245, April
+              2010.
+
+   [RFC5853]  Hautakorpi, J., Camarillo, G., Penfield, R., Hawrylyshen,
+              A., and M. Bhatia, "Requirements from Session Initiation
+              Protocol (SIP) Session Border Control (SBC) Deployments",
+              RFC 5853, April 2010.
+
+   [RFC5939]  Andreasen, F., "Session Description Protocol (SDP)
+              Capability Negotiation", RFC 5939, September 2010.
+
+   [RFC6146]  Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
+              NAT64: Network Address and Protocol Translation from IPv6
+              Clients to IPv4 Servers", RFC 6146, April 2011.
+
+   [RFC6157]  Camarillo, G., El Malki, K., and V. Gurbani, "IPv6
+              Transition in the Session Initiation Protocol (SIP)", RFC
+              6157, April 2011.
+
+
+
+
+
+Boucadair, et al.             Informational                    [Page 13]
+
+RFC 6947          SDP Alternate Connectivity Attribute          May 2013
+
+
+   [RFC6333]  Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
+              Stack Lite Broadband Deployments Following IPv4
+              Exhaustion", RFC 6333, August 2011.
+
+   [RFC6406]  Malas, D. and J. Livingood, "Session PEERing for
+              Multimedia INTerconnect (SPEERMINT) Architecture", RFC
+              6406, November 2011.
+
+   [RFC6888]  Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A.,
+              and H. Ashida, "Common Requirements for Carrier-Grade NATs
+              (CGNs)", BCP 127, RFC 6888, April 2013.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Boucadair, et al.             Informational                    [Page 14]
+
+RFC 6947          SDP Alternate Connectivity Attribute          May 2013
+
+
+Appendix A.  ALTC Use Cases
+
+A.1.  Terminology
+
+   The following terms are used when discussing the ALTC use cases:
+
+   o  SBE (Signaling Path Border Element) denotes a functional element,
+      located at the boundaries of an ITAD (IP Telephony Administrative
+      Domain) [RFC2871], that is responsible for intercepting signaling
+      flows received from UAs and relaying them to the core service
+      platform.  An SBE may be located at the access segment (i.e., be
+      the service contact point for UAs), or be located at the
+      interconnection with adjacent domains [RFC6406].  An SBE controls
+      one or more DBEs.  The SBE and DBE may be located in the same
+      device (e.g., the SBC [RFC5853]) or be separated.
+
+   o  DBE (Data Path Border Element) denotes a functional element,
+      located at the boundaries of an ITAD, that is responsible for
+      intercepting media/data flows received from UAs and relaying them
+      to another DBE (or media servers, e.g., an announcement server or
+      IVR).  An example of a DBE is a media gateway that intercepts RTP
+      flows.  An SBE may be located at the access segment (i.e., be the
+      service contact point for UAs) or be located at the
+      interconnection with adjacent domains ([RFC6406]).
+
+   o  Core service platform ("core SPF") is a macro functional block
+      including session routing, interfaces to advanced services, and
+      access control.
+
+   Figure 2 provides an overview of the overall architecture, including
+   the SBE, DBE, and core service platform.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Boucadair, et al.             Informational                    [Page 15]
+
+RFC 6947          SDP Alternate Connectivity Attribute          May 2013
+
+
+                                  +----------+
+                                  | Core SIP |
+                       +--------->|    SPF   |<---------+
+                       |  SIP     +----------+     SIP  |
+                       v                                v
+                 +-----------+                   +-----------+
+   +-----+  SIP  |    SBE    |                   |    SBE    |  SIP
+   |  S  |<----->|           |                   |           |<----->
+   |  I  |       +-----------+                   +-----------+
+   |  P  |             ||                              ||
+   |     |       +-----------+                   +-----------+
+   |  U  |  RTP  |    DBE    |       RTP         |    DBE    |   RTP
+   |  A  |<----->|           |<----------------->|           | <----->
+   +-----+       +-----------+                   +-----------+
+
+   SIP UA can be embedded in the CPE or in a host behind the CPE
+
+                  Figure 2: Service Architecture Overview
+
+A.2.  Multicast Use Case
+
+   Recently, a significant effort has been undertaken within the IETF to
+   specify new mechanisms to interconnect IPv6-only hosts to IPv4-only
+   servers (e.g., [RFC6146]).  This effort exclusively covered unicast
+   transfer mode.  An ongoing initiative, called "multrans", has been
+   launched to cover multicast issues that are encountered during IPv6
+   transition.  The overall problem statement is documented in
+   [MULTRANS-PS].
+
+   A particular issue encountered in the context of IPv4/IPv6
+   coexistence and IPv6 transition of multicast services is the
+   discovery of the multicast group and source (refer to Section 3.4 of
+   [MULTRANS-PS]):
+
+   o  For an IPv6-only receiver requesting multicast content generated
+      by an IPv4-only source:
+
+      *  An ALG is required to help the IPv6 receiver select the
+         appropriate IP address when only the IPv4 address is advertised
+         (e.g., using SDP).  Otherwise, access to the IPv4 multicast
+         content cannot be offered to the IPv6 receiver.  The ALG may be
+         located downstream of the receiver.  As such, the ALG does not
+         know in advance whether the receiver is dual-stack or
+         IPv6-only.  The ALG may be tuned to insert both the original
+         IPv4 address and the corresponding IPv6 multicast address
+         using, for instance, the ALTC SDP attribute.
+
+
+
+
+
+Boucadair, et al.             Informational                    [Page 16]
+
+RFC 6947          SDP Alternate Connectivity Attribute          May 2013
+
+
+      *  To avoid involving an ALG in the path, an IPv4-only source can
+         advertise both its IPv4 address and its IPv4-embedded IPv6
+         multicast address [ADDR-FORMAT] using, for instance, the ALTC
+         SDP attribute.
+
+   o  For a dual-stack source sending its multicast content over IPv4
+      and IPv6, both IPv4 and IPv6 addresses need to be inserted in the
+      SDP part.  A means (e.g., ALTC) is needed for this purpose.
+
+A.3.  Introducing IPv6 into SIP-Based Architectures
+
+A.3.1.  Avoiding Crossing CGN Devices
+
+   Some service providers are in the process of enabling DS-Lite
+   [RFC6333] as a means to continue delivering IPv4 services to their
+   customers.  To avoiding crossing four levels of NAT when establishing
+   a media session (two NATs in the DS-Lite Address Family Transition
+   Router (AFTR) and two NATs in the DBE), it is recommended to enable
+   IPv6 functions in some SBEs/DBEs.  Then, DS-Lite AFTRs will not be
+   crossed for DS-Lite serviced customers if their UA is IPv6-enabled:
+
+   o  For a SIP UA embedded in the CPE, this is easy to implement since
+      the SIP UA [RFC3261] can be tuned to behave as an IPv6-only UA
+      when DS-Lite is enabled.  No ALTC is required for this use case.
+   o  For SIP UAs located behind the CPE, a solution to indicate both
+      IPv4 and IPv6 (e.g., ALTC) is required in order to avoid crossing
+      the DS-Lite CGN.
+
+A.3.2.  Basic Scenario for IPv6 SIP Service Delivery
+
+   A basic solution to deliver SIP-based services using an IPv4-only
+   core service platform to an IPv6-enabled UA is to enable the
+   IPv4/IPv6 interworking function in the SBE/DBE.  Signaling and media
+   between two SBEs and DBEs is maintained over IPv4.  IPv6 is used
+   between an IPv6-enabled UA and an SBE/DBE.
+
+   Figure 3 shows the results of session establishment between UAs.  In
+   this scenario, the IPv4/IPv6 interworking function is invoked even
+   when both involved UAs are IPv6-enabled.
+
+
+
+
+
+
+
+
+
+
+
+
+Boucadair, et al.             Informational                    [Page 17]
+
+RFC 6947          SDP Alternate Connectivity Attribute          May 2013
+
+
+                                 +----------+
+                                 | Core SIP |
+                            +--->|SPF (IPv4)|<---+
+                   IPv4 SIP |    +----------+    |IPv4 SIP
+                            v                    v
+                      +-----------+        +-----------+
+                      |    SBE    |        |    SBE    |  SIP
+             +------->|IPv4/v6 IWF|        |           |<-------+
+             |IPv6    +-----------+        +-----------+    IPv4|
+             | SIP                                           SIP|
+      +----+ |        +-----------+        +-----------+        | +----+
+      |IPv6|-+IPv6 RTP|    DBE    |IPv4 RTP|    DBE    |IPv4 RTP+-|IPv4|
+      | UA |<-------->|IPv4/v6 IWF|<------>|           |<-------->| UA |
+      +----+          +-----------+        +-----------+          +----+
+
+
+                                 +----------+
+                                 | Core SIP |
+                            +--->|SPF (IPv4)|<---+
+                   IPv4 SIP |    +----------+    |IPv4 SIP
+                            v                    v
+                      +-----------+        +-----------+
+                      |    SBE    |        |    SBE    |  SIP
+             +------->|IPv4/v6 IWF|        |IPv4/v6 IWF|<-------+
+             |IPv6    +-----------+        +-----------+    IPv6|
+             | SIP                                           SIP|
+      +----+ |        +-----------+        +-----------+        | +----+
+      |IPv6|-+IPv6 RTP|    DBE    |IPv4 RTP|    DBE    |IPv6 RTP+-|IPv6|
+      | UA |<-------->|IPv4/v6 IWF|<------>|IPv4/v6 IWF|<-------->| UA |
+      +----+          +-----------+        +-----------+          +----+
+
+                         Figure 3: Basic Scenario
+
+   It may be valuable for service providers to consider solutions that
+   avoid redundant IPv4/IPv6 NATs and that avoid involving several DBEs.
+
+A.3.3.  Avoiding IPv4/IPv6 Interworking
+
+   A solution to indicate both IPv4 and IPv4 addresses is required for
+   service providers that want the following:
+
+   1.  A means to promote the invocation of IPv6 transfer capabilities
+       that can be enabled, while no parsing errors are experienced by
+       core service legacy nodes.
+   2.  To optimize the cost related to IPv4-IPv6 translation licenses.
+   3.  To reduce the dual-stack lifetime.
+   4.  To maintain an IPv4-only core.
+   5.  To have a set of SBEs/DBEs that are IPv6-enabled.
+
+
+
+Boucadair, et al.             Informational                    [Page 18]
+
+RFC 6947          SDP Alternate Connectivity Attribute          May 2013
+
+
+   This section provides an overview of the procedure to avoid IPv4/IPv6
+   interworking.
+
+   When an SBE receives an INVITE, it instantiates in its DBE an
+   IPv6-IPv6 context and an IPv6-IPv4 context.  Both an IPv6 address and
+   an IPv4 address are returned, together with other information such as
+   port numbers.  The SBE builds an SDP offer, including both the IPv4
+   and IPv6-related information using the "altc" attribute.  IPv6 is
+   indicated as the preferred connectivity type; see Figure 4.
+
+                     o=- 25678 753849 IN IP4 192.0.2.2
+                     c=IN IP4 192.0.2.2
+                     m=audio 12340 RTP/AVP 0 8
+                     a=altc:1 IP6 2001:db8::2 6000
+                     a=altc:2 IP4 192.0.2.2 12340
+
+                  Figure 4: SDP Offer Updated by the SBE
+
+   The request is then forwarded to the core SPF, which, in turn,
+   forwards it to the terminating SBE.
+
+   o  If this SBE is a legacy one, then it will ignore "altc" attributes
+      and use the "c=" line.
+
+   o  If the terminating SBE is IPv6-enabled:
+
+      *  If the called UA is IPv4 only, then an IPv6-IPv4 context is
+         created in the corresponding DBE.
+
+      *  If the called UA is IPv6-enabled, then an IPv6-IPv6 context is
+         created in the corresponding DBE.
+
+   Figure 5 shows the results of the procedure when placing a session
+   between an IPv4 and IPv6 UAs, while Figure 6 shows the results of
+   establishing a session between two IPv6-enabled UAs.  The result is
+   still not optimal since redundant NAT66 is required (Appendix A.3.4).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Boucadair, et al.             Informational                    [Page 19]
+
+RFC 6947          SDP Alternate Connectivity Attribute          May 2013
+
+
+                                 +----------+
+                                 | Core SIP |
+                            +--->|SPF (IPv4)|<---+
+                   IPv4 SIP |    +----------+    |IPv4 SIP
+                            v                    v
+                      +-----------+        +-----------+
+                      |    SBE    |        |    SBE    |  SIP
+             +------->|IPv4/v6 IWF|        |IPv4/v6 IWF|<-------+
+             |IPv6    +-----------+        +-----------+    IPv4|
+             | SIP                                           SIP|
+      +----+ |        +-----------+        +-----------+        | +----+
+      |IPv6|-+IPv6 RTP|    DBE    |IPv6 RTP|    DBE    |IPv4 RTP+-|IPv4|
+      | UA |<-------->|   NAT66   |<------>|IPv4/v6 IWF|<-------->| UA |
+      +----+          +-----------+        +-----------+          +----+
+                       2001:db8::2
+
+         Figure 5: Session Establishment between IPv4 and IPv6 UAs
+
+                                 +----------+
+                                 | Core SIP |
+                            +--->|SPF (IPv4)|<---+
+                   IPv4 SIP |    +----------+    |IPv4 SIP
+                            v                    v
+                      +-----------+        +-----------+
+                      |    SBE    |        |    SBE    |  SIP
+             +------->|IPv4/v6 IWF|        |IPv4/v6 IWF|<-------+
+             |IPv6    +-----------+        +-----------+    IPv6|
+             | SIP                                           SIP|
+      +----+ |        +-----------+        +-----------+        | +----+
+      |IPv6|-+IPv6 RTP|    DBE    |IPv6 RTP|    DBE    |IPv6 RTP+-|IPv6|
+      | UA |<-------->|   NAT66   |<------>|   NAT66   |<-------->| UA |
+      +----+          +-----------+        +-----------+          +----+
+                       2001:db8::2
+
+             Figure 6: Session Establishment between IPv6 UAs
+
+A.3.4.  DBE Bypass Procedure
+
+   For service providers wanting to involve only one DBE in the media
+   path when not all SBEs/DBEs and UAs are IPv6-enabled, a means to
+   indicate both IPv4 and IPv6 addresses without inducing session
+   failures is required.  This section proposes an example procedure
+   using the "altc" attribute.
+
+   When the originating SBE receives an INVITE from an IPv6-enabled UA,
+   it instantiates in its DBE an IPv6-IPv6 context and an IPv6-IPv4
+   context.  Both an IPv6 address and an IPv4 address are returned,
+   together with other information, such as port numbers.  The SBE
+
+
+
+Boucadair, et al.             Informational                    [Page 20]
+
+RFC 6947          SDP Alternate Connectivity Attribute          May 2013
+
+
+   builds an SDP offer, including both IPv4 and IPv6-related information
+   using the "altc" attribute (Figure 7).  IPv6 is indicated as
+   preferred connectivity type.
+
+                     o=- 25678 753849 IN IP4 192.0.2.2
+                     c=IN IP4 192.0.2.2
+                     m=audio 12340 RTP/AVP 0 8
+                     a=altc:1 IP6 2001:db8::2 6000
+                     a=altc:2 IP4 192.0.2.2 12340
+
+                  Figure 7: SDP Offer Updated by the SBE
+
+   The request is then forwarded to the core SPF, which, in turn,
+   forwards it to the terminating SBE:
+
+   o  If the destination UA is IPv6 or reachable with a public IPv4
+      address, the SBEs only forwards the request without altering the
+      SDP offer.  No parsing error is experienced by core service nodes
+      since ALTC is backward compatible.
+
+   o  If the terminating SBE does not support ALTC, it will ignore this
+      attribute and use the legacy procedure.
+
+   As a consequence, only one DBE is maintained in the path when one of
+   the involved parties is IPv6-enabled.  Figure 8 shows the overall
+   procedure when the involved UAs are IPv6-enabled.
+
+                                 +----------+
+                                 | Core SIP |
+                            +--->|SPF (IPv4)|<---+
+                   IPv4 SIP |    +----------+    |IPv4 SIP
+                            v                    v
+                      +-----------+        +-----------+
+                      |    SBE    |        |    SBE    |  SIP
+             +------->|IPv4/v6 IWF|        |IPv4/v6 IWF|<-------+
+             |IPv6    +-----------+        +-----------+    IPv6|
+             | SIP                                           SIP|
+      +----+ |        +-----------+                             | +----+
+      |IPv6|-+IPv6 RTP|    DBE    |          IPv6 RTP           +-|IPv6|
+      | UA |<-------->|   NAT66   |<----------------------------->| UA |
+      +----+          +-----------+                               +----+
+   2001:db8::1        2001:db8::2
+
+                       Figure 8: DBE Bypass Overview
+
+
+
+
+
+
+
+Boucadair, et al.             Informational                    [Page 21]
+
+RFC 6947          SDP Alternate Connectivity Attribute          May 2013
+
+
+   The main advantages of such a solution are as follows:
+
+   o  DBE resources are optimized.
+   o  No redundant NAT is maintained in the path when IPv6-enabled UAs
+      are involved.
+   o  End-to-end delay is optimized.
+   o  The robustness of the service is optimized since the delivery of
+      the service relies on fewer nodes.
+   o  The signaling path is also optimized since no communication
+      between the SBE and DBE at the terminating side is required for
+      some sessions.  (That communication would be through the Service
+      Policy Decision Function (SPDF) in a Telecoms and Internet
+      converged Services and Protocols for Advanced Networks/IP
+      Multimedia Subsystem (TISPAN/IMS) context.)
+
+A.3.5.  Direct Communications between IPv6-Enabled User Agents
+
+   For service providers wanting to allow direct IPv6 communications
+   between IPv6-enabled UAs, when not all SBEs/DBEs and UAs are
+   IPv6-enabled, a means to indicate both the IPv4 and IPv6 addresses
+   without inducing session failures is required.  Below is an example
+   of a proposed procedure using the "altc" attribute.
+
+   At the SBE originating side, when the SBE receives an INVITE from the
+   calling IPv6 UA (Figure 9), it uses ALTC to indicate two IP
+   addresses:
+
+   1.  An IPv4 address belonging to its controlled DBE.
+   2.  The same IPv6 address and port as received in the initial offer
+       made by the calling IPv6.
+
+   Figure 9 shows an excerpted example of the SDP offer of the calling
+   UA, and Figure 10 shows an excerpted example of the updated SDP offer
+   generated by the originating SBE.
+
+                    o=- 25678 753849 IN IP6 2001:db8::1
+                    c=IN IP6 2001:db8::1
+                    m=audio 6000 RTP/AVP 0 8
+
+                   Figure 9: SDP Offer of the Calling UA
+
+                     o=- 25678 753849 IN IP4 192.0.2.2
+                     c=IN IP4 192.0.2.2
+                     m=audio 12340 RTP/AVP 0 8
+                     a=altc:1 IP6 2001:db8::1 6000
+                     a=altc:2 IP4 192.0.2.2 12340
+
+                  Figure 10: SDP Offer Updated by the SBE
+
+
+
+Boucadair, et al.             Informational                    [Page 22]
+
+RFC 6947          SDP Alternate Connectivity Attribute          May 2013
+
+
+   The INVITE message will be routed appropriately to the destination
+   SBE:
+
+   1.  If the SBE is a legacy device (i.e., IPv4-only), it will ignore
+       IPv6 addresses and will contact its DBE to instantiate an
+       IPv4-IPv4 context.
+   2.  If the SBE is IPv6-enabled, it will only forward the INVITE to
+       the address of contact of the called party:
+
+       a.  If the called party is IPv6-enabled, the communication will
+           be placed using IPv6.  As such, no DBE is involved in the
+           data path, as illustrated in Figure 11.
+       b.  Otherwise, IPv4 will be used between the originating DBE and
+           the called UA.
+
+                                 +----------+
+                                 | Core SIP |
+                            +--->|SPF (IPv4)|<---+
+                   IPv4 SIP |    +----------+    |IPv4 SIP
+                            v                    v
+                      +-----------+        +-----------+
+                      |    SBE    |        |    SBE    |  SIP
+             +------->|IPv4/v6 IWF|        |IPv4/v6 IWF|<-------+
+             |IPv6    +-----------+        +-----------+    IPv6|
+             | SIP                                           SIP|
+      +----+ |                                                  | +----+
+      |IPv6|-+                         IPv6 RTP                 +-|IPv6|
+      | UA |<---------------------------------------------------->| UA |
+      +----+                                                      +----+
+      2001:db8::1
+
+                   Figure 11: Direct IPv6 Communication
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Boucadair, et al.             Informational                    [Page 23]
+
+RFC 6947          SDP Alternate Connectivity Attribute          May 2013
+
+
+Authors' Addresses
+
+   Mohamed Boucadair
+   France Telecom
+   Rennes  35000
+   France
+
+   EMail: mohamed.boucadair@orange.com
+
+
+   Hadriel Kaplan
+   Acme Packet
+   71 Third Ave.
+   Burlington, MA  01803
+   USA
+
+   EMail: hkaplan@acmepacket.com
+
+
+   Robert R Gilman
+   Independent
+
+   EMail: bob_gilman@comcast.net
+
+
+   Simo Veikkolainen
+   Nokia
+
+   EMail: Simo.Veikkolainen@nokia.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Boucadair, et al.             Informational                    [Page 24]
+