idnits 2.17.1 draft-ahn-autoconf-addresspool-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(i) Publication Limitation clause. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 6 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. 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 (July 3, 2010) is 5038 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'RFC2119' on line 76 -- Possible downref: Normative reference to a draft: ref. '1' ** Obsolete normative reference: RFC 3315 (ref. '2') (Obsoleted by RFC 8415) Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 AUTOCONF Working Group Sanghyun Ahn 2 Internet Draft University of Seoul 3 Expires: January 4, 2011 Yujin Lim 4 University of Suwon 5 July 3, 2010 7 MANET Address Configurtion using Address Pool 8 draft-ahn-autoconf-addresspool-01.txt 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. This document may not be modified, 14 and derivative works of it may not be created, except to format it 15 for publication as an RFC or to translate it into languages other 16 than English. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on January 4, 2011. 36 Copyright Notice 38 Copyright (c) 2010 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents (http://trustee.ietf.org/ 43 license-info) in effect on the date of publication of this document. 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. 47 Abstract 49 This document describes an address configuration mechanism based on 50 the concept of address pool allocation in the connected MANET. 51 The Internet gateway acts as a DHCP (Dynamic Host Configuration 52 Protocol) server and assigns not a single address but a part of its 53 address pool to an address requesting node and, then, the node can 54 assign a part of its own address pool to its neighbor nodes. 55 By doing this, the address allocation procedure can be expedited. 57 Table of Contents 59 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 60 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 4. Address Pool based MANET Address Configuration . . . . . . . . 3 63 5. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 4 64 5.1 Address Pool Release Request (APRR) message . . . . . . . 4 65 5.2 Address Pool Release Reply (APRP) message . . . . . . . . 4 66 5.3 DHCP Options . . . . . . . . . . . . . . . . . . . . . . 5 67 6. Other Considerations . . . . . . . . . . . . . . . . . . . . . 5 68 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 71 1. Requirements notation 73 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 74 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 75 document are to be interpreted as described in [RFC2119]. 77 2. Introduction 79 The MANET can be classified into the standalone MANET and the 80 connected MANET [1]. The conntected MANET allows a MANET node to 81 communicate with global Internet nodes via the Internet gateway 82 (IGW). In order for a MANET node to communicate with a node in the 83 external global Internet, the MANET node has to obtain a globally 84 unique IP address. In the wireless multi-hop communication 85 environment, the mechanism using the IGW as the centralized DHCP 86 (Dynamic Host Configuration Protocol) [2] server is not desirable 87 since it may incur long address allocation delay. 89 In this draft, we describe an address configuration mechanism that 90 allows stable and fast global IP address allocation based on the DHCP 91 mechanism in the connected MANET. In the proposed scheme, the IGW 92 acts as a DHCP server and allocates a part of its address pool to 93 an address requesting node. Now, the node with the allocated address 94 pool can act a DHCP server and allocate a part of its address pool 95 to the other address requesting nodes. 97 3. Terminology 99 Address Pool A range of addresses starting from LOW to HIGH. 101 4. Address Pool based MANET Address Configuration 103 The IGW periodically broadcasts Router Advertisement (RA) messages to 104 the entire MANET and the MANET node receiving the RA message can 105 request for addresses to the IGW by unicasting a DHCP_Request [2] 106 message. Any intermediate node receiving the DHCP_Request message 107 intercepts the message and allocates a part of its address pool in 108 lieu of the IGW if its address pool is big enough to allocate by 109 unicasting a DHCP_Reply message to the address requesting node. 110 Otherwise, it forwards the DHCP_Request message to the IGW. Once the 111 IGW receives the DHCP_Request message, the IGW allocates a part of 112 its address pool to the addres requesting node by sending a 113 DHCP_Reply message. 115 The node with the allocated address pool assigns one address to its 116 interface and keeps the rest of its address pool for later 117 allocation to other MANET nodes requesting addresses. 119 In order to avoid the renewal of the allocated address pool, the 120 valid-lifetime field in the DHCP_Reply message is set to 121 '0xffffffff' (that is, infinite use of the address pool). If the size 122 of the address pool of the IGW reaches below a pre-specified 123 threshold, the IGW broadcasts an Address Pool Release Request (APRR) 124 message to the entire MANET. The MANET node receiving the APRR 125 message sends an Address Pool Release Reply (APRP) message to let 126 the IGW know those addresses already being used or assigned by the 127 APRP message sent node. 129 5. Message Format 131 5.1 Address Pool Release Request (APRR) message 133 This message is broadcast by the IGW to the entire MANET in order to 134 request for the list of addresses used by MANET nodes. 136 0 1 2 3 137 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 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 OPTION_ADDPOOL_RELEASE_REQUEST(24)| option-len | 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 | APRR-options | 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 5.2 Address Pool Release Reply (APRP) message 146 This message is unicast by a MANET node to the IGW in order to give 147 the list of addresses used by the MANET node. 149 0 1 2 3 150 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 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 OPTION_ADDPOOL_RELEASE_REPLY(24)| option-len | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | used address | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | APRP-options | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 5.3 DHCP options 161 The OPTION_ADDRSS_POOL_REQUEST option is defined to allow a MANET 162 node to request for an address pool to the DHCP server. This option 163 is included in the DHCP_Request message [2] as shown in the 164 following figure. 166 0 1 2 3 167 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 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | OPTION_ORD(6) | option-len | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 |OPTION_ADDRESS_POOL_REQUEST(21)| requested-option-code-2 | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | ... | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 The OPTION_IAADDPOOL option is defined to allow the DHCP server to 177 to allocate an address pool to the address pool request MANET node. 178 This option is included in the DHCP_Reply message [2] as shown in 179 the following figure. 181 0 1 2 3 182 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 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | OPTION_IAADDPOOL(22) | option-len | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | lowest IPv6 address(LOW) | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | highest IPv6 address(HIGH) | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | preferred-lifetime | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | valid-lifetime | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | IA_ADDPOOL-options | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 6. Other Considerations 199 TBD. 201 References 203 [1] E. Baccelli, "Address Autoconfiguration for MANET: Terminology 204 and Problem Statement," draft-ietf-autoconf-statement-04.txt, 205 Feb. 2008. 206 [2] R. Droms, J. Bound, B. Volz, T. Lemon, C. Perkins and M. Carnery, 207 "Dynamic Host Configuration Protocol for IPv6(DHCPv6)," RFC 3315, 208 July 2003. 210 Authors' Addresses 212 Sanghyun Ahn 213 University of Seoul 214 90, Cheonnong-dong, Tongdaemun-gu 215 Seoul 130-743 216 Korea 217 Email: ahn@uos.ac.kr 219 Yujin Lim 220 University of Suwon 221 San 2-2, Wau-ri, Bongdam-eup 222 Hwaseong-si, Gyeonggi-do, 445-743 223 Korea 224 Email: yujin@suwon.ac.kr