One document matched: draft-dupont-pcp-dslite-01.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc text-list-sybols="o-*+"?>
<rfc category="std" docName="draft-dupont-pcp-dslite-01" ipr="trust200902">
  <front>
    <title abbrev="PCP DS-Lite">
      The Port Control Protocol in Dual-Stack Lite environments
    </title>

    <author fullname="Francis Dupont" initials="F." surname="Dupont">
      <organization>Internet Systems Consortium</organization>
      <address>
        <email>fdupont@isc.org</email>
      </address>
    </author>
    <author fullname="Tina Tsou" initials="T." surname="Tsou">
      <organization>Huawei Technologies</organization>
      <address>
        <postal>
          <street>2330 Central Expressway</street>
          <city>Santa Clara</city>
          <country>USA</country>
        </postal>
        <phone>+1-408-330-4424</phone>
        <email>tina.tsou.zouting@huawei.com</email>
      </address>
    </author>
    <author fullname="Jacni Qin" initials="J." surname="Qin">
      <organization>ZTE Corporation</organization>
      <address>
	<postal>
	  <street/>
	  <city>Shanghai</city>
	  <country>P.R.China</country>
	</postal>
	<email>jacni@jacni.com</email>
      </address>
    </author>

    <date day="30" month="October" year="2011" />

    <workgroup>PCP Working Group</workgroup>

    <keyword>PCP, DS-Lite</keyword>

    <abstract>
      <t>This document specifies the so-called "plain mode" for
      the use of the Port Control Protocol (PCP) in Dual-Stack
      Lite (DS-Lite) environments.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>The Dual-Stack Lite (DS-Lite, <xref target="RFC6333"/>)
      is a technology which enables a broadband service provider to
      share IPv4 addresses among customers by combining two well-known
      technologies: IP in IP (IPv4-in-IPv6) and Network Address
      Translation (NAT).</t>

      <t>Typically, the home gateway embeds a Basic Bridging BroadBand
      (B4) capability that encapsulates IPv4 traffic into a IPv6
      tunnel to the carrier-grade NAT, named the Address Family
      Transition Router (AFTR). AFTRs are run by service
      providers.</t>

      <t>The Port Control Protocol (PCP, <xref
      target="I-D.ietf-pcp-base"/> allows customer applications
      to create mappings in a NAT for new inbound communications
      destined to machines located behind a NAT. In a DS-Lite
      environment, PCP servers control AFTR devices.</t>

      <t>Two different modes of operations were proposed: the plain
      and the encapsulation modes. This document selects the plain
      mode as the one to use.</t>

      <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>
    </section>

    <section title="Plain Mode">
      <t>In the plain mode the B4, the customer end-point of
      the DS-Lite IPv6 tunnel, implements a PCP proxy
      (<xref target="I-D.bpw-pcp-proxy"/>) function
      and uses UDP over IPv6 with the AFTR to send PCP requests
      and receive PCP responses.</t>

      <t>The B4 MUST source PCP requests with the IPv6 address
      of its DS-Lite tunnel end-point and MUST use a THIRD PARTY
      option either empty or carrying the IPv4 internal address
      of the mappings.</t>

      <t>In the plain mode the PCP discovery (<xref
      target="I-D.ietf-pcp-base"/> section 7.1 "General PCP Client:
      Generating a Request") is changed into:
      <list style="numbers">
	<t>if a PCP server is configured (e.g., in a configuration
        file or via DHCPv6), that single configuration source is used as
        the list of PCP Server(s), else;</t>
        <t>use the IPv6 address of the AFTR.</t>
      </list>
      To summary: the first rule remains the same with the precision
      that DHCP is DHCPv6, in the second rule the default router list
      is replaced by the AFTR.</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This document makes no request of IANA.</t>

      <t>Note to RFC Editor: this section may be removed on
      publication as an RFC.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>The plain mode provides a control point inside the home
      network where any policy on PCP requests can be applied, e.g.:
      <list style="symbols">
        <t>restrict the use of THIRD PARTY options to the B4</t>
        <t>apply an access-list on internal addresses and/or ports</t>
      </list></t>

      <t>At the opposite the encapsulation mode <xref target="encap"/>
      by default is fully transparent for the B4: PCP requests are
      blindly encapsulated as any other IPv4 packets to the
      Internet. So to apply a policy on them requires heavier and far
      less flexible tools.</t>
    </section>

    <section title="Acknowledgments">
      <t>Reinaldo Penno who checks the validity of the argument
      about the relative complexity of the encapsulation mode
      at the AFTR side.</t>
      <t>Christian Jacquenet and Mohammed Boucadair who proposed
      improvements to the document, including the PCP server
      discovery by Mohammed.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.6333"?>
      <?rfc include="reference.I-D.ietf-pcp-base"?>
      <?rfc include="reference.RFC.2119"?>
    </references>

    <references title="Informative References">
      <?rfc include="reference.I-D.bpw-pcp-proxy"?>
      <?rfc include="reference.I-D.bpw-pcp-upnp-igd-interworking"?>
    </references>

    <section anchor="encap" title="Encapsulation Mode">
      <t>The encapsulation mode deals at the B4 side with PCP traffic
      as any IPv4 traffic: it is encapsulated to and decapsulated from
      the AFTR over the DS-Lite IPv4 over IPv6 tunnel.</t>

      <t>At the AFTR side things are a bit more complex because
      the PCP server needs the context, here the source IPv6 address,
      for both to manage mappings and to send back response.
      So the AFTR MUST tag PCP requests with the source IPv6 address
      after decapsulation and before forwarding them to the PCP server,
      and use the same tag to encapsulate PCP responses to correct B4s.
      (the term "tag" is used to describe the private convention between
      the AFTR and the PCP server).</t>
    </section>

    <section title="Justification">
      <t>We believe most customers will run a PCP proxy on the B4
      because:
      <list style="symbols">
        <t>they want a control point where to apply security
        (<xref target="Security"/>)</t>
        <t>they run an InterWorking Function (IWF) for other
        protocols (<xref target="I-D.bpw-pcp-upnp-igd-interworking"/>)
        on the B4 so the proxy is just part of a bigger system</t>
      </list>
     BTW when the home network has only one node (dual-stack capable
     with embedded B4 element) attached, it is the PCP client.</t>

     <t>For a PCP proxy to use IPv4 (encapsulation mode) or
     IPv6 (plain mode) does not make a sensible difference,
     so from an implementation point of view the real difference
     is on the PCP server / AFTR side: the encapsulation mode
     require an Application Level Gateway (ALG) to tag PCP request
     with the corresponding customer after decapsulation,
     when the plain mode is fully transparent.</t>
    </section>
   </back>
</rfc>