One document matched: draft-boucadair-pcp-sip-ipv6-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="info" docName="draft-boucadair-pcp-sip-ipv6-03"
     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.</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.</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>
        </list></t>

      <t>Experimentation results, including SIP flow examples, are documented
      in <xref target="I-D.boucadair-pcp-nat64-experiments"></xref>.</t>

      <t>Even 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.</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>.</t>
    </section>

    <section title="PCP Features">
      <t></t>

      <section title="Learn External IP Address and Port">
        <t>The PCP base specification allows to create mappings in
        PCP-controlled devices and therefore prepare for receiving incoming
        packets. A SIP User Agent 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>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 use by a SIP UA to
        request port parity be preserved by the PCP server.</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>
      </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. The retrieved prefix will be used to locally build
        an IPv6-converted IPv4 address corresponding to the IPv4 address
        included in the SDP message received from a remote IPv4-only SIP UA in
        a SDP offer or answer.</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>
      </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>
    </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 and S. Kiesel for their review.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include='reference.RFC.3261'?>

      <?rfc include='reference.RFC.3550'?>

      <?rfc include='reference.RFC.3581'?>

      <?rfc include='reference.RFC.6887'?>
    </references>

    <references title="Informative References">
      <?rfc include="reference.RFC.5245"?>

      <?rfc include='reference.RFC.5626'?>

      <?rfc include='reference.RFC.4961'?>

      <?rfc include='reference.RFC.6333'?>

      <?rfc include='reference.RFC.6223'?>

      <?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.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>

      <!---->
    </references>
  </back>
</rfc>