draft-ietf-dhc-dhcpv6-tunnels.xml

<?xml version="1.0" encoding="US-ASCII"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="no" ?>
<?rfc tocompact="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="yes" ?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc comments="yes" ?>
<?rfc inline="yes" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc3315 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3315.xml">
<!ENTITY rfc3736 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3736.xml">
<!ENTITY rfc5969 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5969.xml">
<!ENTITY rfc5625 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5625.xml">
<!ENTITY I-D.ietf-mboned-auto-multicast SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mboned-auto-multicast.xml">
<!ENTITY I-D.ietf-v6ops-ipv6-cpe-router SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-v6ops-ipv6-cpe-router.xml">
]>

<rfc category="info" docName="draft-ietf-dhc-dhcpv6-tunnels-00.txt"
     ipr="trust200902">
  <front>
    <title abbrev="">DHCPv6 through Tunnels</title>

    <author fullname="Xiaohu Xu" initials="X" surname="Xu">
      <organization abbrev="">Huawei Technologies</organization>

      <address>
        <postal>
          <street>No.3 Xinxi Rd., Shang-Di Information Industry Base</street>
          <city>Beijing</city>
          <region>Hai-Dian District</region>
          <code>100085</code>
          <country>P.R. China</country>
        </postal>
        <phone>+86 10 82882573</phone>
        <email>xuxh@huawei.com</email>
      </address>
    </author>

    <author fullname="Dayong Guo" initials="D" surname="Guo">
      <organization abbrev="">Huawei Technologies</organization>
      <address>
        <postal>
          <street>No.3 Xinxi Rd., Shang-Di Information Industry Base</street>
          <city>Beijing</city>
          <region>Hai-Dian District</region>
          <code>100085</code>
          <country>P.R. China</country>
        </postal>
	<phone>+86-10-82882578</phone>
        <email>guoseu@huawei.com</email>
      </address>
    </author>

    <author fullname="Ole Troan" initials="O" surname="Troan">
      <organization abbrev="">Cisco</organization>

      <address>
        <postal>
          <street></street>
          <city>Oslo</city>
          <region></region>
          <code></code>
          <country>Norway</country>
        </postal>
        <email>ot@cisco.com</email>
      </address>
    </author>

    <author fullname="Marc Blanchet" initials="M." surname="Blanchet">
      <organization>Viagenie</organization>

      <address>
        <postal>
          <street>2600 boul. Laurier, suite 625</street>
          <city>Quebec</city>
          <region>QC</region>
          <code>GV1 4W1</code>
          <country>Canada</country>
        </postal>
        <email>Marc.Blanchet@viagenie.ca</email>
      </address>
    </author>
    
    <date year="2011" />

    <area>Internet</area>

    <workgroup>Network Working Group</workgroup>

    <!--  SECTION 0:  Abstract                      -->

    <abstract>
      <t>The host configuration protocol DHCPv6 <xref
      target="RFC3315"></xref> relies on link-local addressing and
      multicast to function. However, most of the existing 6over4
      tunnel link types (e.g., 6rd <xref target="RFC5969"></xref> )
      don't support IPv6 link-local addresses and even IPv6 multicast
      addresses. Taking 6rd as an example, this document specifies how
      DHCPv6 can be used across such tunnel links .</t>
    </abstract>
  </front>

  <middle>
    <!--  SECTION 1:  Introduction                  -->

    <section title="Introduction">
      <t>As specified in the DHCPv6 specification <xref
      target="RFC3315"></xref>, "...The client MUST use a link-local address
      assigned to the interface for which it is requesting configuration
      information as the source address in the header of the IP datagram." and
      "...Unless otherwise specified in this document, or in a document that
      describes how IPv6 is carried over a specific type of link (for link
      types that do not support multicast), a client sends DHCP messages to
      the All_DHCP_Relay_Agents_and_Servers". </t>

      <t>However, link-local addresses and even multicast addresses are not
      supported over most of the existing 6over4 tunnel link types. 6rd as
      described in <xref target="RFC5969"></xref> is a real example.</t>

      <t>Taking 6rd as an example, this document describes how DHCPv6 service
      can be provided across such tunnel links .</t>
    </section>

    <!--  SECTION 2: REQUIREMENTS LANGUAGE                                         -->

    <section anchor="sec:conventions" title="Conventions">
      <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 RFC 2119 <xref
      target="RFC2119"></xref>.</t>
    </section>

    <!-- conventions -->

    <!--  SECTION 3: DESCRIPTION                                                   -->

    <section title="DHCPv6 over 6rd links">
      <t>There are two problems to be solved with regards to providing DHCPv6
      service over a 6rd link:<list style="symbols">
          <t>A DHCPv6 client uses an IPv6 link-local address as the source
          address when requesting configuration information <xref
          target="RFC3315"></xref>. Link-local addressing is not supported on
          an 6rd link.</t>

          <t>A DHCPv6 client sends a request to the
          All_DHCP_Relay_Agent_and_Servers multicast address. 6rd as specified
          in <xref target="RFC5969"></xref> does not support IPv6
          multicast.</t>
        </list></t>

      <t>The first problem can be solved by changing the DHCPv6 protocol to
      allow for a global address to be used as the source address in requests.
      Another solution that does not require protocol changes, is to send
      DHCPv6 requests via a local DHCPv6 relay on the 6rd CE.</t>

      <t>The 6rd CE MUST support a local DHCPv6 client and relay. The DHCPv6
      client running on the 6rd CE's virtual tunnel interface MUST send DHCPv6
      messages through a local DHCPv6 relay that encapsulates the client
      message and forwards it to a DHCPv6 server or relay using one of the 6rd
      CE's global unicast addresses as the source address.</t>

      <t>The 6rd CE DHCPv6 relay agent SHOULD use the 6rd BR IPv6 anycast
      address as the destination address, section 20 of <xref
      target="RFC3315"></xref>. If the 6rd link supports multicast <xref
      target="I-D.ietf-mboned-auto-multicast"></xref> the 6rd CE DHCPv6 relay
      MAY use the All_DHCP_Servers <xref target="RFC3315"></xref> as the
      destination address of Relay-forward messages.</t>

      <t>The 6rd BRs in the 6rd domain must be configured as DHCPv6 relays or
      servers on their 6rd virtual interfaces.</t>

      <t>The 6rd CE SHOULD behave according to <xref
      target="I-D.ietf-v6ops-ipv6-cpe-router"></xref>. In particular it
      operates a DHCPv6 client on the WAN side (6rd virtual) interface and as
      a DHCPv6 server on the LAN-side interface(s).</t>
    </section>

    <!--  SECTION 4:  IANA Considerations           -->

    <section title="IANA Considerations">
      <t>This specification does not require any IANA actions.</t>
    </section>

    <!--  SECTION 5:  Security Considerations      	-->

    <section title="Security Considerations">
      <t>There are no new security considerations pertaining to this
      document.</t>
    </section>

    <!--  SECTION 6:  Acknowledgements     			-->

    <section title="Acknowledgements">
      <t>The authors would like to thank Ted Lemon, Fred Templin and other
      people for their valuable comments.</t>
    </section>
  </middle>

  <back>
    <!--  SECTION 8.1:  Normative References		-->

    <references title="Normative References">
      &rfc2119;

      &rfc3315;

      &rfc3736;

      &rfc5969;
    </references>

    <references title="Informative References">
      &rfc5625;

      &I-D.ietf-mboned-auto-multicast;

      &I-D.ietf-v6ops-ipv6-cpe-router;
    </references>

    <!--  SECTION 8.2:  Informative References		-->
  </back>
</rfc>