FYI. Regards, Thomas ---------- Forwarded message ---------- Date: Wed, 1 Jul 1998 21:32:10 -0500 From: Karl Denninger <karl@mcs.net> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng 5964) Request - has anyone read (and can I get comments on) the draft that I posted ~6 months back on address allocation for IPv6? The subject says it all. For those who might not still have it, here is the document: INTERNET DRAFT K. Denninger Expires 10 May 1998 10 November 1997 IPV6 NUMBER ASSIGNMENT PROTOCOL Rev 0.1 draft-denninger-ipv6number-00.txt Status ====== 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 learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract ======== This memorandum shall be entitled "IPV6 NUMBER ASSIGNMENT PROTOCOL", and describes a proposed policy, procedure and control structure for the allocation of IPV6 Internet addresses. This memorandum discusses the issues surrounding IPV6 numbering on a hierarchial structure and overview. It also presents, where possible and relevant, justification for the positions expressed in this paper. Distribution is unlimited and comments are invited. Revisions ========= As a draft, this document may be revised at any time. The revision number of the document in question is displayed at the top of the masthead, and should be referred to when commenting on the proposal contained in this draft. Operating Assumptions ===================== This draft is written under the following assumptions: 1) The IPv6 number space, as a 128-bit entity, is virtually unlimited in scope. 2) It is required that we utilize the IPv6 space in a hierarchial manner since full destination-level routing of a 128-bit space would require 2^128 lookup table entries - prohibitive for any device now existant or envisioned to be available in the forseeable future. 3) The size of the address space at 128 bits requires reasonable assumptions to be made about end node addresses and devices, but does not functionally limit the number of known networks, nor should the protocol for assignment of numbers artifically impose constraints on the number of possible autonomous systems. 4) An Autonomous System, or "AS" in today's terminology, is one routing entity with a consolidated policy and procedure for exchanging traffic with others. 5) Historically multiple AS numbers have been assigned to single entities. It is desirable to reduce or eliminate this practice such that a given AS uniquely identifies an organization for administrative purposes, but the functionality of multiple geographic regions which function independantly cannot be lost. 6) It is desirable to permit every man, woman, child, toaster, automobile or other vehicle and light switch if desired to have its own unique end-point identifier on the global Internet. 7) It is desired that backward-compatibility with IPv4 assignments be maintained to the greatest possible degree such that gateways to allow IPv4 and IPv6 to co-exist during a transition period, expected to last several years, are possible to construct in an efficient and functional manner. Since these gateways are required to operate at wire speeds, which today may reach or exceed 155mbps (and in the future will run at higher data rates) the simplicity of the mapping function is a paramount design consideration. 8) A function to provide unique IPv4-compatible endpoint identifiers is desired by the community during the transition period, and for user-friendly end-point identifiers on a permanent basis (including after IPv4 is considered deprecated). 9) Since 128 bits of address constitutes more space than we can envision needing for the forseeable (and even beyond) future, we will make certain assumptions about potential future uses which aren't realistic or even possible at the present time given the state of science in the late 1990s. Items Not Addressed =================== The following item is intentionally omitted from discussion in this draft: "Command and control structures" necessary to implement assumption #8. This draft does not attempt to set political agendas or create policy bodies. Definitions =========== Autonomous System (AS): An Autonomous System, for the purposes of this draft, is a network which is (1) connected to more than one other network, (2) assigns addresses to end users or other providers of network services, and (3) announces its network presence to more than one other network over the connections defined in (1). End Customer: An End Customer (EC) is any entity which (1) does not fit the definition of an AS above, and which (2) consumes or uses IPv6 addresses. Allocation Framework ==================== IPv6 numbers are 128-bit integers. To maintain a hierarchial structure over assignment, we must break down these numbers into fields which are either assigned by a numbering authority under delegation or which are controlled by the autonomous system and assigned ultimately to customers. To meet to goals and assumptions in the above section, this draft attempts to detail "automatic" fields which are assigned by virtue of either location or an entities status as an autonomous system. To break down the allocation of IPv6 numbers, we therefore define the following field names, uses, and bit placements, counting from the LEFT of the address field. Note that the first 64 bits of the address are defined as *assigned* and the second 64 bits are defined as *provider dependant*, giving each AS 2^64 addresses to assign to customers. Bits Len Name Use ===================================================================== 0 - 7 8 GALAXY Reserved for when subspace and/or other worlds (ie: the moon) become viable destinations. As the scope of our transmission and reception capability increases, we can increase the "reach" of a given value in this field. For the purposes of the Earth-based communication we use today, this value shall be zero (0). 8 - 17 10 COUNTRY Represents the country code of the designee. This permits 1024 countries to be represented on each planet (well above what we have today on Earth). Numbering for these to be taken from ISO in order of "creation" of the country in question. Country codes represent geographies; if a country renames itself or changes government system this does not change its designated code. A country which splits into two or more independant nations "creates" new country codes for the new, independant entities (with the original fragment, as close as can be determined, being left in existance). Absent cataclysmic events (ie: a country disappearing into the sea) country codes are never destroyed. 18 - 43 26 RESVC Reserved for future use. 44 - 47 4 REGION Reserved for use by an AS in specifying regional routing policy *within* a country. 48 - 63 16 ASN Provider's AS Number. Note that we currently have 2194 ASNs in the GLOBAL routing system. As such, this should be more than sufficient space. If it is not, then we can encroach on or redefine the RESVC and REGION fields as needed. --------------- End ASSIGNED addresses 64 - 95 32 RESVA Reserved for future use by the provider when IPv4 compatibility no longer is necessary, OR for use at their discretion in the current instance (ie: "overloading" if an address needs to be mapped which already exists in the IPv4 space). 96 - 127 IPV4 Existing IPv4 address space compatibility zone. Authorities Designating Fields ============================== GALAXY Assigned by whatever intergalactic or interplanetary authority might come to exist in the future. Currently zero (Earth) and not modifyable since no such authority currently exists. COUNTRY Tracks ISO country code designation system automatically. Existing and new country codes are assigned by an automated mapping process which does not require decisions by any standards body. REGION For organizations which have multiple autonomous routing zones within a country, they can use this field (16 possible values) to designate multiple routing policy domains within a country. Note that under NO circumstance should this field be used as a substitute for country designations. ASN AS Numbers are assigned by existing delegation processes, with one exception - only one ASN may be assigned to a given organization. In the event that multiple ASNs are required for a given organization the organization should use the multiple REGION designations where appropriate. RESVA & IPV4 Assignable by the ASN holder as they deem fit. Route Exchange ============== Routers which are attempting to set up peering sessions for the exchange of routes must agree on the position and size of the following fields: GALAXY COUNTRY RESVC REGION ASN An attaching router MUST obtain the other end's designations for these parameters. A router may (1) configure itself to match the existing mesh's idea of these fields, (2) refuse to establish a peering session if it has hard-coded values which disagree, or (3) CHANGE its field designations PROVIDED that no data existant in the current tables conflicts with the newly-desired defaults. Routers may specify some connections as MASTER and some as SLAVE; MASTER peering connections must choose actions (1) and (2) as the only possible outcome of configuration exchange, while SLAVE connections may take step (3) if it is possible. This permits a dynamically-configured Internet where the sizes and positions of fields may be changed by mutual agreement. Characteristics Of This Delegation Method ========================================= This delegation scheme has the following important characteristics which will make hierarchial routing more efficient in the Internet of tomorrow under the IPv6 addressing scheme: 1) Easy routing. End-node ASNs which wish to make full routing decisions within a region of a country will only need to care about the "ASN" field. They can safely ignore the REGION and COUNTRY designations. Any national ASN can choose to ignore the REGION designation (potentially at its peril). This gives a current route table size for FULL route exchange of just over 2,000 entries. Regional ASNs compute and carry a table of "best" COUNTRY and GALAXY exit points and forward traffic to those as appropriate. Note that recomputation of GALAXY and COUNTRY exits may be deemed a very low priority task at the discretion of the ASN. This design gives low-end providers in a given region a maximum route table size of 65,536 entries, and a current route table size of just over 2,000. 2) Multinational ASNs must use the COUNTRY, REGION and ASN fields to make routing decisions. Multinational ASNs which wish to use only one ASN per country do not need multiple REGION codes. Those which do wish to sub-divide countries may use a REGION code within those countries, but not elsewhere. 3) Growth of the Internet in a given country does not impact the route table size for non-multinational providers outside of that country. Multinational providers see impact no worse than they have to cope with today under IPv4 addressing. 4) All "address assignment" policies which could be used to restrain trade disappear; each provider has a 64-bit address space to themselves, which is more than enough to accomodate every possible device attached to that provider. (64 bits of address give you 18,446,744,073,709,551,616 possible addresses). We can therefore address every man, woman, child, dog, cat, and light switch under this scheme and never even come close to running out. 5) IPV4 mapping at the low order end gives us very easy NAT capability between IPV6 and IPV4. Specifically, if two ASNs cooperate through either themselves or a third party, they can set policies on the allocation of the IPV4 field which will insure uniqueness (similar to what IANA does now) - allowing full end-user IPV4 portability. Transport to the full IPV6 layer for backbone routing is now an index function in most of today's CPUs - a one-clock-cycle operation. This byte-alignment is important to maintain high performance in the gateway function, as these devices will have to run at wire speeds. Author's Address ================ Karl Denninger Email: <karl@MCS.Net> Voice: [+1 312 803-MCS1] Fax: [+1 312 248-9865] draft-denninger-ipv6number-00.txt Expires 10 May 1998 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com --------------------------------------------------------------------