The following Annotated Bibliography on Addressing Trends, Standards and Drivers is Appendix A to the report prepared by Mark McFadden and Tony Holmes of the Ad Hoc Group on Numbering and Addressing. Annotated Bibliography on Addressing Trends, Standards and Drivers February, 2001
February 2001, version 4 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 describe 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 fourth version of the document. TABLE OF CONTENTS The document is divided into sections:
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 omissions are my responsibility and corrections, suggestions, and proposals for further contributions are welcomed by the editor: Mark McFadden PO Box 7102
ISP GUIDELINES FOR REQUESTING INITIAL IP
ADDRESS SPACE 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 receive 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 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 registry concept and the procedures for becoming a local registry in RIPE's area of responsibility.
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 assignments 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 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 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.
IANA GUIDELINES FOR IPv4 MULTICAST ADDRESS
ALLOCATION This document is an expansion of RFC 2780 and attempts to codify existing IANA practice used in the assignment of IPv4 multicast addresses. The document notes that "due to the relatively small size of the IPv4 multicast addresses space, further allocation of IPv4 multicast address space is not recommended. Specifically, the IANA should only assign addresses in those cases where the dynamic selection (SDP/SAP), GLOP, SSM or Administratively scoped address spaces cannot be used." The document goes on to identify allocation guidelines for the Local Network Control Block (224.0.0/24), the Internetwork Control Block (224.0.1/24), the AD-HOC Block (224.0.2.0/24), the SDP/SAP Block (224.2/16), the Source Specific Multicast Block (232/8) and the GLOP Block (233/8). The document is currently an Internet Draft and is a work in progress.
AN APPEAL TO THE INTERNET COMMUNITY TO
RETURN UNUSED IP NETWORKS (AND 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 This document provides the rationale and standards for private IPv4 address space. Specifically it carves out three CIDR blocks for use in private networks:
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 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 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:
The document is currently an Internet Draft and is a work in progress. the sixth version of this document was posted as an Internet Draft in February 2001.
INTERNET MULTICAST ADDRESS ALLOCATION ARCHITECTURE This RFC documents a multicast address allocation architecture (MALLOC) for the Internet that is intended to be generic enough to apply to both IPv4 and IPv6 environments. It uses an administrative scoping method (rather than globally valid addresses) which is documented in RFC 2365. The document describes three layers for the address architecture. First, a protocol or mechanism that a multicast client uses to request a multicast address from a multicast address allocation server (MAAS). Next, an intra-domain protocol or mechanism that MAAS's use to coordinate allocations to ensure they do not allocate duplicate addresses. Finally, an inter-domain protocol or mechanism that allocates multicast address ranges (with lifetimes) to Prefix Coordinators. The document is RFC 2908.
IP VERSION 6 ADDRESSING ARCHITECTURE 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. Editor's note (version 3):
AN IPV6 AGGREGATABLE GLOBAL UNICAST ADDRESS
FORMAT 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:
Where FP Format Prefix (001)
IPV6 TESTING ADDRESS ALLOCATION 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:
FP = 001 and TLA = 0x1FFE. The NLA is assigned by the 6bone administrator and the SLA is defined by the individual organization. The document is RFC 2471 and is on the IETF Standards Track.
IPV6 MULTICAST ADDRESS ASSIGNMENTS 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 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:
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:
The document is RFC 2526 and is in the IETF's Standards Track.
PROPOSED TLA AND NLA ASSIGNMENT RULES 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.
IPV6 ASSIGNMENT AND ALLOCATION POLICY DOCUMENT This document describes the registry system for distributing globally unique unicast IPv6 address space. Developed in concert by the Regional Internet Registries the document first describes the IPv6 address space as a distributed, hierarchical numbering space, managed by the IANA and further delegated by the Regional Internet Registries (Regional IRs) as described in RFC 1881 (see above). In the case of IPv6, the Regional IRs allocate Top-Level Aggregation Identifiers (TLAs) to organizations, which, as TLA Registries, in turn allocate or assign address space to other Internet Service Providers (ISPs) and end users. ISPs then serve as Next Level Aggregation (NLA) Registries for their customers. This document was the result of substantial coordinated effort by the regional registries in coordination with their members. After describing the IPv6 space the document goes on to describe the responsibilities, policies, and procedures associated with IPv6 address space management. The policies apply not just to the regional registries but to all organizations in the allocation hierarchy. The goal of the document is a clear description of the allocation policy and the roles of each organization that wishes to use IPv6.
IAB/IESG RECOMMENDATIONS ON IPv6 ADDRESS
ALLOCATIONS This document describes a series of recommendations
on IPv6 allocation The IAB suggests that the same type of rule could be used in the allocation of addresses in edge networks; if there is doubt whether an edge network will in turn be subnetted, the edge network might be encouraged to allocate the first subnet numbers as multiples of some power of 2, preserving room for further subnetting, up to a point, without renumbering. In fact, they recommend use of a fixed boundary between the private and the public IPv6 addressing topology. Their concrete recommendations are:
The document then presents arguments for the fixed boundary and a discussion of whether nr not giving a /48 to every subscriber represents a waste of address space. Editor's note: as of the third version of the bibliography the RIPE and APnic communities had agreed to the IAB/IESG recommendation. The proposal is still under discussion at ARIN. The document is currently an Internet Draft and is a work in progress.
DEFAULT ADDRESS SELECTION FOR IPv6 Implementation and transition to IPv6 requires that default address selection consider for IPv4 and IPv6 addresses in the event of dual-stack implementations. This document describes a pair of algorithms that specify address selection for all IPv6 implementations. The reason this is important is because the IPv6 addressing architecture (see above) allows multiple unicast addresses to be assigned to interfaces. The result is that IPv6 implementations will often find themselves faced with multiple source and destination address to choose from. What is needed are default algorithms, common across all applications, for selecting source and destination addresses. This document describes two such algorithms: one for source address selection and another for destination address selection. The document is currently an Internet Draft and is a work in progress.
FLEXIBLE METHOD FOR AN IPv6 ADDRESSING
PLAN This Internet draft suggests a proposed method that helps organisations develop addressing plans for IP addresses. The flexibility enables the organisation to postpone the final decision on the number of bits to partition in the address space they have. It does it by keeping the bits around the borders of the partition to be free as long as possible. This scheme is applicable to any bits addressing scheme using bits with partitions in the space, but it has special meaning in the context of IPv6 because the number of bits available to edge networks in the address space is yet to be resolved (see above). The document is an Internet Draft and is a work in progress.
6BONE pTLA AND pNLA FORMATS This memo defines how the 6bone uses the 3FFE::/16 IPv6 address prefix, allocated in RFC 2471, "IPv6 Testing Address Allocation", to create pseudo Top-Level Aggregation Identifiers (pTLA's) and pseudo Next-Level Aggregation Identifiers (pNLA's). According to the RFC: "The purpose of creating pseudo TLA and NLA formats for the 6bone is to provide a prototype of the actual TLA and NLA formats as they might be used in production IPv6 networks. To do this economically, using only a minimum of real production IPv6 address space, a single TLA, 3FFE::/16, was reserved by the IANA (Internet Assigned Numbers Authority) for testing on the 6bone. Thus it was necessary to define a pretend-to-be, or pseudo, TLA and NLA structure to use under the 3FFE::/16 prefix." Today the first 12-bits of the NLA ID space are assigned as the pTLA that defines the top level of aggegation (backbone) for the 6bone. This would eventually provide for 4096 6bone backbone networks, or pTLA-s, and leaves a 20-bit pNLA ID for each pTLA to assign as needed.
The remaining NLA ID space can be used by each pTLA for their downward aggregated delegation:
This document is in the Internet Standards track and is RFC 2921.
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 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 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 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 mobile 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 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: 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 terminals 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 This document identifies the key 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 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 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 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 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 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 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.
UNDERSTANDING IP ADDRESSING: EVERYTHING
YOU EVER WANTED TO KNOW This paper is a tutorial on IP Addressing
in the public Internet. In
GENERAL PACKET RADIO SERVICE 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.
IANA ALLOCATION GUIDELINES IN THE INTERNET
PROTOCOL SUITE This RFC discusses the guidelines for IANA allocation of fields in the IPv4, IPv6, ICMP, UDP and TCP protocol headers for which the IANA assigns values. With regard to addressing, the document codifies the allocation responsibilities for IP source and destination addresses, IPv4 unicast addresses, IPv4 multicast addresses, IPv4 reserved addresses, IPv6 source and destination addresses, IPv6 anycast addresses, as well as IPv6 multicast addresses. The document is in the standards track and is RFC 2780.
This is version four of this bibliography, February 2001. CONTACT INFORMATION This document was compiled by Mark McFadden, Commercial Internet eXchange, Herndon, Virginia. Any errors or omissions are my responsibility and corrections, suggestions, and proposals for further contributions are welcomed by the editor: Mark McFadden Questions concerning the layout, construction and functionality of this site should be sent to webmaster@icann.org. (c) 2000-2001 The Internet Corporation for Assigned Names and Numbers All rights reserved. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
