idnits 2.17.1 draft-george-dhc-request-retransmission-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (June 25, 2012) is 4323 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2434' is defined on line 127, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DHC R. George 3 Internet-Draft Huawei Technologies 4 Intended status: BCP June 25, 2012 5 Expires: December 27, 2012 7 DHCPv6 Request Retransmission 8 draft-george-dhc-request-retransmission-00 10 Abstract 12 The DHCP client sends SOLICIT message to get IP address from the 13 server. If the address pool is empty, all address in the pool have 14 allocated to the clients, the server will return error code. 15 NoAddrsAvail (server has no address available to assign in the IA). 16 Client retransmit the SOLICIT message (section 14 RFC 3315) and may 17 get the same response. 19 This draft defines a new suboption for the Dynamic Host Configuration 20 Protocol (DHCP) to identify the retry time to sent next SOLICIT 21 message. Hence, avoid unnecessary retransmit of SOLICIT messages. 22 The suboption carries a value that identifies when an address will be 23 available in the address pool. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on December 27, 2012. 42 Copyright Notice 44 Copyright (c) 2012 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology used in this document . . . . . . . . . . . . . . . 3 61 3. Option Format . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 64 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 6.1. Normative References . . . . . . . . . . . . . . . . . . . 4 66 6.2. Informative References . . . . . . . . . . . . . . . . . . 4 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 1. Introduction 71 To avoid the retry after getting a NoAddrAvail status message from 72 the server, add a new DHCP option, retry-after. The server may 73 return retry-after message with a value that is the time when an IP 74 address is available in the server address pool.(it can be calculated 75 as MIN(t3-current time) for all the client got address from the 76 server. Client may avoid retry till retry-after value, if 77 NoAddrsAvail received.. 79 2. Terminology used in this document 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 83 document are to be interpreted as described in [RFC2119]. 85 3. Option Format 87 The format of the Retry after suboption. 89 0 1 2 3 90 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 91 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 92 | OPTION_RETRY_AFTER_TIME | Option-len | 93 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 94 | RETRY-TIME | 95 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 97 option-code OPTION_RETRY_AFTER_TIME (TBD). 99 option-len 2. 101 elapsed-time The amount of time the client has to wait to 102 get an address from this server. This time is 103 expressed in hundredths of a second 104 (10^-2 seconds). 106 4. Security Considerations 108 The security considerations of [RFC3315] and [RFC2131] are relevant 109 to this document. 111 5. IANA Considerations 113 TBD 115 6. References 117 6.1. Normative References 119 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 120 Requirement Levels", BCP 14, RFC 2119, March 1997. 122 6.2. Informative References 124 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 125 RFC 2131, March 1997. 127 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 128 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 129 October 1998. 131 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 132 and M. Carney, "Dynamic Host Configuration Protocol for 133 IPv6 (DHCPv6)", RFC 3315, July 2003. 135 Author's Address 137 Robins George 138 Huawei Technologies 139 Solitaire 140 Bangalore, Karnataka 560071 141 India 143 Phone: +918041117676 144 Email: robinsgv@gmail.com