<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="info" docName="draft-petrescu-relay-route-pd-problem-00.txt"
     ipr="trust200902">
  <!-- category values: std, bcp, info, exp, and historic ipr values:
       trust200902, noModificationTrust200902,
       noDerivativesTrust200902, or pre5378Trust200902 you can add the
       attributes updates="NNNN" and obsoletes="NNNN" they will
       automatically be output with "(if approved)" -->

  <front>
    <title abbrev="DHCPv6 Route Problem at Relay during PD">Route Problem at
    Relay during DHCPv6 Prefix Delegation</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>

    <author fullname="Leaf Y. Yeh" initials="L." surname="Yeh">
      <organization>Freelancer Technologies</organization>
      <address>
        <postal>
          <street></street>
          <city></city>
          <region></region>
          <code></code>
          <country>P. R. China</country>
        </postal>
        <email>leaf.yeh.sdo@gmail.com</email>
      </address>
    </author>

    <author fullname="Alexandru Petrescu" initials="A." surname="Petrescu">
      <organization>CEA</organization>
      <address>
        <postal>
          <street></street>
          <city></city>
          <region></region>
          <code></code>
          <country>France</country>
        </postal>
        <phone></phone>
        <email>
	  Alexandru.Petrescu@cea.fr
	</email>
      </address>
    </author>
    

    <date />

    <!-- Meta-data Declarations -->

    <area>Internet</area>

    <workgroup>Network Working Group</workgroup>

    <!-- WG name at the upperleft corner of the doc, IETF is fine for
         individual submissions.  If this element is not present, the
         default is "Network Working Group", which is used by the RFC
         Editor as a nod to the history of the IETF. -->

    <keyword>DHCPv6 Prefix Delegation, Relay, Route, route
    installment</keyword>

    <!-- Keywords will be incorporated into HTML output files in a
         meta tag but they have no effect on text or nroff output. If
         you submit your draft to the RFC Editor, the keywords will be
         used for the search engine. -->

    <abstract>
      <t>
	The operation of a prefix delegation procedure with the DHCPv6
	protocol may need route setup and maintenance at the
	Delegating Router, Requesting Router and on the entity on
	which the Relay agent is implemented.  This document describes
	the problem of routing during DHCPv6 prefix delegation, and is
	illustrated by ADSL-type and cellular-type of topologies which
	may use Relays; we refer to section 14 of RFC 3633 which
	mentions the need of 'a protocol or other out of band
	communication to add routing information for delegated
	prefixes'.  Based on this problem, a number of requirements
	from the service providers are described.
      </t>
      
      <t>
	A small set of documented solutions are separately mentioned
	(snooping, route injection, etc.), together with their pros
	and cons according to a particular judgment.
      </t>      
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>
	The operation of a prefix delegation procedure with the DHCPv6
	protocol may need route setup and maintenance at the
	Delegating Router, Requesting Router and on the entity on
	which the Relay agent is implemented.  This document describes
	the problem of routing during DHCPv6 prefix delegation, and is
	illustrated by ADSL-type and cellular-type of topologies which
	may use Relays; we refer to section 14 of RFC 3633 which
	mentions the need of 'a protocol or other out of band
	communication to add routing information for delegated
	prefixes'.  Based on this problem, a number of requirements
	from the service providers are described.
      </t>
      
      <t>
	A small set of documented solutions are separately mentioned
	(snooping, route injection, etc.), together with their pros
	and cons according to a particular judgment.
      </t>            
    </section>

    <section 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">RFC 2119</xref>.</t>

      <t>
	PE router stands for 'Provider Edge' router.  It is a router
	in the provider's network, situated at its edge.  It is
	connected directly to the CE router ('Customer's Edge') which
	is situated within the customer's network, at its edge.
      </t>
      
    </section>

    <section title="Problem and the Related Topologies">
      <section title="Problem">
	<t>
	  This is a problem mentioned in the context of the
	  specification of the Relay Agent behaviour, in DHCPv6 Prefix
	  Delegation <xref target="RFC3633"/>.  If the network
	  topology in which running Prefix Delegation is run involves
	  a Relay Agent, then the delegating router may need a
	  protocol or other out-of-band communication to add routing
	  information for delegated prefixes into any router through
	  which the requesting router may forward traffic.  That
	  protocol or out-of-band communication are left unspecified.
	</t>

	<t>
	  A more detailed interpretation of that problem is described
	  next.
	</t>
	<t>
	  Intuitively, the Prefix Delegation operation consists in a
	  request and a delegation phase (more precisely, a prefix
	  allocation is performed by the software in the Server, and
	  messages such as Solicit/Advertise/Request/Reply are used,
	  see <xref target="RFC3315"/>).  In the request phase, the
	  Requesting Router requests an IPv6 prefix (not just an IPv6
	  address).  In the delegation phase, the Delegating Router
	  allocates (reserves) a prefix for use by the Requesting
	  Router; this prefix is then sent by the Delegating Router to
	  the Requesting Router.
	</t>

	<t>
	  Allocating a prefix is an operation different than
	  allocating simply an address.  In IPv6, one of the
	  differences relates to the way in which the routing is set
	  up with respect to the allocated parameter.  The routing for
	  the allocated address is pre-set ((1) the address is part of
	  a prefix, and the routing is pre-set for that prefix and (2)
	  the address is allocated by the Server and may be resolved
	  on-link); whereas the routing for a prefix can not be
	  pre-set ((1) it is next to impossible to pre-aggregate
	  several /64 allocated prefixes into a single pre-set /64
	  prefix and (2) the IP address of the next-hop is not known
	  at the Server during the prefix allocation phase, being
	  pre-configured on the Client, and not relayed in the
	  messages sent by the Relay; yet this address is needed for
	  route setup).  The concepts of numbered and unnumbered
	  interface may also play a distinctive role.
	</t>
	<t>
	  An alternative explanation: in the case of allocating an
	  address, the routing is pre-set for one particular prefix,
	  during network setup operation.  Due to the imposed length
	  of the Interface ID on the widely used Ethernet-type of
	  links, that pre-set prefix has length 64.  That particular
	  prefix covers the entire set of addresses which may be
	  dynamically allocated by DHCP.  On the contrary, dynamically
	  allocating a prefix does not benefit of this pre-setting of
	  routing, because of that 64 limit.  One can not pre-set a
	  prefix of length 64 which covers other prefixes of same
	  length /64.  There is thus a need to dynamically set a route
	  for the allocated prefix (because it is not possible to
	  pre-set routes for allocated prefixes).
	</t>
      </section>

      <section title="Relay vs. non-Relay Topologies">
	<t>
	  In practice, some topologies may accommodate easily the
	  deployment of Prefix Delegation, yet other topologies may
	  pose problems with respect to PD.  A topology where the
	  Requesting Router is a neighbor to the Delegating Router,
	  and the Requesting Router's default route is the Delegating
	  Router, may easily accommodate the Prefix Delegation
	  operation (in this case too, the delegating router needs the
	  operation of route set-up for network reachability).  This
	  topology is pictured below.
	</t>

	<t>
	  <figure align="center">
	    <artwork align="center">
	      <![CDATA[
             /----------\
             | Internet |
             \----------/
                   |
             +------------+
             | Delegating |
             |   Router   |
             +------------+
                   |
             +------------+
             |Requestting |
             |   Router   |
             +------------+
                  |            +--------+
                  \------------| Host PC|
                               +--------+
              ]]>                      
	    </artwork>
	  </figure>
	</t>
	
	<t>
	  On another hand, a topology where the Requesting Router is
	  not an immediate IP neighbor to the Delegating Router,
	  and/or RR's default route is not the DR, the operation of
	  allocating a prefix must necessarily involve an operation of
	  route set up.  This topology is illustrated below.
	</t>

	<t>
	  <figure align="center">
	    <artwork align="center">
	      <![CDATA[
             /----------\
             | Internet |
             \----------/
                   |
                   |         +------------+
                  ...--------| Delegating |
                   |         |   Router   |
                   |         +------------+
                   | 
            +------------+
            | DHCP Relay |
            +------------+
                   |
            +------------+
            | Requesting |
            |   Router   |
            +------------+
                   |            +--------+
                   \------------| Host PC|
                                +--------+
	      ]]>                      
	    </artwork>
	  </figure>
	</t>

	<t>
	  The operation of Prefix Delegation in the topology
	  illustrated above needs to provoke the setting up of a route
	  at the DHCP Relay during the Prefix Delegation operation.
	  Otherwise, the DHCP Relay will not be able to forward
	  packets addressed to Host PC (which is configured with an
	  address in the range of the allocated prefix).
	</t>

	<t>
	  This problem statement if related exclusively to the
	  operation of the Relay Agent and the computer (Router or
	  Host) on which this Agent runs.  These entities are direct
	  neighbors (in the sense of the Neighbor Discovery protocol)
	  with the interface on which the Requesting Router emits the
	  DHCPv6 Request message.  On another hand, a similar problem,
	  is considered in a more generic manner: upon delegation, use
	  a routing protocol to maintain routing state at Delegating
	  Routers, at other intermediary routers (for routers not
	  necessarily direct neighbors to the RR), and at the
	  Requesting Router; this is described in section 2.3.4 of
	  <xref target="I-D.stenberg-pd-route-maintenance"/>.
	</t>
      </section>

      <section title='Relay Topologies for Large-scale Deployments'>
	<t>
      	  The Figure 1 in <xref target="RFC3633"/> illustrates a
      	  network architecture in which prefix delegation could be
      	  used.  That architecture is relating directly to the use of
      	  DSL deployments.	  
	</t>

	<t>
      	  The following topologies pertinent for large-scale
      	  deployments are considered.  A topology for home
      	  deployments, and a topology of mobile hotspots (tethering
      	  smartphone) are pictured.
	</t>
      	<t>
      	  <figure align="center">
      	    <artwork align="center">
      	      <![CDATA[

             +------+------+  DHCPv6 Server
             |    DHCPv6   |
             |    Server   |
             |             |
             +------+------+
                    |
           _________|_________
          /                   \
         |  ISP Core Network   |
          \___________________/
                    |  Network-facing interface
                    |
             +------+------+
             |   Provider  |
             |     Edge    |  DHCPv6 Relay Agent, DHCPv6 Requestor
             |    Router   |
             +------+------+
                    |  Customer-facing interface
           _________|_________
          /                   \
         |   Access Network    |
          \___________________/
                    |
                    |
             +------+------+
             |   Customer  |  DHCPv6 Client
             |     Edge    |  DHCPv6-PD Requesting Router
             |    Router   |
             +------+------+
                    |
           _________|_________
          /                   \
         |  Customer Network   |
          \___________________/
      	      ]]>
      	    </artwork>
      	  </figure>
      	  <figure align="center">
      	    <artwork align="center">
      	      <![CDATA[
                                       +-------------+
                    ___________________|Correspondent|
                   |                   |    Node     |
                   |                   +-------------+
               /--------\              (peer node, RFC6275)
               |Internet|
               \--------/
                   |
               /--------\             +------------+
               |Cellular|_____________| DHCP Server|
               |Network |             +------------+
               \--------/            Delegating Router
                   |
               +--------+
               | Access |
               | Router |
               | DHCP   |
               | Relay  |
               +--------+
                   |
                     cellular radio link
                   |
               +-----------+
               | Tethering | Requesting
               | Smartphone| Router
               +-----------+
                   |             +-----------+
                   |--  wifi  ---| 'tethered'|
                                 |    PC     |
                                 +-----------+
      	      ]]>
      	    </artwork>
      	  </figure>
      	</t>
	<t>
    	In the above figure, the cellular network is considered to be
    	similar to an ISP network.
	</t>

      </section>

    </section>

    <section title="Issues and Requirements">
      <t>
	As a reminder, the main requirement from service providers is the
	following:
      </t>

        <t>
	  <list style="symbols">
            <t>
	      Need for deterministic and dynamic means to drive route
	      aggregates and associated route announcement actions to
	      be undertaken by PE routers while ensuring a consistency
	      with prefix assignment states. In particular:
	    <list style="symbols">
                <t>
		  Optimizing the size of routing and forwarding tables
		  must be supported. As such, route aggregation must
		  be supported by these routers.
		</t>

                <t>
		  Failures to deliver incoming packets to a customer
		  serviced behind a given PE router must be
		  avoided. Dedicated routing actions must be achieved
		  to ensure incoming traffic will be forwarded to the
		  appropriate customer's device. Nevertheless,
		  triggers to drive the level of route aggregation and
		  required route announcement actions must be
		  supported.
		</t>

                <t>
		  Prefix assignments and routing actions must be
		  correlated otherwise delivery of connectivity
		  service will fail.
		</t>
              </list>
	    </t>
          </list>
	</t>

        <t>
	  These requirements can be fulfilled by a variety of
	  solutions that have their limits. For instance:
	</t>

        <t>
	  <list style="symbols">
            <t>
	      Current practices rely on static configuration. This
	      practice is prone to errors.
	    </t>

            <t>
	      The level of route aggregation cannot be driven by PE
	      routers without any hint(s) from an entity that has the
	      visibility on aggregation policies and the status of
	      prefixes, etc.
	    </t>

            <t>
	      Relying on proprietary means to trigger the injection of
	      routing entries may lead to undesired behavior: increase
	      the size of routing table and forwarding table due to
	      injecting very specific routes, etc.
	    </t>
          </list>
	</t>

        <t>
	  Note:
	</t>

        <t>
	  <list style="symbols">
            <t>
	      Prefix assignment policies can be configured to DHCP
	      servers including topological aware considerations
	      (e.g., regional-based assignment, per-service
	      assignment, etc.). Refer to Section 4 of <xref
	      target="I-D.lemon-dhc-topo-conf"/>.
	    </t>

            <t>
	      Status of active (prefix) states is maintained by DHCP
	      servers.
	    </t>

            <t>
	      The use of DHCP for this purpose does not require an
	      additional interface to pass the state maintained by the
	      DHCP server to a routing controller which will then
	      undertake appropriate actions.
	    </t>
          </list>
	</t>

	<t>
	  Finally, it is worth mentioning that other standards
	  development organizations consider the use of DHCPv6 Prefix
	  Delegation in particular contexts:
	  <list style="symbols">
          <t>
	    at the Broadband Forum ('BBF'), a technical report titled
	    "IPv6 in the context of TR-101", dated November 2010,
	    <xref target="bf"/>, lists a number of requirements
	    derived from the problem that "hosts receiving IPv6
	    addresses from the RR are not known to the BNG, i.e. the
	    BNG is not aware of what addresses/prefixes are assigned
	    to hosts attached to the RG acting as RR."
	  </t>
	  <t>
	    at 3GPP, the specification <xref target="3gpp-ref"/>
	    describes the use of DHCPv6 prefix delegation using S2c.
	    It is for a "User Equipment acting as a Mobile Router".
	  </t>
        </list>	  

	</t>
      </section>
      
    <section title="Potential Solutions, Solution Space">
      <t></t>

      <section title="DHCPv6 message snooping for PD-prefix">
        <t>
	  The Provider Edge (PE) router acting as relay snoops every
	  reply message from the server with valid lease. Per the
	  parameters, such as valid-lifetime and preferred-lifetime,
	  shown the IA_PD option, PE router knows the lease of each
	  delegated prefix. Then the PE can add and withdraw the
	  associated route per the lease of each delegated prefix.
	</t>

	<t>
	  Pros:  no new messages and options defined, no additional
	  function on the relay.
	</t>
	<t>
	  Cons: but PE router need to snoop each DHCPv6-PD message,
	  then take action for routing per the lease of each delegated
	  prefix.
	</t>

	<t>
	  In the real deployed network, PE router always need to
	  handle each protocol message in the control plane including
	  DHCPv6 message. That makes snooping sounds not a problem for
	  PE router. Almost every implementation of PE router today in
	  the Telecom's network adopts the method of snooping to get
	  the lease of each delegated prefix.
	</t>

      </section>

      <section title="ietf-dhc-dhcpv6-agentopt-delegate for PD-prefix">
        <t>
	  <xref target="I-D.ietf-dhc-dhcpv6-agentopt-delegate"/>.
	</t>

	<t>
	  The relay use OPTION_ORO to request the assigned address or
	  the delegated prefixes for the client from the server. But
	  the draft has not mentioned in which DHCPv6 message the
	  OPTION_ORO will always be employed.
	</t>

	<t>
	  Pros: no new messages, just define a new RAAN option
	  (OPTION_AGENT_NOTIFY) to convey OPTION_IAADDR and
	  OPTION_IAPREFIX, sounds it can de-couple with the DHCPv6-PD
	  mechanism.
	</t>
	<t>
	  Cons: sounds only for the route @ relay (or PE
	  router) co-related with the delegated prefix, have no route
	  aggregation.
	</t>

	<t>
	  Due to PE router need to interpret and handle each protocol
	  message in the control plane, it can get the assigned
	  address or the delegated prefixes directly from the DHCPv6
	  message. That makes RAAN option unnecessary.
	</t>
      </section>

      <section title="draft-ietf-dhc-dhcpv6-prefix-pool-opt-03 for
		      prefix pool of PD">
        <t>
	  <xref target="I-D.ietf-dhc-dhcpv6-prefix-pool-opt"/>.
	</t>
	
        <t>
	  PE router acting as relay use OPTION_ORO in the
	  relay-forward of DHCPv6-PD message to request the
	  information about the prefix pool (and its status).  After the
	  PE got the OPTION_PREFIX_POOL in the Relay-reply message, it
	  can add the aggregation route per the status (or lease) of
	  the prefix pool. The aggregation route can dramatically
	  reduce the size of the routing table in the ISP network.
	</t>

	<t>
	  Pros: no new messages, just define a new option
	  (OPTION_PREFIX_POOL) to convey the information about prefix
	  pools.
	</t>
	<t>
	  Cons: lightweight but piggyback on the UDP-based DHCPv6
	  message.
	</t>

	<t>
	  This draft hasn't achieve Consensus yet, but may need to
	  simplify the mechanism to gain more support.
	</t>
      </section>

      <section title="draft-joshi-dhc-dhcpv6-aggr-route-opt for
		      aggregation route of PD">
	<t>
	  <xref target="I-D.joshi-dhc-dhcpv6-aggr-route-opt"/>
	</t>

	<t>
	  PE router acting as relay tries to employ new messages
	  exchange between relay and server, including new function of
	  information-request, renew and reply, reconfigure. That make
	  the communication between the relay and server to be the
	  communication between hosts.
	</t>
	<t>
	  Pros: de-coupled from the DHCPv6-PD mechanism, communication
	  between hosts could employ the reliable TCP.
	</t>
	<t>
	  Cons: introduce new functionality defined for the relay and
	  server, define new messages and option (OPTION_AGGR_ROUTE),
	  have problem of synchronization for the status of
	  aggregation route or for the leases of delegated prefixes.
	</t>
	<t>
	  This draft may be incomplete work, maybe further discussion
	  may be needed.
	</t>
      </section>

    </section>

    <section anchor="Security" title="Security Considerations">
      <t></t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t></t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>The authors would like to acknowledge Mikael Abrahamsson</t>
    </section>
  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>
    <references title="Normative References">
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119"
      ?>
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4861"
      ?>
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3633"
      ?>
     <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3315"
      ?>            
    </references>

    <references title="Informative References">
      <?rfc
	include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.lemon-dhc-topo-conf'?>
      <?rfc
	include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-dhc-dhcpv6-agentopt-delegate'?>
      <?rfc
	include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-dhc-dhcpv6-prefix-pool-opt'?>
      <?rfc
	include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.joshi-dhc-dhcpv6-aggr-route-opt'?>
      <?rfc
	include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.stenberg-pd-route-maintenance'?>                  

      <reference anchor="bf" >
	<front>
	  <title>
	    Broadband Forum, Technical Report, TR-177, "IPv6 in the
	    Context of TR-101, Issue: 1, Issue date: November 2010",
	    document freely available at the URL
	    http://www.broadband-forum.org/technical/download/TR-177.pdf
	    accessed on October 4th, 2013.
	  </title>
	  <author/>
	  <date/>
	</front>
      </reference>

      <reference anchor="3gpp-ref" >
	<front>
	  <title>
	    3GPP TS 23.402 V12.2.0 (2013-09), Technical Specification,
	    3rd Generation Partnership Project; Technical
	    Specification Group Services and System Aspects;
	    Architecture enhancements for non-3GPP accesses (Release
	    12),
	    http://www.3gpp.org/ftp/Specs/archive/23_series/23.402/23402-c20.zip
	    accessed on October 7th, 2013 
	  </title>
	  <author/>
	  <date/>
	</front>
      </reference>          
      
    </references>



    <section anchor="changelog" title="ChangeLog">
      <t>The changes are listed in reverse chronological order, most recent
      changes appearing at the top of the list.</t>

      <t>From draft-relay-route-pd-problem-00.txt to
      draft-authors-relay-route-pd-problem-00.txt: <list style="symbols">
          <t>first version.</t>
        </list></t>
    </section>

    <section title="Software">
      <t>
	Prototype implementations.
      </t>
    </section>

    <section title="draft-stenberg-pd-route-maintenance-00">
      <t></t>
    </section>

    <section title="Snooping only">
      <t>not sure.</t>
    </section>

    <section title="ICMP Redirect">
      <t>
	One possible solution to inform an entity in the network
	about a better route to a destination is to use the message
	ICMPv6 Redirect, as specified in <xref target="RFC4861"/>.
	This message is used by Routers to inform hosts about better
	routes.
      </t>
      <t>
	Some DHCPv6 Prefix Delegation deployments consider that the
	DHCPv6 Relay functionality is co-located within a Router.
	In this case, it is not possible to use the ICMP Redirect
	message.
      </t>
      <t>
	However, in other possible deployments, the DHCPv6 Relay
	functionality is co-located in a Host; in this case the use
	of ICMPv6 Redirect may be possible.  An example topology of
	this use of DHCP Relay on a Host is depicted in the
	following figure:
      </t>

      <t> 
	<figure align="center">
	  <artwork align="center">
	    <![CDATA[
                                  ________ ----------  
                                 |        |DHCPServer| 
                                ...        ----------  
                                 |     
              ----------     ---------     
             | Host     |   | Access  |     
             | DHCPRelay|   | Router  |     
              ----------     ---------     
                  |              |     
              ----+--------------+     
                  |     
              ----------     ----     
             |Requesting|   | PC |     
             | Router   |   |    |     
              ----------     ----     
                  |            |     
              ----+------------+--      
	    ]]>
	  </artwork>
	</figure>
      </t>

    </section>    
      
  </back>
</rfc>
