INTERNET-DRAFT Marc Blanchet 2 July 1998 Viagenie inc. Expires 2 January 1999 A flexible allocation scheme for IP addresses (IPv4 and IPv6) Status of this Memo This document is an Internet-Draft. 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." To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu Abstract This draft presents an IP address allocation scheme that enables the IP allocator (the organisation that allocates addresses) to postpone the final decision of prefix length by keeping space between allocated bits of the different parts of the IP address. This enables the allocator to change the different part lengths of the prefix (TLA, subTLA, SLA, ...) even after allocated spaces. This scheme is applicable to both IPv4 and IPv6 but is envisionned mainly for IPv6 where the address space is larger and more flexible. 1. Context IPv6 addresses have a more flexible structure for address allocation where no pre-defined prefixes (called subnetmasks in IPv4) are used (except a few special cases). It enables the registries, the service provider, the network designer and others to allocate addresses based on different criterias, like size of networks, estimated growth rate, etc. It happens often that the initial design of the allocation doesn’t scale well because a small network becomes larger than expected, needing more addresses. But then, the allocator cannot allocate contiguous addresses because they were already assigned to another network. Non-contiguous addresses breaks the address aggregation for routing. RFC1219 [IPv4Assign] describes an allocation scheme for IPv4 where address space is kept unallocated between the leftmost bits of the subnet part and the rightmost bits of the host part of the address. This enables the network designer to change the subnetmask without renumbering, for the central bits that were not allocated. This work generalize the previous scheme by an algorithm to allocate IP addresses for all the parts of an IPv6 address allocated by all levels of the allocators (TLA, registries, ISPs, organisations, ...). 2. Scheme We define parts of the IP address as p1, p2 , p3, ... pN in order, so that an IP address is composed of all its parts contiguous. Boundaries between each part is based on the prefix allocated by the next level allocator. Part p1 is the leftmost part probably assigned to a TLA, Part p2 can be allocated by the TLA to a large provider or a national registry. Part p3 can be allocated to a large customer or a smaller provider, etc. Each part can be of different length. We define l(pX) the length of part X. +------+------+------+------+------+------+ | p1 | p2 | p3 | p4 | ... | pN | +------+------+------+------+------+------+ <------- ipv6 or ipv4 address ------------> The algorithm for allocating addresses is as follows : a) for the leftmost part (p1), allocate addresses using the leftmost bits first b) for the rightmost part (pN), allocate addresses using the rightmost bits first c) for all other parts (center parts), predefine an arbitrary boundary (prefix) and then allocate addresses using the center bits first of the part being allocated. This algorithm grow allocated bits in such way that it keeps unallocated bits near the boundary of the parts. This means that the prefix between any two parts can be changed forward or backward, later on, up to the allocated bits. 3. Allocation p1 will be allocated as follows : Order Assignment 1 10000000 2 01000000 3 11000000 4 00100000 5 10100000 6 01100000 7 11100000 8 00010000 9 ... pN (the last part) will be allocated as follows : Order Assignment 1 00000001 2 00000010 3 00000011 4 00000100 5 00000101 6 00000110 7 00000111 8 00001000 9 ... pX (where 1 < X < N) will be allocated as follows : (for example, with a 8 bit predefined length l(pX)=8)) Order Assignment 1 00001000 2 00010000 3 00011000 4 00000100 5 00001100 6 00010100 7 00011100 8 00100000 9 ... 4. Acknowledgements 5. Security Considerations Address allocation doesn’t seem to have any specific security consideration. 6. References [IPv4Assign] RFC1219 On the assignment of subnet numbers. P.F. Tsuchiya. Apr-01-1991. (Format: TXT=30609 bytes) (Status: INFORMATIONAL) [IPv6AddrArch] IP Version 6 Addressing Architecture, R. Hinden, S. Deering, Jan-1998, draft-ietf-ipngwg-addr-arch-v2-06.txt, Work in progress. 7. Author’s address Marc Blanchet Viagenie inc. 3107 des hôtels Ste-Foy, Québec, Canada G1W 4W5 Email : Marc.Blanchet@viagenie.qc.ca Tel. : 418-656-9254 Fax : 418-656-0183 ----------------------------------------------------------- Marc Blanchet | Marc.Blanchet@viagenie.qc.ca Viagénie inc. | http://www.viagenie.qc.ca 3107 des hôtels | tél.: 418-656-9254 Ste-Foy, Québec | fax.: 418-656-0183 Canada, G1W 4W5 | radio: VA2-JAZ ------------------------------------------------------------ pgp :57 86 A6 83 D3 A8 58 32 F7 0A BB BD 5F B2 4B A7 ------------------------------------------------------------ Auteur du livre TCP/IP Simplifié, Éditions Logiques, 1997 ------------------------------------------------------------