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
On Sun, Nov 16, 1997 at 01:00:18AM -0500, Philip J. Nesser II wrote:
> IMRAN CHOWDHURY supposedly said:
> >
> > As many contries are trying to come onto the Internet and many children
> > are using Internet daily, Its becoming a pain for parents to block their
> > children from Serfing Internet where they can get Adult meterial. We are
> > also seeing many Countries willingness to block certain propaganda
> > message. To accomodate controversial sites, we can assign a block of IP
> > address from the address pool that will be managed by Global or Regional
> > Provider.
> >
>
>
> Imran,
>
> I will try and make a relatively complete but brief answer to your
> suggestion in an attempt to keep a huge amount of mail from flying back and
> forth.
>
> 1. Blocking of certain material is a growing problem for many concern
> people and a variety of solutions are being discussed in numerous venues.
>
> 2. Trying to solve a largely application layer problem at the network
> level is an avenue that will certainly fail. Solve the problem at the
> application layer.
>
> 3. Assigning a block of addresses for such a solution is unworkable for
> many reasons, but a few are: who decides what is questionable? how can
> you force someone to move to such a block? what implications does such a
> block have on global routing efficiency? etc. etc.
>
> This issue has been raised numerous times and the more popular suggestion
> has been to create a .XXX TLD for such material, but the same questions
> arise. The IETF is not the Internet Police. We don't make judgements only
> provide technical solutions to technical problems. If you want to protect
> your kids then I appluad you (too many parents just ignore these things),
> but that is not a technical problem for the IETF, but a social and cultural
> one. If you rephrase the request to "How do we design a context based
> tagging system with vertification and certification by independent
> agencies" then you might get some people talking over in the application
> and security areas.
>
> ---> Phil
>
> P.S. Please go look at the IETF archives for a long drawn out discussion
> of this issue a while back.
>