RFC 3675

.sex Considered Dangerous

📅 published February 2004, from ietf

📄 .sex Considered Dangerous 🎀

okay bestie, this RFC is basically a giant "pls don't do this" note about the idea of a .sex or adult-only domain 💅 Here's the title block so you know who wrote it and when:

  • RFC: 3675
  • Title: .sex Considered Dangerous
  • Author: D. Eastlake 3rd, Motorola Laboratories
  • Working group: Network Working Group
  • Category: Informational
  • Date: February 2004
  • Obsoletes / Updates: nothing is listed in the header

Status of this Memo ✨

this one's just informational, bestie 🦋 It's not a standard of any kind, and you can distribute it as much as you want.

Copyright (C) The Internet Society (2004). All Rights Reserved.

Abstract 💜

every so often somebody suggests a special top level name, or an IP address bit, to flag "adult" or "unsafe" stuff. This doc explains why that's an ill considered idea 🙈 It looks at it from the legal, philosophical, and especially the technical side.

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

    7.1.  Normative References . . . . . . . . . . . . . . . . . . 18
    7.2.  Informative References . . . . . . . . . . . . . . . . . 19
8.  Acknowledgement. . . . . . . . . . . . . . . . . . . . . . . . 21
9.  Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 21
10. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 22

1. Introduction 🦋

so people keep floating the idea of a special top level name or an IP address bit to mark "adult" or "unsafe" material, or whatever 👀 Spoiler: this doc says it's a bad plan, and it explains why from the legal, philosophical, and technical angles 🫶

2. Background 🌸

So the idea of a .sex, .xxx, .adult, or similar top-level domain, where salacious or similar material would have to live, keeps popping up with some politicians and commentators 💅 Other ideas include a domain only for material viewed as appropriate for minors, or using IP address bits or ranges to split up content.

In an October 1998 report for 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" 😭 They also said they were wary of regulating the computer industry, and that any decision by the U.S. government "will have international consequences" [HOUSEREPORT].

British Telecom backed adult top-level domains 🍓 In a 1998 letter to the U.S. Department of Commerce, they said they "strongly supported" that plan. Their reasoning: "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 execs have endorsed the concept too 💜 In 1998, Seth Warshavsky, president of the Internet Entertainment Group, told the U.S. Senate Commerce committee he'd like to see a .adult domain. "We're suggesting the creation of a new top-level domain called '.adult' where all sexually explicit material on the Net would reside," Warshavsky said in an interview at the time [WARSHAVSKY].

More recently, other folks in the industry have said they don't necessarily object to an adult domain, as long as they can keep using .com 🙈

Conservative groups in the U.S. aren't eager for such a domain. They'd rather have criminal laws aimed 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 🎀 In a prepared statement, he said "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 that created 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 an adult domain might be only "moderately effective", and that it raises privacy and free speech concerns [COPAREPORT].

The commission also explored a so-called red zone or green zone for content, done by allocating a new set of IP addresses under IPv6 🧚 Any material not in one of those two zones would be viewed as being in a gray zone, and not necessarily appropriate or inappropriate for minors. The 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 aren't entirely clear, but former ICANN Chairwoman Esther Dyson said the adult industry didn't entirely agree that such a domain would be appropriate. One .xxx hopeful, ICM Registry of Ontario, Canada, asked ICANN to reconsider in December 2000 [ICM-REGISTRY].

In 2002, the U.S. Congress mandated the creation of a kids.us domain for "child safe" material 🌈 This came after they were 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.

okay bestie, let's talk about the legal drama 🍿 when it comes to sexually-explicit material, every person, court, and government has a totally different vibe on what's acceptable and what's not. Attitudes shift over time, so something that's fine in one town or year can spark protests the next year. 😭 When it came to figuring out which depictions of sexual activity should be illegal, one U.S. Supreme Court justice basically shrugged and said obscenity is: "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". 🙈 So even at the national level, there's no agreed-upon rule for what's illegal and what isn't. It's giving chaos. And it gets messier, because there are over 200 United Nations country codes, and in most of them, political subdivisions can impose their own restrictions. 🌍 Even legal nude modeling has different age limits. They're commonly 18 years of age, but only 17 years of age in one Scandinavian country. 🧚 A photographer there running what's seen as a legal and proper photo shoot would be branded a felon and child pornographer in the U.S.A. Wild, right? In yet other countries and groups, the whole idea 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, heavily filter their Internet connections and have set up government agencies to protect their society from websites that officials see as immoral. 🚫 Their views on what should be included in a .sex domain would hardly be identical to those in liberal western nations. Not the same vibes at all. 💅

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. 😤 Plus, having a domain like that would create an irresistible temptation for conservative legislators to force controversial publishers to move there and punish anyone who doesn't. Not it. 🙅‍♀️

Some conservative politicians already complained that ICANN did not approve .xxx at 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". 💀 Major tea.

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 give up their current domain name. 🎀 Instead, they'd likely add a .xxx variant and keep their original address. But here's the catch: the existence of .xxx could push legislators in the U.S. and other countries to require them to publish exclusively from an adult domain. That would invite ongoing political interference with Internet governance, and raise concerns about forced speech and self-labeling. 😬 Big yikes energy.

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 reported in July 2000 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. So even the people in charge weren't 100% sure who gets to be in charge. 🤷‍♀️

The American Civil Liberties Union, along with other members of the international Global Internet Liberty Campaign, warns 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 they're there, they'd be stigmatized and easily blocked by schools, libraries, companies, and other groups using filtering software. And publishers of this kind of information, who don't see themselves as pornographers and keep their existing addresses, could be targeted for prosecution. That's not it, that's not it at all. 😭

An adult top-level domain would likely open the door for related efforts, whether policy or legislative. 🦋 There are many different axes along 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. 🌀 Suggestions like these invite ongoing lobbying of ICANN, the U.S. government, and other policy-making bodies by special-interest groups that aren't concerned with the technical feasibility or practicality of their advice. Lowkey a whole mess. 🙃

An adult top-level domain could also 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". (For the record, 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 get harmed by this kind of proposal too. 🔒 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. 😩 And it's also implausible that a top-level domain would be effective at controlling access to chat, email, newsgroups, instant messaging, and new services yet to be invented. The internet is literally always evolving, bestie. 🚀

4. Technical Difficulties 🛠️

Okay, so even if we ignore all the philosophical and legal drama above, there are still some seriously big technical difficulties with trying to sort content by domain names or IP addresses. 🤯 Mandatory content labeling is usually pushed with the idea of using a top-level domain name, which we talk about in section 4.1., but we also look at the possibility of using IP address bits or ranges in section 4.2.

In section 4.1.4., we get into difficulties with a few particular higher-level protocols. Some of these protocols use different name spaces, so it's giving "every protocol is its own little world" energy. 🌍 Keep in mind that future protocols might be devised with naming characteristics nobody has even dreamed of yet. ✨

We also talk about PICS labels [PICS] as an alternative technology in section 4.3. 🎀

Only a limited technical background is assumed here, so some basic info is included below. 🧸 In some cases, descriptions are simplified and details are left out, so don't come for me in the comments. 🙈

This technical discussion minimizes the definitional problems. 💡 Still, to evaluate some technical considerations, we need some estimate of how much categorization would be necessary for a realistic global censorship system. There's no hope of agreement on this point, so we'll arbitrarily assume that the world's population consists of approximately 90,000 overlapping communities, each with a different categorization of interest. 🌐 We'll also 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's too small. Either way, we'll 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 it hasn't been deployed to any significant extent yet. 🔐

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. So 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>. It could also be the name of a computer (say mailhost.example.com) that handles mail addressed to anyone "@foo.example.com", and/or other information. 📬

There are also other naming systems in use, like newsgroup names and Internet Relay Chat (IRC) channel names. 💬

The usual labeling idea 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: whose language do you take the names from to impose? 🤔 Words and acronyms can mean very different things in different languages, and the chance of confusion multiplies when phonetic collisions are considered. Oops. 🙃

As an example of possible problems, the government of Turkmenistan suspended new registrations in ".tm" for several years. That was a source of revenue, but some of the registered second-level domain names may have been problematic. 💸 In particular, their web home page at <http://www.nic.tm> said:

Statement from the .TM NIC "The response to the .TM registry has been overwhelming. Thousands of names have been registered from all over the world. Some of the names registered, however, may be legally obscene in Turkmenistan, and as a result the .TM NIC registry is reviewing its naming policy for future registrations. The .TM NIC has suspended registrations until a new policy can be implemented. We hope to be live again shortly."

Imagine being the registry and having to explain that one. 😭 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) 🌈

okay so the DNS is honestly a masterpiece. It's built on hierarchical delegation of data maintenance, and that's the reason it has been able to scale over the five orders of magnitude it has grown since it was first deployed. Iconic design, no notes 💅

Now the first problem. Most computers or web sites have a mix of stuff, and only some of it should be specially classified 🙈 Using special top level domain names (TLDs) multiplies the number of DNS zones the site has to manage. Say the site has 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. That only needs the maintenance of the single example.net zone of database entries, which is so clean 🧚 With special TLD labeling, though, at least example.net (for normal stuff), example.net.sex, and example.net.kids would need to be maintained. That's three separate zones, in different parts of the DNS tree, under three separate delegations. Way too much going on for one site 😭

As the number of categories grows, the number of category combinations explodes, and it quickly becomes completely unmanageable 💀 If 300 bits worth of labeling is required, the system could, in theory, need 2**300 name categories. That's an impossibility. No individual site would need to use all of the categories, and the category domain names wouldn't all have to be top level names. But it would still be an unmanageable nightmare 🫠

4.1.3. You Can't Control What Names Point At You! 🙅‍♀️

ngl this one is so frustrating. Providers of data on the Internet cannot stop anyone from creating names that point to their computer's IP address with misleading domain names 😤

The DNS 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, a domain name within that URL is most commonly 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 others). So the controller of example.com can insert data so that purity.example.com has the same computer address associated with it as www.obscene.example.sex. This directs any reference to purity.example.com to use that 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 making it conform to any ".sex" labeling law 🙃 Or someone could create a name that conforms to an adult labeling requirement, such as foo.stuff.sex, that actually points to someone else's totally unobjectionable site, maybe just to pollute the labeling 🎀 See the diagram below. Each "zone" could be hosted on a different set of physical computers.

         +-----------------------------------------+
         |          . (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 more considerations for particular protocols, and we'll only look at 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 they show even more technical problems with name based labeling 💜

4.1.4.1. Electronic Mail (SMTP) 📧

Standard Internet tools give you no way to stop users from putting arbitrary domain names inside email headers 😩

The standard Internet email protocol separates "envelope" information from content [RFC 2821, 2822]. The envelope info says where a message claims to have come from and who it's supposed to be delivered to. The content has fields that start with labels like "From:" and "To:", but those content fields actually have no effect, and anyone can forge them with simple, normally available software, like telnetting to the SMTP port on a mail server 🫣 Content fields aren't compared with envelope fields. Requiring them to match would be like requiring that postal letters dropped in a mailbox list that mailbox as their return address, and only letting residence or business return addresses on mail the post office picks up from that residence or business. Lol, no thanks 📮

Different mail clients show envelope info and headers differently, but generally the main content fields get the most prominence. So even though it's not exactly the same as content labeling, it's super easy to send mail to anyone with arbitrary domain names in the email addresses in the From and To headers, and so on 💅

It's also easy to set up a host that forwards mail to an email address or mailing list. Mail sent with normal mail tools to this forwarder will automatically have content headers that reflect the forwarder's name. But the forwarder changes the envelope information and causes the mail to actually be sent to the forwarding destination mail address 🦋

For example (with names disguised), there's a social mailing list, innocuous@foo.example.org, and someone set up a forwarder at cat-torturers@other.example. Mail sent to the forwarder gets forwarded and shows up 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's work going on to secure email, but for now those efforts only let you verify whether or not a particular entity was the actual author of the mail. When they provide authentication, they add yet a third type of "From" address alongside the envelope and content "From" addresses. They don't relate to controlling or authenticating the domain names in the content of the mail, though 🥲

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. So web sites with different domain names can be accessed even if they're 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 reached through different domain names. But for a computer with any reasonable variety of data, the explosion of trying to name every type of data differently would require an unmanageable number of names 🍓

With the earlier HTTP 1.0 [RFC 1945], the original domain name used in the URI was not included when a web request was sent to a server machine 🕰️

On the other hand, the web has automatic forwarding 🏃‍♀️ So when someone tries to access data at a particular domain name, the server there can redirect the browser, temporarily or permanently, to a different name. It can also redirect you to a numeric IP address, which gets around name filtering. Wild, right? 🙃

4.1.4.3. News (NNTP) 📰

Net news [RFC 977, 2980] uses hierarchically structured newsgroup names that look similar to domain names, except the most significant label is on the left and the least on the right, the opposite of domain names 🔄 Even though the names are structured hierarchically, there's 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 only on messages in the newsgroups they want to exchange ✨

Hierarchical zones in the domain name system are managed locally, but they need to be reachable starting at the top level root servers, which are more or less controlled by ICANN and the US Department of Commerce 🏛️ In the net news world there's no central point or points like that. Any pair or larger set of news servers anywhere in the world can agree to exchange news messages under any newsgroup names they like, including duplicates of names used elsewhere on the net. That makes central control, or even influence, virtually impossible 👑 In fact, within some parts of the newsgroup namespace on some servers, anyone can create new newsgroups with arbitrary names 🫶

Even if newsgroup names could be controlled, the contents of the messages are decided by posters. Some groups are moderated, but most aren't. "Cancel" messages can be sent out for news messages, but that mechanism is open to abuse, so some servers are configured to ignore cancels 🙅‍♀️ Either way, the message may have been distributed to a huge number of computers worldwide before any cancel goes out 😱

And of course, fitting 300 bits worth of labeling into newsgroup names is just as impossible as fitting it into domain names 💀

4.1.4.4. Internet Relay Chat (IRC) 💬

Internet Relay Chat [RFC 2810-2813] is another example of a service that 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 isn't hierarchical, each server has to know about all the names, and that limits how big a network of servers can get 🫠

As with newsgroup names, IRC channel names are local decisions. They aren't subject to or reachable from any global "root", which makes centralized political control virtually impossible 🌈

4.2. Content Filtering Using IP Addressing 🌈

Okay so this is where it gets really interesting, bestie 🧚 The Internet Protocol (IP) is literally what the whole Internet is built on, and its big thing is that it chops data up into "packets". Each packet gets handled and routed individually from source to destination, and every single one carries a numeric address for where the Internet will try to deliver it. 📦

(Real talk, end users don't normally see these numbers 🙈 They deal with "domain names" like we covered in section 4.1. above.)

The main numeric address system in use right now is IPv4, aka Internet Protocol Version 4, which gives you 32 bit addresses [RFC 791]. There's a lowkey big migration happening to the newer IPv6 [RFC 2460], which gives you 128 bit addresses [RFC 2373, 2374]. 🚀

Packets can get modified maliciously in transit, but the most common result is denial of service. 💀

Using addresses for content filtering is a very coarse technique, and that's the first problem 😭 IP addresses refer to network interfaces, which usually correspond to entire computer systems. One system could house multiple web pages, sets of files, and more, and you might only want to block or enable a tiny piece of it. Also, a single IP address may increasingly correspond to a NAT (Network Address Translation) box [RFC 2663], which hides multiple computers behind it. In that case though, those computers are usually not servers. 🖥️

But even beyond that coarse granularity, the practical constraints of hierarchical routing make allocating even a single IPv4 address bit, or a significant number of IPv6 address bits, impossible. 🙅‍♀️

4.2.1. Hierarchical Routing 🗺️

IP addresses are technically inappropriate for content filtering, bestie, because their assignment is intimately tied to network routing and topology.

As packets flow through the Internet, decisions have to be made about how to forward them "towards" their destination. That happens by comparing the initial bits of the packet destination address to entries in a "routing table", then forwarding the packet as indicated by the table entry with the longest prefix match.

So while the Internet is actually a mesh, we can pretend for simplicity that it has a central backbone at the "top". A packet is typically routed like this:

The local networking code checks its routing table to see if the packet should go directly to another computer on the "local" network, go to a router that specially forwards it to another nearby network, or get routed "up" to a "default" router that forwards it to a higher level service provider's network. If the destination is "far enough away", the packet eventually gets forwarded up to a router on the backbone. That router can't send the packet "up" because it's at the top, in the "default free" zone, so it must have a complete table of the other top level routers to send the packet to. Right now those top level routers are very large and expensive devices, and they have to maintain tables of tens of thousands of routes. 🤯 When the packet reaches the top level router of the part of the network where its destination lies, it gets forwarded "down" to successive routers that are more and more specific and local, until it reaches a router on the local network where the destination address lies. That local router sends the packet directly to the destination computer. ✨

Because all of these routing decisions are made on a longest prefix match basis, IP addresses aren't general names or labels. They're 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's also worth noting that there's some inefficiency in allocation at each level of the hierarchy [RFC 1715]. Allocations are generally a power of two addresses, and as requirements grow and/or shrink, it is not practical to use every address.

(This 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. Those 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 haven't been allocated with this in mind, so renumbering by every organization with hosts on the Internet would be required. That's a Herculean task costing in the billions of dollars. 😩

Even if these problems were overcome, allocating even a single bit near the top of the address bits would likely double the number of routes in the default free zone. That would exceed the capacity of current routers and require upgrading thousands of them to new routers that don't exist yet, at a gargantuan cost. Allocating 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 of this is only if a single bit is allocated to content labeling, let alone more than one. And we're 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, since 300 is a lot larger than 128. And if it were possible, it 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. 🤯

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.

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, where 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 has to assume there will be deliberate attempts to cause data to be incorrectly labeled and incorrectly categorized. 😈 This might be due to some perceived advantage of a 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. ✨

7. References 📚

7.1. Normative References 📚

these are the must-reads 💅 the stuff the rest of the doc leans on, so here's the full list, links and all:

  • [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] PICS 1.1 Label Distribution -- Label Syntax and Communication Protocols <http://www.w3.org/TR/REC-PICS-labels>, October 1996.
  • [PICS] PICSRules 1.1 Specification <http://www.w3.org/TR/REC-PICSRules>, December 1997.
  • [PICS] 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.
  • [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 🦋

these ones are the extra reading, the receipts and background 🧚 not required to implement, but SO good for context:

8. Acknowledgement 🫶

a big shoutout to Declan McCullagh, who wrote substantially all of sections 2 and 3 of this document. the people who make these things happen deserve all the flowers 🌸

9. Authors' Addresses 🎀

the people behind the doc, and how to reach them:

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

the legal bit stays word-for-word, since it's binding and I'm not messing with it 🙈

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. ✨

📦 where this page comes from