INTERNIC IP ALLOCATION GUIDELINES FOR INTERNET SERVICE PROVIDERS
Learn about the Hubs and Spokes Internet Infrastructure, International bandwidth, international traffic.
The InterNIC Registry, under the authority of the Internet Assigned Numbers Authority, allocates blocks of IP address space to Internet Service Providers (ISP) for the purpose of using that space with their customers.
ISPs and others not located in the InterNIC's geographical area of responsibility should contact their appropriate Regional Registry for information on how to obtain IP addresses. The following is a list of Regional Registries and National NICs that have authority to allocate
IP addresses: Other Regional Registries
RIPE NCC (European Registry) firstname.lastname@example.org
APNIC (Asia Pacific Registry) email@example.com
InterNIC Delegated Registries within the Americas
CA*net (Canadian NIC) firstname.lastname@example.org
RNP (Brazilian Registry) email@example.com
Classless Interdomain Routing (CIDR)
ISPs are encouraged to request address space from their upstream provider. It must be noted that the upstream provider maintains control of the allocated block unless explicitly and contractually stated otherwise. CIDR blocks may be allocated directly from the InterNIC if preferred.
The following guidelines have been established in an attempt to allocate address space to ISPs in a way that is fair and addresses the issues of router table growth, route flapping (which is proportional to the number of route entries), and IP address preservation. This document also details procedures that must be followed by ALL IP resellers receiving address space which is then leased to their customers.
DNS Security Extensions (DNSSEC)
The industry bodies responsible for the root servers that underpin the Internet have claimed success in implementing its DNS Security Extensions (DNSSEC) to the last clusters. The deployment is the final step before implementing the security required to prevent DNS cache poisoning attacks on Internet addresses.
Six deployments in total were made to the Internet's 13 root server clusters, beginning 27 January this year, with the final root server dubbed "J-Root" receiving the fix between 5pm and 7pm UTC on 5 May (3am-5am AEST on 6 May). The fix enables the cluster to begin serving a Deliberately Unvalidatable Root Zone (DURZ), which would eventually enable the ability to serve signed addresses. The industry bodies involved, ICANN and Verisign, expect to distribute signed keys through the servers on 1 July. According to a post on the Root DNSSEC website, "no harmful effects have been identified" following the transition.
The move toward extra security for DNS root servers comes two years after renowned security expert, Dan Kaminsky, exposed flaws in the DNS system, allowing would-be hackers to divert top-level domains to another IP address instead of the intended one. While network engineers rushed to patch their servers against the expert's proof-of-concept Kaminsky bug in the year following its exposure, the short-term patch did not fully resolve the issue around DNS cache poisoning. The security flaw potentially allows hackers to redirect browsers to another IP address when a domain name is entered, as well as possibly subverting email as well, according to some security professionals. Mark Newtown Internode network engineer said potential melt-downs surrounding the DNSSEC deployment problems would most likely be due to ageing firewalls and modems. Many top-level domains are yet to commit to DNSSEC signatures. Global top-level domains like .org and .edu are expected to comply by June, with .net in December. Verisign has said it will ensure the most popular domain, .com, is signed under DNSSEC regulations by March next year.
Due to technical and implementation constraints on the Internet routing system and the possibility of routing overload, certain policies may need to be enforced by the major transit providers in order to reduce the number of globally advertised routes. These potential policies may include setting limits on the size of CIDR prefixes added to the routing tables, filtering of non-aggregated routes, etc. Therefore, addresses obtained directly from the InterNIC (non-provider-based, also known as portable) are not guaranteed to be routable on the Internet.
If connectivity across the Internet is to be maintained, follow these steps when requesting address space:
a) Ask your provider;
b) Ask your provider's provider;
c) Ask the InterNIC registry as a last resort.
Again note that addresses issued directly from the InterNIC,(non- provider based), are the least likely to be routable across the Internet.
ISPs requesting address space from the InterNIC are required to complete the IP template reserved for ISPs. The template can be found via rs.internic.net as /templates/isp-ip-template.txt.
URL = ftp://rs.internic.net/templates/isp-ip-template.txt
Any request judged to be lacking sufficient details will be returned to the requestor for additional information.
In an effort to ensure that CIDR is implemented and utilized as efficiently as possible, the InterNIC Registry issues blocks of addresses on appropriate "CIDR-supported" bit boundaries. Network Providers will also need to be aware of the procedures that define bit boundary IP address allocation, and utilize these procedures when assigning IP address space to their respective customers. It is also recommended that providers make classless assignments whenever possible.
The following documents contain important information related to CIDR:
RFC 1482 - Aggregation Support in the NSFNET Policy-Based Routing Database
RFC 1517 - Applicability Statement for the Implementation of Classless Inter-Domain Routing
RFC 1518 - An Architecture for IP Address Allocation with CIDR
RFC 1519 - Classless Inter-Domain Routing (CIDR) : an Address Assignment and Aggregation Strategy
RFC 1520 - Exchanging Routing Information Across Provider Boundariesin the CIDR Environment
Determination of CIDR block allocation size is the responsibility of the InterNIC, this allocation is based on the ISP's 3 - 6 month requirement and other information the InterNIC deems necessary. Please note that the allocations are not based solely on a predicted customer base.
Initial allocations will be relatively small. Subsequent allocated blocks may be increased based on utilization verification supplied to the InterNIC.
Subsequent allocations of CIDR block addresses will be based on need; this need will be demonstrated based on the number of assignment actions that have been transmitted to the InterNIC Registry. Assignment information is to be forwarded to the InterNIC within 7 days of the assignment so that the WHOIS may be maintained efficiently.
Transmission of assignment information is also necessary for the following reasons:
a) To ensure that a provider has exhausted, or is about to exhaust its current CIDR allocation such that an additional allocation is justified.
b) To allow operational people to see which organization is using the assigned address space and whom to contact in the event of operational/security problems, etc.
c) To assist in the IP allocation studies.
There are two options available for tracking assignment information:
1) Shared WHOIS Project (SWIP)
Assignment actions can be submitted by utilizing the database exchange format defined by the SWIP project. Information regarding SWIP may be obtained via anonymous FTP from rs.internic.net.
The files may be found under the /pub/swip directory.
[ URL = ftp://rs.internic.net/pub/swip ]
RWhois is a distributed database for hierarchical information. Information on RWHOIS can be found at rs.internic.net, ftp/pub/rwhois.
[ URL = ftp://rs.internic.net/pub/rwhois ]
ALL ISPs, regardless of where they receive their CIDR blocks should either SWIP the assignment information or establish an RWHOIS server. If SWIP is the chosen method, ISPs should register with the InterNIC as an ISP to receive a maintainer ID necessary to SWIP the assignment information.
ISPs are required to assign address space based on utilization efficiency. To this end, ISPs should have documented justification available for each assignment. The InterNIC may at any time ask for this justification. If not available, this could impact future allocations.
Any ISP whose customer has a requirement of /18 bits or less ( >= 64 Class C's) should forward the template to the InterNIC for review. The following information should accompany the standard IP template:
a) Network engineering plans, including subnets and host counts, and hosts per subnet with projected utilization rates and associated confidence levels of those projections for one and two years in the future.
b) Deployment schedule for the network, including major milestones for each subnet.
c) Network topology diagrams.
All ISPs receiving /16 bits or less (>= 256 Class C's) from the InterNIC will be responsible for maintaining all IN-ADDR.ARPA domain records for their respective customers. The ISP will then be responsible for the maintenance of IN-ADDR.ARPA domain records of all longer prefixes that have been delegated out of that block.
EARTHLINK SAYS IT WON'T INSTALL DEVICE FOR FBI:
Major Internet service provider EarthLink says it has rejected the FBI's attempt to install Carnivore, the bureaus' new sophisticated surveillance device, on its network due to privacy concerns and service disruptions it causes. EarthLink executives pledged to provide help when possible to authorities in criminal investigations, but said installing Carnivore would force technical adjustments that could bring part of its network down and affect service for thousands of customers. The ISP also claims that Carnivore poses large liability issues for it because there is no way to determine whether Carnivore's monitoring is limited to the criminal investigation, or is practicing a less discreet surveillance.
Edupage, 14 July 2000 (Wall Street Journal, 2000 July 14)