DHCPv6 MRC Clarification
draft-hunt-dhcpv6-clarify-mrc-00

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on August 18, 2009.

Copyright Notice

Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

Abstract

The definition of the Maximum Retransmission Count (MRC) variable described in RFC 3315 is clarified to resolve an ambiguity.

Table of Contents

1.  Introduction
2.  Recommendations
3.  Acknowledgments
4.  IANA Considerations
5.  Security Considerations
6.  References
    6.1.  Normative References
    6.2.  Informative References
§  Author's Address

1.  Introduction

Section 14 of RFC 3315 (Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, “Dynamic Host Configuration Protocol for IPv6 (DHCPv6),” July 2003.) [RFC3315] has an ambiguous definition of the Maximum Retransmission Count (MRC) variable. The existing text says:

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.

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.

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

2.  Recommendations

In section 14 of RFC 3315 (Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, “Dynamic Host Configuration Protocol for IPv6 (DHCPv6),” July 2003.) [RFC3315], the definition of MRC should be read as follows:

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.

Future revisions of RFC 3315 should include this language.

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.

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.

3.  Acknowledgments

The ambiguity discussed in this document was first noted by Hideshi Enokihara on the DHCWG mailing list.

Jeremy Reed and David Hankins of ISC provided editorial feedback.

4.  IANA Considerations

This document requests no IANA actions.

5.  Security Considerations

None.

6.  References

6.1. Normative References

6.2. Informative References

Author's Address