Chapter 4. IP Address Space and AS Numbers

All IP addresses aren’t created equal. Which kind of IP addresses to announce over BGP is an important decision: it has a large impact on the reachability of your network, and it also has important financial consequences. The main decision is whether to keep using ISP-based addresses or to apply for an independent address range of your own. This poses an important question: where do IP addresses come from, if not from your ISP?

The Internet Assigned Numbers Authority (IANA) is responsible for assigning the protocol numbers used on the Internet. This includes IP addresses and AS numbers, but the IANA has delegated these activities to three Regional Internet Registries (RIRs):

APNIC: http://www.apnic.net

The Asia-Pacific Network Information Centre in Brisbane, Australia, serves most of Asia, Australia, and the Pacific.

ARIN: http://www.arin.net

The American Registry for Internet Numbers in Chantilly, Virginia, United States, serves North America.

RIPE NCC: http://www.ripe.net

The Réseaux IP Européens Network Coordination Centre in Amsterdam, The Netherlands, serves Europe, the Middle East, and the former Soviet Union countries.

Work is currently underway to establish two additional RIRs: one serving the region of Latin America, and the other serving continental Africa. For the time being, ARIN serves Latin America, the Caribbean, and Africa south of the Sahara, and the RIPE NCC serves Africa north of the Sahara.

In turn, the RIRs delegate responsibility for assigning IP address space to Local Internet Registries (LIRs) or directly to ISPs (which are also considered LIRs by RIPE).

When an ISP requests address space for the first time, the RIR allocates a relatively large block of address space, usually a /20. Then the RIR assigns a smaller range of addresses from this allocation to the ISP. The ISP now gets to announce the full allocation over BGP, but actual use is limited to the addresses that are actually assigned. If the ISP requests more address space for their own use or for customers, further assignments are made from the initial allocation. New blocks of address space are allocated to ISPs from which to draw further assignments if necessary. These allocations are called Provider Aggregatable (PA) address blocks, because an ISP can aggregate several address ranges assigned to customers into a larger range and so announce a relatively small number of routes (one per PA block) over BGP.

The Different Types of Address Space

The IP address assignment policies the RIRs use themselves and impose on LIRs and ISPs are based on RFC 2050, “Internet Registry IP Allocation Guidelines.” These IP address assignment guidelines were developed in coordination with user communities, the Internet Engineering Steering Group (IESG), and the Internet Engineering Task Force (IETF). They have three main goals:

  • Conservation, to let the remaining IPv4 address space last as long as possible

  • Routability, to make sure that assigned addresses are reachable throughout the Internet

  • Registration, so every assignment is unique and to aid troubleshooting

Unfortunately, the conservation and routability objectives are at odds with each other. Conservation calls for assigning the smallest possible number of addresses, while routability is best served by keeping the total number of assigned address ranges to a minimum by assigning large blocks to avoid fragmentation of the IP address space. For regular single-homed organizations, there isn’t much of a problem; ISPs can assign small address ranges from a PA block to such organizations, keeping the number of routes in the global routing table relatively small—one for each PA block. For this reason, it’s hard to get IP addresses from a RIR directly for organizations that connect only to a single ISP: this unnecessarily breaks aggregation. Multihomed networks, on the other hand, can’t get around this and have three options:

Request “Provider Independent” (PI) address space

PI space can’t be aggregated by an ISP, so it must always be announced over BGP “as is.” This was often done in the past, and it’s still possible (but not easy) to get even small blocks of PI space at the time of this writing. It seems this is discouraged, and/or the policies on this may change, but don’t take “no” for an answer too easily when requesting PI space.

Act as an ISP and request a PA block of their own

This is hard to do and expensive, but if you have enough ISP-like traits, it can be worth it, because this is the “highest quality” address space.

Request address space from an ISP’s PA block but announce it as PI space

This is sometimes called “shooting holes” in the ISPs PA block. Since BGP uses a longest-match-first route lookup algorithm, a long prefix (smaller block) will always be preferred over a shorter one. So if your ISP announces a /19 and has assigned you a /23 out of that block, you can announce the /23, and other networks will use that route, regardless of the presence or status of the /19.

The routability of these three types of addresses is potentially very different. Some people feel the current global routing table is already too large with more than 100,000 entries: it takes relatively long to initialize the routing table when a router connects to its BGP peers, and convergence of routing updates across the globe is slower than it should be. Others feel the current situation isn’t problematic, and reasonable growth of the global routing table is possible. There is probably no magic limit where backbone routers stop functioning altogether, but it’s likely that more and more of the larger networks will install filters to minimize the number of routes in their network, just as Sprint did in 1995.

That year, Sprint decided to filter out any prefixes longer than 18 bits in the 206.x.x.x and higher Class C address space. This means that Sprint routers allowed routes in the routing table only for networks the size of 64 Class C’s or larger: if you had a 32 Class C or smaller aggregate in this range, you were unreachable for Sprint customers.

Since 1995, the increase in router CPU speed and memory size has been higher than the growth of the global routing table, so even midrange routers can comfortably handle full routing, and there is little need for such a policy right now. It seems the global routing table is growing exponentially again since late 1998, though not alarmingly fast yet. Before that, it had been growing at a more modest linear rate since the introduction of CIDR in 1993.[16] There is a possibility that transit networks will start filtering out long prefixes (small address ranges) in the future. The three different ways to get address space for use with BGP each have pros and cons with regard to possible filters.

Provider-Independent Address Space

Since more than half the global routing table consists of /24 announcements, those are the first candidates for being filtered. More aggressive filters may even filter out everything smaller than the smallest assigned PA blocks, possibly with some exceptions for “the swamp,” the part of the Class C space assigned in pre-CIDR days(192.x.x.x and part of 193.x.x.x). The currently allocated smallest PA blocks are /20, but much of the Class C space is allocated to ISPs in /19 and larger blocks. With this kind of aggressive filtering, you will be completely unreachable from many parts of the Internet if you depend on a small PI block announcement. Since the RIRs won’t assign you a larger PI block if you can’t demonstrate the need for the number of addresses in question, using a PI block smaller than /20 (especially a /24 or even smaller block) is a dangerous proposition. As RFC 2050 states:

Note that addresses issued directly from the IRs, (non-provider based), are the least likely to be routable across the Internet.

This of course also applies to PI address space requested through an ISP.

Your Own Provider Aggregatable Block

The best way to avoid being filtered is getting a PA block of your own. Since you aren’t expected to use the entire block yourself, you can get a much larger block than would be possible with PI space under similar circumstances. Also, PA blocks are the least likely to be filtered. They are only assigned to ISPs and “enterprise registries,” but if this isn’t too much of a stretch for your business, you can become one by selling connectivity to daughter organizations or to other companies within the same building. ARIN charges a $2,500 fee for assigning /19 or less address space, either PI or PA. Startup and renewal fees apply depending on the situation. An organization requesting address space directly from the RIPE NCC must become a LIR (in other words, a RIPE member) which costs 1,800 euros a year for small ISP and enterprise registries, and there is a one-time 2,100-euro startup fee. APNIC also requires membership and charges an annual membership fee of $1,250 to very small members holding /22 worth of address space or less and a “resource application” fee of $2,500 for the first IP address assignment. All fees are from fee schedules for the year 2002.

The RIR might refuse to allocate you a PA block if they think you are too small an ISP to start using those addresses for yourself and your customers in the near future. (RIPE requires you to demonstrate the need for a /22.) It’s never a good idea to misrepresent the truth when dealing with a RIR, since they will review any previous IP address assignments whenever you submit a new request. Any inconsistencies between the old requests and the current status of the subsequently assigned addresses will, at the very least, delay the processing of the new request. In more severe cases, the new request may be turned down, or previous assignments may even be revoked. On the other hand, nobody can predict the future, so erring on the optimistic side—within reason—when filling in the three-month, one-year, and/or two-year growth figures in the request shouldn’t be a problem.

Warning

It’s possible that the IP addresses you currently hold will be pinged to determine whether they are in use. If you filter ICMP echo and/or echo reply packets, you may want ask your ISPs or RIR if they do this and allow their ping packets through your firewall if necessary.

Address Space From an ISP

If you can’t get a PA block or a sufficiently large PI block to avoid being filtered, the only alternative is to use IP addresses assigned by an upstream ISP from their PA block: the same kind of address space single-homed organizations use. You can announce those addresses over BGP, even though your upstream ISP also announces the larger block. Announcements like this are likely candidates for filtering elsewhere on the Net, but unlike the situation in which PI space is filtered, this isn’t immediately catastrophic; the larger announcement for the ISP PA block is still in place, so you are still reachable in the regular, single-homed way. ISPs would rather not have any holes in their PA blocks, but most will cooperate with such a setup. If your new ISPs allow it, it’s also possible to keep using addresses from an ISP you are no longer connected to. But this should be avoided: when your route is lost, all traffic to your network starts to flow over the old ISP, which can’t send it to you, so you are unreachable. If some other networks filter your announcements, some of your traffic will end up at the old ISP, where either it gets filtered, which you won’t like, or it’s forwarded to one of your current ISPs, which your old ISP won’t like, because you are using bandwidth on their network without paying for it.

Warning

Many ISPs have policies on what kind of announcements that fall within the PA range of a different ISP they will accept from their customers. These policies don’t always make sense. Sometimes they don’t accept this kind of announcement at all; sometimes they will accept them only if the ISP the addresses came from has no objections.

When you are in the process of selecting ISPs, and when you decide from which ISP you’re going to take address space, it’s important to review the interconnection between both ISPs and the route filtering policies they use. Some ISPs won’t announce a prefix out of another ISP’s PA block or will do so only if the other ISP doesn’t object. It’s essential that your ISPs accept the prefix you announce not only from you, but also from the other ISP. This may not be the case if one ISP filters. Figure 4-1 shows why this is important.

Fallback routing when depending on an aggregate
Figure 4-1. Fallback routing when depending on an aggregate

If ISP X filters your announcement, they will send traffic to your network only to the ISP that announces the aggregate your addresses fall in, ISP B in this case. But when your connection to ISP B is down, ISP B can’t deliver the traffic. As long as ISP B peers with ISP A and accepts your announcement from them, the traffic will simply flow over the peering link, and you’re still reachable.

Requesting Address Space

If you have decided you want to use addresses from the PA space of one of your ISPs, you should discuss this with both ISPs to make sure they’re on board with what you want to do. It’s a good idea to get this in writing. Then you can proceed to request the addresses from your ISP.

PI addresses can be requested directly from a RIR, but in most cases, it’s better to request them through one of your ISPs or at least consult with the ISP first. They’ll have to forward your request to the RIR anyway, but involving an ISP will most likely save you time. Your ISP can make sure the request is in order before forwarding it, and the RIRs have more trust in an ISP they’ve worked with before than in someone they don’t know. It may also save you some fees. Make sure your ISP understands you’re talking about provider-independent address space, since this isn’t all that common; few organizations qualify for a large enough block of PI space to avoid filtering.

If you want a PA block of your own, consult your RIR’s web site.

As an end-user organization, you will be asked to provide a full list of subnets with the projected immediate and future use of each subnet when requesting IP address space. Example 4-1 shows how this would appear in the ARIN request form.

Example 4-1. A list of subnets as required for ARIN address requests
--------------------------------------------------------
Subnet#  Subnet Mask      Max  Now   1yr   Description
--------------------------------------------------------
1.0      255.255.255.192   64   36    49   Wired PCs
1.1      255.255.255.224   32   15    30   Wireless PCs
1.2      255.255.255.240   16    7    10   Web servers, DNS
1.3      255.255.255.248    8    8     8   Dial-up modems
1.4      255.255.255.248    8    2     2   Firewall DMZ
--------------------------------------------------------
Totals                    128   68    99
--------------------------------------------------------

The first number (“Subnet#”) doesn’t mean anything: it’s just to keep the subnets apart in later discussions. Note that the “Max” number is the total number of addresses in the subnet, including the normally unusable first (network) and last (broadcast) address, but the “Now” and “1yr” numbers include only the number of addresses actually used for hosts and other systems that require an IP address, such as routers. When compiling the list, start with the largest subnet, so that all subnets automatically start on the proper bit boundaries. See Appendix A for more information on (sub)netmask calculations. The use of Variable Length Subnet Masking (VLSM) and subnet zero are mandatory, but this shouldn’t be a problem for today’s routers. There are also policies about giving each virtual web server its own IP address and giving dial-up, ADSL, and cable users fixed IP addresses. These policies boil down to something like, “Please use dynamic addresses, but if you insist on using static addresses, we’ll assign them, for now.”

If you are in the RIPE or APNIC regions, don’t forget to request delegation of the DNS reverse mapping of your new IP addresses, using the appropriate request forms.[17] The ARIN IP address request form has room for two name servers, so if your name servers will not move to the newly requested address range, there is no need to request delegation separately. If it’s necessary to change this information later, send in a request based on a template that is mentioned in the IP address request form. Due to the structure of the in-addr.arpa zone, the delegation may have to come from the RIR even for IP addresses assigned by an ISP. Ask your ISP if this is the case. It’s also possible just to request delegation from the RIR; they will inform you if your ISP is responsible for delegating authority over this part of the in-addr.arpa space.

The information about IP address assignments and allocations is recorded in publicly accessible databases, one for each RIR. These databases can be queried using the whois protocol, which is, of course, implemented in the whois command, available on every Unix system. There are also versions for most other operating systems, and if all else fails, you can use the whois query tool on each RIR’s web page. (URLs are at the beginning of the chapter.) If you haven’t done this before, you might want to look up your current IP address in the appropriate regional registry’s database:

whois -h whois.apnic.net <address>
whois -h whois.arin.net <address>
whois -h whois.ripe.net <address>

The whois server will then give you the details of the organization the addresses are assigned to, as well as contact information for the administrative and technical contacts for this organization. (This could be you!) The RIR databases contain similar information about Autonomous System numbers, which can be queried by doing a whois query on the AS number (preceded by “AS” for RIPE and APNIC). Much more information about ASes is present in the Routing Registries, discussed later this chapter.

Renumbering IP Addresses

Obviously, you need to renumber IP addresses when switching to a newly requested PI or PA block of your own. But renumbering is also advisable when using multiple address ranges from an ISP: it’s better to announce a single, large block than to announce several small ones. Announcing as few routes as possible keeps the size of the global routing table down, which is good for everyone. Also, the larger your announcement, the less likely your route will be filtered, which is good for you. This means asking your ISP to exchange several small address ranges for a single larger one.

Renumbering is a lot of work, but there are some ways to make it as painless as possible to reconfigure the network equipment and deal with users and other departments who also have to make changes:

Make a plan

That way you don’t forget anything. And if you update the plan when you find something unexpected, you’ll have a much better plan if you ever have to renumber again. (Knock on wood.)

Use the new and old addresses side by side for a while

It’s next to impossible to change everything at once, so you need some overlap between the moment the new addresses become available and the moment the old addresses are decommissioned.

Register the new DNS IP addresses as soon as possible

You need to register the IP addresses for your name servers with the RIR and/or your ISPs for the reverse mappings, and with InterNIC/NSI and all other registries where you have registered domain names, including the registries for any country TLD domains you have. This may take some time, so start this process as soon as your name servers are able to respond to queries sent to the new addresses. Also, all name servers that run as secondaries for your domains, or that are primaries for domains you are secondary for, need to be configured with the new addresses.

Make the translation from the old to the new numbers as simple as possible

It’s much easier to remember and explain that 123.56.7.x becomes 213.75.6.x than arbitrary individual mappings from old addresses to new ones. You will probably make some subnets larger and other smaller, so there will be exceptions to the basic rule, but having a rule with a number of exceptions is still better than having no rule at all. For instance, if you have two Class Cs with about 100 addresses in use, only a few of which with a host address over 128, you might want to merge them into a single new /24 like this: "123.56.7.1 through 123.56.7.126 become 213.75.6.x. 123.56.8.1 through 123.56.8.126 become 213.75.6.x+128. Contact me when your IP address ends in a number higher than 126.”

Start using DHCP for PCs and other workstations

If PCs and workstations use the Dynamic Host Configuration Protocol (DHCP) to obtain an IP address and other information automatically, you have to reconfigure only one or a few DHCP servers when renumbering. Since you have to renumber anyway, it may be worthwhile to switch to DHCP at this point. You can also switch to DHCP first and renumber later, but this is probably hard to do without having a large enough number of spare addresses in the old range. Switching to DHCP but keeping the current address isn’t advisable, because you can’t determine whether the change was successful.

Transitioning the servers painlessly

There are two ways to make the address transition as painless as possible for hosts that run services such as HTTP. It’s best to run with two addresses temporarily. That way, there is no down time and no name server problems. Not all systems support multiple IP addresses on the same interface, however, and some servers, especially HTTP servers, require extensive configuration per IP address, which may be hard to duplicate temporarily.

The alternative is to set the Time To Live (TTL) in the DNS zone file to a low value, such as 300 seconds, a day or more before the transition. This is accomplished by adding the number 300 between the hostname and the “IN” in the zone file. For example:

test    300    IN    A    192.0.2.17

With a lower TTL, remote name servers cache the name-to-address mapping for just 5 minutes instead of the usual 24 hours or more. You can then change the IP address for the server and update the name server, and the new address will be used almost immediately. Without changing the TTL, some systems will connect to the old address and some to the new address for as long as the old information is cached in some remote name servers. Don’t forget to set the TTL back to the default, or the load on your name server will be higher than necessary.

Don’t forget firewalls and other IP-based access restrictions

Most firewalls and many other kinds of access restrictions filter based on IP address. Make a list of every system you have access to, including those on remote networks that aren’t renumbered, and see if you have to configure the new IP addresses somewhere. Use the Unix grep command to find places where IP addresses are mentioned, if necessary. Keep a list of all the places the IP addresses are, so that you can remove the old addresses more easily later. You may want to use DNS names rather than IP addresses in your filters, but do this only when you are certain the DNS replies are always trustworthy enough to depend on for this purpose.

Communicate the new settings to users as soon as they work, but not before

Some users will immediately reconfigure their systems after you’ve told them the new settings for the IP address, netmask, default gateway, and name server, so don’t give them this information until the new addresses actually work. This also saves you from having to inform users again when you have to make changes to the address deployment plan.

Don’t take too much time

If you take six months to complete the address transition, many of the necessary changes that must take place at the end of the transition period (or have been put off) will be forgotten. It’s better to create and maintain some momentum by keeping the transition period short. Two weeks should be enough for users and other departments to do the necessary reconfiguring. This period is, of course, communicated in advance and doesn’t coincide with any busy periods.

Log (attempted) use of the old addresses

By logging the use of old addresses, you can monitor the progress of the renumbering operation. Towards the end of the transition period, you can see who hasn’t renumbered yet and again ask them to do so.

Test decommissioning the old addresses

Disabling the old addresses for a while is a good way to flush out anyone or anything that still uses the old addresses. It’s usually easier to deal with this after enabling the old addresses again for a while: this takes the pressure off. So don’t wait until the last moment to decommission the old addresses, but rather test this a few times in advance.

Test if the addresses have been removed completely

After decommissioning the old addresses, do a few traceroutes to see if the network is really free of them and they are properly routed to the outside.

There is an RFC about renumbering, mostly from a router point of view: RFC 2072 “Router Renumbering Guide.”

The AS Number

The next step towards running BGP is requesting an AS number. The IANA has reserved the AS numbers from 64512 to 65535 for private use, similar to the 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16 IP address ranges for private networks.[18] Note that, unlike networks that use RFC 1918 address space, a network using a private AS number can still enjoy full connectivity to the entire Internet. The use of a private AS number isn’t limited just to private networks but is also useful in cases where a network is fully connected to the Net, but the actual way in which this is accomplished doesn’t have to be communicated throughout the world. For example, a company can have two connections to the same ISP and use BGP to route traffic over those connections in a fault-tolerant way. An AS number is needed to run BGP in this setup, but it can be a private one: the ISP can leave out the specific route to this customer, because this information is covered by an aggregate. Another example would be two companies that independently connect to the Internet but also have a private connection and want to use BGP to exchange routing information between them. In these situations, it’s still important to coordinate the AS numbers to be used with all parties involved, so everybody uses a different AS number.

Multihomed networks connecting to two or more ISPs need a “real” (or rather unique) AS number, which can be obtained from the RIRs, in a way similar to obtaining IP addresses. ARIN charges a one-time fee of $500 and a small yearly maintenance fee per AS. The only fees RIPE charges are the membership and startup fees; there is no extra charge for assigning an AS number. RIPE allows nonmember organizations to submit a request for an AS number to one of their ISPs, who will forward the request to the RIPE NCC. The main requirement for getting an AS number is being multihomed. The RIRs check on this by requiring you to list the ASes you will be connecting to using BGP.

Routing Registries

When running BGP, it’s a good idea to register your routing policy in a Routing Registry (RR). These RRs exist for two purposes:

To aid in troubleshooting

When there is a problem related to your network, others can check the policies to see whether the current routing is the way it should be.

To create filters

Many networks filter routing updates they get from neighboring networks to avoid black holes and routing instability. Filters can be automatically created using the contents of the RRs.

Some ISPs require their customers to register their routing policy in a particular RR, usually their own. Many of the registries replicate each other’s data, so registering at a single RR should be enough. The oldest RRs are the ones at RIPE and the Routing Arbiter Project, along with several run by ISPs. The Routing Arbiter Project was funded by the National Science Foundation from 1994 to 1998 to research leading-edge routing in the United States and to develop tools for routing. The Routing Arbiter Database (RADB) is still operational, now funded by a cost-recovery fee charged to those who register their data in the RADB. The database can be queried at http://whois.radb.net/. ARIN runs a RR separate from their regular database at http://www.rr.arin.net/. The APNIC database also holds some routing information, but it isn’t a full RR. A comprehensive list of RRs is available at the Internet Routing Registry, http://www.irr.net/.

Routing Policy Specification Language

For many years, the data in the RRs was in a format described in RIPE document 181, but most RRs now use the Routing Policy Specification Language (RPSL) defined in RFC 2622, which can define a broader set of routing policies.

Tip

The Routing Policy Specification Language isn’t part of the BGP protocol. The actual implementation of a routing policy on a set of routers is done with filters and route maps, as discussed in Chapter 5 and further.

A simple routing policy in RPSL format and a ROUTE object to link a block of IP addresses to this policy look like this:

whois -h whois.ripe.net 222.33.48.0/20
route:        222.33.48.0/20
descr:        Joes PA block
origin:       AS60000
mnt-by:       JOESWEBFARM-MNT
changed:      joe@joeswebfarm.co.uk 20001020
source:       RIPE
whois -h whois.ripe.net as60000
aut-num:      AS60000
as-name:      JOESWEBFARM-AS
descr:        Joes Web Farm Autonomous System
import:       from AS60001 accept AS60001
import:       from AS60002 accept AS-NANCYSNET
import:       from AS60003 accept ANY
export:       to AS60001 announce AS60000
export:       to AS60002 announce AS60000
export:       to AS60003 announce AS60000
admin-c:      JB600-RIPE
tech-c:       JB600-RIPE
notify:       joe@joeswebfarm.co.uk
mnt-by:       JOESWEBFARM-MNT
changed:      joe@joeswebfarm.co.uk 20001020
source:       RIPE

The routing databases use a hybrid object-oriented/relational model, where different kinds of objects are connected through relationships formed by one object referencing another. For example, the AUT-NUM object has a TECH-C field that links to a PERSON object, rather than containing all the information about the technical contact in the AUT-NUM object itself. The most important objects are:

AS-SET

An AS-SET is used to group a number of ASes together. For instance, all the ASes an ISP announces to other ISPs (this includes the ISP’s own AS and ASes of BGP-speaking customers). If the ASes you speak BGP with accept the AS-SET rather than just your AS number from you, you can later add more AS numbers without neighboring ASes needing to update their ROUTE objects. Naming for AS-SET objects is AS-<name>.

AUT-NUM

The object that describes an Autonomous System. Naming: AS<number>.

MNTNER

Referring to this object protects other objects from being changed by unauthorized persons. The MNTNER (maintainer) object indicates the type of authentication to be used for all objects. Naming: <name>-MNT.

PERSON

This object holds the details about a single person. The “name” of a PERSON object is the NIC handle: <initials><number>-<registry>.

ROLE

This object is similar to a PERSON object, but it applies to a group of people that share a common role, such as a help desk or a network operations center (NOC). ROLE objects use NIC handles like PERSON objects.

ROUTE

The ROUTE object defines which AUT-NUM objects an IP address range belongs to. ROUTE objects are identified by a prefix: <network>/<bits>.

It isn’t necessary to spend a lot of time learning RPSL—many of the objects are fairly self-explanatory, and examples of routing policies will be given later in this book—but RFC 2650, “Using RPSL in Practice” is a good introduction to the Routing Policy Specification Language. Your first interactions with a RR after requesting an AS number should be along these lines:

  1. Select a Routing Registry. This should be the RIPE Database in the RIPE region.

  2. Select a name for your network in the RR, and check if the name is free. The restrictions on these names are similar to those of domain names, and you can’t use names that begin with AS-, RS-, RTRS-, FLTR-, or PRNG- and some names that are words used in policy expressions, such as ANY, NOT, or INBOUND.

  3. Find out how to register a MNTNER object and create one. Instructions are available on the RR’s web site under “Routing Registry” or “database.”

  4. Find out how to update the database. Emailing new or modified objects to a special email address usually does this.

  5. If you are now, or may ever be, in the position to provide IP transit service to another AS, register an AS-SET object containing just your own AS number in the set.

  6. Create an AUT-NUM object for your AS.

  7. Create ROUTE objects for your address blocks.

It’s a good idea to protect your objects in the RR database by using DES or PGP authentication. If you don’t, anyone who knows how to falsify the From: header in an email address can update or delete information about your network. PGP uses strong encryption, but it’s rather complex: installing it just for this purpose is probably overkill, but if you already have it installed, use it. DES encryption works the same way as a traditional Unix passwd file: once the password is encrypted, it can no longer be decrypted. Checking whether a supplied password is correct is done by encrypting this password with the same seed and checking whether the result is identical. This means the encrypted password is listed in the MNTNER object, but when updating any object that links to this maintainer, you have to supply the clear text password in a password: line.

Warning

This type of DES password authentication is open to password-guessing attacks, the passwords can be intercepted on their way over the network, and updating Route Registry information is usually done using unencrypted email.

If you are the administrator of a Unix machine, the easiest way to create a DES-encrypted password is to change the password for a test user with the passwd command and then copy the encrypted password from the /etc/passwd file. However, some Unix systems use the MD5 algorithm rather than DES. RIPE provides more tips and a link to a web page where you can encrypt passwords on the RIPE Database FAQ page: http://www.ripe.net/ripencc/faq/database/qa5.html#5.



[16] “Analyzing the Internet’s BGP Routing Table,” by Geoff Huston (http://macross.dynodns.net/idr/4-1-bgp.pdf

[17] The reverse mapping is the special domain in-addr.arpa in the DNS system that makes it possible for a name server to find the name associated with an IP address. To create a reverse mapping for your IP addresses, authority over the appropriate part of the in-addr.arpa domain must be delegated to your DNS servers.

[18] RFC 1918, “Address Allocation for Private Internets” (formerly RFC 1597), and RFC 1930, “Guidelines for creation, selection, and registration of an Autonomous System (AS).”

Get BGP now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.