Home / Blogs

An Alternative to .XXX: IANA Adult Port Assignments

As an alternative to the creation of the .XXX TLD, ICANN/IANA can assign special port numbers that can be used to label adult content.


IANA assigns port numbers as part of its duties. For example, port 80 is reserved for the HTTP protocol (i.e. the World Wide Web). Port 443 is reserved for the HTTPS protocol (SSL-secure version of HTTP). Port 23 is for Telnet, port 25 is for SMTP, and so on. One can see the full list at here.

One can theoretically run protocols over any port (e.g. you can have a web server on port 25 or port 18666—http://localhost:18666/ could access a webserver running locally on port 18666). In a real sense, the IANA port assignments are just suggestions to the world as to what to expect on certain ports, whether it be a mail server, WHOIS, FTP, POP email or any other service/protocol.

.XXX Proposal

Ultimately, the .XXX proposal comes down to the use of a top-level-domain (TLD) string as a label mechanism. It creates an expectation that if one goes to the domain example.xxx, it will probably have adult content.

The .XXX proposal has been very controversial, as one can see from the public comments.

One of the major criticisms is the name allocation mechanism. There can only be one sex.xxx or porn.xxx, for example. Should that domain be allocated to the current registrant of sex.com? What about the registrant of sex.ca or sex.co.uk or sex.net or sex.de or other existing TLDs? Allocation mechanisms such as auctions or RFPs or “priority to oldest existing registered domain” and other systems have been discussed, but none that will make everyone happy.

In addition, there has been a great concern that trademark holders or existing registrants will need to make defensive registrations, in order to prevent their comparable domains to be registered in the .XXX space. For example, IBM might never want to get into the adult content business, but will likely be compelled to register IBM.XXX. Mercedes-Benz owns Mercedes.com, and likely will not want to see adult content at Mercedes.XXX via a webcam girl whose first name happens to be “Mercedes.” A non-trademark holder (e.g. an individual John Smith) might feel compelled to register JohnSmith.XXX to ensure that someone else doesn’t register it and use it inappropriately. Some have argued that new TLDs are almost guaranteed a profit because of the vast number of defensive registrations that are made in sunrise periods, usually at premium prices relative to general registrations, in order to prevent cybersquatting.

There are also concerns that registrants will need to pay $60/year or more to a new registry, which is considerably higher than their existing domains, and that this represents a “tax” on their business, increasing their costs for the benefit of a for-profit registry operator.

Suppose .XXX was rejected. Does an alternative mechanism exist to label content? There already exist mechanisms such as ICRA labels, for instance. They can be used with any TLD, and don’t require a new TLD. Indeed, the use of .XXX is really a very simple form of a label, in that a domain using it is allowing a “binary choice” form of filtering, either something is in .XXX, or not in .XXX (i.e. “on/off”). Others have counter-proposed .KIDS, as a white-listed TLD, instead.

Use of Port Numbers as a Label

Another alternative would be for ICANN/IANA to assign, reserve and register port numbers specifically for adult-related content. As an example, port 18666 is currently unreserved/unassigned, and can thus be used as a label to the world to expect adult content to be on that port. Ports 18001 through 18180 are also unreserved/unassigned at present. (Age 18 is typically the age at which one is considered an “adult”, thus motivating those particular numeric choices; the “666” is there for those who recall the April Fool’s Joke about the “Evil Bit”, i.e. RFC 3514. So, one can in a way consider this the “Evil Port”, if one has a sense of humour, although there is no technical reason why any random port can handle the job of being the label.) Ideally, two ports would be reserved, to be able to have counterparts to secure (HTTPS) and non-secure (HTTP) protocols.

Adult companies that wish to label their content could thus do so by serving their content on the chosen port (I’ll use 18666 in the following examples, but it can be anything that ICANN/IANA decides upon).

Instead of having a nude image at http://www.example.com/nude.jpg the webmaster could instead “label” it by having the nude image come instead from http://www.example.com:18666/nude.jpg . Browsers like Internet Explorer, FireFox and Opera could eventually even shorten the above using “adult” as a replacement for the combination of “http” and “18666”, so that one could use “adult://www.example.com/nude.jpg” as a URL.

On a technical level, this is very easy to implement, as Apache and other webservers can be configured to serve up content on any port. At a first approximation, the cost is $0. It is obviously much cheaper and less disruptive to implement for adult webmasters than registering .XXX domains.

Also, the contention over the allocation mechanisms of a .XXX domain would disappear under this alternative. Sex.com, sex.ca, sex.net, sex.de, sex.co.uk, and all other TLDs can co-exist, all serving up their adult content on ports 18666 instead of port 80, if they wanted to use a port-based label mechanism. Companies like Playboy, Penthouse, etc. need not register any new domains, they just would change a webserver setting instead if they wished to use this alternative form of a content label.

There would be no need for defensive registrations, as folks could continue along with their existing domains. Mercedes-Benz, Gucci, Yahoo, Chanel or other brandholders would not need to worry that cybersquatters have another playground in which to infringe upon their trademarks.

Some supporters of .XXX only support it if governments make it mandatory. Their theory is that it would be a lot easier to filter adult content if it was all located in the .XXX space. However, if the government instead made it mandatory that all adult content was served from port 18666, it could be filtered just as easily (it’s a very trivial firewall rule to permit/deny access to a single port). ISPs or parental filtering software could filter a single port just as easily as they can filter a single TLD.

Some supporters of .XXX want to make a lot of money (i.e. through operation of the registry, being a registrar, or speculating in domain names)! The use of port 18666 would not make these people happy, though, as there’d be no pot of gold at the end of the rainbow, to implement use of a port label such as port 18666 to identify content. However, if it is the goal of ICANN to find efficient and low-cost solutions to “problems”, the use of ports as a label mechanism is offered as an alternative to solve the same problems that .XXX purportedly solves.

If you support this as a low-cost and efficient alternative proposal to .XXX, you can still leave public comments for ICANN at [email protected] (mentioning “IANA Adult Port Assignments” in the subject somewhere might make things easier to track) before ICANN makes its decision on .XXX at the end of March.

By George Kirikos, President, Leap of Faith Financial Services Inc.

Filed Under


George Kirikos  –  Mar 17, 2007 7:20 PM

As a followup, after I submitted the above article I read about:


which is a very similar idea (derived independently; I guess great minds think alike, or fools seldom differ).

John Levine  –  Mar 18, 2007 12:59 AM

This is a terrible idea for mostly technical reasons.

There’s only about a thousand port numbers that can be used by net services. (Port numbers are a 16 bit field, but numbers above 1024 are traditionally available for dynamic allocation as programs need them, and it would require a global software upgrade to change that.)

Historically the demand for port numbers has been quite low, since the only reason to allocate one is when someone comes up with a new technical communications protocol.  The allocation process has been quite nerdy. Part of the IETF’s RFC publication process is to note which RFCs define something that needs its own port.  In practice, a new port number gets assigned a few times a year.

But if you were to assign semantics to port numbers, there’d be a huge land rush, they’d become valuable, and you would run into exactly the same arguments about allocation that you have now about TLDs, only it’ll be worse since unlike TLDs, we can and would run out of available port numbers.

George Kirikos  –  Mar 18, 2007 2:57 AM

I believe it is port numbers above 49151, not 1024, that you refer to, see here, and note that there is a section “The Dynamic and/or Private Ports are those from 49152 through 65535.” Those between 0 and 1023 are the ones that are restricted to “system (or root) processes or by programs executed by privileged users.”

The ones between 1024 are 49151 are still somewhat limited in number, of course, albeit 48 times less limited than below 1024, and ICANN/IANA would have to be conservative in allocating any additional “evil ports.”

John Levine  –  Mar 18, 2007 3:31 AM

No, it’s ports above 1024. I’m referring to what TCP software on actual computers actually does. Every TCP connection requires a port number at both ends, and the normal approach in TCP software is to for the client end of a connection to pick an arbitrary port number which often is down in the 2000 or 3000 range.

But whether the limit is 1K or 64K, the number is small enough that hoarding would happen. I can assure you that IANA would be no match for the speculators, and we’d have a port shortage, a flurry of lawsuits, or probably both.

As soon as you need an allocation policy, you have all the same problems you have with the TLD allocation policy, so what have you accomplished other than to make it much harder for actual new protocols to get the port numbers they need?

The Famous Brett Watson  –  Mar 18, 2007 4:50 AM

I can think of a large number of variations on this theme, such as the inclusion of a keyword in the URL, using “xxx” as a bottom-level domain name (instead of the traditional “www”—cute, huh?), using PICS or various other content-marking schemes, and so on. But then it struck me that I’m not sure what the problem is. Consequently, I don’t know if any of my solutions (or the port number solution) actually solve anything.

What problem are we trying to solve, here? I don’t think there’s any agreement as to what the problem is, or even if there is a problem.

Are we looking for a technical solution to the problem of keeping kids away from porn on the Internet? (Gloss over the globally inconsistent definitions of “kids” and “porn” for now.) Is that what “.xxx” is about? Are we saying we don’t need “.xxx” because we have other ways to label porn? Well yeah, PICS is over ten years old. Remember PICS? I’m sure some of you remember it. PICS shows that technical solutions to the kids+porn problem are easy: it’s just getting all the necessary parties to actually use them that’s hard.

But it seems to me that the “.xxx” registry idea was not proposed as a protective measure. Like most applicants with a TLD proposal, this was primarily intended to be a money-maker, and I’m pretty sure they don’t care whether the money is from real pornographers or preemptive registrations. Money is money. Is the problem that “.xxx” would mean another domain name land-rush? That didn’t stop “.eu” did it? Why do we care about a “.xxx” land-rush?

If your concern is not the land rush itself, but rather that a name associated with you may be registered under “.xxx”, and this possibility doesn’t sit well with you, then go ahead and oppose “.xxx” on the basis of “potential for malicious use” or something. There’s no real need to offer alternatives if this is the problem: just say “no”.

Solutions are a dime a dozen. Being able to actually identify the problem: that’s gold.

Comment Title:

  Notify me of follow-up comments

We encourage you to post comments and engage in discussions that advance this post through relevant opinion, anecdotes, links and data. If you see a comment that you believe is irrelevant or inappropriate, you can report it using the link at the end of each comment. Views expressed in the comments do not represent those of CircleID. For more information on our comment policy, see Codes of Conduct.

CircleID Newsletter The Weekly Wrap

More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.

I make a point of reading CircleID. There is no getting around the utility of knowing what thoughtful people are thinking and saying about our industry.

Co-designer of the TCP/IP Protocols & the Architecture of the Internet



Brand Protection

Sponsored byCSC

Domain Names

Sponsored byVerisign


Sponsored byVerisign

New TLDs

Sponsored byRadix


Sponsored byDNIB.com

IPv4 Markets

Sponsored byIPv4.Global

Threat Intelligence

Sponsored byWhoisXML API