Internet DRAFT - draft-hunt-dhcpv6-clarify-mrc
draft-hunt-dhcpv6-clarify-mrc
Internet Engineering Task Force E. Hunt
Internet-Draft ISC
Updates: 3315 (if approved) February 13, 2009
Intended status: Standards Track
Expires: August 17, 2009
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 17, 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
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
Hunt Expires August 17, 2009 [Page 1]
Internet-Draft DHCPv6 MRC Clarification February 2009
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Recommendations . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 4
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 4
6.1. Normative References . . . . . . . . . . . . . . . . . . . 4
6.2. Informative References . . . . . . . . . . . . . . . . . . 4
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 4
Hunt Expires August 17, 2009 [Page 2]
Internet-Draft DHCPv6 MRC Clarification February 2009
1. Introduction
Section 14 of RFC 3315 [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 [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.
Hunt Expires August 17, 2009 [Page 3]
Internet-Draft DHCPv6 MRC Clarification February 2009
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
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
6.2. Informative References
[ENOKIHARA]
Enokihara, H., "Petty question regarding MRC in RFC3315",
2007, <http://www.ietf.org/mail-archive/web/dhcwg/current/
msg06876.html>.
Author's Address
Evan Hunt
ISC
950 Charter St.
Redwood City, CA 94063
USA
Email: each@isc.org
Hunt Expires August 17, 2009 [Page 4]
