ICANN: Ad Hoc Committee on Addressing Ad Hoc Effort Bibliography

February 2000, version 1

Mark McFadden mcfadden@cix.org

PURPOSE AND MOTIVATION

This document is intended to be a basic, annotated bibliography for use in ICANN's Ad Hoc effort. The bibliography points to documents that descirbe IPv4 and IPv6 addressing policies and protocols, documents that describe the intersection between the addressing requirements for IP and other technologies (especially PSTN and mobile), and general or tutorial documents on addressing policy. This bibliography is not intended to be an exhaustive reference to all available literature on Internet addressing; instead it is intended to be a basic contribution to the ICANN Ad Hoc effort and its Terms of Reference.

For each document in the bibliography the author, date and availability of the document is provided. This is the first version of the document.

TABLE OF CONTENTS

The document is divided into sections:

• Section 1: IPv4 and IPv6 Addressing in the Internet Section 1, part 1: IPv4 Policies and Protocols Section 1, part 2: IPv6 Policies and Protocols
• Section 2: Impacts on Addressing of New Technologies Section 3: General and Tutorial documents

SUBSEQUENT VERSIONS

The editor of this document expects that contributions and suggestions by the community will lead to further versions of this document. Suggestions for additions and corrections are cheerfully welcomed. Contact information for the editor is at the end of the document.

CONTACT INFORMATION

This document was compiled by Mark McFadden, Commercial Internet eXchange, Herndon, Virginia. Any errors or ommissions are my responsibility and corrections, suggestions, and proposals for further contributions are welcomed by the editor:

Mark McFadden mcfadden@cix.org

PO Box 7102 Madison, Wisconsin 53707-5707 US

Section 1: IPv4 and IPv6 Addressing in the Internet Part 1: IPv4 Policies and Protocols

ISP GUIDELINES FOR REQUESTING INITIAL IP ADDRESS SPACE Author: ARIN

This is ARIN's document that describes ISP guidelines for requesting initial allocations of IP address space. ARIN allocates IP address prefixes no longer than /20. To recieve an initial allocation an organization must demonstrate the efficient utilization of a minimum contiguous or non-contiguous /21 (eight /24s) and provide reassignment information for /29 and shorter prefix lengths using the Shared WHOIS Project (SWIP) or by providing the same information fields in an RWHOIS server. Organizations requesting address space from ARIN must also provide detailed information showing that a /20 will be utilized within three months and agree that the new /20 will be used to renumber out of the current addresses which will be returned to their upstream provider(s) within 18 months. The document provides additional language that defines how requests from calble-based providers are to be handled. ISPs that have residential cable subscribers use Net 24 address space to provide cable service to their customers. In most cases, these ISPs do not assign space to individual customers, but rather allocate it to the part of the cable infrastructure to which customers connect. ARIN also makes "micro-allocations" to exchange points in the Internet. Some public exchange points are considered to be part of the critical infrastructure of the Internet. ARIN makes micro-allocations to these public exchange points no longer than a /24.

EUROPEAN INTERNET REGISTRY POLICIES AND PROCEDURES Author: RIPE Local Internet Registry Working Group

This is RIPE's document that describes the procedures for requesting allocations of IP address space. RIPE follows the same procedures for allocation decision regardless of whether the allocation is an additional allocation or an initial allocation. The requestor is required to provide information on the size of the request, the structure of the network and how the addresses are to be used, the number of subnets and type of IP connection or transit in place. The requestor must also submit an addressing plan that describes the projected use of the space. Every request in given an individual evaluation process that takes current RIPE assignment guidelines into account. Local IRs are given an initial /19 from which to allocate addresses. Additional allocation requests can be made when the currently allocated address space is nearly used up (about 80 percent). In addition, the RIPE NCC recommends that local registries set up reverse delegation services for all of the addresses assigned for their own infrastructure and to their customers. The document gives an explanation of the local regustry concept and the procedures for becoming a local registry in RIPE's area of responsibility.
 
 

POLICIES FOR ADDRESS SPACE MANAGEMENT IN THE ASIA PACIFIC REGION Author: APNIC

APNIC delegates address assignment authority to local IRs and national IRs who then apply APNIC's policies. All IR's are to adopt consistent address space management space policies and treat address assignements as "leases." The need for documentation, security and confidentiality are stressed in the assignment process. Like ARIN and RIPE, APNIC uses a slow start mechanism for initial allocations. While there are exceptions to the slow start process, the slow start mechanism is used to ensure that large blocks of address space are used, if they are assigned. The maximum assignment window for a LIR is a /19.
 
 

INTERNET REGISTRY IP ALLOCATION GUIDELINES Authors: Hubbard, Kosters, Conrad, Karrenberg, Postel

This document is the current IP address assignment policy and distribution document for unicast IPv4 addresses. The document describes not only the rules and guidelines for governing the distribution of the address space, but also the underlying registry system. The document has a section of the local assignment policies of each registry, but these sections have been rendered obsolete by document specific to each registry. The document does not address multicast or private address space. This document is known both as RFC 2050 and as BCP (Best Current Practices) 12.
 
 

ADMINISTRATIVELY SCOPED IP MULTICAST ADDRESS SPACE Author: Meyer

This document defines the "administratively scoped IPv4 multicast space" to be the range 239.0.0.0 to 239.255.255.255. In addition, it describes a simple set of semantics for the implementation of Administratively Scoped IP Multicast. Administratively Scoped Multicast was a response to architectural problems identified in using the TTL field in the IP header for multicast scoping. The document uses the range to provide local scope addresses and organization local scope addresses. Finally, it provides a mapping between the IPv6 multicast address classes documented in RFC 1884 and IPv4 multicast address classes. The document is RFC 2365 and BCP 23.
 
 

AN APPEAL TO THE INTERNET COMMUNITY TO RETURN UNUSED IP NETWORKS (AND PREFIXES) TO THE IANA Author: Nesser

This document, written when there was little certainty about the pace of exhaustion of Ipv4 address space, was an appeal to the Internet community at-large to return unused address space. In some cases, notably Stanford University, large amounts of space was returned for reallocation to the registries. The document also requests that ISPs return unused prefixes which fall outside their usual address blocks to the IANA for reuse. The document is RFC 1917 and BCP 4.
 
 

ADDRESS ALLOCATION FOR PRIVATE INTERNETS Authors: Rekhter, Moskowitz, Karrenberg, de Groot, Lear

This document provides the rationale and standards for private IPv4 address space. Specifically it carves out three CIDR blocks for use in

private networks: 10.0.0.0 - 10.255.255.255 (10/8 prefix)
172.16.0.0 - 172.31.255.255 (172.16/12 prefix)
192.168.0.0 - 192.168.255.255 (192.168/16 prefix)
The document discusses the advantages and disadvantages of using
private address space. The document is RFC 1918 and BCP 5.

IMPLICATIONS OF VARIOUS ADDRESS ALLOCATION POLICIES FOR INTERNET ROUTING Authors: Rekhter, Li

This document examines the implications of a variety of address allocation policies and their effect on routing in the public Internet. The RFC addresses the intrinsic value of IPv4 addresses as well as providing a technical overview of hierarchical routing in the Internet. The implications of hierarchical routing on routing tables and address policy are examined in detail. The document examines the interaction of address allocation policy with the implications of that policy on routing. As an example the document says, "IP address allocation and management policy is a complex, multifaceted issue. It covers a broad range of issues, such as who formulates the policies, who executes the policies, what is the role of various registries, what is the role of various organizations (e.g., ISOC, IAB, IESG, IETF, IEPG, various government bodies, etc.), the participation of end users in requesting addresses, and so on. Address allocation and management and the scalability of the routing system are interrelated - only certain address allocation and management policies yield scalable routing. The Internet routing system is subject to both technological and fundamental constraints. These constraints restrict the choices of address allocation policies that are practical." Scalability of routing is a key topic and the document concludes by suggesting that addresses should be "lent" to those who use them rather than "owned" by those that use them. The document is RFC 2008 and BCP 7.
 
 

DOCUMENTING SPECIAL USE IPV4 ADDRESS BLOCKS Author: Manning

This document lists the existent special use prefixes from the IPv4 space that have been registered with the IANA and provides some suggestions for operational procedures when these prefixes are encountered. This document does not address IPv4 space that is reserved for future delegation in the operational Internet.

The current list of special use prefixes: 0.0.0.0/8 127.0.0.0/8 192.0.2.0/24 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 169.254.0.0/16 all D/E space (RFC 1166)

The document is currently an Internet Draft and is a work in progress.

Part 1: IPv6 Policies and Protocols

IP VERSION 6 ADDRESSING ARCHITECTURE Authors: Hinden, Deering

This specification defines the addressing architecture of the IP Version 6 protocol. IPv6 addresses are 128-bit identifiers for interfaces and groups of interfaces including unicast addresses, anycast addresses, and multicast addresses. The addresses are specified as eight 16-bit pieces of the address. Two other notations are provided for in the specification. Several types of IPv6 addresses are provided for: reserved addresses (for NSAP and IPX allocation, as well as addresses reserved in general), aggregatable global unicast addresses, link-local and site local unicast addresses, and multicast addresses. IPv6 unicast addresses are aggregatable with contiguous bit-wise masks similar to IPv4 addresses under Class-less Interdomain Routing (CIDR). The document is RFC 2373 and is in the IETF's standards track.
 
 

AN IPV6 AGGREGATABLE GLOBAL UNICAST ADDRESS FORMAT Authors: Hinden, O'Dell, Deering

This document replaces the original IPv6 address format which was previously defined in RFC 2073. The intent is to provide a new format that provides greater aggregation for more effective routing. The other improvements over RFC 2073 included removal of the registry bits because they are not needed for route aggregation, support of EUI-64 based interface identifiers, support of provider and exchange based aggregation, separation of public and site topology, and new aggregation based terminology.

The aggregatable global unicast address format is as follows:

IPV6 TESTING ADDRESS ALLOCATION Authors: Hinden, Fink, Postel

This document describes an allocation plan for IPv6 addresses to be used in testing IPv6 prototype software. These addresses are temporary and will be reclaimed in the future. Any IPv6 system using these addresses will have to renumber at some time in the future. These addresses will not to be routable in the Internet other than for IPv6 testing.
 

The Aggregatable Global Unicast Address Allocation format defined in [AGGR] is as follows:  

IPV6 MULTICAST ADDRESS ASSIGNMENTS Authors: Hinden, Deering

This document defines the initial assignment of IPv6 multicast addresses. It adapts the existing IPv4 multicast address space to IPv6 and supports node-local, site-local and link-local scope addresses. Note that RFC 2373, IP Version 6 Addressing Architecture, is the document that defines rules for new IPv6 multicast addresses. This document is an informational RFC: RFC 2375.

RESERVED IPV6 SUBNET ANYCAST ADDRESSES Authors: Johnson, Deering

The IP Version 6 addressing architecture defines an "anycast" address as an IPv6 address that is assigned to one or more network interfaces (typically belonging to different nodes), with the property that a packet sent to an anycast address is routed to the "nearest" interface having that address, according to the routing protocols' measure of distance. This document defines a set of reserved anycast addresses within each subnet prefix, and lists the initial allocation of these reserved subnet anycast addresses.

Specifically, for IPv6 address types required to have to have 64-bit interface identifiers in EUI-64 format, these reserved subnet anycast addresses are constructed as follows:
 
 

| 64 bits | 57 bits | 7 bits |
+---------------------------------+------------------+------------+
| subnet prefix | 1111110111...111 | anycast ID |
+---------------------------------+------------------+------------+
| interface identifier field |

For other IPv6 address types (that is, with format prefixes other than those listed above), the interface identifier is not in EUI-64 format and may be other than 64 bits in length; these reserved subnet anycast addresses for such address types are constructed as follows:

| n bits | 121-n bits | 7 bits |
+---------------------------------+------------------+------------+
| subnet prefix | 1111111...111111 | anycast ID |
+---------------------------------+------------------+------------+
| interface identifier field |

The document is RFC 2526 and is in the IETF's Standards Track.
 
 

PROPOSED TLA AND NLA ASSIGNMENT RULES Author: Hinden

This document proposes rules for Top-Level Aggregation Identifiers (TLA ID) and Next-Level Aggregation Identifiers (NLA ID) as defined in [AGGR]. These proposed rules apply to registries allocating TLA ID's and to organizations receiving TLA ID's. TLA ID's were to be assigned to organizations providing transit topology. The first stage of allocation was proposed to allocate a Sub-TLA ID. When the recipient had demonstrated that they have assigned more than 90% of the NLA ID for their Sub-TLA ID, they will be allocated a TLA ID.

This proposal is intended as input from the IPng working group to the IANA and Registries. The document was superceded by a different proposal from the Regional Internet Registries. This document is and informational RFC: RFC 2450.

Section 2: Impacts on Addressing of New Technologies

IP MOBILITY ARCHITECTURE FRAMEWORK Authors: Becker, Patil, Qaddoura

This document identifies several drivers that provide input for an IP Mobility based network and also describes a high level IP Mobility architecture that extends the current third generation IMT2000 wireless architecture and builds on Mobile IP concepts. The document discusses the evolution of today's access strategyes -- including TDMA, CDMA and GSM -- and suggests that, as heterogeneous networks evolve, the mobility management provided by those netowrks must also evolve to ensure seamless roaming between the networks. Since the networks of the futre will be build on top of packet switched technology, the document also discusses the role of addressing and address mapping in those new networks. The document is currently an Internet Draft and is a work in progress.
 
 

3G WIRELESS DATA PROVIDER ARCHITECTURE USING MOBILE IP AND AAA Author: (editied by) Hiller

This draft specifies a third generation wireless architecture that is consistent with the requirements set by the International Telecommunications Union (ITU) for International Mobile Telecommunications 2000 (IMT-2000)systems. IMT-2000 systems will provide wireless voice, high speed data, and multimedia services. This draft has been developed by the Telecommunications Industry Association (TIA) Standards Subcommittee TR45.6. As a guiding principle this draft has leveraged the use of RFCs and Internet drafts wherever possible, including Mobile IP and AAA. A network reference model is provided, along with a set of more detailed requirements. The document suggests that Mobile IP services will support both statically and dynamically assigned home addresses. A mobile may indicate a request for a dynamic home address assignment in the Mobile IP RRQ, or a mobile may indicate a static address. Home addresses may be public or private. The document is currently an Internet Draft and is a work in progress.
 
 

PRIVATE ADDRESSES IN MOBILE IP Authors: Perkins, Montenegro, Calhoun

The document discusses the use of possibly non-unique private addresses (i.e., addresses that are not globally routable in the internet) for mobile nodes, foreign agents, or home agents is not handled by RFC 2002. Full-scale deployment of Mobile IP would benefit from an ability to provide mobility across differing address spaces, sometimes called "realms", especially because corporate networks often use private address spaces. It also specifies changes to enable Mobile IP to handle such addresses. The document is currently an Internet Draft and is a work in progress.
 
 

NAI RESOLUTION FOR WIRELESS NETWORKS Authors: Aravamudhan, O'Brien, Patil

RFC 2486 defines the need of a standardized format for identifying ISP subscribers for dial-up roaming operations. It introduced the Network Access Identifier (NAI) to fulfill this need. The NAI is provided by the mobile node to the dialed ISP during PPP authentication. The ability to resolve an NAI for second and third generation cellular mobile nodes allow traditional cellular service providers to evolve their home cellular networks to provide cellular services, IP packet data services and so on with a single subscription using NAIs. Additionally, this allows cellular provider to evolve their networks to be IP based. Second and third generation cellular mobile nodes must perform a registration and authentication process with their wireless service provider before the mobile node user may initiate other operations . These mobile nodes do not support the programming of an NAI nor does the cellular registration message support the transfer of an NAI to the wireless access network. For example, North American cellular networks (e.g. AMPS, TDMA, CDMA) service mobiler nodes that register with a Mobile Identification Number (MIN). The MIN is then associated with a cellular subscriber. MIN is shown here only as an example, the same general idea is applicable to other types of identifiers used in different access network types. It would be convenient if an option was available to provide the wireless subscriber identification in the form of an NAI during the wireless registration and authentication process. This document proposes a solution to resolve NAIs from traditional mobile node identifiers. The document is currently an Internet Draft and is a work in progress.
 
 

EURESCOM P909 CONTRIBUTION TO PINT AND SPIRITS INTERACTION BETWEEN INTERNET AND PSTN TO REQUEST SERVICES FROM ONE DOMAIN TO THE OTHER

Date: February 2000

This document is intended to provide input to the IETF SPIRITS Working Group (SPIRITS WG) and to the IETF PINT Working Group (PINT WG) from the viewpoint of European network operators that are involved in EURESCOM P909 Project "Enabling Technologies for IN Evolution and IN-Internet Integration". The input is based on current results that were achieved in the project. As the project title says P909 project deals with IN-Internet integration issues. The project has defined an architecture for IN-Internet inte gration and it has selected and described some IN-Internet services which can be interesting from the business perspective and challenging from the technical perspective. Some of these services are "officially" chartered in IETF: ICW in SPIRITS, Click-to-Dial (Request to Call) as well as proposed Conference Service in PINT. However, there are additional IN-Internet convergence services that P909 studies and that are included in this document only as examples. Selected services can help in defining requirements both in the context of how services supported by IP network entities can be started from IN (Intelligent Network) requests and how Internet applications can request and enrich PSTN (Public Switched Telephone Network) telephony services. Section 2 and 3 of the document provides some general information on the EURESCOM and P909 project. The document is currently an Internet Draft and is a work in progress.
 
 

TELECOMMUNICATIONS AND INTERNET PROTOCOL HARMONIZATION OVER NETWORKS: NUMBERING Author: ETSI

This document discusses numbering and addressing schemes -- along with required functionality -- for TIPHON compliant networks. Four options are discussed: calls from IP-based terminals to terminasl in a switched network; from terminals in a switched network to IP-based terminals; from terminals in switched networks through IP-based networks; and finally from terminals in IP-based networks through the switched networks. The document describes the naming and numbering schemes needed within the network to identify users and terminals in either IP- based networks or switched networks.
 
 

TECHNICAL SPECIFICATION GROUP SERVICES AND SYSTEM ASPECTS: ADVANCED ADDRESSING Author: 3rd Generation Partnership Project

This document identifies the kep features of UTMS' advanced addressing scheme and requirements for numbering and addressing in UTMS. The document describes examples of directory, application and translations mechanisms that would be built on the addressing strategy. A key requirement is the need for UMTS users to be able to internetwork with users in legacy environments. This requirements document is being used to develop a proposal for advanced addressing and numbering systems for UTMS. The document also discusses the need for address translation capabilities across transport gateways.
 
 

GLOBAL CIRCULATION OF IMT-2000 TERMINALS Author: European Radiocommunications Committee

This report considers the need for global circulation of IMT-2000 terminal equipment and how support for administrative, addressing and policy issues would be managed in such an environment. In addition to discussing the physical layer for transport, the paper discusses administrative mechanisms for supporting global roaming of IMT-2000 terminals. Global roaming requires terminal identification and the ability to pass identity and addressing information from one provider to another. This report considers mechanisms for supporting a variety of terminal types in heterogeneous networks.
 
 

THE FUTURE MOBILE MARKET Author: UMTS Forum

This report assesses the anticipated future market for mobile multimedia services as well as mobile voice and data services. The report has been updated since an original study in 1997 that includes projected growth in mobile users and satellite traffic. In particular it suggests that there will be 426 million users of terrestrial mobile services by the end of this year, 940 million by 2005 and more than 1.7 billion by 2010. It is also projected that there will be 190 million physical mobile users in North America by 2005, rising to 220 million by 2010. The report predicts that there will be 400 million physical mobile users in the Asia Pacific region by 2005. The Western European marketplace will see total traffic levels of 63 Terrabytes/month.
 
 

A PROPOSAL FOR THE PROVISIONING OF PSTN INITIATED SERVICES RUNNING ON THE INTERNET Author: Buller

This Internet Draft has arisen out of work concentrating on the interconnection of IP and the Public Switched Telephone Network (PSTN) undertaken within the PINT working group. Efforts within this group have, to date, concentrated on the initiation of PSTN services from the Internet. This Internet Draft aims to describe a possible architecture for th implementation of services initiated from the PSTN such as, but no limited to, Internet Call Waiting (ICW). It also identifies th possibility of using this class of service, in conjunction with the PINT work already undertaken, in order to provide a third flavour of service. The proposal suggests that the schemes for translating Calling Line Identity into actual locations (through translations of addresses or other schemes) is a protocol or profile that would arise out of future work. The document is currently an Internet Draft and is a work in progress.

Two documents from a recent ITU-T SG11 meeting in Geneva, March 1-19, 1999 also address the interconnection of IP and the Public Switched Telephone Network: INIP_arch.doc (MS-Word) http://www.bell-labs.com/mailing-lists/pint/INIP_arch.doc describes the IN functional architecture in support of PINT and IP telephony services; INIP-flows.doc (MS-Word) available at: http://www.bell-labs.com/mailing-lists/pint/INIP_flows.doc describes the message flows for click-to-dial, click-to-fax, and Internet call waiting services.
 
 

ENUM REQUIREMENTS Author: Brown

This paper defines the requirements for a DNS-based architecture and protocols for mapping a telephone number to a set of attributes (e.g., URLs) which can be used to contact a resource associated with that number. There are many possible protocols that can be considered for a telephone number mapping service. The purpose of this document is to focus discussion on a DNS-based rather than an address-to-address sytle solution. The document is currently an Internet Draft and is a work in progress.
 
 

URLS FOR TELEPHONE CALLS Author: Vaha-Sipila

This document specifies URL (Uniform Resource Locator) schemes ''tel'', ''fax'' and ''modem'' for specifying the location of a terminal in the phone network and the connection types (modes of operation) that can be used to connect to that entity. This specification is intended to cover voice calls (normal phone calls, answering machines and voice messaging systems), facsimile (telefax) calls and data calls, both for POTS and digital/mobile subscribers. The proposal is currently an Internet Draft and is a work in progress.
 
 

E.164 RESOLUTION Author: Brown

This paper addresses global access to address information and additional subscriber and equipment information, given a telephone number as input. The proposal uses a directory structure to provide clients with the ability to access directory information, given only a telephone number. The directory is structured according to the E.164 numbering plan, with each node in the tree representing a single digit of an E.164 telephone number. Given a telephone number, an LDAP or DNS query can pinpoint an entry in the global tree. This structure allows Information Consumers to retrieve information without having to perform a global search for a telephone number and without having to understand different numbering plan structures. The proposal is currently an Internet Draft and is a work in progress.

Section 3: General and Tutorial documents

UNDERSTANDING IP ADDRESSING: EVERYTHING YOU EVER WANTED TO KNOW Author: Chuck Semeria

This paper is a tutorial on IP Addressing in the public Internet. In discusses Internet scaling problems, the difrference between historical, classful addressing and CIDR, subnetting, routing and route aggregation, control of the growth of routing tables, how routing works in a classless environment, and strategies for address conservation that appeared in the late 1990's. The document is intended primarily as a tutorial.
 
 

GENERAL PACKET RADIO SERVICE Author: Peter Ryavvy

This report is a description of packet based mobile transports that support IP. GPRS will operate at higher speeds than current mobile networks provide and, as a result, is an important development for mobile data networks. GPRS supports direct IP access where a customer makes a circuit-switched call but rather than switching the cal into the public switched fabric, the carrier that terminates it at a router that is connected to the public Internet. The potential requirements for addressing in the GPRS environment are discussed as well as a timeline for deployment of the technology.

DOCUMENT VERSION

This is version one of this bibliography, February 2000.

CONTACT INFORMATION

This document was compiled by Mark McFadden, Commercial Internet eXchange, Herndon, Virginia. Any errors or ommissions are my responsibility and corrections, suggestions, and proposals for further contributions are welcomed by the editor:

Mark McFadden mcfadden@cix.org PO Box 7102 Madison, Wisconsin 53707-5707 US