idnits 2.17.1 draft-denninger-ipv6number-00.txt: 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-19) 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. == 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 387 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 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.) ** There are 18 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** There are 168 instances of lines with control characters in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 236: '...attaching router MUST obtain the other...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (10 November 1997) is 9657 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) No issues found here. Summary: 11 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT K. Denninger 3 Expires 10 May 1998 10 November 1997 5 IPV6 NUMBER ASSIGNMENT PROTOCOL 6 Rev 0.1 8 draft-denninger-ipv6number-00.txt 10 Status 11 ====== 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its 15 areas, and its working groups. Note that other groups may also 16 distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other 20 documents at any time. It is inappropriate to use Internet- 21 Drafts as reference material or to cite them other than as "work 22 in progress". 24 To learn the current status of any Internet-Draft, please check 25 the "1id-abstracts.txt" listing contained in the Internet- Drafts 26 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net 27 (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East 28 Coast), or ftp.isi.edu (US West Coast). 30 Abstract 31 ======== 32 This memorandum shall be entitled ''IPV6 NUMBER ASSIGNMENT PROTOCOL'', 33 and describes a proposed policy, procedure and control structure for 34 the allocation of IPV6 Internet addresses. 36 This memorandum discusses the issues surrounding IPV6 numbering on a 37 hierarchial structure and overview. It also presents, where possible 38 and relevant, justification for the positions expressed in this paper. 40 Distribution is unlimited and comments are invited. 42 Revisions 43 ========= 44 As a draft, this document may be revised at any time. The revision 45 number of the document in question is displayed at the top of the 46 masthead, and should be referred to when commenting on the proposal 47 contained in this draft. 49 Operating Assumptions 50 ===================== 51 This draft is written under the following assumptions: 53 1) The IPv6 number space, as a 128-bit entity, is virtually unlimited 54 in scope. 56 2) It is required that we utilize the IPv6 space in a hierarchial 57 manner since full destination-level routing of a 128-bit space 58 would require 2^128 lookup table entries - prohibitive for any 59 device now existant or envisioned to be available in the 60 forseeable future. 62 3) The size of the address space at 128 bits requires reasonable 63 assumptions to be made about end node addresses and devices, 64 but does not functionally limit the number of known networks, 65 nor should the protocol for assignment of numbers artifically 66 impose constraints on the number of possible autonomous 67 systems. 69 4) An Autonomous System, or "AS" in today's terminology, is one 70 routing entity with a consolidated policy and procedure for 71 exchanging traffic with others. 73 5) Historically multiple AS numbers have been assigned to single 74 entities. It is desirable to reduce or eliminate this 75 practice such that a given AS uniquely identifies an 76 organization for administrative purposes, but the 77 functionality of multiple geographic regions which function 78 independantly cannot be lost. 80 6) It is desirable to permit every man, woman, child, toaster, 81 automobile or other vehicle and light switch if desired to 82 have its own unique end-point identifier on the global 83 Internet. 85 7) It is desired that backward-compatibility with IPv4 86 assignments be maintained to the greatest possible degree such 87 that gateways to allow IPv4 and IPv6 to co-exist during a 88 transition period, expected to last several years, are 89 possible to construct in an efficient and functional manner. 90 Since these gateways are required to operate at wire speeds, 91 which today may reach or exceed 155mbps (and in the future 92 will run at higher data rates) the simplicity of the mapping 93 function is a paramount design consideration. 95 8) A function to provide unique IPv4-compatible endpoint 96 identifiers is desired by the community during the transition 97 period, and for user-friendly end-point identifiers on a 98 permanent basis (including after IPv4 is considered 99 deprecated). 101 9) Since 128 bits of address constitutes more space than we can 102 envision needing for the forseeable (and even beyond) future, 103 we will make certain assumptions about potential future uses 104 which aren't realistic or even possible at the present time 105 given the state of science in the late 1990s. 107 Items Not Addressed 108 =================== 109 The following item is intentionally omitted from discussion in this 110 draft: 112 "Command and control structures" necessary to implement 113 assumption #8. This draft does not attempt to set political 114 agendas or create policy bodies. 116 Definitions 117 =========== 118 Autonomous System (AS): An Autonomous System, for the purposes of this 119 draft, is a network which is (1) connected to 120 more than one other network, (2) assigns addresses 121 to end users or other providers of network 122 services, and (3) announces its network 123 presence to more than one other network over 124 the connections defined in (1). 126 End Customer: An End Customer (EC) is any entity which (1) does 127 not fit the definition of an AS above, and which 128 (2) consumes or uses IPv6 addresses. 130 Allocation Framework 131 ==================== 132 IPv6 numbers are 128-bit integers. To maintain a hierarchial 133 structure over assignment, we must break down these numbers into 134 fields which are either assigned by a numbering authority under 135 delegation or which are controlled by the autonomous system and 136 assigned ultimately to customers. 138 To meet to goals and assumptions in the above section, this draft 139 attempts to detail "automatic" fields which are assigned by virtue of 140 either location or an entities status as an autonomous system. 142 To break down the allocation of IPv6 numbers, we therefore define the 143 following field names, uses, and bit placements, counting from the LEFT 144 of the address field. Note that the first 64 bits of the address are 145 defined as *assigned* and the second 64 bits are defined as *provider 146 dependant*, giving each AS 2^64 addresses to assign to customers. 148 Bits Len Name Use 149 ===================================================================== 150 0 - 7 8 GALAXY Reserved for when subspace and/or other worlds 151 (ie: the moon) become viable destinations. As 152 the scope of our transmission and reception 153 capability increases, we can increase the "reach" 154 of a given value in this field. For the purposes 155 of the Earth-based communication we use today, 156 this value shall be zero (0). 158 8 - 17 10 COUNTRY Represents the country code of the designee. 159 This permits 1024 countries to be represented 160 on each planet (well above what we have today 161 on Earth). Numbering for these to be taken from 162 ISO in order of "creation" of the country in 163 question. Country codes represent geographies; 164 if a country renames itself or changes 165 government system this does not change its 166 designated code. A country which splits into 167 two or more independant nations "creates" new 168 country codes for the new, independant entities 169 (with the original fragment, as close as can be 170 determined, being left in existance). Absent 171 cataclysmic events (ie: a country disappearing 172 into the sea) country codes are never destroyed. 174 18 - 43 26 RESVC Reserved for future use. 176 44 - 47 4 REGION Reserved for use by an AS in specifying 177 regional routing policy *within* a country. 179 48 - 63 16 ASN Provider's AS Number. Note that we currently 180 have 2194 ASNs in the GLOBAL routing system. 181 As such, this should be more than sufficient 182 space. If it is not, then we can encroach on 183 or redefine the RESVC and REGION fields as needed. 185 --------------- End ASSIGNED addresses 187 64 - 95 32 RESVA Reserved for future use by the provider when 188 IPv4 compatibility no longer is necessary, OR 189 for use at their discretion in the current 190 instance (ie: "overloading" if an address 191 needs to be mapped which already exists in the 192 IPv4 space). 194 96 - 127 IPV4 Existing IPv4 address space compatibility zone. 196 Authorities Designating Fields 197 ============================== 198 GALAXY Assigned by whatever intergalactic or interplanetary 199 authority might come to exist in the future. 200 Currently zero (Earth) and not modifyable since no 201 such authority currently exists. 203 COUNTRY Tracks ISO country code designation system 204 automatically. Existing and new country codes are 205 assigned by an automated mapping process which does 206 not require decisions by any standards body. 208 REGION For organizations which have multiple autonomous 209 routing zones within a country, they can use this 210 field (16 possible values) to designate multiple 211 routing policy domains within a country. Note that 212 under NO circumstance should this field be used as a 213 substitute for country designations. 215 ASN AS Numbers are assigned by existing delegation 216 processes, with one exception - only one ASN may be 217 assigned to a given organization. In the event that 218 multiple ASNs are required for a given organization 219 the organization should use the multiple REGION 220 designations where appropriate. 222 RESVA & IPV4 Assignable by the ASN holder as they deem fit. 224 Route Exchange 225 ============== 226 Routers which are attempting to set up peering sessions for the 227 exchange of routes must agree on the position and size of the 228 following fields: 230 GALAXY 231 COUNTRY 232 RESVC 233 REGION 234 ASN 236 An attaching router MUST obtain the other end's designations for these 237 parameters. A router may (1) configure itself to match the existing 238 mesh's idea of these fields, (2) refuse to establish a peering 239 session if it has hard-coded values which disagree, or (3) CHANGE its 240 field designations PROVIDED that no data existant in the current 241 tables conflicts with the newly-desired defaults. 243 Routers may specify some connections as MASTER and some as SLAVE; 244 MASTER peering connections must choose actions (1) and (2) as the only 245 possible outcome of configuration exchange, while SLAVE connections 246 may take step (3) if it is possible. 248 This permits a dynamically-configured Internet where the sizes and 249 positions of fields may be changed by mutual agreement. 251 Characteristics Of This Delegation Method 252 ========================================= 253 This delegation scheme has the following important characteristics 254 which will make hierarchial routing more efficient in the Internet of 255 tomorrow under the IPv6 addressing scheme: 257 1) Easy routing. End-node ASNs which wish to make full routing 258 decisions within a region of a country will only need to care 259 about the "ASN" field. They can safely ignore the REGION and 260 COUNTRY designations. Any national ASN can choose to ignore 261 the REGION designation (potentially at its peril). This gives 262 a current route table size for FULL route exchange of just over 263 2,000 entries. Regional ASNs compute and carry a table of "best" 264 COUNTRY and GALAXY exit points and forward traffic to those as 265 appropriate. Note that recomputation of GALAXY and COUNTRY 266 exits may be deemed a very low priority task at the discretion 267 of the ASN. 269 This design gives low-end providers in a given region a 270 maximum route table size of 65,536 entries, and a current 271 route table size of just over 2,000. 273 2) Multinational ASNs must use the COUNTRY, REGION and ASN fields 274 to make routing decisions. Multinational ASNs which wish to 275 use only one ASN per country do not need multiple REGION 276 codes. Those which do wish to sub-divide countries may use a 277 REGION code within those countries, but not elsewhere. 279 3) Growth of the Internet in a given country does not impact the 280 route table size for non-multinational providers outside of 281 that country. Multinational providers see impact no worse 282 than they have to cope with today under IPv4 addressing. 284 4) All "address assignment" policies which could be used to 285 restrain trade disappear; each provider has a 64-bit address 286 space to themselves, which is more than enough to accomodate 287 every possible device attached to that provider. (64 bits of 288 address give you 18,446,744,073,709,551,616 possible addresses). 289 We can therefore address every man, woman, child, dog, cat, 290 and light switch under this scheme and never even come close 291 to running out. 293 5) IPV4 mapping at the low order end gives us very easy NAT 294 capability between IPV6 and IPV4. Specifically, if two ASNs 295 cooperate through either themselves or a third party, they can 296 set policies on the allocation of the IPV4 field which will 297 insure uniqueness (similar to what IANA does now) - allowing 298 full end-user IPV4 portability. Transport to the full IPV6 299 layer for backbone routing is now an index function in most of 300 today's CPUs - a one-clock-cycle operation. This 301 byte-alignment is important to maintain high performance in 302 the gateway function, as these devices will have to run at 303 wire speeds. 305 Author's Address 306 ================ 308 Karl Denninger 310 Email: 311 Voice: [+1 312 803-MCS1] 312 Fax: [+1 312 248-9865] 313 On Sun, Nov 16, 1997 at 01:00:18AM -0500, Philip J. Nesser II wrote: 314 > IMRAN CHOWDHURY supposedly said: 315 > > 316 > > As many contries are trying to come onto the Internet and many children 317 > > are using Internet daily, Its becoming a pain for parents to block their 318 > > children from Serfing Internet where they can get Adult meterial. We are 319 > > also seeing many Countries willingness to block certain propaganda 320 > > message. To accomodate controversial sites, we can assign a block of IP 321 > > address from the address pool that will be managed by Global or Regional 322 > > Provider. 323 > > 324 > 325 > 326 > Imran, 327 > 328 > I will try and make a relatively complete but brief answer to your 329 > suggestion in an attempt to keep a huge amount of mail from flying back and 330 > forth. 331 > 332 > 1. Blocking of certain material is a growing problem for many concern 333 > people and a variety of solutions are being discussed in numerous venues. 334 > 335 > 2. Trying to solve a largely application layer problem at the network 336 > level is an avenue that will certainly fail. Solve the problem at the 337 > application layer. 338 > 339 > 3. Assigning a block of addresses for such a solution is unworkable for 340 > many reasons, but a few are: who decides what is questionable? how can 341 > you force someone to move to such a block? what implications does such a 342 > block have on global routing efficiency? etc. etc. 343 > 344 > This issue has been raised numerous times and the more popular suggestion 345 > has been to create a .XXX TLD for such material, but the same questions 346 > arise. The IETF is not the Internet Police. We don't make judgements only 347 > provide technical solutions to technical problems. If you want to protect 348 > your kids then I appluad you (too many parents just ignore these things), 349 > but that is not a technical problem for the IETF, but a social and cultural 350 > one. If you rephrase the request to "How do we design a context based 351 > tagging system with vertification and certification by independent 352 > agencies" then you might get some people talking over in the application 353 > and security areas. 354 > 355 > ---> Phil 356 > 357 > P.S. Please go look at the IETF archives for a long drawn out discussion 358 > of this issue a while back. 359 >