Subject: Comment on An IPv6 Aggregatable Global Unicast Address Format

From: IMRAN CHOWDHURY <[email-masked]>
Date: Sun, 16 Nov 1997 00:20:24 -0500

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.

Current model states for:

  The aggregatable global unicast address format is as follows:

      | 3 |  13 |    32     |   16   |          64 bits               |
      +---+-----+-----------+--------+--------------------------------+
      |FP | TLA | NLA ID    | SLA ID |         Interface ID           |
      |   | ID  |           |        |                                |
      +---+-----+-----------+--------+--------------------------------+

      <--Public Topology--->   Site
                            <-------->
                             Topology
                                      <------Interface Identifier----->

   Where

      FP           Format Prefix (001)
      TLA ID       Top-Level Aggregation Identifier
      NLA ID       Next-Level Aggregation Identifier
      SLA ID       Site-Level Aggregation Identifier
      INTERFACE ID Interface Identifier

On the NLA ID which is 32 bit, we can reserve 6 bit for content based
Internet access.

  It will appear as follows:

      | 3 |  13 |    26   | 6      |   16   |          64
bits               |
     
+---+-----+---------+--------+-----------------------------------------+
      |FP | TLA | NLA ID  | CBS ID | SLA ID |         Interface
ID           |
      |   | ID  |         |       
|                                         |
     
+---+-----+---------+--------+-----------------------------------------+

      <--------Public Topology----->   Site
                                   <------->
                                    Topology
                                             <------Interface
Identifier----->

   Where

      FP           Format Prefix (001)
      TLA ID       Top-Level Aggregation Identifier
      NLA ID       Next-Level Aggregation Identifier
      CBS ID       Contest Based Service Identifier
      SLA ID       Site-Level Aggregation Identifier
      INTERFACE ID Interface Identifier

This will able parents or countries block unwanted materials.

Imran Chowdhury

[email-masked]

---

From: "Philip J. Nesser II" <[email-masked]>
Date: Sun, 16 Nov 1997 01:00:18 -0500 (EST)

> address from the address pool that will be managed by Global or Regional

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.

---

From: "Philip J. Nesser II" <[email-masked]>
Date: Sun, 16 Nov 1997 01:00:18 -0500 (EST)

Imran,

--->  Phil

---

From: Robert Elz <[email-masked]>
Date: Sun, 16 Nov 1997 17:08:40 +1100

Date:        Sun, 16 Nov 1997 00:20:24 -0500
    From:        IMRAN CHOWDHURY <[email-masked]>
    Message-ID:  <[email-masked]>

  | This will able parents or countries block unwanted materials.

No it won't, as the addresses assigned, and the unwanted materials, are
in general two quite distinct sets, which can't be related to each other.

Eg: consider a web cache - assuming people have previously fetched both
"good" and "bad" materials, it will all be coming back to your end user
from exactly the same place (that is, exactly the same address).

It has to be the content itself which is marked in some way if you want to
aid automated deletion of whatever your definition is of objectionable
content - nothing else has a hope of being effective.

kre

ps: people keep suggesting using addresses in some way for this purpose,
I guess it is an appealing idea - it just doesn't work.   And I saw
Phil Nesser's reply, decided to send this anyway (I agree with what he
said) because I thought my reply was complementary.

---

From: Robert Elz <[email-masked]>
Date: Sun, 16 Nov 1997 17:08:40 +1100

kre

---

From: "David W. Morris" <[email-masked]>
Date: Sat, 15 Nov 1997 22:11:05 -0800 (PST)

This has at least one problem in addition to use of the PICS rating system
from W3C ... it would be really difficult to get the granularity of
content rating reflected in this kind of scheme to match the way I want
to control my Kids access. Based on my principals, I may tolerate more
or less in any of at least three dimensions (sex, language, violence).

Then there is the problem shared with PICS .... the difficulty of 
structuring the various User interactions such that content 'aggregators'
such as Infoseek, Altavista, Yahoo, etc. don't present in their summaries
access to unacceptable material.

Dave Morris

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 16 Nov 1997 10:55:45 +0000 (GMT)

Phil is 100% correct. This problem cannot be solved at the network
layer; the preferred solution so far is PICS as specified by
the W3C.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  Brian E Carpenter (IAB Chair)           [email-masked]
  IBM United Kingdom Laboratories         http://www.hursley.ibm.com/~bc/
  MP 185                                  phone: +44 1962 816833
  Hursley Park                            fax:   +44 1962 818101
  Winchester
  Hampshire SO21 2JN, UK

>- Philip J. Nesser II said:
>

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 16 Nov 1997 10:55:45 +0000 (GMT)

---

From: Karl Denninger <[email-masked]>
Date: Sun, 16 Nov 1997 12:25:04 -0600

I'd like to propose a slightly different model for address assignmnt..

This is a draft which I hadn't quite yet finished, but since the IESG is
supposedly looking into ratifying something, I HAVE TO get it out here
before I can get it completely done.

Comments appreciated, consideration of this model even more so.

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: <[email-masked]>
	Voice: [+1 312 803-MCS1]
	Fax:   [+1 312 248-9865]

draft-denninger-ipv6number-00.txt		    Expires 10 May 1998

---

From: Karl Denninger <[email-masked]>
Date: Sun, 16 Nov 1997 12:25:04 -0600

Status
======

Abstract
========

Revisions
=========

Operating Assumptions
=====================

Items Not Addressed
===================

Definitions
===========

Allocation Framework
====================

Bits	Len	Name    Use

Route Exchange
==============
	
	GALAXY
	COUNTRY
	RESVC
	REGION
	ASN

Author's Address
================

	Karl Denninger 

	Email: <[email-masked]>
	Voice: [+1 312 803-MCS1]
	Fax:   [+1 312 248-9865]

---

From: [email-masked]
Date: Sun, 16 Nov 1997 17:16:31 -0500

multinational ASes?

---

From: [email-masked]
Date: Sun, 16 Nov 1997 17:16:31 -0500

multinational ASes?

---

From: Karl Denninger <[email-masked]>
Date: Sun, 16 Nov 1997 18:03:46 -0600

> multinational ASes?

Already provided for (see the field directly ABOVE the ASN).

--
-- 
Karl Denninger ([email-masked])| MCSNet - Serving Chicagoland and Wisconsin
http://www.mcs.net/~karl     | T1's from $600 monthly to FULL DS-3 Service
			     | NEW! K56Flex modem support is now available
Voice: [+1 312 803-MCS1 x219]| 56kbps DIGITAL ISDN DOV on analog lines!
Fax:   [+1 312 803-4929]     | 2 FULL DS-3 Internet links; 400Mbps B/W Internal

---

From: Karl Denninger <[email-masked]>
Date: Sun, 16 Nov 1997 18:03:46 -0600