doc: Add RFC documents

1 files changed, 1235 insertions, 0 deletions

diff --git a/doc/rfc/rfc3675.txt b/doc/rfc/rfc3675.txt
new file mode 100644
index 0000000..31f8978
--- /dev/null
+++ b/doc/rfc/rfc3675.txt
@@ -0,0 +1,1235 @@
+
+
+
+
+
+
+Network Working Group                                    D. Eastlake 3rd
+Request for Comments: 3675                         Motorola Laboratories
+Category: Informational                                    February 2004
+
+
+                        .sex Considered Dangerous
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2004).  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 from the legal, philosophical, and particularly, the technical
+   points of view.
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
+   2.  Background . . . . . . . . . . . . . . . . . . . . . . . . . .  2
+   3.  Legal and Philosophical Problems . . . . . . . . . . . . . . .  4
+   4.  Technical Difficulties . . . . . . . . . . . . . . . . . . . .  6
+       4.1.  Content Filtering Using Names. . . . . . . . . . . . . .  7
+             4.1.1.  Linguistic Problems. . . . . . . . . . . . . . .  7
+             4.1.2.  Explosion of Top Level Domain Names (TLDs) . . .  8
+             4.1.3.  You Can't Control What Names Point At You! . . .  9
+             4.1.4.  Particular Protocol Difficulties . . . . . . . . 10
+                     4.1.4.1.  Electronic Mail (SMTP) . . . . . . . . 10
+                     4.1.4.2.  Web Access (HTTP). . . . . . . . . . . 11
+                     4.1.4.3.  News (NNTP). . . . . . . . . . . . . . 12
+                     4.1.4.4.  Internet Relay Chat (IRC). . . . . . . 13
+       4.2.  Content Filtering Using IP Addressing. . . . . . . . . . 13
+             4.2.1.  Hierarchical Routing . . . . . . . . . . . . . . 14
+             4.2.2.  IP Version 4 Addresses . . . . . . . . . . . . . 15
+             4.2.3.  IP Version 6 Addresses . . . . . . . . . . . . . 15
+       4.3.  PICS Labels. . . . . . . . . . . . . . . . . . . . . . . 16
+   5.  Security Considerations. . . . . . . . . . . . . . . . . . . . 17
+   6.  Conclusions. . . . . . . . . . . . . . . . . . . . . . . . . . 17
+   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
+
+
+
+Eastlake 3rd                 Informational                      [Page 1]
+
+RFC 3675               .sex Considered Dangerous           February 2004
+
+
+       7.1.  Normative References . . . . . . . . . . . . . . . . . . 18
+       7.2.  Informative References . . . . . . . . . . . . . . . . . 19
+   8.  Acknowledgement. . . . . . . . . . . . . . . . . . . . . . . . 21
+   9.  Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 21
+   10. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 22
+
+1.  Introduction
+
+   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 from the legal, philosophical, and the technical points of view.
+
+2.  Background
+
+   The concept of a .sex, .xxx, .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].
+
+
+
+
+
+
+Eastlake 3rd                 Informational                      [Page 2]
+
+RFC 3675               .sex Considered Dangerous           February 2004
+
+
+   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 other 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-
+   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].
+
+
+
+
+
+Eastlake 3rd                 Informational                      [Page 3]
+
+RFC 3675               .sex Considered Dangerous           February 2004
+
+
+   In 2002, the U.S. 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.
+
+3.  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
+   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 would be branded a felon and child
+   pornographer in the U.S.A.  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 government agencies to
+   protect their society from web sites that officials view as immoral.
+   Their views on what should be included in a .sex 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 .sex 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.
+
+
+
+
+
+
+Eastlake 3rd                 Informational                      [Page 4]
+
+RFC 3675               .sex Considered Dangerous           February 2004
+
+
+   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 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, and other policy-making
+   bodies by special-interest groups that are not concerned with the
+   technical feasibility or practicality of their advice.
+
+
+
+
+
+Eastlake 3rd                 Informational                      [Page 5]
+
+RFC 3675               .sex Considered Dangerous           February 2004
+
+
+   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 that 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.
+
+4.  Technical Difficulties
+
+   Even ignoring the philosophical and legal difficulties outlined
+   above, there are substantial technical difficulties in attempting to
+   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 4.1., but we also
+   discuss the possibility of using IP address bits or ranges in section
+   4.2.
+
+   In section 4.1.4., 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 4.3.
+
+   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
+
+
+
+Eastlake 3rd                 Informational                      [Page 6]
+
+RFC 3675               .sex Considered Dangerous           February 2004
+
+
+   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.
+
+4.1.  Content Filtering Using 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].  Domain Names form an important part of most World Wide Web
+   addresses or URLs [RFC 2396], commonly appearing after "//".
+   Security for the domain name system is being standardized [RFC 2535],
+   but has not been deployed to any significant extent.
+
+   Domain names designate nodes in a globally 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 4.2. below), mail delivery information, and 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>, 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 .sex or .xxx for "adult" material and/or .kids for "safe"
+   material or the like.  The technical and linguistic problems with
+   this are described in the subsections below.
+
+4.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
+
+
+
+
+Eastlake 3rd                 Informational                      [Page 7]
+
+RFC 3675               .sex Considered Dangerous           February 2004
+
+
+   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."
+
+   There are approximately 6,000 languages in use in the world today,
+   although this is expected to decline to around 3,000 by the year
+   2100.
+
+4.1.2.  Explosion of Top Level Domain Names (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 over the 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 top level domain names (TLDs)
+   multiplies 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 "adult" piles.  Without special TLD labels, it
+   can store them under kids.example.net, adult.example.net, and
+   other.example.net, for instance.  This would require 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.sex, and example.net.kids would need to be maintained,
+   which are in three separate zones, in different parts of the DNS
+   tree, under three separate delegations.
+
+   As the number of categories expands, the number of category
+   combinations explodes, and 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 top level names.  But it would
+   still be an unmanageable nightmare.
+
+
+
+
+
+
+Eastlake 3rd                 Informational                      [Page 8]
+
+RFC 3675               .sex Considered Dangerous           February 2004
+
+
+4.1.3.  You Can't Control What Names Point At You!
+
+   Providers of data on the Internet cannot stop anyone from creating
+   names pointing to their computer's IP address with misleading domain
+   names.
+
+   The DNS system works as a database.  It 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 a domain name within
+   that URL is looked up in the DNS.  The resulting address is then used
+   to address the packets sent from your web browser or other software
+   to the server or peer.
+
+   Remember what we said in Section 4.1.1. about hierarchical
+   delegation?  Control is delegated and anyone controlling a DNS zone
+   of data, say example.com, can insert data at that name or any deeper
+   name (except to the extent that they delegate some of the deeper
+   namespace to yet others).  So the controller of example.com can
+   insert data so that purity.example.com has, associated with it, the
+   same computer address, which is associated with
+   www.obscene.example.sex.  This directs any reference to
+   purity.example.com to use the associated IP address which is the same
+   as the www.obscene.example.sex 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.  They are technically
+   incapable of causing it to conform to any ".sex" labeling law.  In
+   the alternative, someone could create a name conforming to an adult
+   labeling requirement, such as foo.stuff.sex, that actually pointed to
+   someone else's entirely unobjectionable site, perhaps for the purpose
+   of polluting the labeling.  See diagram below.  Each "zone" could be
+   hosted on a different set of physical computers.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake 3rd                 Informational                      [Page 9]
+
+RFC 3675               .sex Considered Dangerous           February 2004
+
+
+            +-----------------------------------------+
+            |          . (root) zone                  |
+            | .com  .org  .net  .us  .uk  .sex  ...   |
+            +---+---------------------------+---------+
+                |                           |
+                V                           V
+       +--------------------+         +--------------------+
+       |     .com zone      |         |     .sex zone      |
+       |  example.com  ...  |         |  example.sex  ...  |
+       +---------------+----+         +---------------+----+
+                       |                              |
+                       V                              V
+      +---------------------+             +----------------------+
+      |  example.com zone   |             |   example.sex zone   |
+      |                     |             |                      |
+      | purity.example.com -+--+      +---+- obscene.example.sex |
+      | virtue.example.com  |  |      |   |     porn.example.sex |
+      |      |              |  |      |   |        |             |
+      +------+--------------+  |      |   +--------+-------------+
+             |                 +------+------+     |
+             |          +-------------+      |     |
+             V          V                    V     V
+         +-----------------+              +------------------+
+         |  Virtuous Data  |              |  Salacious Data  |
+         +-----------------+              +------------------+
+
+4.1.4.  Particular Protocol Difficulties
+
+   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, use different name spaces and illustrate further technical
+   problems with name based labeling.
+
+4.1.4.1.  Electronic Mail (SMTP)
+
+   Standard Internet tools provide no way to stop users from putting
+   arbitrary domain names inside email headers.
+
+   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 content fields 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.  To require
+   them to be the same would be like requiring that postal letters
+
+
+
+Eastlake 3rd                 Informational                     [Page 10]
+
+RFC 3675               .sex Considered Dangerous           February 2004
+
+
+   deposited in a mail box list that mail box as their return address
+   and only allowing residence or business return addresses on mail
+   picked up by the post office from that residence or business.
+
+   While different mail clients display envelope information and headers
+   from the content of email differently, generally the principle
+   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 up 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, instead of the usual
+   "To: innocuous@foo.example.org" content header.  Mail reader software
+   then displays the cat-torturers header.  Similar things can be done
+   using the "bcc" or "blind courtesy copy" feature of Internet mail.
+
+   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.  When providing authentication,
+   they add yet a third type of "From" address to the envelope and
+   content "From" addresses, but they do not relate to controlling or
+   authenticating domain names in the content of the mail.
+
+4.1.4.2.  Web Access (HTTP)
+
+   With modern web servers and browsers supporting HTTP 1.1 [RFC 2616],
+   the domain name used to access the site is available.  Thus, web
+   sites with different domain names can be accessed 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 can 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.
+
+
+
+
+
+
+Eastlake 3rd                 Informational                     [Page 11]
+
+RFC 3675               .sex Considered Dangerous           February 2004
+
+
+   With earlier HTTP 1.0 [RFC 1945], when a web request was sent to a
+   server machine, the original domain name used in the URI was not
+   included.
+
+   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.
+
+4.1.4.3.  News (NNTP)
+
+   Net news [RFC 977, 2980] uses hierarchically 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 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, including duplicates of those used elsewhere in the
+   net, 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 some 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.
+
+   And of course, fitting 300 bits worth of labeling into news group
+   names is just as impossible as it is to fit into domain names.
+
+
+
+
+
+
+
+
+
+Eastlake 3rd                 Informational                     [Page 12]
+
+RFC 3675               .sex Considered Dangerous           February 2004
+
+
+4.1.4.4.  Internet Relay Chat (IRC)
+
+   Internet Relay Chat [RFC 2810-2813] is another example of a service
+   which uses a different name space.  It uses a single level space of
+   "channel names" that 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.
+
+4.2.  Content Filtering Using 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 carries 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 4.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 [RFC 2460],
+   which provides for 128 bit addresses [RFC 2373, 2374].
+
+   Packets can be modified maliciously in transit but the most common
+   result of this is denial of service.
+
+   One problem in using addressing for content filtering is that this is
+   a very coarse technique.  IP addresses refer to 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.
+
+
+
+
+
+
+Eastlake 3rd                 Informational                     [Page 13]
+
+RFC 3675               .sex Considered Dangerous           February 2004
+
+
+4.2.1.  Hierarchical Routing
+
+   IP addresses are technically inappropriate for content filtering
+   because their assignment is intimately tied to network routing and
+   topology.
+
+   As packets of data flow through the Internet, decisions must be made
+   as to how to forward them "towards" their destination.  This is 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 cannot send the packet "up" since it
+   is at the top, or "default free" zone, and must have a complete table
+   of other top level routers in which to send the packet.  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 gets forwarded "down" to
+   successive routers which are more and more specific and local until
+   eventually it 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 critically and intimately associated with the
+   actual topology and routing structure of the network.  If they were
+   assigned at random, routers would be required to remember so many
+   specific routes for specific addresses that it would far exceed the
+   current technical capabilities for router design.  The Internet would
+   be fatally disrupted and 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.
+
+
+
+
+Eastlake 3rd                 Informational                     [Page 14]
+
+RFC 3675               .sex Considered Dangerous           February 2004
+
+
+   (The above simplified description ignores multi-homing and many other
+   details.)
+
+4.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.  Such an allocation would, in effect, cut the
+   number of available addresses in half.  There just aren't enough
+   addresses, even without the inefficiency of hierarchical allocation
+   [RFC 1715] and routing, to do this.  Even if there were, current
+   numbers have not been allocated with this in mind so that renumbering
+   by every organization with hosts on the Internet would be required, a
+   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.  This would exceed the capacity
+   of current routers and require the upgrade of thousands of them to
+   new routers that do not exist yet at a gargantuan cost.  The
+   allocation of a bit near the bottom of the address bits would require
+   world-wide local reconfiguration which would be impractical to
+   require or enforce, even if the bit were available.
+
+   And all this is if only a single bit is allocated to content
+   labeling, let alone more than one.  And we are assuming you would
+   actually need 300 bits, more than there are!
+
+   Basically, the idea is a non-starter.
+
+4.2.3.  IP Version 6 Addresses
+
+   IPv6 provides 128 bit address fields [RFC 2373, 2374].  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 4.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, say, 20 bits, if that were possible, would
+   impossibly multiply table sizes by a million.
+
+
+
+
+Eastlake 3rd                 Informational                     [Page 15]
+
+RFC 3675               .sex Considered Dangerous           February 2004
+
+
+   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 possible, one or
+   two bits could be allocated there, which would be clearly inadequate.
+
+4.3.  PICS Labels
+
+   PICS Labels (Platform for Internet Content Selection) is a
+   generalized system for providing "ratings" for Internet accessible
+   material.  The PICS documents [PICS] should be consulted for details.
+   In general, PICS assumes an arbitrarily large number of rating
+   services and rating systems.  Each service and system is identified
+   by a URL.
+
+   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.
+
+   A PICS rating system is essentially a definition of one or more
+   dimensions and the numeric range of the values that can be assigned
+   in each dimension to a rated object.  A service is a source of labels
+   where a label includes actual ratings.  Ratings are either specific
+   or generic.  A specific rating applies only to the material at a
+   particular URL [RFC 2396] and does not cover anything referenced from
+   it, even included image files.  A generic rating applies to the
+   specified URL and to all URLs for which the stated URL is a prefix.
+
+   A simplified example label might look like the following:
+
+      (PICS-1.1 "http://movie-rating-service.example.net"
+         labels for "ftp://movies.example.sex/raunchy-movie"
+         ratings (sex 6 violence 1 language 8 drugs 2 Satanism 0))
+
+   Machine readable rating system descriptions include the range of
+   values and set of dimensions provided.  Additional information, such
+   as beginning and ending time of validity, can be incorporated into
+   labels.
+
+
+
+
+
+Eastlake 3rd                 Informational                     [Page 16]
+
+RFC 3675               .sex Considered Dangerous           February 2004
+
+
+   Labels can currently be made available in three ways: (1) embedded in
+   HTML, (2) provided with data in an HTTP response, and (3) separately
+   from a third party.  If content is required to have labels embedded
+   in it or transmitted by the source when data is returned, as in the
+   first two ways listed above, it raises the problems of categorization
+   granularity and forced speech.  However, if used in the third way
+   whereby a separate party determines and provides labels for content,
+   and users are free to select whatever such third party or parties
+   they wish to consult, it can support a myriad of categories, editors,
+   and evaluators to exist in parallel.
+
+   Digital signatures are available to secure PICS Labels [PICS].
+
+5.  Security Considerations
+
+   Any labeling or categorization scheme must assume that there will be
+   deliberate attempts to cause data to be incorrectly labeled and
+   incorrectly categorized.  This might be due to some perceived
+   advantage of particular labeling or merely to disrupt the system.
+   After all, if sources would always accurately and conveniently label
+   sent information, security would be much easier [RFC 3514].  Such
+   enforceability considerations are discussed in conjunction with the
+   various mechanisms mentioned in this document.
+
+6.  Conclusions
+
+   The concept that a single top level domain name, such as .sex, or a
+   single IP address bit, could be allocated and become the mandatory
+   home of "adult" or "offensive" material world wide is legal and
+   technical 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 technically
+   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,
+   as well as cause severe linguistic problems for domain or other
+   character string names.
+
+   However, 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.
+
+
+
+
+
+Eastlake 3rd                 Informational                     [Page 17]
+
+RFC 3675               .sex Considered Dangerous           February 2004
+
+
+7.  References
+
+7.1. Normative References
+
+   [PICS]         Platform for Internet Content Selection PICS 1.1
+                  Rating Services and Rating Systems -- and Their
+                  Machine Readable Descriptions <http://www.w3.org/TR/
+                  REC-PICS-services>, October 1996.
+
+                  PICS 1.1 Label Distribution -- Label Syntax and
+                  Communication Protocols <http://www.w3.org/TR/REC-
+                  PICS-labels>, October 1996.
+
+                  PICSRules 1.1 Specification
+                  <http://www.w3.org/TR/REC-PICSRules>, December 1997.
+
+                  PICS Signed Labels (DSIG) 1.0 Specification
+                  <http://www.w3.org/TR/REC-DSig-label/>, May 1998.
+
+   [RFC 791]      Postel, J., "Internet Protocol", STD 5, RFC 791,
+                  September 1981.
+
+   [RFC 977]      Kantor, B. and P. Lapsley, "Network News Transfer
+                  Protocol", RFC 977, February 1986.
+
+   [RFC 1035]     Mockapetris, P., "Domain Names - Implementation and
+                  Specifications", STD 13, RFC 1035, November 1987.
+
+   [RFC 1591]     Postel, J., "Domain Name System Structure and
+                  Delegation", RFC 1591, March 1994.
+
+   [RFC 1945]     Berners-Lee, T., Fielding, R. and H. Frystyk,
+                  "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945,
+                  May 1996.
+
+   [RFC 2373]     Hinden, R. and S. Deering, "IP Version 6 Addressing
+                  Architecture", RFC 2373, July 1998.
+
+   [RFC 2374]     Hinden, R., O'Dell, M. and S. Deering, "An IPv6
+                  Aggregatable Global Unicast Address Format", RFC 2374,
+                  July 1998.
+
+   [RFC 2616]     Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
+                  Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext
+                  Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
+
+
+
+
+
+
+Eastlake 3rd                 Informational                     [Page 18]
+
+RFC 3675               .sex Considered Dangerous           February 2004
+
+
+   [RFC 2663]     Srisuresh, P. and M. Holdrege, "IP Network Address
+                  Translator (NAT) Terminology and Considerations", RFC
+                  2663, August 1999.
+
+   [RFC 2810]     Kalt, C., "Internet Relay Chat: Architecture", RFC
+                  2810, April 2000.
+
+   [RFC 2821]     Klensin, J., Ed., "Simple Mail Transfer Protocol", RFC
+                  2821, April 2001.
+
+   [RFC 2822]     Resnick, P., Ed., "Internet Message Format", RFC 2822,
+                  April 2001.
+
+   [RFC 2980]     Barber, S., "Common NNTP Extensions", RFC 2980,
+                  October 2000.
+
+7.2.  Informative 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,
+
+   [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>
+
+
+
+
+Eastlake 3rd                 Informational                     [Page 19]
+
+RFC 3675               .sex Considered Dangerous           February 2004
+
+
+   [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>
+
+   [RFC 1034]     Mockapetris, P., "Domain Names - Concepts and
+                  Facilities", STD 13, RFC 1034, November 1987.
+
+   [RFC 1715]     Huitema, C., "The H Ratio for Address Assignment
+                  Efficiency", RFC 1715, November 1994.
+
+   [RFC 2396]     Berners-Lee, T., Fielding, R. and L. Masinter,
+                  "Uniform Resource Identifiers (URI): Generic Syntax",
+                  RFC 2396, August 1998.
+
+   [RFC 2460]     Deering, S. and R. Hinden, "Internet Protocol, Version
+                  6 (IPv6) Specification", RFC 2460, December 1998.
+
+   [RFC 2535]     Eastlake, 3rd, D., "Domain Name System Security
+                  Extensions", RFC 2535, March 1999.
+
+   [RFC 2606]     Eastlake, 3rd, D. and A. Panitz, "Reserved Top Level
+                  DNS Names", BCP 32, RFC 2606, June 1999.
+
+   [RFC 2811]     Kalt, C., "Internet Relay Chat: Channel Management",
+                  RFC 2811, April 2000.
+
+   [RFC 2812]     Kalt, C., "Internet Relay Chat: Client Protocol", RFC
+                  2812, April 2000.
+
+   [RFC 2813]     Kalt, C., "Internet Relay Chat: Server Protocol", RFC
+                  2813, April 2000.
+
+   [RFC 2854]     Connelly, D. and L. Masinter, "The 'text/html' Media
+                  Type", RFC 2854, June 2000.
+
+   [RFC 3513]     Hinden, R. and S. Deering, "Internet Protocol Version
+                  6 (IPv6) Addressing Architecture", RFC 3513, April
+                  2003.
+
+   [RFC 3514]     Bellovin, S., "The Security Flag in the IPv4 Header",
+                  1 April 2003.
+
+   [WARSHAVSKY]   Congress weighs Net porn bills," CNET article,
+                  February 10, 1998, <http://news.cnet.com/
+                  news/0-1005-200-326435.html>
+
+
+
+
+
+Eastlake 3rd                 Informational                     [Page 20]
+
+RFC 3675               .sex Considered Dangerous           February 2004
+
+
+8.  Acknowledgement
+
+   The contribution and efforts of Declan McCullagh, who wrote
+   substantially all of sections 2 and 3 of this document, are
+   gratefully acknowledged.
+
+9.  Authors' Addresses
+
+   Donald E. Eastlake 3rd
+   Motorola Laboratories
+   155 Beaver Street
+   Milford, MA 01757 USA
+
+   Phone: +1-508-786-7554 (w)
+          +1-508-634-2066 (h)
+   EMail: dee3@torque.pothole.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake 3rd                 Informational                     [Page 21]
+
+RFC 3675               .sex Considered Dangerous           February 2004
+
+
+10.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2004).  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 assignees.
+
+   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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake 3rd                 Informational                     [Page 22]
+