One document matched: draft-eastlake-xxx-03.txt
Differences from draft-eastlake-xxx-02.txt
INTERNET-DRAFT Donald Eastlake 3rd
Motorola
Declan McCullagh
CNet
Expires: May 2003 November 2002
.xxx Considered Dangerous
---- ---------- ---------
<draft-eastlake-xxx-03.txt>
Status of This Document
Distribution of this draft is unlimited. Comments should be sent to
the authors.
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026. Internet-Drafts are
working documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." The list
of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft
Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
Periodically there are proposals to mandate the use of a special top
level name or an IP address bit to flag "adult" or "unsafe" material
or the like. This document explains why this is an ill considered
idea.
D. Eastlake 3rd, D. McCullagh [Page 1]
INTERNET-DRAFT .xxx Considered Dangerous November 2002
Table of Contents
Status of This Document....................................1
Copyright Notice...........................................1
Abstract...................................................1
Table of Contents..........................................2
1. Background..............................................3
2. Legal and Philosophical Problems........................4
3. Technical Difficulties..................................6
3.1 Domain Name System (DNS) and Other Names...............7
3.1.1 Linguistic Problems..................................8
3.1.2 The DNS Hierarchy and Use of TLDs....................8
3.1.3 You Can't Control What Names Point At You!...........9
3.1.4 Particular Protocol Considerations..................10
3.1.3.1 Electronic Mail (SMTP)............................10
3.1.4.2 Web Access (HTTP).................................11
3.1.3.3 News (NNTP).......................................11
3.1.3.4 Internet Relay Chat...............................12
3.2 IP Addressing.........................................12
3.2.1 Hierarchical Routing................................13
3.2.2 IP Version 4 Addresses..............................14
3.2.3 IP Version 6 Addresses..............................14
3.3 PICS Labels...........................................15
4. Conclusions............................................15
References................................................16
Authors Addresses.........................................18
Full Copyright Statement..................................19
Expiration and File Name..................................19
D. Eastlake 3rd, D. McCullagh [Page 2]
INTERNET-DRAFT .xxx Considered Dangerous November 2002
1. Background
The concept of a .xxx, .sex, .adult, or similar top-level domain in
which it would be mandatory to locate salacious or similar material
is periodically suggested by some politicians and commentators. Other
proposals have included a domain reserved exclusively for material
viewed as appropriate for minors, or using IP address bits or ranges
to segregate content.
In an October 1998 report accompanying the Child Online Protection
Act, the House Commerce committee said "there are no technical
barriers to creating an adult domain, and it would be very easy to
block all websites within an adult domain." The report also said that
the committee was wary of regulating the computer industry and that
any decision by the U.S. government "will have international
consequences." [HOUSEREPORT]
British Telecom has backed adult top-level domains, saying in a 1998
letter to the U .S. Department of Commerce that it "strongly
supported" that plan. The reason: "Sexually explicit services could
then be legally required to operate with domain names in this gTLD
[that] would make it much simpler and easier to control access to
such sites..." [BT] One of ICANN's progenitors, the GTLD-MOU
committee, suggested a "red-light-zone" top-level domain in a
September 1997 request for comment. [GTLD-MOU]
Some adult industry executives have endorsed the concept. In 1998,
Seth Warshavsky, president of the Internet Entertainment Group, told
the U.S. Senate Commerce committee that he would like to see a .adult
domain. "We're suggesting the creation of a new top-level domain
called '.adult' where all sexually explicit material on the Net would
reside," Warshavsky said in an interview at the time. [WARSHAVSKY]
More recently, other entrepreneurs in the industry have said that
they do not necessarily object to the creation of an adult domain as
long as they may continue to use .com.
Conservative groups in the U.S. say they are not eager for such a
domain, and prefer criminal laws directed at publishers and
distributors of sexually-explicit material. The National Law Center
for Children and Families in Fairfax, Virginia, said in February 2001
that it did not favor any such proposal. For different reasons, the
American Civil Liberties Union and civil liberties groups also oppose
it.
Sen. Joseph Lieberman, the U.S. Democratic Party's vice presidential
nominee, endorsed the idea at a June 2000 meeting of the federal
Commission on Child Online Protection. Lieberman said in a prepared
statement that "we would ask the arbiters of the Internet to simply
abide by the same standard as the proprietor of an X-rated movie
theater or the owner of a convenience store who sells sexually-
D. Eastlake 3rd, D. McCullagh [Page 3]
INTERNET-DRAFT .xxx Considered Dangerous November 2002
explicit magazines." [LIEBERMAN]
In the 1998 law creating this commission, the U.S. Congress required
the members to investigate "the establishment of a domain name for
posting of any material that is harmful to minors." The commission
devoted a section of its October 2000 report to that topic. It
concluded that both a .xxx and a .kids domain are technically
possible, but would require action by ICANN. The report said that an
adult domain might be only "moderately effective" and raises privacy
and free speech concerns. [COPAREPORT]
The commission also explored the creation of a so-called red zone or
green zone for content by means of allocation of a new set of IP
addresses under IPv6. Any material not in one of those two zones
would be viewed as in a gray zone and not necessarily appropriate or
inappropriate for minors. Comments from commissioners were largely
negative: "Effectiveness would require substantial effort to attach
content to specific IP numbers. This approach could potentially
reduce flexibility and impede optimal network performance. It would
not be effective at blocking access to chat, newsgroups, or instant
messaging."
In October 2000, ICANN rejected a .xxx domain during its initial
round of approving additional top-level domains. The reasons are not
entirely clear, but former ICANN Chairwoman Esther Dyson said that
the adult industry did not entirely agree that such a domain would be
appropriate. One .xxx hopeful, ICM Registry of Ontario, Canada, in
December 2000 asked ICANN to reconsider its decision. [ICM-REGISTRY]
In 2002, the US Congress mandated the creation of a kids.us domain
for "child safe" material. This was after being convinced that, for
reasons some of which are described in the following section, trying
to legislate standards for the whole world with a .kids domain was
inappropriate.
2. Legal and Philosophical Problems
When it comes to sexually-explicit material, every person, court, and
government has a different view of what's acceptable and what is not.
Attitudes change over time, and what is viewed as appropriate in one
town or year may spark protests in the next. When faced with the
slippery nature of what depictions of sexual activity should be
illegal or not, one U.S. Supreme Court justice blithely defined
obscenity as: "I know it when I see it."
In the U.S.A., obscenity is defined as explicit sexual material that,
among other things, violates "contemporary community standards" -- in
other words, even at the national level, there is no agreed-upon rule
D. Eastlake 3rd, D. McCullagh [Page 4]
INTERNET-DRAFT .xxx Considered Dangerous November 2002
governing what is illegal and what is not. Making matters more knotty
is that there are over 200 United Nations country codes, and in most
of them political subdivisions can impose their own restrictions.
Even for legal nude modeling, age restrictions differ. They're
commonly 18 years of age, but only 17 years of age in one
Scandinavian country. A photographer there conducting what's viewed
as a legal and proper photo shoot likely would be branded a felon and
child pornographer in the U.S. In yet other countries and groups, the
entire concept of nude photography or even any photography of a
person in any form may be religiously unacceptable.
Saudi Arabia, Iran, Northern Nigeria, and China are not likely to
have the same liberal views as, say, the Netherlands or Denmark.
Saudi Arabia and China, like some other nations, extensively filter
their Internet connection and have created a government agencies to
protect their society from web sites that officials view as immoral.
Their views on what should be included in a .xxx domain would hardly
be identical to those in liberal western nations.
Those wildly different opinions on sexual material make it
inconceivable that a global consensus can ever be reached on what is
appropriate or inappropriate for a .xxx or .adult top-level domain.
Moreover, the existence of such a domain would create an irresistible
temptation on the part of conservative legislators to require
controversial publishers to move to that domain and punish those who
do not.
Some conservative politicians already have complained that ICANN did
not approve .xxx in its October 2000 meeting. During a February 2001
hearing in the U.S. House of Representatives, legislators warned that
they "want to explore ICANN's rationale for not approving two
particular top level domain names -- .kids and .xxx -- as a means to
protect kids from the awful smut which is so widespread on the
Internet."
It seems plausible that only a few adult publishers, and not those
who have invested resources in building a brand around a .com site,
would voluntarily abandon their current domain name. Instead, they'd
likely add a .xxx variant and keep their original address. The
existence of .xxx could propel legislators in the U.S. and other
countries to require them to publish exclusively from an adult
domain, a move that would invite ongoing political interference with
Internet governance and raise concerns about forced speech and self-
labeling.
In fact, the ultimate arbiter of generic top-level domain names -- at
least currently -- is not ICANN, but the U.S. government. The U.S.
Congress' General Accounting Office in July 2000 reported that the
Commerce Department continues to be responsible for domain names
allowed by the authoritative root. [GAO] The GAO's auditors concluded
D. Eastlake 3rd, D. McCullagh [Page 5]
INTERNET-DRAFT .xxx Considered Dangerous November 2002
it was unclear whether the Commerce Department has the "requisite
authority" under current law to transfer that responsibility to
ICANN.
The American Civil Liberties Union -- and other members of the
international Global Internet Liberty Campaign -- caution that
publishers speaking frankly about birth control, AIDS prevention, gay
and lesbian sex, the social problem of prison rape, etc., could be
coerced into moving to an adult domain. Once there, they would be
stigmatized and easily blocked by schools, libraries, companies, and
other groups using filtering software. Publishers of such information
who do not view themselves as pornographers and retain their existing
addresses could be targeted for prosecution.
The existence of an adult top-level domain would likely open the door
for related efforts, either policy or legislative. There are many
different axes through which offensive material can be defined: Sex,
violence, hate, heresy, subversion, blasphemy, illegal drugs,
profanity, political correctness, glorification of crime, incitement
to break the law, and so on. Such suggestions invite the ongoing
lobbying of ICANN, the U.S. government, or other policy-making bodies
by special-interest groups that are not concerned with the technical
feasibility or practicality of their advice.
An adult top-level domain could have negative legal repercussions by
endangering free expression. U.S. Supreme Court Justice Sandra Day
O'Connor has suggested that the presence of "adult zones" on the
Internet would make a future Communications Decency Act (CDA) more
likely to be viewed as constitutional. In her partial dissent to the
Supreme Court's rejection of the CDA in 1997 [CDA], O'Connor said
that "the prospects for the eventual zoning of the Internet appear
promising." (The Supreme Court ruled the CDA violated free speech
rights by making it a crime to distribute "indecent" or "patently
offensive" material online.)
Privacy could be harmed by such a proposal. It would become easier
for repressive governments and other institutions to track visits to
sites in a domain labeled as adult and record personally-identifiable
information about the visitor. Repressive governments would instantly
have more power to monitor naive users and prosecute them for their
activities. It's also implausible that a top-level domain would be
effective in controlling access to chat, email, newsgroups, instant
messaging, and new services as yet to be invented.
3. Technical Difficulties
Even ignoring the philosophical and legal difficulties outlined
above, there are substantial technical difficulties in attempting to
D. Eastlake 3rd, D. McCullagh [Page 6]
INTERNET-DRAFT .xxx Considered Dangerous November 2002
impose content classification by domain names or IP addresses.
Mandatory content labeling is usually advanced with the idea of using
a top level domain name, discussed in section 3.1, but we also
discuss the possibility of using IP address bits or ranges in section
3.2.
In section 3.3 difficulties with a few particular higher level
protocols are discussed. In some cases, these protocols use
different name spaces. It should be kept in mind that additional
future protocols may be devised with as yet undreamed of naming
characteristics.
We also discuss PICS labels [PICS] as an alternative technology in
section 3.4.
Only a limited technical background is assumed so some basic
information is included below. In some cases descriptions are
simplified and details omitted.
This technical discussion minimizes the definitional problems.
However, it is still necessary for evaluating some technical
considerations to have some estimate of the amount of categorization
that would be necessary for a realistic global censorship system.
There is no hope of agreement on this point. For our purposes, we
will arbitrarily assume that the world's population consists of
approximately 90,000 overlapping communities, each of which would
have a different categorization of interest. Further, we arbitrarily
assume that some unspecified but clever encoding scheme enables a
proper global categorization of all information by a 300 bit label.
Some would say a 300 bit label is too large, others that it is too
small. Regardless, we will use it for some technical evaluations.
3.1 Domain Name System (DNS) and Other Names
The most prominent user visible part of Internet naming and
addressing is the domain name system [RFC 1034, 1035]. Domain Names
are dotted sequences of labels such as aol.com, world.std.com,
www.rosslynchapel.org.uk, or ftp.gnu.lcs.mit.edu [RFC 1035, 1591,
2606]. They form an important part of most World Wide Web addresses
or URLs [RFC 2396], commonly appearing after "//".
Domain names simply name nodes in a global distributed hierarchically
delegated database. A wide variety of information can be stored at
these nodes including IP addresses of machines on the network (see
section 3.2 below), mail delivery information, and many other types
of information. Thus, the data stored at foo.example.com could be
the numeric information for sending data to a particular machine,
which would be used if you tried to browse <http://foo.example.com>,
D. Eastlake 3rd, D. McCullagh [Page 7]
INTERNET-DRAFT .xxx Considered Dangerous November 2002
the name of a computer (say mailhost.example.com) to handle mail
addressed to anyone "@foo.example.com", and/or other information.
There are also other naming systems in use, such as news group names
and Internet Relay Chat (IRC) channel names.
The usual labeling idea presented is to reserve a top level name,
such as .xxx for "adult" material and/or .kids for "safe" material or
the like. This has technical and linguistic problems with this are
described in the subsections below.
3.1.1 Linguistic Problems
When using name labeling, the first problem is from whose language do
you take the names to impose? Words and acronyms can have very
different meanings in different languages and the probability of
confusion is multiplied when phonetic collisions are considered.
As an example of possible problems, note that for several years the
government of Turkmenistan suspended new registrations in ".tm",
which had previously been a source of revenue, because some of the
registered second level domain names may have been problematic. In
particular, their web home page at <http://www.nic.tm> said:
Statement from the .TM NIC
The response to the .TM registry has been overwhelming. Thousands
of names have been registered from all over the world. Some of
the names registered, however, may be legally obscene in
Turkmenistan, and as a result the .TM NIC registry is reviewing
its naming policy for future registrations. The .TM NIC has
suspended registrations until a new policy can be implemented. We
hope to be live again shortly.
3.1.2 The DNS Hierarchy and Use of TLDs
An important aspect of the design of the Domain Name System (DNS) is
the hierarchical delegation of data maintenance. The DNS really only
works, and has been able to scale the over five orders of magnitude
it has grown since its initial deployment, due to this delegation.
The first problem is that one would expect most computers or web
sites to have a mix of material only some of which should be
specially classified. Using special TLDs multiples the number of DNS
zones the site has to worry about. For example, assume the site has
somehow already sorted its material into "kids", "normal", and
D. Eastlake 3rd, D. McCullagh [Page 8]
INTERNET-DRAFT .xxx Considered Dangerous November 2002
"adult" piles. Without special TLD labels, it can store them under
kids.example.net, adult.example.net, and other.example.net, for
instance, which requires only the maintenance of the single
example.net zone of database entries. With special TLD labeling, at
least example.net (for normal stuff), example.net.xxx, and
example.net.kids would need to be maintained which are three separate
zones in different parts of the DNS tree under three separate
delegations. As the number of categories expands and the number of
category combinations explodes, this quickly becomes completely
unmanageable. If 300 bits worth of labeling is required, the system
could, in theory, need 2**300 name categories, an impossibility. No
individual site would need to use all categories and the category
domain names would not all have to be all top level names. But it
would still be an unmanageable nightmare.
3.1.3 You Can't Control What Names Point At You!
The DNS system works as a database and associates certain data,
called resource records, or RRs, with domain names. In particular,
it can associate IP address resource records with domain names. For
example, when you browse a URL, most commonly the domain name within
that URL is looked up in the DNS and the resulting address is used to
address the packets sent from your web browser or other software to
the server or peer.
Remember what we said in Section 3.1.1 about hierarchical delegation?
Anyone controlling a DNS zone of data, say example.com, can insert
data at that name or any deeper name (except to the extent they
maintain delegations of some of the deeper namespace to yet others).
So the controller of example.com can insert data so that
purity.example.com has stored at it the same computer address which
is at www.obscene.example.xxx. This directs any reference to
purity.example.com to use the associated IP address which is the same
as the www.obscene.example.xxx web site. The manager of that
hypothetical web site, who controls the obscene.example.xxx zone, has
no control over the example.com DNS zone and so is technically
incapable of causing it to conform to any "xxx" labeling law. Or, in
the alternative, someone could create a name conforming to an adult
labeling requirement that actually pointed to someone else's entirely
unobjectionable site, perhaps for the purpose of polluting the
labeling.
Thus, providers of data on the Internet cannot stop anyone from
creating names pointing to their computer's IP address with
misleading domain names.
D. Eastlake 3rd, D. McCullagh [Page 9]
INTERNET-DRAFT .xxx Considered Dangerous November 2002
3.1.4 Particular Protocol Considerations
There are additional considerations related to particular protocols.
We consider only a few here. The first two, electronic mail and the
World Wide Web, use domain name addressing. The second two, net news
and IRC, actually use different name spaces and illustrate further
technical problems with name based labeling.
3.1.3.1 Electronic Mail (SMTP)
The standard Internet electronic mail protocol separates "envelope"
information from content [RFC 2821, 2822]. The envelope information
indicates where a message claims to have originated and to whom it
should be delivered. The content has fields starting with labels
like "From:" and "To:" but these actually have no effect and can be
arbitrarily forged using simple. normally available software, such a
telnetting to the SMTP port on a mail server. Content fields are not
compared with envelope fields.
While different mail clients display envelope information and headers
from the content of email differently, generally the common content
fields are given prominence. Thus, while not exactly the same as
content labeling, it should be noted that it is trivial to send mail
to anyone with arbitrary domain names in the email addresses
appearing in the From and To headers, etc.
It is also easy set up a host to forward mail to an email address or
mailing list. Mail sent with normal mail tools to this forwarder
will automatically have content headers reflecting the forwarder's
name but the forwarder will change the envelope information and cause
the mail to be actually sent to the forwarding destination mail
address. For example, (with names disguised) there is a social
mailing list innocuous@foo.example.org and someone set up a forwarder
at cat-torturers@other.example. Mail sent to the forwarder is
forwarded and appears on the innocuous mailing list but with a "To:
cat-torturers@other.example" header in its body and this is the
header that is displayed by mail readers. In some cases, similar
things can be done using the "bcc" or blind courtesy copy feature of
Internet mail.
Thus, standard Internet tools provide no way to control domain names
appearing inside email headers.
There is work proceeding on securing email; however, such efforts at
present only allow you to verify whether or not a particular entity
was the actual author of the mail. They do not generally relate to
controlling or authenticating domain names in the content of the
mail.
D. Eastlake 3rd, D. McCullagh [Page 10]
INTERNET-DRAFT .xxx Considered Dangerous November 2002
3.1.4.2 Web Access (HTTP)
At least with modern web servers and browsers supporting HTTP 1.1
[RFC 2616], the domain name used to access the site is available to
access different web sites even if they are on the same machine at
the same IP address. This is a small plus for name based labeling
since different categories of information on the same computer could
be set up to be accessed via different domain names. But for a
computer with any reasonable variety of data, the explosion of trying
to differently name all types of data would require an unmanageable
number of names.
On the other hand, the web has automatic forwarding. Thus, when one
tries to access data at a particular domain name, the server there
can re-direct your browser, temporarily or permanently, to a
different name. Or it can re-direct you to a numeric IP address so as
to by-pass name filtering.
3.1.3.3 News (NNTP)
Net news uses hierarchical structured newsgroup names that are
similar in appearance to domain names except that the most
significant label is on the left and the least on the right, the
opposite of domain names. However, while the names are structured
hierarchically, there is no central control. Instead, news servers
periodically connect to other news servers that have agreed to
exchange messages with them and then they update each other on
messages only in those newsgroups in which they wish to exchange
messages.
Although hierarchical zones in the domain name system are locally
managed, they need to be reachable starting at the top level root
servers which are in turn more or less controlled by ICANN and the US
Department of Commerce. With no such central point or points in the
net news world, any pair or larger set of news servers anywhere in
the world can agree to exchange news messages under any news group
names they like, making central control or even influence virtually
impossible. In fact, within some parts of the news group namespace on
some servers, anyone can create new newsgroups with arbitrary names.
Even if news group names could be controlled, the contents of the
messages are determined by posters. While some groups are moderated,
most are not. "Cancel" messages can be sent out for news messages,
but that mechanism is subject to abuse so many servers are configured
to ignore cancels. In any case, the message may have been distributed
to a huge number of computers world wide before any cancel is sent
out.
D. Eastlake 3rd, D. McCullagh [Page 11]
INTERNET-DRAFT .xxx Considered Dangerous November 2002
And of course, the fitting 300 bits worth of labeling into news group
names is just as impossible as it is to fit into domain names.
3.1.3.4 Internet Relay Chat
Internet Relay Chat is another example of a service which uses a
different name space. It uses a single level space of "channel
names" which are meaningful within a particular network of IRC
servers. Because it is not hierarchical, each server must know about
all names, which limits the size of a network of servers.
As with newsgroup names, the fact that IRC channel names are local
decisions not subject to or reachable from any global "root" makes
centralized political control virtually impossible.
3.2 IP Addressing
A key characteristic of the Internet Protocol (IP) on which the
Internet is based is that it breaks data up into "packets". These
packets are individually handled and routed from source to
destination. Each packet has in it a numeric address for the
destination point to which the Internet will try to deliver the
packet.
(End users do not normally see these numeric addresses but instead
deal with "domain names" as described in section 3.1 above.)
The predominant numeric address system now in use is called IPv4, or
Internet Protocol Version 4, which provides for 32 bit addresses [RFC
791]. There is increasing migration to the newer IPv6, which
provides for 128 bit addresses [RFC 1752].
One problem in using addressing for content filtering is that this is
a very coarse technique. IP addresses address network interfaces
which usually correspond to entire computer systems which could house
multiple web pages, sets of files, etc., only a small part of which
it was desired to block or enable. Increasingly, a single IP address
may correspond to a NAT (Network Address Translation) box [RFC 2663]
which hides multiple computers behind it, although in that case these
computers are usually not servers.
However, even beyond this problem of coarse granularity, the
practical constraints of hierarchical routing make the allocation of
even a single IPv4 address bit or a significant number of IPv6
address bits impossible.
D. Eastlake 3rd, D. McCullagh [Page 12]
INTERNET-DRAFT .xxx Considered Dangerous November 2002
3.2.1 Hierarchical Routing
As packets of data flow through the Internet, decisions must be made
as to how to forward them "towards" their destination. This is
normally done by comparing the initial bits of the packet destination
address to entries in a "routing table" and forwarding the packets as
indicated by the table entry with the longest prefix match.
While the Internet is actually a mesh, if, for simplicity, we
consider it to have a central backbone at the "top", a packet is
typically routed as follows:
The local networking code looks at its routing table to determine if
the packet should be sent directly to another computer on the "local"
network, to a router to specially forward it to another nearby
network, or routed "up" to a "default" router to forward it to a
higher level service provider's network. If the packet's destination
is "far enough away" it will eventually get forwarded up to a router
on the backbone. Such a router can not sent the packet "up" since it
is at the top or "default free" zone and must have a complete table
of what other top level router to send the packet to. Currently,
such top level routers are very large and expensive devices. They
must be able to maintain tables of tens of thousands of routes. When
the packet gets to the top level router of the part of the network
within which its destination lies, it get forwarded "down" to
successive routers which are more and more specific and local until
eventually its gets to a router on the local network where its
destination address lies. This local router sends the packet
directly to the destination computer.
Because all of these routing decisions are made on a longest prefix
match basis, it can be seen that IP addresses are not general names
or labels but are intimately associated with the actual topology and
routing structure of the network. If there were assigned at random,
routers would be required to remember so many specific routes for
specific addresses that it would exceed the current technical
capabilities for router design and the Internet would not work.
It should also be noted that there is some inefficiency in allocation
at each level of hierarchy [RFC 1715]. Generally allocations are of
a power of two addresses and as requirements grow and/or shrink, it
is not practical to use every address for a computer.
(The above simplified description ignores multi-homing and many other
details.)
D. Eastlake 3rd, D. McCullagh [Page 13]
INTERNET-DRAFT .xxx Considered Dangerous November 2002
3.2.2 IP Version 4 Addresses
There just isn't any practical way to reallocate even one bit of IPv4
global Internet Addresses for content filtering use. Such addresses
are in short supply and such an allocation would, in effect, cut the
number of available addresses in half. There just aren't enough
addresses, given the inefficiency of hierarchical allocation and
routing, to do this. Even if there were, current numbers have not
been allocated with this in mind so that a renumbering within every
organization with hosts on the Internet would be required, a
nightmarish and Herculean task costing in the billions of dollars.
Even if these problems were overcome, the allocation of even a single
bit near the top of the address bits would likely double the number
of routes in the default free zone, exceeding the capacity of current
routers and requiring the upgrade of thousands of them to new routers
that do not exist yet. The allocation of a bit near the bottom of the
address bits would require world wide local action which would be
impossible to require or enforce, even if the bit were available.
And all this is for only a single bit, let alone more than one, is
allocated to content labeling. And we are assuming you would actually
need 300 bits, more than there are!
Basically, the idea is a non-starter.
3.2.3 IP Version 6 Addresses
IPv6 provides 128 bit address fields. Furthermore, allocation of
IPv6 addresses is in its infancy. Thus the allocation of, say, one
bit of IPv6 address for labeling is conceivable.
However, as discussed above (section 3.2.1), every high bit allocated
for labeling doubles the cost imposed on the routing system.
Allocating one bit would generally double the size of routing tables.
Allocating two bits would multiply them by four. Allocating the 300
bits we assume necessary for realistic world wide labeling is
logically impossible for IPv6, 300 being a lot larger than 128, and
if it were, would result in technically unachievable routing table
sizes. Even allocating 30 bits, if that were possible, could
impossibly multiply table sizes by a billion.
Allocating low bits also has problems. There are technical proposals
that use the bottom 64 bits in a manner incompatible with their use
for labels [RFC 2374]. So it would probably have to be "middle bits"
(actually low bits of the upper half). As with IPv4, it would be
impossible to enforce this world wide. If it were, it might be
conceivable that one or two bits could be allocated there, which
would be completely inadequate.
D. Eastlake 3rd, D. McCullagh [Page 14]
INTERNET-DRAFT .xxx Considered Dangerous November 2002
3.3 PICS Labels
PICS Labels [PICS] have several modes. If content is required to
have labels in it, which is one mode, it raises all the problems of
categorization granularity and forced speech. But if used in a mode
whereby a third party determines and provides labels for content and
users are free to select whatever such third party or parties they
wish to consult, it is a way to permit a myriad of categories,
editors, and evaluators to exist in parallel.
It would be quite reasonable to have multiple PICS services that, in
the aggregate, provided 300 bits of label information or more. There
could be a PICS service for every community of interest. This sort
of technology is really the only reasonable way to make
categorizations or labelings of material available in a diverse and
dynamic world.
While such PICS label services could be used to distribute government
promulgated censorship categories, for example, it is not clear how
this is any worse than government censorship via national firewalls.
4. Conclusions
The concept that a single top level domain name, such as .xxx, or a
single IP address bit, could be allocated and become the mandatory
home of "adult" or "offensive" material world wide is hopeless
nonsense.
Global agreement on what sort of material should be in such a ghetto
is impossible. In the world wide context, the use of a single
category or small number of categories is absurd. The implementation
of a reasonable size label that could encompass the criterion of the
many communities of the world, such as 300 bits, is impossible at the
domain name or IP address level and will remain so for the
foreseeable future. Besides technical impossibility, such a mandate
would be an illegal forcing of speech in some jurisdictions and for
domain names faces severe linguistic problems.
Nevertheless, the concept of a plethora of independent reviewers,
some of which might be governmental agencies, and the ability of
those accessing information to select and utilize ratings assigned by
such reviewers, is possible.
D. Eastlake 3rd, D. McCullagh [Page 15]
INTERNET-DRAFT .xxx Considered Dangerous November 2002
References
[BT] - British Telecom comments to U.S. Commerce Department, February
20, 1998,
<http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/BT.htm>
[CDA] - Reno v. American Civil Liberties Union, 117 S.Ct. 2329, June
26, 1997,
<http://supct.law.cornell.edu/supct/html/96-511.cpanel.html>
[COPAREPORT] - Final Report of the COPA Commission to the U.S.
Congress, October 20, 2000,
<http://www.copacommission.org/report/newtopleveldomain.shtml>
[GAO] - GAO Report OGC-00-33R, July 7, 2000,
<http://www.gao.gov/new.items/og00033r.pdf>
[GTLD-MOU] - GTLD-MOU Policy Oversight committee RFC 97-02, September
13, 1997, <http://www.gtld-mou.org/docs/notice-97-02.html>
[HOUSEREPORT] - U.S. House Commerce Committee report, 105th Congress,
October 5, 1998.
<http://www.epic.org/free_speech/censorship/hr3783-report.html>
[ICM-REGISTRY] - Request for reconsideration from ICM Registry to
ICANN, December 15, 2000,
<http://www.icann.org/committees/reconsideration/icm-
request-16dec00.htm>
[LIEBERMAN] - Testimony of Senator Joe Lieberman before Children's
Online Protection Act Commission, June 8, 2000,
<http://www.senate.gov/~lieberman/press/00/06/2000608958 .html>
[PICS] - Platform for Internet Content Selection
Service Descriptions <http://www.w3.org/TR/REC-PICS-services>
Label Format and Distribution <http://www.w3.org/TR/REC-PICS-
labels>
PICS Rules <http://www.w3.org/TR/REC-PICSRules>
PICS Signed Labels (DSIG) 1.0 Specification
<http://www.w3.org/TR/REC-DSig-label/>
[RFC 791] - "Internet Protocol", J. Postel, September 1981.
[RFC 1034] - P. Mockapetris, "Domain Names - Concepts and
Facilities", STD 13, November 1987.
[RFC 1035] - P. Mockapetris, "Domain Names - Implementation and
Specifications", STD 13, November 1987.
[RFC 1591] - J. Postel, "Domain Name System Structure and
D. Eastlake 3rd, D. McCullagh [Page 16]
INTERNET-DRAFT .xxx Considered Dangerous November 2002
Delegation", March 1994.
[RFC 1715] - C. Huitema, "The H Ratio for Address Assignment
Efficiency", November 1994.
[RFC 1752] - S. Bradner, A. Mankin, "The Recommendation for the IP
Next Generation Protocol", January 1995.
[RFC 2374] - R. Hinden, M. O'Dell, S. Deering, "An IPv6 Aggregatable
Global Unicast Address Format", July 1998.
[RFC 2396] - T. Berners-Lee, R. Fielding, L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", August 1998.
[RFC 2460] - "Internet Protocol, Version 6 (IPv6) Specification", S.
Deering and R. Hinden, December 1998.
[RFC 2606] - D. Eastlake, A. Panitz, "Reserved Top Level DNS Names",
June 1999.
[RFC 2616] - "Hypertext Transfer Protocol -- HTTP/1.1", R. Fielding,
J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-
Lee, June 1999.
[RFC 2663] - "IP Network Address Translator (NAT) Terminology and
Considerations", P. Srisuresh, M. Holdrege, August 1999.
[RFC 2821] - "Simple Mail Transfer Protocol", J. Klensin, Editor,
April 2001.
[RFC 2822] - "Internet Message Format", P. Resnick, Editor, April
2001.
[WARSHAVSKY] - "Congress weighs Net porn bills," CNET article,
February 10, 1998, <http://news.cnet.com/news/0-1005-200-326435.html>
D. Eastlake 3rd, D. McCullagh [Page 17]
INTERNET-DRAFT .xxx Considered Dangerous November 2002
Authors Addresses
Donald E. Eastlake 3rd
Motorola Laboratories
155 Beaver Street
Milford, MA 01757 USA
Telephone: +1-508-634-2066 (h)
+1-508-851-8280 (w)
EMail: Donald.Eastlake@motorola.com
Declan McCullagh
CNet
Telephone: +1-202-299-1013
EMail: Declan.McCullagh@cnet.com
D. Eastlake 3rd, D. McCullagh [Page 18]
INTERNET-DRAFT .xxx Considered Dangerous November 2002
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Expiration and File Name
This draft expires May 2003.
Its file name is draft-eastlake-xxx-03.txt.
D. Eastlake 3rd, D. McCullagh [Page 19]
| PAFTECH AB 2003-2026 | 2026-04-23 16:14:24 |