RE: draft-hubbard-registry-guidelines-03.txt

JohnM <> Mon, 29 July 1996 15:11 UTC

Received: from by id aa04629; 29 Jul 96 11:11 EDT
Received: from cnri by id aa04625; 29 Jul 96 11:11 EDT
Received: from by CNRI.Reston.VA.US id aa05774; 29 Jul 96 11:11 EDT
Received: from by id aa04616; 29 Jul 96 11:11 EDT
Received: from cnri by id aa04603; 29 Jul 96 11:11 EDT
Received: from by CNRI.Reston.VA.US id aa05768; 29 Jul 96 11:11 EDT
Received: by with Microsoft Exchange (IMC 4.0.838.14) id <>; Mon, 29 Jul 1996 11:09:10 -0400
Message-ID: <>
From: JohnM <>
To: "'davidc@APNIC.NET'" <>, "'dfk@RIPE.NET'" <>, "''" <>, "''" <>, "'Postel@ISI.EDU'" <>, 'Jim Browning' <>
Cc: 'CIDRD List' <>, 'IESG' <iesg@CNRI.Reston.VA.US>, 'IETF' <ietf@CNRI.Reston.VA.US>
Subject: RE: draft-hubbard-registry-guidelines-03.txt
Date: Mon, 29 Jul 1996 11:08:50 -0400
Return-Receipt-To: <JohnM@Competitive.Com>
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.838.14
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

It seems as if there is quite a bit of political wrangling over IP
addresses and how they should be doled out and administered.

Consider the Internet-draft that would allow all IP addresses to be
created and used dynamically.  Addresses would be created primarily by
using global positioning (latitude-longitude-altitude) information
coupled with MAC  addresses (network interface card manufacturer/serial

The draft is in the IETF internet draft area and is entitled 


Wouldn't it make IP address management simpler?

>From: 	Jim Browning[]
>Sent: 	Saturday, July 20, 1996 8:42 PM
>To: 	'davidc@APNIC.NET';; 'dfk@RIPE.NET';; '';;
>'';; 'Postel@ISI.EDU';
>Cc: 	'CIDRD List'; 'IESG'; 'IETF'
>Subject: 	draft-hubbard-registry-guidelines-03.txt
>As reflected in the minutes of the CIDRD WG meeting in Montreal, the
>has requested additional comments on the referenced draft.  To the
>that this message reiterates comments I made about the earlier draft, I
>apologize for the redundancies, however if they are included here, it
>because my earlier comments still apply:
>>                             1. Introduction
>> Internet address space is distributed according to the following
>> three goals:
>> 1) Conservation: Fair distribution of globally unique Internet address
>> space according to the operational needs of the end-users and Internet
>> Service Providers operating networks using this address space.
>> Prevention of stockpiling in order to maximize the lifetime of the
>> Internet address space.
>The reference to "Fair distribution" should be removed from the 
>Conservation paragraph because it is out of context.  Fair Distribution
>Conservation are both important goals, but they are not the *same*
> In fact, the two often conflict.  I recommend that they be split into 
>separate goals by adding the following:
>    4) Fair Distribution: Allocation of IP addresses according to the 
>operational needs of end-users, fairly and objectively determined.
>> It is in the interest of the Internet community as a whole that the
>> above goals be pursued.  However it should be noted that
>> "Conservation" and "Routability" are often conflicting goals.  All
>> the above goals may sometimes be in conflict with the interests of
>> individual end-users or Internet service providers.  Careful analysis
>> and judgement is necessary in each individual case to find an
>> appropriate compromise.
>Compromise is not an appropriate goal.  It presumes that there will be
>negotiation, and that the end result will be the allocation of an
>block smaller than requested, but larger than initially offered.  As 
>opposed to 'judgment and compromise'', the goal should be "the
>application of objective criteria", which will result in a correct and 
>supportable decision.  Compromises, while they give something to each
>in a negotiation, rarely result in the best decision.
>> The Internet Assigned Numbers Authority has authority over all number
>> spaces used in the Internet.  This includes Internet Address Space. IANA
>> allocates parts of the Internet address space to regional IRs according
>> to its established needs.
>The source of IANA's authority should be referenced: 
><draft-ietf-poised95-ietf-orgs-03.txt>, or another more definitive 
>reference if there is one.
>> Regional IRs
>> Regional IRs are established under the authority of the IANA.  This
>> requires consensus within the Internet community of the region.  A con-
>> sensus of Internet Service Providers in that region may be necessary to
>> fulfill that role.
>The process for establishing these IRs should be clearly defined, as
>the mechanisms for evaluating whether the distribution goals outlined
>this draft are being met.
>> The specific duties of the regional IRs include coordination and
>> representation of all local IRs in its respective regions.
>The duties of the IRs should include meeting the distribution
>and ensuring that local IRs meet them as well.
>> Local IRs
>> Local IRs are established under the authority of the regional IR and
>> IANA.  These local registries have the same role and responsibility as
>> the regional registries within its designated geographical areas.  These
>> areas are usually of national dimensions.
>Just as with the IRs, The process for establishing Local IRs should be 
>clearly defined, as should the mechanisms for evaluating whether the 
>distribution goals outlined in this draft are being met at the local
>>                         2.  Allocation Framework
>> 2.1  Guidelines for Internet Service Providers (ISPs)
>> ISPs who exchange routing information with other ISPs at multiple loca-
>> tions and operate without default routing may request space directly
>> from the regional registry in its geographical area.
>Many multi-homed ISPs, with peering agreements in place, choose to
>a default route as well.  I see no reason why this draft should
>such an ISP from obtaining a direct allocation of addresses when other 
>factors indicate that it is appropriate.
>> To facilitate hierarchical addressing, implemented using Classless
>> Inter-Domain Routing (CIDR), all other ISPs should request address space
>> directly from its upstream provider.  ISPs only request address space
>> directly from regional registries if their immediate requirement, when
>> satisfied with a contiguous block allocation, has a reasonable probabil-
>> ity of being routable on the Internet, and they meet one or more of the
>> following conditions.
>>        a)  the ISP is directly connected to a major routing exchange
>>            (for purposes of this document, a major routing exchange
>>             is defined as a neutral layer 2 exchange point connecting
>>             four or more unrelated ISPs.)
>The issue of physical connectivity should not be a concern of this
> Many people believe that the future will see an increased reliance on 
>regional exchanges (which may or may not fit the above definition) and 
>private exchange/peering agreements which do not occur at an exchange 
>point.  Several major NSPs have begun taking the private exchange
>only two providers) approach in order to reduce congestion at the NAPs.
> There is no reason these efforts should be discouraged through IP 
>allocation policy. The issue is whether there is a valid need for 
>addresses, and this has little to do with where networks are exchanging
>>        b)  the ISP is multi-homed, that is, it has more than one
>>            simultaneous connection to the global Internet and no
>>            connection is favored over the other
>I don't understand why favoring one connection over another should be a
>factor.  I also fail to see how this can be objectively determined. 
>this mean that if an ISP is multi-homed with two connections of the
>speed to two different NSPs, but she pads her AS path for one of them
>route traffic is carried on a preferred (for whatever reason) path,
>she can not obtain a direct allocation of addresses?  I think this
>prevents the application of objective criteria.
>> The following are the IP allocation guidelines for ISPs:
>> 4.     IP addresses are allocated to ISPs using a slow-start
>>        procedure.  New ISPs will receive a minimal amount based
>>        on immediate requirement.  Thereafter,  allocated blocks may be
>>        increased based on utilization verification supplied to the
>>        regional registry.  The parent registries are responsible for
>>        determining appropriate initial and subsequent allocations.
>>        Additional address allocations will provide enough address space
>>        to enable the ISP to assign addresses for three months
>>        without requesting additional address space from its parent
>>        registry.  Please note that projected customer base has little
>>        impact on the address allocations made by the parent registries.
>>        Initial allocation will not be based on any current or future
>>        routing restrictions but on demonstrated requirements.
>There is an apparent conflict between this paragraph and later (Section
>paragraphs which reference a one-year period which will be taken into 
>account, and that there needs to be only 50% utilization in the first
>>  6.    Regional registries may set a maximum limit on assignment sizes
>>        such that a second opinion of the regional registry is required.
>This appears to be discussing the internal mechanics of a registry, but
>only with respect to one detail.  If the draft is going to define *how*
>registry meets the distribution goals, then there are a whole host of
>details that need to be specified.  I suggest either deleting this 
>paragraph, or restating it so that it addresses obtaining additional 
>opinions from regional registries parent registry.
>>                         3. Assignment Framework
>> An assignment is the delegation of authority over a block of IP
>> addresses to an end enterprise.   The end enterprise will use addresses
>> from an assignment internally only; it will not sub-delegate those
>> addresses.  This section discusses some of the issues involved in
>> assignments and the framework behind the assignment of addresses.
>> In order for the Internet to scale using existing technologies, use of
>> regional registry services should be limited to the assignment of IP
>> addresses for organizations meeting one or more of the following condi-
>> tions:
>>       a)  the organization has no intention of connecting to
>>           the Internet-either now or in the future-but it still
>>           requires a globally unique IP address.  The organization
>>           should consider using reserved addresses from RFC1918.
>>           If it is determined this is not possible, they can be
>>           issued unique (if not Internet routable) IP addresses.
>>       b)  the organization is multi-homed with no favored connection.
>>       c)  the organization's actual requirement for IP space is
>>           very large, for example, the network prefix required to
>>           cover the request is of length /18 or shorter.
>If I am reading section 3 correctly (the wording could be clearer), it
>differentiating between end users who want to obtain addresses from a 
>registry, and ISPs who want to obtain addresses from a registry.  Why
>distinction?  Why should an end user with a large (/18 or shorter) 
>requirement be allowed to obtain addresses from a registry, when an ISP
>with a similar size requirement must also meet other criteria (NAP 
>connection, multi-homing, etc.).  If there are to be different criteria
>based upon whether a requester will be assigning addresses to other 
>entities, I would think the criteria should be less confining for the
>as the size of her address space is more likely to increase in the
>and she is more likely to end up with a NAP connection and/or be 
>This revision is much improved, although I believe there are
>issues (e.g., how registries are established) which must still be
><NPI>.  I appreciate the effort put forth by its authors, and the 
>opportunity to provide additional comments.
>Jim Browning <>;
>619/643-1802   Fax 619/643-1801