idnits 2.17.1 draft-ietf-ipv6-ipaddressassign-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 180 has weird spacing: '...of bits pick ...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 18, 2002) is 7830 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '2' is defined on line 326, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1219 (ref. '1') Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet M. Blanchet 3 Internet-Draft Viagenie inc. 4 Expires: May 19, 2003 November 18, 2002 6 A Flexible Method for Managing the Assignment of Bits of an IPv6 7 Address Block 8 draft-ietf-ipv6-ipaddressassign-05 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at http:// 26 www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on May 19, 2003. 33 Copyright Notice 35 Copyright (C) The Internet Society (2002). All Rights Reserved. 37 Abstract 39 This document proposes a method to manage the assignment of bits of 40 an IPv6 address block or range. When an organisation needs to make 41 an address plan for its subnets or when an ISP needs to make an 42 address plan for its customers, this method enables the organisation 43 to postpone the final decision on the number of bits to partition in 44 the address space they have. It does it by keeping the bits around 45 the borders of the partition to be free as long as possible. This 46 scheme is applicable to any bits addressing scheme using bits with 47 partitions in the space, but its first intended use is for IPv6. It 48 is a generalization of RFC1219 [1] and can be used for IPv6 49 assignments. 51 Table of Contents 53 1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Description of the Algorithm . . . . . . . . . . . . . . . . . 4 56 3.1 Leftmost . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3.2 Rightmost . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3.3 Centermost . . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 4. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 5. Implementation . . . . . . . . . . . . . . . . . . . . . . . . 6 61 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 62 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 63 References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 8 65 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 9 67 1. Rationale 69 IPv6 addresses have a flexible structure for address assignments. 70 This enables registries, internet service providers, network 71 designers and others to assign address ranges to organizations and 72 networks based on different criteria, like size of networks, 73 estimated growth rate, etc. Often, the initial assignment doesn't 74 scale well because a small network becomes larger than expected, 75 needing more addresses. But then, the assignment authority cannot 76 allocate contiguous addresses because they were already assigned to 77 another network. 79 RFC1219 [1] describes an allocation scheme for IPv4 where address 80 space is kept unallocated between the leftmost bits of the subnet 81 part and the rightmost bits of the host part of the address. This 82 enables the network designer to change the subnet mask without 83 renumbering, for the central bits not allocated. 85 This work generalizes the previous scheme by extending the algorithm 86 so it can be applied on any part of an IP address, which are assigned 87 by any assignment authority level (registries, ISPs of any level, 88 organizations, ...). It can be used for both IPv4 and IPv6. 90 This document does not provide any recommendation to registries on 91 how to assign address ranges to their customers. 93 2. Scheme 95 We define parts of the IP address as p1, p2 , p3, ... pN in order, 96 so that an IP address is composed of these parts contiguously. 97 Boundaries between each part are based on the prefix assigned by the 98 next level authority. Part p1 is the leftmost part probably assigned 99 to a registry, Part p2 can be allocated to a large internet service 100 provider or to a national registry. Part p3 can be allocated to a 101 large customer or a smaller provider, etc. Each part can be of 102 different length. We define l(pX) the length of part X. 104 +------+------+------+------+------+------+ 105 | p1 | p2 | p3 | p4 | ... | pN | 106 +------+------+------+------+------+------+ 107 <------- ipv6 or ipv4 address ------------> 109 The algorithm for allocating addresses is as follows : a) for the 110 leftmost part (p1), assign addresses using the leftmost bits first b) 111 for the rightmost part (pN), assign addresses using the rightmost 112 bits first c) for all other parts (center parts), predefine an 113 arbitrary boundary (prefix) and then assign addresses using the 114 center bits first of the part being assigned. 116 This algorithm grows assigned bits in such way that it keeps 117 unassigned bits near the boundary of the parts. This means that the 118 prefix between any two parts can be changed forward or backward, 119 later on, up to the assigned bits. 121 3. Description of the Algorithm 123 This section describes the assignment of leftmost bits, rightmost 124 bits and centermost bits. 126 3.1 Leftmost 128 p1 will be assigned in order as follows : 130 Order Assignment 131 1 00000000 132 2 10000000 133 3 01000000 134 4 11000000 135 5 00100000 136 6 10100000 137 7 01100000 138 8 11100000 139 9 00010000 140 ... 142 This is actually a mirror of binary counting. 144 3.2 Rightmost 146 pN (the last part) will be assigned in order as follows : 148 Order Assignment 149 1 00000000 150 2 00000001 151 3 00000010 152 4 00000011 153 5 00000100 154 6 00000101 155 7 00000110 156 8 00000111 157 9 00001000 158 ... 160 3.3 Centermost 162 pX (where 1 < X < N) will be assigned in order as follows : (for 163 example, with a 8 bit predefined length l(pX)=8)) 165 Order Assignment 166 1 00000000 167 2 00001000 168 3 00010000 169 4 00011000 170 5 00000100 171 6 00001100 172 7 00010100 173 8 00011100 174 9 00100000 175 ... 177 The bits are assigned using the following algorithm: 179 1. The first round is to select only the middle bit (and if there is 180 an even number of bits pick the bit following the center) 182 2. Create all combinations using the selected bits that haven't yet 183 been created. 185 3. Start a new round by adding one more bit to the set. In even 186 rounds add the preceding bit to the set. In odd rounds add the 187 subsequent bit to the set. 189 4. Repeat 2 and 3 until there are no more bits to consider. 191 4. Example 193 As an example, a provider P1 has been assigned the 3ffe:0b00/24 194 prefix and wants to assign prefixes to its connected networks. It 195 anticipates in the foreseeable future a maximum of 256 customers 196 consuming 8 bits. One of these customers, named C2, anticipates a 197 maximum of 1024 customer's assignments under it, consuming 10 other 198 bits. 200 The assignment will be as follows, not showing the first 24 leftmost 201 bits (3ffe:0b00/24: 00111111 11111110 00001011): 203 P1 assigns address space to its customers using leftmost bits: 205 10000000 : assigned to C1 206 01000000 : assigned to C2 207 11000000 : assigned to C3 208 00100000 : assigned to C4 209 ... 211 C2 assigns address space to its customers (C2C1, C2C2, ...) using 212 centermost bits: 214 0000010000 : assigned to C2C1 215 0000100000 : assigned to C2C2 216 0000110000 : assigned to C2C3 217 ... 219 Customers of C2 can use centermost bits for maximum flexibility and 220 then the last aggregators (should be a network in a site) will be 221 assigned using rightmost bits. 223 Putting all bits together for C2C3: 224 P1 |C2 |C2C3 225 00111111 11111110 00001011 01000000 00001100 00 226 <-------> <------> 227 growing bits 229 By using this method, P1 will be able to expand the number of 230 customers and the customers will be able to modify their first 231 assumptions about the size of their own customers, until the 232 "reserved" bits are assigned. 234 5. Implementation 236 The following Perl code was written by Jocelyn Picard 237 (Jocelyn.Picard@viagenie.qc.ca) and implements this draft. This code 238 is free and without any warranty. 240 #!/sur/bin/perl -w 241 use strict; 243 #========================================================= 244 # allocation(Last Prefix,Number of bits,Method) 245 # 246 # Last Prefix = last prefix allocated, ex: 3ffe:b00::/48 247 # Number of bits = range we want to allocate 248 # Method = method to use: l,c or r (left,center,right) 249 # 250 # Returns next prefix using selected method 251 # 252 # Note: no validation is made 253 # 254 #------------------------------------------------------- 255 sub allocation { 256 my ($ip,$pl)=split('/',shift); 257 my ($nbits,$method) = @_ ; 258 my ($w,@Abits,$abits); 260 my $i = $ip =~ s/:/:/g; 261 my $repl= ':0' x (9 - $i); 262 $ip =~ s/::/$repl/; 263 $ip =~ s/^:/0:/; 265 foreach $i (split(':',$ip)) { 266 push @Abits, split('',unpack("B16", pack("n", hex($i)))); 267 } 268 my $sp = int($nbits/2); 270 for($i=0;$i<$nbits;$i++) { 271 if ($method eq "c") { 272 $w = ($i % 2) ? $sp - ($i+1)/2: $sp + $i/2; 273 } 274 elsif ($method eq "r") { 275 $w = $nbits -1 - $i; 276 } 277 else { 278 $w = $i ; 279 } 280 $w += $pl - $nbits; 282 if ($Abits[$w] == 0) { 283 $Abits[$w] = 1; 284 last; 285 } 286 else { 287 return 0 if ($i == $nbits-1); 288 $Abits[$w] = 0; 289 } 290 } 291 $abits = join("",@Abits); 292 $ip = ""; 293 for($i=0;$i<8;$i++) { 294 $ip .= sprintf("%lx", 295 unpack("n", pack("B16", substr($abits, $i * 16,16)))) . ":"; 296 } 297 chop $ip; 298 $ip =~ s/(:0){2,}$/::/; 299 return($ip . "/$pl"); 300 } 301 #=============================================================== 302 # 303 #Usage example: allocation of 100 /48 using "centermost" method 304 # 305 my $Prefix = '3ffe:b00::/48'; 306 for(my $i=0;$i<100;$i++) { 307 print $Prefix = allocation($Prefix,16,'c'),"\n"; 308 } 310 6. Security Considerations 312 Address assignment doesn't seem to have any specific security 313 consideration. 315 7. Acknowledgements 317 Thanks to Steve Deering, Bob Hinden, Thomas Narten, Erik Nordmark, 318 Florent Parent and Jocelyn Picard for their very useful comments on 319 this work. 321 References 323 [1] Tsuchiya, P., "On the assignment of subnet numbers", RFC 1219, 324 April 1991. 326 [2] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 327 9, RFC 2026, October 1996. 329 Author's Address 331 Marc Blanchet 332 Viagenie inc. 333 2875 boul. Laurier, bureau 300 334 Sainte-Foy, QC G1V 2M2 335 Canada 337 Phone: +1 418 656 9254 338 EMail: Marc.Blanchet@viagenie.qc.ca 339 URI: http://www.viagenie.qc.ca/ 341 Full Copyright Statement 343 Copyright (C) The Internet Society (2002). All Rights Reserved. 345 This document and translations of it may be copied and furnished to 346 others, and derivative works that comment on or otherwise explain it 347 or assist in its implementation may be prepared, copied, published 348 and distributed, in whole or in part, without restriction of any 349 kind, provided that the above copyright notice and this paragraph are 350 included on all such copies and derivative works. However, this 351 document itself may not be modified in any way, such as by removing 352 the copyright notice or references to the Internet Society or other 353 Internet organizations, except as needed for the purpose of 354 developing Internet standards in which case the procedures for 355 copyrights defined in the Internet Standards process must be 356 followed, or as required to translate it into languages other than 357 English. 359 The limited permissions granted above are perpetual and will not be 360 revoked by the Internet Society or its successors or assigns. 362 This document and the information contained herein is provided on an 363 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 364 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 365 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 366 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 367 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 369 Acknowledgement 371 Funding for the RFC Editor function is currently provided by the 372 Internet Society.