From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc3675.txt | 1235 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1235 insertions(+) create mode 100644 doc/rfc/rfc3675.txt (limited to 'doc/rfc/rfc3675.txt') 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 , 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 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 , October 1996. + + PICS 1.1 Label Distribution -- Label Syntax and + Communication Protocols , October 1996. + + PICSRules 1.1 Specification + , December 1997. + + PICS Signed Labels (DSIG) 1.0 Specification + , 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, + + + [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, + + + [GAO] "GAO Report OGC-00-33R", July 7, 2000, + + + [GTLD-MOU] "GTLD-MOU Policy Oversight committee RFC 97-02", + September 13, 1997, + + + [HOUSEREPORT] "U.S. House Commerce Committee report", 105th + Congress, October 5, 1998. + + + [ICM-REGISTRY] "Request for reconsideration from ICM Registry to + ICANN", December 15, 2000, + + + + + +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, + + + [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, + + + + + +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] + -- cgit v1.2.3