<?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 strict='yes'?>
<?rfc iprnotified='no'?>
<rfc category="info" docName="draft-templin-client-cllao-00.txt"
     ipr="trust200902" obsoletes="">
  <front>
    <title abbrev="Client CLLAO">Client-Inserted Client Link-Layer Address
    Options in DHCPv6</title>

    <author fullname="Fred L. Templin" initials="F. L." role="editor"
            surname="Templin">
      <organization>Boeing Research &amp; Technology</organization>

      <address>
        <postal>
          <street>P.O. Box 3707</street>

          <city>Seattle</city>

          <region>WA</region>

          <code>98124</code>

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

        <email>fltemplin@acm.org</email>
      </address>
    </author>

    <date day="21" month="January" year="2015"/>

    <keyword>I-D</keyword>

    <keyword>Internet-Draft</keyword>

    <abstract>
      <t>RFC6939 presents a method for DHCPv6 relay agents to insert a Client
      Link Layer Address Option (CLLAO) in a DHCPv6 Relay-Forward message. In
      some cases, however, the DHCPv6 client may need to insert a CLLAO in its
      message on its own behalf even though it is on the same link as the
      DHCPv6 server. This document discusses client-inserted CLLAOs.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="intro" title="Introduction">
      <t><xref target="RFC6939"/> specifies a method for DHCPv6 relays<xref
      target="RFC3315"/> to insert a Client Link-Layer Address Option (CLLAO)
      in Relay-Forward messages. This provides a means for a first-hop relay
      to inform the DHCPv6 server of the link-layer address of the DHCPv6
      client on the client&lt;-&gt;relay link. However, on some links it may
      be necessary for the server to receive a CLLAO even when it is on the
      same link as the client. In that case, the client itself must insert the
      CLLAO.</t>

      <t>Asymmetric Extended Route Optimization (AERO) <xref
      target="I-D.templin-aerolink"/> is an example of a link where it may be
      difficult or impossible for the DHCPv6 server to determine the DHCPv6
      client's link-layer address through normal socket API operations. In
      that case, if the client inserts a CLLAO option the server can discover
      the client's link-layer address by examining the option fields of the
      DHCPv6 message instead of the message headers. The following section
      specifies the protocol for client-inserted CLLAOs.</t>
    </section>

    <section anchor="minencaps" title="Client-Inserted CLLAOs">
      <t>When a DHCPv6 client is on the same link as the server, and the
      server requires a means for discovering the client's link-layer address,
      the client inserts a CLLAO option <xref target="RFC6939"/> in its DHCPv6
      messages and writes the link-layer address of the sending interface in
      the "link-layer address" field.</t>

      <t>When a DHCPv6 server is on the same link as the client, and the
      client includes a CLLAO option in its DHCPv6 messages, the server
      processes the CLLAO option locally as necessary and returns the CLLAO
      option in its DHCPv6 replies.</t>

      <t>When a DHCPv6 relay on the same link as a client forwards the
      client's DHCPv6 messages, and the server requires a means for
      discovering the client's link-layer address, the relay follows the
      specifications in <xref target="RFC6939"/>.</t>

      <t>A DHCPv6 client MUST NOT include a CLLAO option if it is not on the
      same link as the server. </t>
    </section>

    <section anchor="iana" title="IANA Considerations">
      <t>This document introduces no IANA considerations.</t>
    </section>

    <section anchor="secure" title="Security Considerations">
      <t>When DHCPv6 authentication <xref target="RFC3315"/> and/or DHCPv6
      Security <xref target="I-D.ietf-dhc-sedhcpv6"/> are used, the DHCPv6
      client/server MUST NOT include the CLLAO option in security signature
      calculations. This means that the link-layer address in the CLLAO could
      be rewritten by a link-layer switching element on the path from the
      client to the server and not detected by the security mechanism.
      However, such a condition would only be possible on unsecured links
      where link-layer switching elements present a man-in-the-middle attack
      threat.</t>
    </section>

    <section anchor="ack" title="Acknowledgements">
      <t/>
    </section>
  </middle>

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

      <?rfc include="reference.RFC.6939"?>

      <?rfc ?>
    </references>

    <references title="Informative References">
      <?rfc include="reference.I-D.templin-aerolink"?>

      <?rfc include="reference.I-D.ietf-dhc-sedhcpv6"?>
    </references>
  </back>
</rfc>
