Operating an Internet Service Provider is a complicated task that involves careful management of many interdependent areas. In order for the user to utilize the full capacity of the product and enjoy reliable operation, all of these areas must be managed
properly. This is a short document which details some of the problems with the incumbent's network. An explanation of select areas of importance will be accompanied with facts on how the incumbent fails to properly implement in these areas.
DNS stands for Domain Name Service. DNS handles the association between domain names (such as www.apple.com) and the Internet Protocol numbered addresses that computers themselves use to identify each other (such as 22.214.171.124). Every computer on the Int
ernet has a unique IP address. DNS is very helpful to us because domain names are much easier to remember than IP addresses. Each time an Internet user wishes to contact another computer over the Internet (to check mail, or visit a web page, for example),
the name that the user types in must be "looked up" against the database of name to number associations. A DNS server is a computer that performs name to number lookups, and is a very important part of being able to access the Internet (since most user r
equests are made by name, not number). DNS servers are normally configured to store information about only the networks which the owner of the DNS server operates. DNS servers can communicate with other DNS servers in order to retrieve information about c
omputers elsewhere on the Internet. If a DNS server for a given network is not available, the Internet seems broken for users of that network, and access to that network is impossible from the Internet. Cable and Wireless uses Microsoft DNS server softwar
e running on Windows, which is quite prone to problems and outages, and is a generally insecure operating system. A much better solution is any Unix based DNS server, the standard in the industry.
DNS does name to number lookups, but also number to name lookups. The number to name lookup process is called reverse dns. Reverse DNS is often used by a server when a user makes a connection to that server on the Internet. In order for the server to know
the name of the computer that is connecting, the server will often automatically do a reverse DNS lookup on the address that the user is using. So, for example, if our IP address is 126.96.36.199, and we connect to a server, the server would do a DNS lo
okup of 188.8.131.52. We can see the domain name that is associated to that IP address by manually doing a DNS lookup. The output of the Unix "host" program is shown below.
andre@core[~]% host 184.108.40.206
220.127.116.11.IN-ADDR.ARPA domain name pointer ghost20.blackmagiclabs.com
ghost120.blackmagiclabs.com is the reverse dns entry for the IP address 18.104.22.168.
If we do a forward DNS lookup on the name ghost20.blackmagiclabs.com, we should come up with this same IP address.
andre@core[~]% host ghost20.blackmagiclabs.com
ghost20.blackmagiclabs.com has address 22.214.171.124
This shows that both forward and reverse DNS are functioning properly for this domain name, and its associated address.
On the incumbent's network, reverse DNS associations are not implemented for almost all of the IP addresses in use. For example, the IP address 126.96.36.199, which is used for a DSL subscriber on the incumbent's network (the IP address is not fixed to a
ny single subscriber, more on that later in this document), has no reverse DNS entry. When we try to do a DNS lookup on the IP address, no reply is returned.
andre@core[~]% host 188.8.131.52
Host not found, try again.
The problem caused by having broken reverse DNS is the delay that is incurred when trying to connect to some Internet servers. If the server tries to do a reverse DNS lookup on the user's IP when the user connects, no reply is returned. The server waits f
or a specified amount of time for a reverse DNS reply before allowing the user to finish connecting. That time period is called the timeout. Sometimes the timeout is only a few seconds, but more often it's at least 30 seconds, sometimes several minutes. T
he reverse DNS lookup process is not done on most world wide web servers that users connect to, but is almost always used with other Internet protocols such as file transfer protocol (ftp), secure shell (ssh), and others.
The bottom line is that users experience a very substantial delay *every time* they initiate a connection to an Internet server that does a reverse DNS lookup. Oftentimes the program the user is using to make the connection to the Internet server has a ti
meout for connections that is shorter than the timeout of the reverse DNS lookup. In this case, the user's computer would assume that the remote server cannot accept connections, because the timeout is reached on the user's computer before the server real
izes that there is no reverse dns entry for the user's IP address. This would effectively block access to this server, unless the user was aware of this problem and knew enough to increase the timeout on their program used to initiate the connection. Prop
er use of DNS requires that both forward and reverse DNS be implemented. Therefore, the DNS systems on the incumbent's network are literally half-broken.
An IP address is the means by which computers identify themselves and other computers on the Internet (and also on many other small networks which may or may not be connected to the Internet). Proper administration of IP addresses is crucial to the smooth
operation of a network. There are several problems with the incumbent's network in this area.
--Unauthorized use of un-registered IP addresses
There is a fixed number of IP addresses available on the Internet, and they are allocated as needed by internationally recognized authorities which exist for this sole purpose, such as the Internet Corporation for Assigned Names and Numbers (located at ht
tp://www.icann.org) and the American Registry for Internet Numbers (located at http://www.arin.net). These organizations manage the allocation of IP addresses to make sure that they are used efficiently and correctly.
It is possible to obtain information about the ownership of an IP address by using the "whois" page on ARIN's website, located at http://whois.arin.net/whois/index.html. If we do a whois lookup on the IP address we used a moment ago for DNS lookups, 204.1
88.165.78, we see:
Cable & Wireless USA (NETBLK-CW-02-BLK) CW-02-BLK184.108.40.206 - 220.127.116.11
CABLE AND WIRELESS - ANTIGUA (NETBLK-CW-204-188-160) CW-204-188-160 18.104.22.168 - 22.214.171.124
This tells us that the owner is in fact Cable and Wireless USA, and that it exists inside the Antigua group since it falls between 126.96.36.199 and 188.8.131.52 (presumably also because this particular IP address is being used in Antigua). This is as
it should be. To verify that this IP address is reachable, we can use the ping program, which sends a short message to an IP address. If everything is working properly, that message gets sent back, and we're told how long it took to get there and back.
andre@core[~]% ping 184.108.40.206
PING 220.127.116.11 (18.104.22.168): 56 data bytes
64 bytes from 22.214.171.124: icmp_seq=0 ttl=251 time=58.156 ms
This ping was successful, and returned in 58 milliseconds.
If everything is working correctly, I should be able to ping this IP address from anywhere on the Internet. Here are the results of a ping command to this same IP address. This time the ping is coming from a computer in Seattle, Washington, USA.
[andre@tesla andre]$ ping 126.96.36.199
PING 188.8.131.52 (184.108.40.206) from 220.127.116.11 : 56(84) bytes of data.
64 bytes from 18.104.22.168: icmp_seq=0 ttl=241 time=243.715 msec
As you can see, it took quite a bit longer this time; 243 milliseconds, due to the fact that it had to traverse a longer distance than the first ping, which was came from inside the incumbent's network.
Now lets take a look at some of the other IP addresses that Cable and Wireless uses on their network. 22.214.171.124 is an address that is in use currently on the incumbent's network. Here are the results of a ping performed from within the incumbent's net
andre@core[~]% ping 126.96.36.199
PING 188.8.131.52 (184.108.40.206): 56 data bytes
64 bytes from 220.127.116.11: icmp_seq=0 ttl=54 time=66.051 ms
Let's use ARIN to look up the owner of that IP address. ARIN tells us:
No match for "18.104.22.168".
If we try to access this IP address from elsewhere on the Internet, we find that the address cannot be reached. Below are the results of a ping performed from Seattle, Washington.
[andre@tesla andre]$ ping 22.214.171.124
PING 126.96.36.199 (188.8.131.52) from 184.108.40.206 : 56(84) bytes of data.
--- 220.127.116.11 ping statistics ---
2 packets transmitted, 0 packets received, 100% packet loss
This shows that the IP address is inaccessible from Seattle. In fact, it is not accessible from anywhere except inside the incumbent's network.
This means that this IP address is not registered for use by anyone, and therefore should not be in use. It is in use on the incumbent's network, and is accessible from the incumbent's network because the network is broken to allow this to occur. If the incumbent's network followed the proper rules for IP addresses, this address would not be in use, and would not be accessible even if it were.
This is a problem because this address could be legitimately assigned to someone on the Internet in the future. A server operated by the legitimate owner of this IP address would be unreachable from the incumbent's network, since the incumbent's routers a
re broken to provide access to this address used illegitimately for their own purposes. This does not cause problems with services in Tortola (until such time as that IP address is used elsewhere), but it certainly does not conform to IP addressing polici
es used on the rest of the Internet and is a clear sign of a poorly operated network.
There are groups of IP addresses that are set aside by ARIN and ICANN for internal use only. This means that these addresses could be used inside a network, but should never be accessible from outside the network. These are special groups of addresses tha
t will never be assigned to any sole organization. Use of these addresses insures that there would never be an IP address conflict as described in the previous paragraph. The incumbent's network design makes proper use of these reserved addresses in some
areas, but also does not use them where they should be used in other areas. As we'll explain shortly, these reserved addresses are also used where they shouldn't be.
Communication between computers on the Internet involves transferring units of data called packets between those computers. Since the Internet is so large, with so many interconnections, there must be a mechanism for directing packets to any given destina
tion. This process is called routing. Without routing, no user would be able to access computers that are on another network.
One serious problem with the incumbent's network is that it attempts to route the private, reserved addresses mentioned previously. These addresses are specifically reserved for internal use only, yet the incumbent's routers attempt to route them out to t
he rest of the Internet as if they were any other IP address. This will be shown with the Unix traceroute program. This program shows the user the path that a packet takes to get to its destination. First let's look at the results of a traceroute to a web
site performed from within the incumbent's network to www.surfbvi.com, one of the incumbent's web servers.
grizzly:~# traceroute www.surfbvi.com
traceroute to andromeda.surfbvi.com (18.104.22.168), 30 hops max, 38 byte packets
1 (192.168.200.254) 0.871 ms 0.722 ms 0.659 ms
2 22.214.171.124 (126.96.36.199) 9.604 ms 10.149 ms 9.635 ms
3 188.8.131.52 (184.108.40.206) 10.557 ms 11.159 ms 10.650 ms
4 220.127.116.11 (18.104.22.168) 12.001 ms 11.342 ms 11.625 ms
This shows that packets traverse three routers before finally reaching the destination (shown on the 4th line).
We could also traceroute to the IP address that is associated to the domain name www.surfbvi.com and get the same results. If we traceroute to an IP that exists elsewhere on the Internet, we will see that the packets traverse more routers to reach their d
estination. Below are the results of a traceroute to a web server at Florida State University.
grizzly:~# traceroute 22.214.171.124
traceroute to 126.96.36.199 (188.8.131.52), 30 hops max, 38 byte packets
1 (192.168.200.254) 0.782 ms 0.780 ms 0.820 ms
2 184.108.40.206 (220.127.116.11) 9.791 ms 9.734 ms 9.651 ms
3 18.104.22.168 (22.214.171.124) 11.580 ms 11.197 ms 10.121 ms
4 126.96.36.199 (188.8.131.52) 39.568 ms 38.205 ms 71.644 ms
5 if-5-1-0-15-0.bb1.Miami.Teleglobe.net (184.108.40.206) 397.639 ms 186.242 ms 157.982 ms
6 if-9-0.core1.Miami.Teleglobe.net (220.127.116.11) 250.600 ms 154.002 ms 212.738 ms
7 if-10-0.core2.Atlanta.Teleglobe.net (18.104.22.168) 176.478 ms 177.733 ms 181.766 ms
8 if-6-0.core2.Washington.Teleglobe.net (22.214.171.124) 184.625 ms 677.705 ms 199.489 ms
9 ATM2-0.BR2.DCA6.ALTER.NET (126.96.36.199) 135.202 ms 139.751 ms 190.180 ms
10 0.so-4-0-0.XL2.DCA6.ALTER.NET (188.8.131.52) 115.468 ms 154.996 ms 145.570 ms
11 0.so-7-0-0.XR2.DCA6.ALTER.NET (184.108.40.206) 154.917 ms 139.553 ms 180.017 ms
12 0.so-4-0-0.TR2.DCA6.ALTER.NET (220.127.116.11) 161.878 ms 159.153 ms 124.287 ms
13 121.at-5-0-0.TR2.ATL1.ALTER.NET (18.104.22.168) 553.195 ms 154.867 ms 140.299 ms
14 298.at-6-0-0.XR2.ATL1.ALTER.NET (22.214.171.124) 158.257 ms 126.569 ms 135.010 ms
15 194.ATM6-0.GW3.JAX1.ALTER.NET (126.96.36.199) 141.647 ms 147.223 ms 129.912 ms
16 bs-tallahassee-gw.customer.alter.net (188.8.131.52) 144.942 ms 136.485 ms 158.675 ms
17 184.108.40.206 (220.127.116.11) 143.736 ms 162.609 ms 125.549 ms
18 atm4009.c7507.bfs.fsu.edu (18.104.22.168) 144.408 ms 190.312 ms 206.736 ms
19 vlan916.msfc.bfs.fsu.edu (22.214.171.124) 211.794 ms 213.551 ms 215.661 ms
20 garnet1.acns.fsu.edu (126.96.36.199) 289.393 ms 236.943 ms 248.540 ms
(Note also that there is no reverse DNS entries for any of the routers in this path until we reach Miami. This is again due to the lack of reverse DNS on the incumbent's network.)
In order to show that the incumbent's routers are routing the addresses reserved for internal use, we can simply try to traceroute to an IP address that falls within the reserved group. The reserved groups are defined as follows at http://www.faqs.org/rfc
The Internet Assigned Numbers Authority (IANA) has reserved the
following three blocks of the IP address space for private networks:
10.0.0.0 - 10.255.255.255
172.16.0.0 - 172.31.255.255
192.168.0.0 - 192.168.255.255
To show how the incumbent's routers are broken, we will try to traceroute to 10.0.0.0 from within the incumbent's network
grizzly:~# traceroute 10.0.0.0
traceroute to 10.0.0.0 (10.0.0.0), 30 hops max, 38 byte packets
1 dsl-router.hq.islandless.net (192.168.200.254) 0.796 ms 0.796 ms 0.802 ms
2 188.8.131.52 (184.108.40.206) 10.181 ms 9.774 ms 10.268 ms
3 220.127.116.11 (18.104.22.168) 10.651 ms 10.366 ms 11.260 ms
4 22.214.171.124 (126.96.36.199) 27.930 ms 37.632 ms 21.058 ms
5 188.8.131.52 (184.108.40.206) 49.525 ms 55.868 ms 29.180 ms
6 220.127.116.11 (18.104.22.168) 28.976 ms 34.086 ms 21.676 ms
7 if-5-1-0-15-0.bb1.Miami.Teleglobe.net (22.214.171.124) 159.453 ms 162.768 ms if-5-1-0-14-0.bb1.Miami.Teleglobe.net (126.96.36.199) 192.239 ms
This shows that a packet destined for 10.0.0.0 gets all the way to Miami before being dropped by a router that knows enough not to forward it to another router. In a properly administered network, the packet would never make it past the first router. Anot
her excerpt from http://www.faqs.org/rfcs/rfc1597.html is included here:
Because private addresses have no global meaning, routing information
about private networks shall not be propagated on inter-enterprise
links, and packets with private source or destination addresses
should not be forwarded across such links. Routers in networks not
using private address space, especially those of Internet service
providers, are expected to be configured to reject (filter out)
routing information about private networks. If such a router
receives such information the rejection shall not be treated as a
routing protocol error.
Indirect references to such addresses should be contained within the
enterprise. Prominent examples of such references are DNS Resource
Records and other information referring to internal private
addresses. In particular, Internet service providers should take
measures to prevent such leakage.
It is important to note that this is not law, nor is it even enforced by anyone. Rather, it represents the terms of an agreement that has been made in order to facilitate the smooth operation of the Internet. The incumbent clearly has no regard for the st
andard practices that are agreed upon by the rest of the Internet at large, and as a result, the incumbent's network is sub-standard and broken.
The incumbent's network is susceptible to hacks which use attacks that hide or otherwise tamper with the source or destination address of packets. Since the incumbent's routers route packets that they should certainly not route, it is theoretically possib
le to gain unauthorized access to parts of the network which would be inaccessible in a properly administered network.
--Use of reserved addresses for customer computers
This is more of a design decision than a flaw with implementation, but the effect is quite important. The incumbent's DSL subscribers must configure their computers to use an IP address in the reserved space of 192.168.200.0 (192.168.200.1 or 192.168.200.
42, or any other address that begins with 192.168.200). In order to communicate with computers on Internet, this address must be converted to a real routable IP address. This conversion occurs in the dsl modem at the customer's location. The same conversi
on happens in reverse when communication comes back from the Internet destined for the user's computer. This conversion process is called Network Address Translation (NAT).
Perhaps an analogy will help explain this concept. Consider a hotel in which you cannot make direct calls from outside the hotel to rooms within the hotel. In order to make a call from the room, you must first dial the switchboard, which then patches you
into a real line that can be used for outgoing calls. This is so because each room is not directly equipped with its own phone line; rather there is a shared line (or perhaps several shared lines) which serve the switchboard. The benefit is that fewer rea
l telephone lines are required to serve the entire hotel, since most of the time, only a small number of lines would be in use at any given time. The switchboard provides access to the lines as needed. The drawback is that it is impossible to make direct
calls to rooms from outside the hotel.
Network Address Translation employs a similar design philosophy. Outgoing access is permitted only after the the dsl modem (acting as the switchboard did in the previous analogy), obtains a valid Internet address. The server that the user connects to sees
the request as having originated from this valid, routable IP address, and then communication can occur. Just as in the previous analogy, there are benefits and drawbacks to using Network Address Translation. The benefit is that fewer real IP addresses n
eed to be used to serve a group of users. However, the drawbacks make Network Address Translation unsuitable for use with Internet access that is designed for paying customers.
With Network Address Translation, it is impossible to initiate communication with the user's computer from the Internet. Communication can only occur if the user initiates the communication from their computer. This means that it's possible for the user t
o log into an email server and retrieve email messages that were left for the user on the email server (which has a real Internet Protocol address), but impossible for the user to run his or her own email server. The user can request to view a web page th
at exists on a web server on the Internet, but it is again impossible for the user to run his or her own web server. In fact, it is impossible for the user to run any kind of server whatsoever. The incumbent also has no provision for allowing its users to
publish content on any of the incumbent's own servers, effectively making the Internet a one way street for its users. Users must rely on servers elsewhere on the Internet if they wish to provide their own content for other Internet users to access.
Network Address Translation provides some level of security, since it is impossible to directly access a computer configured to use reserved addresses from outside the network (it is normally impossible, unless the routers which serve the clients are misc
onfigured to route reserved addresses...), however Network Address Translation was not designed as a security measure. It was designed as a way of conserving IP addresses by not allocating them to computers which do not require global uniqueness.
The conclusion is that the incumbent has decided that its customers will not enjoy the use of a globally unique IP address. This makes the user unable to host information or services of their choosing from their computer to anybody on the Internet. In thi
s writer's experience, Internet Service Providers do not force customers to use reserved addresses because good Internet service includes the ability to host information and be a globally unique participant on the Internet. Considering that the incumbent
owns many tens of thousands (if not hundreds of thousands) of IP addresses, it seems unfair that BVI users do not enjoy the same level of equity as do users of other Internet Service Providers.
In summary, the main points of this document are as follows:
1) Incumbent's DNS servers run Microsoft Windows, an unreliable and insecure platform ill suited for this task. This contributes to unreliable DNS service.
2) Incumbent's reverse DNS is almost completely broken, resulting in delays or complete blockage when accessing many Internet services.
3) Incumbent illegitimately uses IP addresses that are not allocated to the incumbent. This detracts from inter-operability with other networks, since IP addresses are globally unique.
4) Incumbent's network routes reserved IP addresses, when it should not. This is a large security hole, and can cause unexpected and harmful results.
5) Incumbent forces user's computers to use reserved IP addresses, limiting their Internet connectivity to outgoing requests only, and making it impossible for users to host information to other Internet users.
Items 1 through 4 are serious problems that are solid proof of a poorly managed network. This indicates that there are surely other problems with the network as well, considering the lack of competent administration. Item 5 indicates is proof that the inc
umbent's users do not enjoy an equal level of participation in the Internet network.
In conclusion, there is much room for improvement, but with the incumbent having little incentive to improve due to lack of competition, the incumbent's users have little choice but to put up with the incumbent's sub-standard network.