<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc2865 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2865.xml">
<!ENTITY __reference.RFC.2869__g60i1uxb SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2869.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc compact="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc strict="yes" ?>
<?rfc linkmailto="yes" ?>
<rfc category="std" docName="draft-maglione-pcp-radius-ext-05"
     ipr="trust200902">
  <front>
    <title abbrev="PCP RADIUS Extensions">RADIUS Extensions for Port Control
    Protocol</title>

    <author fullname="Roberta Maglione" initials="R." surname="Maglione">
      <organization abbrev="">Telecom Italia</organization>

      <address>
        <postal>
          <street>Via Reiss Romoli 274</street>

          <city>Torino</city>

          <code>10148</code>

          <country>Italy</country>
        </postal>

        <phone></phone>

        <email>roberta.maglione@telecomitalia.it</email>
      </address>
    </author>

    <author fullname="Dean Cheng" initials="D." surname="Cheng">
      <organization>Huawei Technologies</organization>

      <address>
        <postal>
          <street>2330 Central Expressway</street>

          <city>Santa Clara</city>

          <region>CA</region>

          <code>95050</code>

          <country>USA</country>
        </postal>

        <phone>+1 408 330 4754</phone>

        <facsimile></facsimile>

        <email>Chengd@huawei.com</email>

        <uri></uri>
      </address>
    </author>

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

        <phone></phone>

        <facsimile></facsimile>

        <email>mohamed.boucadair@orange.com</email>

        <uri></uri>
      </address>
    </author>

    <date month="October" year="2012" />

    <area>Internet</area>

    <workgroup>pcp</workgroup>

    <abstract>
      <t>This memo specifies a new Remote Authentication Dial In User Service
      (RADIUS) attribute to carry one or a list of Port Control Protocol (PCP)
      Server Names. This attribute can be configured on a RADIUS server so
      that the information can be conveyed to Network Access Server (NAS) via
      RADIUS protocol, and the co-located Dynamic Host Configuration Protocol
      (DHCP/DHCPv6) server can then populate the information to PCP
      client.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="intro" title="Introduction">
      <t>Port Control Protocol (PCP) <xref target="I-D.ietf-pcp-base"></xref>
      provides a mechanism to control how incoming packets are forwarded by
      upstream devices such as NATs and firewalls. PCP is a client-server
      protocol where a PCP client may reside on a host, a Customer Premises
      Equipment (CPE), etc., which communicates with a PCP server that may
      reside anywhere in a network.</t>

      <t><xref target="I-D.ietf-pcp-base"> </xref> defines a procedure for the
      PCP client to communicate with its PCP Server. The IP address of the PCP
      Server(s) can be configured to the PCP Client; if not the PCP Client
      assumes its default router as being its PCP Server.</t>

      <t><xref target="I-D.ietf-pcp-dhcp"></xref> defines DHCPv6 and DHCPv4
      options which are meant to be used by a PCP client to discover a PCP
      server name. However, provisioning for name of the PCP server is
      required on a DHCPv4/DHCPv6 server before it can populate this
      information.</t>

      <t>Auto-configuration on a DHCPv4/DHCPv6 is possible in a broadband
      network, where typically, user profile is maintained on a Remote
      Authentication Dial In User Service (RADIUS) server and RADIUS protocol
      <xref target="RFC2865"></xref> is used to convey user-related
      information to other network elements including a host and CPE. <xref
      target="I-D.ietf-radext-ipv6-access"></xref> describes a typical
      broadband network scenario in which the Network Access Server (NAS) acts
      as the access gateway for the users (hosts or CPEs) and the NAS embeds a
      DHCPv6 Server function that allows it to locally handle any DHCPv6
      requests issued by the clients.</t>

      <t>In such environment, PCP server&rsquo;s name can be configured on a
      RADIUS server, which then passes the information to a NAS that
      co-locates with the DHCPv4/DHCPv6 server, which in turn populates the
      location of the PCP server.</t>

      <t>This memo defines a new RADIUS attribute that can be used to carry
      one or a list of PCP server names. As defined in <xref
      target="I-D.ietf-pcp-dhcp"></xref>, a PCP Server Name can be a DNS name,
      IP literals strings, etc. This document is designed to allow for
      configuring PCP Server name(s) which can be a DNS name, IP literals or
      any strings which may be passed to a local name resolution library on
      the PCP client side. Operational considerations related to the
      configuration of PCP Server names are similar to those discussed in
      Section 4 and Section 7 of <xref target="I-D.ietf-pcp-dhcp"></xref>. The
      proposed RADIUS option is designed to accommodate various deployment
      contexts (e.g., dedicated option per IP connectivity context, single
      option for dual-stack access, etc.).</t>

      <t>The approach described above is already used for providing the FQDN
      of the AFTR in the DS-Lite scenario <xref target="RFC6333"></xref> and
      the equivalent RADIUS attribute for the DS-Lite Tunnel Name is defined
      <xref target="RFC6519"></xref>.</t>
    </section>

    <!-- intro -->

    <section anchor="term" title="Terminology">
      <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"></xref>.</t>

      <t>The following terms are defined in <xref
      target="I-D.ietf-pcp-base"></xref>:</t>

      <t><list counter="1" hangIndent="5">
          <t>- Port forwarding</t>

          <t>- PCP</t>

          <t>- PCP client</t>

          <t>- PCP Server</t>
        </list>The following term is defined in <xref
      target="I-D.ietf-pcp-dhcp"></xref>:</t>

      <t><list counter="1" hangIndent="5">
          <t>- PCP Server Name</t>
        </list></t>
    </section>

    <section title="PCP Server Configuration using RADIUS and DHCPv4/DHCPv6 ">
      <t><xref target="fig1"></xref> illustrates an example of how RADIUS
      protocol works together with DHCPv6, to allow a host to learn
      automatically the name of a PCP server in case of a PPP session that
      carries IPv6 traffic.</t>

      <t>The Network Access Server (NAS) operates as a client of RADIUS and
      co-locates with a DHCPv6 Server for DHCPv6. The NAS initially sends a
      RADIUS Access Request message to the RADIUS server, requesting
      authentication. Once the RADIUS server receives the request, it
      validates the sending client and if the request is approved, the RADIUS
      server replies with an Access Accept message including a list of
      attribute-value pairs that describe the parameters to be used for this
      session. This list MAY also contain the name of a PCP server. When the
      co-located DHCPv6 server receives a DHCPv6 message containing the PCP
      Server Option, it SHALL use the name returned in the RADIUS attribute as
      defined in this memo to populate the DHCPv6 PCP Server option defined in
      <xref target="I-D.ietf-pcp-dhcp"></xref></t>

      <t><figure anchor="fig1" height=""
          title="RADIUS and DHCPv6 Message Flow for a PPP Session">
          <artwork><![CDATA[   PCP/DHCPv6                         NAS                      AAA
  Client                           DHCPv6 Server              Server
    |                                  |                        |
    |----PPP LCP Config Request------> |                        |
    |                                  |                        |
    |                                  |----Access-Request ---->|
    |                                  |                        |
    |                                  |<-Access-Accept---------|
    |                                  | (PCP-server-name)      |
    |<-----PPP LCP Config ACK  -----   |                        |
    |                                  |                        | 
    |                                  |                        |   
    |------ PPP IPv6CP Config Req ---->|                        |
    |                                  |                        |     
    |<----- PPP IPv6CP Config ACK -----|                        |
    |                                  |                        |  
    |-------  DHCPv6 Solicit  -------->|                        |
    |                                  |                        |
    |<-------DHCPv6 Advertisement------|                        |
    |  (PCP server Name DHCPv6 Option) |                        |
    |                                  |                        |
    |-------  DHCPv6 Request  -------->|                        |
    |  (PCP server Name DHCPv6 Option) |                        |
    |                                  |                        |
    |<-------- DHCPv6 Reply ---------  |                        |
    |  (PCP server Name DHCPv6 Option) |                        |
    |                                  |                        |
                        
                DHCPv6                         RADIUS 
]]></artwork>
        </figure></t>

      <t>The <xref target="fig2"></xref> illustrates how the RADIUS protocol
      and DHCPv6 work together to accomplish PCP client configuration when
      DHCPv6 is used to provide connectivity to a requesting host.</t>

      <t>The difference between this message flow and previous one is that in
      this scenario the interaction between NAS and AAA/ RADIUS Server is
      triggered by the DHCPv6 Solicit message received by the NAS from the
      DHCPv6 client, while in case of a PPP Session the trigger is the PPP LCP
      Config Request message received by the NAS.</t>

      <figure anchor="fig2" height=""
              title="RADIUS and DHCPv6 Message Flow for an IP Session">
        <artwork><![CDATA[ PCP/DHCPv6                           NAS                     AAA
  Client                           DHCPv6 Server             Server
    |                                  |                        |
    |------ DHCPv6 Solicit --------->  |                        |
    |                                  |                        |
    |                                  |----Access-Request ---->|
    |                                  |                        |
    |                                  |<-Access-Accept---------|
    |                                  | (PCP-server-name)      |
    |                                  |                        |
    |<-------DHCPv6 Advertisement------|                        |
    |  (PCP server Name DHCPv6 Option) |                        |
    |                                  |                        |
    |-------  DHCPv6 Request  -------->|                        |
    |  (PCP server Name DHCPv6 Option) |                        |
    |                                  |                        |
    | <-------- DHCPv6 Reply --------- |                        |             
    | (PCP server Name DHCPv6 Option)  |                        |

                        
                DHCPv6                         RADIUS 
]]></artwork>
      </figure>

      <t></t>

      <t>In the scenario depicted in <xref target="fig2"></xref> the
      Access-Request packet contains a Service-Type attribute with the value
      Authorize Only (17), thus according to <xref target="RFC5080"></xref>
      the Access-Request packet MUST contain a State attribute.</t>

      <t>A similar message flow also applies to the IPv4 scenario when DHCPv4
      is used to provide connectivity to the user (<xref
      target="fig3"></xref>).</t>

      <figure anchor="fig3" height=""
              title="RADIUS and DHCPv4 Message Flow for an IP Session">
        <artwork><![CDATA[ PCP/DHCPv4                             NAS                     AAA
  Client                            DHCPv4 Server              Server
    |                                  |                        |
    |-------- DHCP Discovery --------> |                        |
    |                                  |                        |
    |                                  |----Access-Request ---->|
    |                                  |                        |
    |                                  |<-Access-Accept---------|
    |                                  | (PCP-server-name)      |
    |                                  |                        |
    |<--------- DHCP Offer ------------|                        |
    |    (PCP server Name Sub-Option)  |                        |
    |                                  |                        |
    |---------  DHCP Request  -------->|                        |
    |   (PCP server Name Sub-Option)   |                        |   
    |                                  |                        |
    | <--------- DHCP Ack -------------|                        |             
    |    (PCP server Name Sub-Option)  |                        |
        
                DHCPv4                         RADIUS 
]]></artwork>
      </figure>

      <t></t>

      <t>After receiving the PCP server name in the initial Access-Accept the
      NAS MUST store the received PCP Server Name locally. When the PCP Client
      sends a DHCPv4 message to request an extension of the lifetimes for the
      assigned address or prefix, the NAS does not have to initiate a new
      Access-Request towards the AAA server to request the PCP server name.
      The NAS retrieves the previously stored PCP Server name and uses it in
      its reply.</t>

      <t>If the DHCPv4 server to which the DHCP Renew message was sent at time
      T1 has not responded, the DHCPv4 client initiates a Rebind/Reply
      exchange with any available server. In this scenario the NAS MUST
      initiate a new Access-Request towards the AAA server, after the
      co-located DHCPv4 server receives the DHCP message. The NAS MAY include
      the PCP Server Name attribute in its Access-Request.</t>

      <t>If the NAS does not receive the PCP server name attribute in the
      Access-Accept it MAY fallback to a pre-configured default tunnel name,
      if any. If the NAS does not have any pre-configured default tunnel name
      or if the NAS receives an Access-Reject, the PCP client can not be
      configured by the NAS.</t>

      <t>The scenario with PPP Session and IPv4 only connectivity does not
      require DHCPv4: the whole configuration of the client is performed by
      PPP. This case is out of scope of this document because in order to
      complete the configuration of the PCP client a new PPP IPC option would
      be required.</t>
    </section>

    <!-- term -->

    <!-- xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx -->

    <section anchor="Attrib" title="RADIUS Attribute">
      <t>A new RADIUS attribute, called PCP-Server-Name, along with its format
      is defined below.</t>

      <t>Description</t>

      <t>The PCP-server-name attribute contains a name or a list of names that
      refers to a PCP server the client requests to establish a connection to
      for PCP related service. The NAS shall use the name returned in the
      RADIUS PCP-server-name attribute to populate the PCP Server Name DHCP
      Sub-Option in IPv4 addressing context, or the PCP Server Name DHCPv6
      Option in IPv6 addressing context, as determined by the DHCP server
      <xref target="I-D.ietf-pcp-dhcp"></xref>. The same or distinct PCP
      Server Names may be configured; it is out of scope of this document to
      elaborate on this point. Nevertheless, the PCP-server-name attribute
      conveys an indication for the deployment context.</t>

      <t>The PCP-server-name attribute MAY appear in an Access-Accept packet.
      This attribute MAY be used in Access-Request packets as a hint to the
      RADIUS server; for example if the NAS is pre-configured with a default
      PCP server name, this name MAY be inserted in the attribute. The RADIUS
      server MAY ignore the hint sent by the NAS and it MAY assign a different
      PCP Server name. If the NAS includes the PCP Server Name attribute, but
      the AAA server does not recognize it, this attribute MUST be ignored by
      the AAA Server. If the NAS does not receive PCP Server Name attribute in
      the Access-Accept it MAY fallback to a pre-configured default PCP server
      name, if any. If the NAS is pre-provisioned with a default PCP server
      name and the PCP server name received in Access-Accept is different from
      the configured default, then the PCP server name received in the Access-
      Accept message MUST be used for the session.</t>

      <t>The PCP server Name RADIUS attribute MAY be present in
      Accounting-Request records where the Acct-Status-Type is set to Start,
      Stop or Interim-Update. The PCP Server Name RADIUS attribute MUST NOT
      appear more than once in a message.</t>

      <t>A summary of the PCP-Server-Name RADIUS attribute format is shown
      below. The fields are transmitted from left to right.</t>

      <figure>
        <preamble></preamble>

        <artwork><![CDATA[    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |  PCP-Server-Name  ....
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Context           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


]]></artwork>

        <postamble></postamble>
      </figure>

      <t>Type:</t>

      <t><list counter="1" hangIndent="5">
          <t>TBA1 for PCP-Server-Name.</t>
        </list>Length: <list counter="1" hangIndent="5">
          <t>This field indicates the total length in octets of this attribute
          including the Type, the Length fields and the length in octets of
          the PCP-Server-Name field</t>
        </list></t>

      <t>PCP-Server-Name:<list counter="1" hangIndent="5">
          <t>One or a list of PCP Server Name(s). The domain name is encoded
          as specified in <xref target="I-D.ietf-pcp-dhcp"></xref></t>
        </list>Context:<list counter="1" hangIndent="5">
          <t>This field indicates the IP connectivity context: <list
              counter="1" hangIndent="5">
              <t>0: Dual-Stack. The same option is provided for both DHCPv4
              and DHCPv6 requesting hosts</t>

              <t>1: This option is provided for DHCPv4 requesting hosts</t>

              <t>2: This option is provided for DHCPv6 requesting hosts</t>
            </list></t>
        </list></t>

      <!-- ProvSnd -->

      <!-- ProvRecv -->

      <t>The data type of PCP Server Name is a string with opaque
      encapsulation, according to <xref target="RFC6158">section 2.1 of
      </xref></t>

      <t></t>
    </section>

    <section title="Table of attributes">
      <t>The following table provides a guide to which attributes may be found
      in which kinds of packets, and in what quantity.</t>

      <texttable style="none">
        <ttcol>Request</ttcol>

        <ttcol>Accept</ttcol>

        <ttcol>Reject</ttcol>

        <ttcol>Challenge</ttcol>

        <ttcol>Accounting Request</ttcol>

        <ttcol>#</ttcol>

        <ttcol>Attribute</ttcol>

        <c>0-1</c>

        <c>0-1</c>

        <c>0</c>

        <c>0</c>

        <c>0-1</c>

        <c>TBA1</c>

        <c>PCP-Server-Name</c>
      </texttable>

      <t>The following table defines the meaning of the above table
      entries.</t>

      <t></t>

      <texttable style="none" suppress-title="true">
        <ttcol></ttcol>

        <ttcol></ttcol>

        <c>0</c>

        <c>This attribute MUST NOT be present in packet.</c>

        <c>0+</c>

        <c>Zero or more instances of this attribute MAY be present in
        packet.</c>

        <c>0-1</c>

        <c>Zero or one instance of this attribute MAY be present in
        packet.</c>
      </texttable>
    </section>

    <section anchor="seccons" title="Security Considerations">
      <t>This document has no additional security considerations beyond those
      already identified in <xref target="RFC2865"></xref>.</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This document requests the allocation of a new Radius attribute types
      from the IANA registry "Radius Attribute Types" located at
      http://www.iana.org/assignments/radius-types</t>

      <t><list>
          <t>PCP-Server-Name - TBA1</t>
        </list></t>
    </section>

    <section title="Acknowledgments">
      <t>The authors would like to thank Mohamed Boucadair and Mario Ullio for
      their valuable comments.</t>
    </section>
  </middle>

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

      <?rfc include='reference.I-D.ietf-pcp-dhcp'?>

      <?rfc ?>

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

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

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

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

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

      <?rfc ?>

      <?rfc ?>
    </references>

    <references title="Informative References">
      <?rfc include='reference.I-D.ietf-radext-ipv6-access'
?>

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