Dedicated to preserving the central
coordinating functions of the global
Internet for the public good.
Abuse Issues and IP Addresses
Introduction
The IANA receives many reports of spam, apparent hacker activity,
and other forms of abuse. Most frequently, people make these reports
because they have found an Internet address associated with the abusive
activity, and through a bit of research, they find the IANA's name
associated in some way with that address.
In virtually all such cases, the association of the IANA's name with
a particular address is not actually useful in dealing with the abuse
incident. The IANA is not an ISP, and it has absolutely no control
over the use of any Internet Protocol (IP) addresses except the very
few that are directly tied to the iana.org domain name.
This document was written to clear up the confusion concerning IANA's
role, and also to provide some pointers that may be useful in actually
resolving abuse cases. The document is organized as follows:
The
IANA's Role in the Internet
The word "authority" in the IANA's name is perhaps a bit misleading:
it means that the IANA keeps authoritative records concerning various
numbers for other organizations; the choice of what goes into these
records is determined by a variety of engineering and other considerations.
The IANA serves as a bookkeeper in recording the assignments that
are made. In Internet terminology, the record-keeping service IANA
performs is called a registration service, and IANA serves
as a registry.
In addition to IP addresses, IANA also serves as a registry for a
variety of Protocol Numbers (see <http://www.iana.org/numbers.html> and several
other kinds of names and identifiers.
It is important to realize that IANA is not an ISP in any way, and
it does not provide any network services to any end
users or organizations. It does not control the use of any of the
numbers it records, nor, in general, does it have the authority to
change the values it records.
Background
Information on IP Addresses
Structure
of IP Addresses
IP addresses are numbers. Currently there are two types of IP addresses
in active use: IP version 4 (IPv4) and IP version 6 (IPv6). IPv4 was
initially deployed on 1 January 1983 and is still the most commonly
used version.
IPv4 addresses are 32-bit numbers that range from 0 to 4,294,967,295.
They are almost never used or seen in that form. Instead, they are
usually represented by the familiar "dotted decimal" notation,
with four decimal numbers separated by periods, for example, 192.168.0.1
or 10.0.250.252. Each individual number in a dotted decimal ranges
in value from 0 to 255, and thus, in dotted decimal notation, IP addresses
range from 0.0.0.0 to 255.255.255.255.
Given that there are over 4 billion individual IPv4 addresses, in
many circumstances it is impractical to deal with them individually,
and instead one deals with ranges (or "blocks") of IPv4 addresses.
For example, one may be interested in the range of 256 IPv4 addresses
from 192.168.51.0 to 192.168.51.255.
Deployment of the IPv6 protocol began in 1999. IPv6 addresses are
128-bit numbers and are conventionally expressed using hexadecimal
strings (for example, 1080:0:0:0:8:800:200C:417A).
Allocation
of IP Addresses
The IANA maintains a high-level registry of IP addresses. It works
with the Regional Internet Registries (RIRs) to distribute the large
blocks of IP addresses among the RIRs. There are currently 4 RIRs,
distributed around the world: APNIC (Asia/Pacific Region), ARIN (North
America and Sub-Sahara Africa), LACNIC (Latin America and some Caribbean
Islands), and RIPE NCC (Europe, the Middle East, Central Asia, and
African countries located north of the equator). (A fifth regional
registry is in formation for Africa.)
The RIRs are the organizations that actually allocate IP addresses
to ISPs. These allocations are in smaller blocks of addresses. The
IANA web page "Internet Protocol v4 Address Space"
documents how the IPv4 address space is distributed among the RIRs.
Many of the IP address blocks in the IANA's registry are allocated
to the RIRs. For example, consider the following line from the page
referenced above:
068/8 Jun 01 ARIN (whois.arin.net)
This means that the IP address block of 68.0.0.0 - 68.255.255.255
was allocated to ARIN in June 2001. If you are having problems with
an IP address that is part of this block, you should go to ARIN's
Whois at "whois.arin.net" (see below for details) to find
out to whom the IP address has been assigned.
The IANA keeps the above high-level list for all of the IPv4 addresses.
This includes (a) IP addresses that have been allocated to a
RIR or other user, (b) those that are reserved for a special use,
and (c) those that have not yet been allocated by the IANA and are
reserved for future allocation and use.
Special-use IP addresses are assigned to the IANA so that they are
reserved for the special use on behalf of the Internet community.
This DOES NOT mean that the special-use addresses are "used" by the
IANA (see further explanation below).
IP addresses that are unallocated are also registered to the IANA
to indicate that they may be allocated by the IANA in the future.
Only a very small block of IPv4 addresses (192.0.32.0 to 192.0.47.255)
has been "assigned" to the IANA for its use. Only Internet traffic
from this range actually originates from the IANA's own network.
Special-Use
Addresses
Several address ranges are reserved for "Special Use". These addresses
all have restrictions of some sort placed on their use, and in general
should not appear in normal use on the public Internet. The following
briefly documents these addresses in general they are used
in specialized technical contexts. They are described in more detail
in RFC 3330.
- "Private Use" IP addresses:
10.0.0.0 - 10.255.255.255
172.16.0.0 - 172.31.255.255
192.168.0.0 - 192.168.255.255
The above address blocks are reserved for use on private networks,
and should never appear in the public Internet. There are hundreds
of thousands of such private networks (for example home firewalls
sometimes make use of them). The IANA has no record of who uses
these address blocks. Anyone may use these address blocks within
their own network without any prior notification to IANA.
The point of private address space is to allow many organizations
in different places to use the same addresses, and as long as
these disconnected or self-contained islands of IP-speaking computers
(private intranets) are not connected, there is no problem. If
you see an apparent attack, or spam, coming from one of these
address ranges, then either it is coming from your local environment,
or the address has been "spoofed".
The Private addresses are documented in RFC 1918. If you
have further questions about RFC 1918 usage, please contact your
ISP.
- "Autoconfiguration" IP Addresses:
169.254.0.0 - 169.254.255.255
Addresses in the range 169.254.0.0 to 169.254.255.255 are used
automatically by some PCs and Macs when they are configured to
use IP, do not have a static IP Address assigned, and are unable
to obtain an IP address using DHCP.
This traffic is intended to be confined to the local network,
so the administrator of the local network should look for misconfigured
hosts. Some ISPs inadvertently also permit this traffic, so you
may also want to contact your ISP. This is documented in RFC 3330.
- "Loopback" IP addresses:
127.0.0.0 - 127.255.255.255
Each computer on the Internet uses 127.0.0.0/8 to identify itself,
to itself. 127.0.0.0 to 127.255.255.255 is earmarked for what
is called "loopback". This construct allows a computer to establish/validate
its IP stack. Most software only uses 127.0.0.1 for loopback purposes
(the other addresses in this range are seldom used). All of the
addresses within the loopback address are treated with the same
levels of restriction in Internet routing, so it is difficult
to use any other addresses within this block for anything other
than node specific applications, generally bootstraping. This
is documented in RFC 3330.
- "Unallocated" IP addresses:
The IPv4 Address Registry
and the Whois use the word unallocated (sometimes "reserved")
to mean that the addresses are reserved for future allocation.
No one should be using these addresses now. These addresses will
be assigned for use in the public Internet in the future. If addresses
are needed for private networks then the private-use addresses
mentioned above should be used.
- Multicast IP addresses:
224.0.0.0 - 239.255.255.255
Addresses in the range 224.0.0.0 to 239.255.255.255 are set aside
for the special purpose of providing multicast services in the
Internet. (Multicast services allow a computer to send a single
message to many destinations.) Various addresses in this range
are used by routers and others are used by hosts that are listening
to multicast sessions.
These addresses are available for any host that wants to participate
in multicast, and typically are assigned dynamically. The source
address should not be multicast (without prior agreement). The
destination address may be multicast. For technical background
information please see RFC 1112 and RFC 2236.
Hints
for Finding a Person Responsible for a Given IPv4 Address
If you encounter an IPv4 address that does not fit any of the above
categories, researching the various information sources to find a
person responsible for an IP address may be a challenge. Moreover,
even if such a person is found, they may well be halfway around the
world, and not share your language or your legal system. Nonetheless,
it may be worth the effort to try. This section outlines the procedure
one should follow in finding the contact information for a responsible
person.
Step 1 - Look up the IP address in the Regional Internet Registries
(RIRs) "whois" servers.
By using the "Whois" service, look up the IP address in all five
Regional Internet Registries or RIRs.
If one of the RIR's Whois does not have information about the IP
address you are inquiring about, try the others.
If the RIR Whois says the IP address is registered to the IANA, make
sure you try the other RIRs to verify that they also say the IP addresses
are registered to the IANA. (Some of the RIRs database may not have
caught the latest delegations to other RIRs).
Step 2 - If all RIRs list an address as assigned to the IANA,
you should check to see if this address is for "Special Use" or if
it is "Unallocated" ("Reserved").
If the address that you are inquiring about does not
have contact information in one of the RIRs, is not mentioned in the
explanations above, or you have further questions, please send an
e-mail to abuse-filter@iana.org so that we may look into the problem
further.
See below for additional information about fabricated IP addresses
and the blackhole servers.
Fabricated
(or "spoofed") IP addresses
It is quite possible that an IP address in an e-mail header could
be fabricated.
E-mail protocols are not secure and anyone with the minor technical
skills necessary can forge any part of an e-mail. Forgeries generally
are trivial to identify. The IANA cannot locate the individuals who
forge e-mail headers. In fact, return addresses can be spoofed right
down to the packet level. (Just like in postal mail, one can put pretty
much anything as a return address, but if there is a problem with
the "to" address, the letter can't be delivered.) IP addresses can
be spoofed in protocols other than e-mail, as well.
FAQ on "Blackhole
Servers"
Please see the following 8 questions/answers for information regarding
the "blackhole" servers:
Q1: What are the blackhole servers?
A1: The "blackhole" Servers, "blackhole-1.iana.org" and "blackhole-2.iana.org",
are an obscure part of the Internet infrastructure. People are sometimes
puzzled or alarmed to find unexplained references to them in log
files or other places. This FAQ tries to explain what these servers
do, and why you may be seeing them. Specifically, these servers
are part of the Domain Name System (DNS), and respond to inverse
queries to addresses in the the reserved RFC 1918 address ranges:
10.0.0.0 - 10.255.255.255
172.16.0.0 - 172.31.255.255
192.168.0.0 - 192.168.255.255
See: RFC 1918
These addresses are reserved for use on private intranets, and
should never appear on the public internet. The 192.168.0.0 addresses
are especially common, being frequently used in small office or
home networking products like routers, gateways, or firewalls.
Q2. What is "prisoner"
A2. "prisoner" is a blackhole server.
Q3: What are "inverse queries?
A3: With normal ("forward") queries the domain-name system responds
with an address (e.g., "192.0.34.162") when given a name are (e.g.,
"www.iana.org"). Inverse ("reverse") queries do the reverse
the domain name system returns the name ("www.iana.org") when given
the address ("192.0.34.162"). While inverse queries are rare from
a human perspective, some network services automatically do an inverse
lookup whenever they process a request from a particular IP address,
and consequently they form a significant part of DNS network traffic.
Q4: Why do we need the blackhole servers?
A4: Strictly speaking, we don't need the blackhole servers. However,
DNS clients will sometimes remember the results from previous queries
(that is, "good" answers to queries are cached), and the blackhole
servers are configured to return answers that DNS clients can cache.
This allows the clients to rely on their cached answers, instead
of sending another query, which in turn reduces the overall amount
of traffic on the Internet. Since the RFC 1918 addresses should
never be used on the public Internet, there should be no names in
the public DNS that refer to them. Hence, an inverse lookup on one
of these addresses should never work. The IANA blackhole servers
respond to these inverse queries, and always return an answer that
says, authoritatively, that "this address does not exist". Because
of the caching noted above, this is far better than simply not responding
at all, so the blackhole servers are provided as a public service.
Q5: How busy are the blackhole servers?
A5: While rates vary, the blackhole servers generally answer thousands
of queries per second. In the past couple of years the number of
queries to the blackhole servers has increased dramatically. It
is believed that the large majority of those queries occur because
of "leakage" from intranets that are using the RFC 1918 private
addresses. This can happen if the private intranet is internally
using services that automatically do reverse queries, and the local
DNS resolver needs to go outside the intranet to resolve these names.
For well-configured intranets, this shouldn't happen. Users of private
address space should have their local DNS configured to provide
responses to inverse lookups in the private address space.
Q6: But it looks like the blackhole servers are attacking my network/host.
Could it be that a hacker has taken over the servers, and is attacking
other systems?
A6: No system is totally safe from hackers, and the blackhole
servers are no exception. However, the effect you are seeing very
likely has another cause. Because of their special function, there
are a number of reasons why the blackhole servers may appear in
your logs or elsewhere that have nothing to do with hacking. DNS
configuration, especially in an environment where the RFC 1918 addresses
are being used, can be tricky. Firewall configurations can make
things even more complicated. If, for example, your system is configured
to allow all outgoing packets, but to block most incoming packets,
then it may be that your DNS client is in fact sending inverse queries
to the blackhole servers, but blocking (and logging) the returning
answers.
It is also true that other activities of hackers can make the blackhole
servers show up in your logs. It is possible to construct network
packets with forged source addresses that are in the RFC 1918 ranges.
A hacker, for example, could construct a packet that appears to
come from 192.168.35.35 and send it to your network. Sometimes there
are large-scale denial-of-service attacks that use a flood of such
"spoofed" packets. The result might be a large number of queries
coming to the blackhole servers, which may themselves be overloaded
with query traffic. Under conditions of heavy load, the servers
may drop packets, and not respond correctly to some queries. This
may cause odd messages to appear in the error logs of either the
attacking or the attacked host. (In large scale "distributed denial
of service" attacks, many systems are taken over by hackers, and
these systems are used to attack some victim. The owners of the
attacking systems may not even be aware that they have been taken
over by a hacker.)
Q7: OK, maybe you aren't attacking me. What can I do about the
messages in my logs?
A7: The best way solve this problem is to set up DNS on your local
network. Unfortunately, this can be complicated, and may not in
practice be possible. If you are using operating systems from Microsoft,
you might want to look at <http://support.microsoft.com/default.aspx?scid=kb;EN>.
(Please note that the blackhole servers used to be located at isi.edu).
Q8: Is there anything more than just logs at issue?
A8: Possibly. But you should make every effort to fix the problem
from your end, because episodes of overload to the blackhole servers
are becoming more common, and that can have more serious consequences.
See, for example, <http://www.shmoo.com/mail/fw1/apr99/msg00946.html>.
[Thanks to Ed Bennet for input on Q7 and Q8.]
Please send comments on this web site to: webmaster@iana.org
Page Updated
17-Oct-2005
Copyright © 2005 The Internet Corporation
for Assigned Names and Numbers. All rights reserved.
|