You'll need a domain name, for your web site, email, in-addr names in the DNS, and a variety of other reasons. Many IXPs register in the .NET TLD, e.g. "BeirutIX.NET" and "SeattleIX.NET". Others register within their country's ccTLD, e.g. "PTT.BR" and "SwissIX.CH". Many IXPs have names based on their country or city; just plan realistically: if your IXP is not in the largest Internet-using city in your country, you probably shouldn't take the country-name to the exclusion of others. The registries for all top-level domains are found here. While a unique "new generic" top-level domain (ngTLD) confers some significant long-term security benefits, applying for it and setting it up is also a very expensive and time-consuming process, vastly more so than setting up an IXP, so you should rule that course of action out, at least until you're very well established.
It's important to start publishing pieces of information about your IXP as early, and frequently; not only does this create a sense of expectation about the new IXP, but it also shows activity and your progress which is a great way to attract participants to the IXP.
Finding a convenient, and neutral location is one of the more difficult tasks that need to be completed in preparation for the IXP.
It is stongly NOT encouraged to build a facility purely to house the IXP.
IPv4 addresses are now very scarce. IP addresses are normally requested from the Regional Internet Registries (RIRs), and there is one appropriate RIR that serves you, depending upon your location.
List of countries served by ARIN including Canada, the United States, and parts of the Caribbean.
Big-old GIF of a list of countries served by APNIC in the Asia-Pacific region.
LACNIC has a 404-not-found error, but serves Latin America and parts of the Caribbean.
AfriNIC has a 404-not-found error, but serves Africa, including some of the islands of the Indian Ocean.
Some RIRs have reserved blocks of IPv4 addresses for the use of IXPs, and may thus have addresses left after the general pool has been consumed.
Most RIRs default to a /24 of IPv4 address space (that's 256 addresses) for IXPs. That means that your IXP would be able to accommodate, at maximum, about 250 participating networks. That may seem like a lot, but there are already half a dozen IXPs with more participating networks than that. If you're lucky, IPv6 will overtake IPv4 before this constraint limits the growth of your exchange.
Each RIR has its own mechanisms for applying for address space. Generally this consists of filling out a form, and providing supporting documentation. There will likely be an up-front fee, and may be annual recurring fees as well. Because each RIR develops policy independently, and the policies are in a constant state of flux, we won't try to repeat all of them here. Figure out which RIR serves your country, contact that RIR, and ask their staff to walk you through the application process.
In the event that your RIR no longer has any IPv4 space available for IXPs, you will need to resort to the commercial transfer market. Brokers of unused space will match holders of no-longer-needed IPv4 addresses with parties who are looking for more addresses, for a fee.
Under some circumstances, governed by the policies of both RIRs, address space may be commercially transferred from one region to cover a need in another.
Your IXP should eventually have a web site, one or more email lists, a DNS server, and may have other public-facing services. These services will need to be reachable by the public through the Internet. Until IPv6 reachability is sufficient, you'll need at least one unique Internet-routed IPv4 address. The easiest way to get one is to request that one of the participants in the IXP provide the IXP's public-facing server with a statically-routed unique IPv4 address. This means that it needs to be a real, globally-routed, unique address, which is not dependent upon Network Address Translation (NAT). The down-side of this approach is that the ISP that provides the IPv4 address may go out of business or leave the IXP, at which point a transition might have to be performed on short notice.
The alternative is to procure a second /24 block of IPv4 addresses for your public-facing services, and BGP-advertise them to one or more transit providers. This is what large exchanges do. It means more costs and maintenance, in exchange for greater independence and resilience. Since IXP public-facing services do not have reserved pools in the RIRs like peering subnets do, you'll probably need to resort to commercial address space brokers, or a donation of a /24 from a member or other generous party, to make this happen. Again, it's best to speak to your appropriate RIR about this.
Do not subdivide your peering /24 in order to get a block for public-facing services, and do not use an address on the peering /24 for public facing services. Both of these approaches create far more serious problems than they actually solve.
The good news is that IPv6 addresses are plentiful, and come in very large blocks. So at the same time that you're applying for an IPv4 peering block, you should also be applying for an IPv6 block. That block you'll be able to subdivide into a peering subnet and a public-facing-services subnet, and still have a lot left over for any future needs.
Most IXPs today provide some sort of multi-lateral peering service (often called MLPA) through facilities like an onsite BGP route server. The IX managed BGP Route Server makes it easier for participants to change network prefixes with other participants, as, typically, participants start by setting up direct peering sessions to the BGP Route Server, instead of multiple, individual, bilateral sessions. This can be a quick and easy way to get started, and to get prefix exchange happening, at the cost of handing over the responsibility of your network's availability to the IXP operator. Many smaller networks prefer to start peering with the BGP Route Server at the start, because of the ease of setup, but later migrate to setting up individual sessions with their preferred peers.
Choosing a switch doesn't have to be difficult. Aim to get the networks connected at sufficiently high speed (ideally minimum 1Gb/s) now. Don't try to spend too much on the initial switches as you don't want to over-capitalise on your initial installation. It's relatively easy to grow, and extend this as necessary.
Peering relationship are still made on the basis of social interaction and knowledge, so to get your operator (and peering) participants talking to each other, it's strongly recommended that the participants have a chance to meet face to face, to socialise and discuss the value of peering. It's considered good practice for the IXP administrator to introduce new participants to the peering exchange.
As a sign of growth and to signal common operations it's a good idea to provide overall aggregated statistics for the IXP. The simplest way of doing this is still to use opensource software like MRTG, which has no external database dependencies.