[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
INTERNET DRAFT                                              K. Denninger
Expires 10 May 1998                                     10 November 1997

                                  Rev 0.1



     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).

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.

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

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

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

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

        "Command and control structures" necessary to implement
        assumption #8.  This draft does not attempt to set political
        agendas or create policy bodies.

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:


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.