<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC3315 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3315.xml">
]>
<?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="std" docName="draft-hunt-dhcpv6-clarify-mrc-00" ipr="trust200811" updates="3315">

  <front>
    <title>DHCPv6 MRC Clarification</title>

    <author fullname="Evan Hunt" initials="E." surname="Hunt">
      <organization>ISC</organization>

      <address>
        <postal>
          <street>950 Charter St.</street>
          <city>Redwood City</city>
          <region>CA</region>
          <code>94063</code>
          <country>USA</country>
        </postal>
        <email>each@isc.org</email>
      </address>
    </author>

    <date month="February" year="2009" />

    <!-- Meta-data Declarations -->

    <area>General</area>
    <workgroup>Internet Engineering Task Force</workgroup>
    <keyword>dhcpv6 mrc</keyword>

    <?rfc needLines="6" ?>

    <abstract>
      <t>
        The definition of the Maximum Retransmission Count (MRC) variable
        described in RFC 3315 is clarified to resolve an ambiguity.
      </t>
    </abstract>
  </front>

  <middle>
    <section anchor="Introduction" title="Introduction">
      <t>
        Section 14 of <xref target="RFC3315">RFC 3315</xref> has an
        ambiguous definition of the Maximum Retransmission Count (MRC)
        variable.  The existing text says:
      </t>

      <t><list hangIndent="4" style="empty">
        <t>
         MRC specifies an upper bound on the number of times a client may
         retransmit a message.  Unless MRC is zero, the message exchange
         fails once the client has transmitted the message MRC times.
        </t>
      </list></t>

      <t>
        The conflicting use of the words "transmit" and "retransmit"
        has led to two different understandings of the MRC variable.  Some
        implementations use it to limit the total number of transmissions
        a client may send, including the initial one.  Others count only
        subsequent retransmissions.  This has caused problems with formal
        acceptance testing.
      </t>

      <t>
        We favor the second interpretation as a better match to the name
        of the variable.  (If MRC had been intended to include the original
        transmission in its counter, it would have been called the Maximum
        Transmission Count instead.)
      </t>
    </section>

    <section anchor="Recommendations" title="Recommendations">
      <t>
        In section 14 of <xref target="RFC3315">RFC 3315</xref>, the
        definition of MRC should be read as follows:
      </t>

      <t><list hangIndent="4" style="empty">
        <t>
          MRC specifies an upper bound on the number of times a client may
          retransmit a message after the initial transmission has taken
          place.  Unless MRC is zero, client transmissions end after
          the client has transmitted the message a total of MRC + 1 times.
        </t>
      </list></t>

      <t>
        Future revisions of RFC 3315 should include this language.
      </t>

      <t>
        Note that in this interpretation, the special meaning of MRC = 0
        (indicating no limit) makes it impossible to use MRC to limit
        the client to a single transmission and no retransmissions.  This
        inflexibility is unfortunate, but avoids a need to change the
        variable name for clarity.
      </t>

      <t>
        If a single transmission is required, MRD can be used instead,
        to limit the total time the client spends transmitting to a
        period less than the first retransmission timeout.  In this
        scenario, IRT must exceed MRD by an amount greater than the
        random factor added when calculating the first RT.  As an
        example, if MRD is set to one second and IRT to two seconds,
        the first RT will never be lower than 1.9 seconds, and so a
        second transmission will never take place.
      </t>
    </section>

    <section title="Acknowledgments" anchor="Acknowledgments">
      <t>
        The ambiguity discussed in this document was first noted by
        Hideshi Enokihara on the DHCWG mailing list.
      </t>

      <t>
        Jeremy Reed and David Hankins of ISC provided editorial feedback.
      </t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This document requests no IANA actions.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>None.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      &RFC3315;
    </references>

    <references title="Informative References">
      <reference anchor="ENOKIHARA"
                 target="http://www.ietf.org/mail-archive/web/dhcwg/current/msg06876.html">
        <front>
          <title>Petty question regarding MRC in RFC3315</title>

          <author initials="H." surname="Enokihara">
            <organization></organization>
          </author>

          <date year="2007" />
        </front>
      </reference>
    </references>
  </back>
</rfc>
