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

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 17.254.0.91). 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 216.231.45.220, and we connect to a server, the server would do a DNS lo okup of 216.231.45.220. 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 216.231.45.220
220.45.231.216.IN-ADDR.ARPA domain name pointer ghost20.blackmagiclabs.com

ghost120.blackmagiclabs.com is the reverse dns entry for the IP address 213.231.45.220.

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 216.231.45.220

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 204.188.165.78, 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 204.188.165.78
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.

IP Addresses

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-BLK204.188.0.0 - 204.189.255.255
CABLE AND WIRELESS - ANTIGUA (NETBLK-CW-204-188-160) CW-204-188-160  204.188.160.0 - 204.188.175.255

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 204.188.160.0 and 204.188.175.255 (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 204.188.165.204
PING 204.188.165.204 (204.188.165.204): 56 data bytes
64 bytes from 204.188.165.204: 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 204.188.165.204
PING 204.188.165.204 (204.188.165.204) from 216.231.32.120 : 56(84) bytes of data.
64 bytes from 204.188.165.204: 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. 191.254.60.14 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 work. 
andre@core[~]% ping 191.254.60.14
PING 191.254.60.14 (191.254.60.14): 56 data bytes
64 bytes from 191.254.60.14: 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 "191.254.60.14".

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 191.254.60.14
PING 191.254.60.14 (191.254.60.14) from 216.231.32.120 : 56(84) bytes of data.

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

--Improper routing

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 (206.128.211.46), 30 hops max, 38 byte packets
 1  (192.168.200.254)  0.871 ms  0.722 ms  0.659 ms
 2  209.88.236.24 (209.88.236.24)  9.604 ms  10.149 ms  9.635 ms
 3  209.88.236.17 (209.88.236.17)  10.557 ms  11.159 ms  10.650 ms
 4  206.128.211.46 (206.128.211.46)  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 146.201.2.21
traceroute to 146.201.2.21 (146.201.2.21), 30 hops max, 38 byte packets
 1  (192.168.200.254)  0.782 ms  0.780 ms  0.820 ms
 2  209.88.236.24 (209.88.236.24)  9.791 ms  9.734 ms  9.651 ms
 3  209.88.236.17 (209.88.236.17)  11.580 ms  11.197 ms  10.121 ms
 4  206.128.212.9 (206.128.212.9)  39.568 ms  38.205 ms  71.644 ms
 5  if-5-1-0-15-0.bb1.Miami.Teleglobe.net (207.45.198.173)  397.639 ms  186.242 ms  157.982 ms
 6  if-9-0.core1.Miami.Teleglobe.net (207.45.210.41)  250.600 ms  154.002 ms  212.738 ms
 7  if-10-0.core2.Atlanta.Teleglobe.net (64.86.81.190)  176.478 ms  177.733 ms  181.766 ms
 8  if-6-0.core2.Washington.Teleglobe.net (64.86.83.182)  184.625 ms  677.705 ms  199.489 ms
 9  ATM2-0.BR2.DCA6.ALTER.NET (204.255.169.5)  135.202 ms  139.751 ms  190.180 ms
10  0.so-4-0-0.XL2.DCA6.ALTER.NET (152.63.38.138)  115.468 ms  154.996 ms  145.570 ms
11  0.so-7-0-0.XR2.DCA6.ALTER.NET (152.63.38.90)  154.917 ms  139.553 ms  180.017 ms
12  0.so-4-0-0.TR2.DCA6.ALTER.NET (152.63.11.93)  161.878 ms  159.153 ms  124.287 ms
13  121.at-5-0-0.TR2.ATL1.ALTER.NET (146.188.141.61)  553.195 ms  154.867 ms  140.299 ms
14  298.at-6-0-0.XR2.ATL1.ALTER.NET (146.188.232.109)  158.257 ms  126.569 ms  135.010 ms
15  194.ATM6-0.GW3.JAX1.ALTER.NET (152.63.84.29)  141.647 ms  147.223 ms  129.912 ms
16  bs-tallahassee-gw.customer.alter.net (157.130.81.186)  144.942 ms  136.485 ms  158.675 ms
17  204.194.39.158 (204.194.39.158)  143.736 ms  162.609 ms  125.549 ms
18  atm4009.c7507.bfs.fsu.edu (128.186.250.69)  144.408 ms  190.312 ms  206.736 ms
19  vlan916.msfc.bfs.fsu.edu (128.186.250.17)  211.794 ms  213.551 ms  215.661 ms
20  garnet1.acns.fsu.edu (146.201.2.21)  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 s/rfc1597.html 
  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  209.88.236.24 (209.88.236.24)  10.181 ms  9.774 ms  10.268 ms
 3  209.88.236.17 (209.88.236.17)  10.651 ms  10.366 ms  11.260 ms
 4  204.188.160.249 (204.188.160.249)  27.930 ms  37.632 ms  21.058 ms
 5  208.158.6.69 (208.158.6.69)  49.525 ms  55.868 ms  29.180 ms
 6  208.158.6.83 (208.158.6.83)  28.976 ms  34.086 ms  21.676 ms
 7  if-5-1-0-15-0.bb1.Miami.Teleglobe.net (207.45.198.173)  159.453 ms  162.768 ms if-5-1-0-14-0.bb1.Miami.Teleglobe.net (207.45.198.153)  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.