idnits 2.17.1 draft-blanchet-ipaddressalloc-00.txt: -(45): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(137): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-24) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == There are 9 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 182 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction 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 an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 19 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** There are 8 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 86 has weird spacing: '...uch way that ...' -- 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 (2 January 1999) is 9244 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) == Unused Reference: 'IPv6AddrArch' is defined on line 145, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1219 (ref. 'IPv4Assign') Summary: 12 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Marc Blanchet 2 2 July 1998 Viagenie inc. 3 Expires 2 January 1999 5 A flexible allocation scheme for IP addresses (IPv4 and IPv6) 6 8 Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its 12 areas, and its working groups. Note that other groups may also 13 distribute working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six 16 months and may be updated, replaced, or obsoleted by other 17 documents at any time. It is inappropriate to use Internet- 18 Drafts as reference material or to cite them other than as 19 "work in progress." 21 To view the entire list of current Internet-Drafts, please check 22 the "1id-abstracts.txt" listing contained in the Internet-Drafts 23 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 24 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 25 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 27 Abstract 29 This draft presents an IP address allocation scheme that enables the IP 30 allocator (the organisation that allocates addresses) to postpone the final 31 decision of prefix length by keeping space between allocated bits of the 32 different parts of the IP address. This enables the allocator to change 33 the different part lengths of the prefix (TLA, subTLA, SLA, ...) even after 34 allocated spaces. This scheme is applicable to both IPv4 and IPv6 but is 35 envisionned mainly for IPv6 where the address space is larger and more 36 flexible. 38 1. Context 40 IPv6 addresses have a more flexible structure for address allocation where 41 no pre-defined prefixes (called subnetmasks in IPv4) are used (except a few 42 special cases). It enables the registries, the service provider, the 43 network designer and others to allocate addresses based on different 44 criterias, like size of networks, estimated growth rate, etc. It happens 45 often that the initial design of the allocation doesn�t scale well because 46 a small network becomes larger than expected, needing more addresses. But 47 then, the allocator cannot allocate contiguous addresses because they were 48 already assigned to another network. Non-contiguous addresses breaks the 49 address aggregation for routing. 51 RFC1219 [IPv4Assign] describes an allocation scheme for IPv4 where address 52 space is kept 53 unallocated between the leftmost bits of the subnet part and the rightmost 54 bits of the host part of the address. This enables the network designer to 55 change the subnetmask without renumbering, for the central bits that were 56 not allocated. 58 This work generalize the previous scheme by an algorithm to allocate IP 59 addresses for all the parts of an IPv6 address allocated by all levels of 60 the allocators (TLA, registries, ISPs, organisations, ...). 62 2. Scheme 64 We define parts of the IP address as p1, p2 , p3, ... pN in order, so that 65 an IP address is composed of all its parts contiguous. Boundaries between 66 each part is based on the prefix allocated by the next level allocator. 67 Part p1 is the leftmost part probably assigned to a TLA, Part p2 can be 68 allocated by the TLA to a large provider or a national registry. Part p3 69 can be allocated to a large customer or a smaller provider, etc. Each part 70 can be of different length. We define l(pX) the length of part X. 72 +------+------+------+------+------+------+ 73 | p1 | p2 | p3 | p4 | ... | pN | 74 +------+------+------+------+------+------+ 75 <------- ipv6 or ipv4 address ------------> 77 The algorithm for allocating addresses is as follows : 78 a) for the leftmost part (p1), allocate addresses using the leftmost 79 bits first 80 b) for the rightmost part (pN), allocate addresses using the 81 rightmost bits first 82 c) for all other parts (center parts), predefine an arbitrary 83 boundary (prefix) and then allocate addresses using the center 84 bits first of the part being allocated. 86 This algorithm grow allocated bits in such way that it keeps unallocated 87 bits near the boundary of the parts. This means that the prefix between 88 any two parts can be changed forward or backward, later on, up to the 89 allocated bits. 91 3. Allocation 93 p1 will be allocated as follows : 95 Order Assignment 96 1 10000000 97 2 01000000 98 3 11000000 99 4 00100000 100 5 10100000 101 6 01100000 102 7 11100000 103 8 00010000 104 9 ... 106 pN (the last part) will be allocated as follows : 108 Order Assignment 109 1 00000001 110 2 00000010 111 3 00000011 112 4 00000100 113 5 00000101 114 6 00000110 115 7 00000111 116 8 00001000 117 9 ... 119 pX (where 1 < X < N) will be allocated as follows : (for example, with a 8 120 bit predefined length l(pX)=8)) 122 Order Assignment 123 1 00001000 124 2 00010000 125 3 00011000 126 4 00000100 127 5 00001100 128 6 00010100 129 7 00011100 130 8 00100000 131 9 ... 133 4. Acknowledgements 135 5. Security Considerations 137 Address allocation doesn�t seem to have any specific security consideration. 139 6. References 141 [IPv4Assign] RFC1219 On the assignment of subnet numbers. P.F. Tsuchiya. 142 Apr-01-1991. 143 (Format: TXT=30609 bytes) (Status: INFORMATIONAL) 145 [IPv6AddrArch] IP Version 6 Addressing Architecture, R. Hinden, S. Deering, 146 Jan-1998, 147 draft-ietf-ipngwg-addr-arch-v2-06.txt, Work in progress. 149 7. Author�s address 151 Marc Blanchet 152 Viagenie inc. 153 3107 des h�tels 154 Ste-Foy, Qu�bec, Canada 155 G1W 4W5 157 Email : Marc.Blanchet@viagenie.qc.ca 158 Tel. : 418-656-9254 159 Fax : 418-656-0183 161 ----------------------------------------------------------- 162 Marc Blanchet | Marc.Blanchet@viagenie.qc.ca 163 Viag�nie inc. | http://www.viagenie.qc.ca 164 3107 des h�tels | t�l.: 418-656-9254 165 Ste-Foy, Qu�bec | fax.: 418-656-0183 166 Canada, G1W 4W5 | radio: VA2-JAZ 167 ------------------------------------------------------------ 168 pgp :57 86 A6 83 D3 A8 58 32 F7 0A BB BD 5F B2 4B A7 169 ------------------------------------------------------------ 170 Auteur du livre TCP/IP Simplifi�, �ditions Logiques, 1997 171 ------------------------------------------------------------