IPv4 and IPv6 in Visual C#

Paint QR Code ISO/IEC18004 in Visual C# IPv4 and IPv6

There are two kinds of IP addresses because there are two versions of IP in use today. Version 4 is the most widely used. (Previous version numbers were used only in the Internet s early experimental days, and you never see them on the Internet today.) IPv4 has a problem: its addresses are 32-bit numbers, meaning that there are only enough unique addresses for around 4 billion computers. That may sound like a lot, but it s not enough, given how many computers and devices have Internet access and the rate at which new ones are coming online. We are already using ungainly hacks to enable multiple machines to share addresses, and limited IP address space is a big problem. In IPv6, an address is a 128-bit number, which provides sufficient address space for the foreseeable future, but there s a problem. Old computers and routers don t support IPv6. Computers can often be fixed with software upgrades Windows XP can have IPv6 support installed (and it s built into Windows Vista and later versions). But OS support is not the whole story applications may also need to be updated. There s a bigger problem for routers a lot of them have the structure of IPv4 baked into their hardware, so they need to be replaced to get IPv6 support. This makes IPv6 seem like an unattractive choice would you want your web server to have an address that will be inaccessible to anyone who hasn t upgraded her network and Internet connection to IPv6 In fact, it s not quite that bad, because there s a special class of IPv6 addresses that are effectively equivalent to IPv4 addresses, so it s possible to provide an IPv6-based server that s accessible to IPv4 clients. But that means any public service you re likely to want to use will be accessible from IPv4, so there s not a whole lot of incentive for end users or corporate network administrators to throw out perfectly good IPv4 routers to upgrade to IPv6, and it means that phone companies don t have many customers demanding IPv6-capable DSL routers. Consequently, the transition to IPv6 is happening incredibly slowly. Nonetheless, the IPv4 address space problem isn t going to go away, so you will need to write your software in a way that s able to work with both IPv4 and IPv6 addresses if you want it to continue to work as IPv6 adoption gradually picks up. .NET tries to make this relatively easy in practice. Its IPAddress class can hold either kind of address. For most applications, client-side code doesn t even need to be aware of which kind is in use. But occasionally, you ll need to work with an IP address in its numeric form, at which point the distinction matters.

cess to this as part of your connection whose job is to convert these textual names into the IP addresses required to communicate with the machines (or hosts, as the entities associated with IP addresses are conventionally called). Example 13-22 uses the Dns class in the System.Net namespace to look up the IP addresses for a particular hostname. DNS can associate multiple addresses with a name; for example, a DNS name may have both an IPv4 and an IPv6 address. This code loops through all the addresses, printing their type and value. (If you call ToString() on an IPAddress, which is what Console.WriteLine will do in Example 13-22, it ll return the standard string representation for the numeric address.)

IPHostEntry hostDnsEntry = Dns.GetHostEntry("localhost"); foreach(IPAddress address in hostDnsEntry.AddressList) { Console.WriteLine("Type: {0}, Address: {1}", address.AddressFamily, address); }

This example looks up the special hostname localhost, which always refers to the local machine on which the program is running. Both IPv4 and IPv6 define special addresses that are reserved to refer to the local machine, so if you run Example 13-22, you ll see that it prints out two addresses, one for IPv6 and one for IPv4:

Type: InterNetworkV6, Address: ::1 Type: InterNetwork, Address: 127.0.0.1

For years, IPv4 was the only IP version in use, so it s often not qualified with a version number, which is why this IPv4 address s AddressFam ily property is just displayed as InterNetwork, and not InterNetworkV4.

Many DNS entries don t have an IPv6 address, and if you modify Example 13-22 to look up such an address (e.g., at the time of this writing, w3.org has only an IPv4 address) you ll see just one address back from GetHostEntry:

Type: InterNetwork, Address: 128.30.52.45

Armed with an IP address for the machine we want to talk to, we now have enough information for the Internet to deliver IP packets to the target machine. But there are a couple of issues to resolve. First, there s the question of how the receiving machine will know what to do with the packet when it arrives. Second, there s the problem that the Internet is fundamentally unreliable. TCP (the Transmission Control Protocol) offers a solution to both of these problems. The Internet does not guarantee to deliver all IP packets. It can t. Suppose you are using a machine connected to the Internet with a 100 Mbps connection and you try to send data at full speed to a machine that is connected with a 56 Kb modem. (Remember those In some parts of the world, they re still used. If you get a chance, try using a

modern website via a 56 Kb dial-up connection, and then marvel at the fact that 56 kbps modems were once considered really fast.) As we send data to this bandwidthimpoverished machine, the routers between us and them will initially try to manage the speed difference a router connecting a fast network to a slower network will store incoming packets from the fast network in its memory, and they queue up while it plays them out in slow motion to the target network. But eventually it ll run out of memory, at which point it ll just start discarding packets. At busy times of the day, packets may get discarded even if both ends of the connection can operate at the same speed perhaps the route the traffic needs to take through the Internet between the two networks includes busy links that just don t have the bandwidth to support all the traffic that all of the ISP s customers are trying to send. So network congestion can also cause packet loss, even in the absence of speed mismatches. The upshot of this is that IP is not a reliable protocol you get what s sometimes called a best effort service. In attempting to deliver your data, the Internet will give it its best shot, but there are no guarantees. (You may have a service level agreement with your ISP that makes statistical guarantees about the proportion of data it will successfully deliver to and from the boundaries of the ISP s network infrastructure, but there are no guarantees for any single packet, nor can your ISP guarantee what will happen to your data once it has been passed off to someone else s network.) To add to the fun, IP doesn t even guarantee to deliver messages in the same order you sent them. ISPs might have multiple routes through their network to ensure reliability in the face of individual link failures, or just to ensure enough bandwidth to cope with high loads. So if you send a series of IP packets to the same computer, not all of those packets will necessarily take the same route they might be split across two or more routes. Some of those routes may prove to be quicker, meaning that the packets can arrive at their destination in a different order than you sent them. Writing networked applications can be challenging if you have no idea whether any particular message will be received, nor any way of knowing in what order the ones that do arrive will turn up. So to make life easier, we have the Transmission Control Protocol the TCP in TCP/IP. This is a protocol that sits on top of IP and adds some useful features. It provides support for connections rather than each packet being handled in isolation, each transmission is part of the sequence of communication occurring over the connection. TCP puts sequence numbers into each IP packet so that it can detect when packets arrived out of order. And finally, the receiving machine acknowledges receipt of each message. Clients use this to work out how fast the messages are getting through, which enables them to send data at a rate that matches the network s ability to deliver, avoiding problems with mismatched network speeds and network congestion. And clients also use this to work out when data didn t get through and needs to be resent.

These features enable TCP to offer a data transmission service that sends data in order, at a rate that will not try to exceed the capacity of the network routes available and in a fashion that is reliable in the face of occasional packet loss. A socket is usually just an API on top of a TCP connection that presents a stream-style API your program can write data into a socket stream, and the TCP/IP networking code running on the computers at both ends uses TCP to ensure that the program at the receiving end has another socket stream from which it can read the exact same sequence of bytes you wrote into the stream. The programs don t need to know about out-of-order delivery or packet loss. As long as the networks are not hopelessly lossy, it looks like there is perfectly reliable in-order transmission. TCP sockets are symmetrical, in that both ends can send and receive data. And the directions are independent communication can be full duplex, so there s no need for the two ends to take it in turns. TCP also solves the problem of how the receiving computer knows what it s supposed to do with incoming data. A single computer may offer many network services a small company might run the intranet web server, file server, and email server on the same computer, for example. So TCP adds the concept of port numbers. A service on a target machine will be associated with a particular number. There s a central administrative body called IANA the Internet Assigned Numbers Authority which (among other things) assigns and publishes port numbers for common services. For example, IANA has designated port 80 as the TCP port on which HTTP servers usually accept incoming requests. When a web browser (or the WebClient class we saw earlier) fetches a resource via HTTP, it does so by opening a TCP connection to port 80.

A single client computer might open several simultaneous connections to the same service web browsers often do this in order to download the various pictures, CSS, and JavaScript files concurrently, so as to be able to display the web page sooner. To distinguish between them, each connection has a client-side port number as well as a server-side port. But while you need to know the server port in order to connect, the client port number is usually picked for you dynamically by the OS.

Let s look at a real example. We re going to connect to a service using a very old and very simple protocol called Daytime Protocol. This hasn t changed since its specification was published in 1983 you can find its definition in a document called RFC867 at http://www.faqs.org/rfcs/rfc867.html. It s remarkably simple: clients open a TCP connection to port 13 on a server that offers the daytime service, and the server will send back the time of day as text and then close the connection. The specification is pretty vague about the format it says this:

There is no specific syntax for the daytime. It is recommended that it be limited to the ASCII printing characters, space, carriage return, and line feed. The daytime should be just one line.

It then goes on to give examples of a couple of popular formats, but servers are free to do pretty much anything they like.

This is a service that cannot be accessed with the WebClient or any of the WebRequest family of classes those types expect data to be layered inside HTTP (or sometimes another higher-level protocol such as FTP), but Daytime Protocol just makes very basic, direct use of plain TCP. So we need to use sockets if we want to access such a service. The U.S. government s National Institute of Standards and Technology (NIST) lists a few servers that offer this daytime service. Once such machine, located in Redmond, Washington, has the DNS name of time-nw.nist.gov. We ll use that. To start with, we need to look up its IP address, which we ll do using a similar technique to Example 13-22:

IPHostEntry hostDnsEntry = Dns.GetHostEntry("time-nw.nist.gov"); IPAddress serverIp = hostDnsEntry.AddressList[0];

Next, we need to open a TCP connection to port 13 (the daytime service port) on that machine. To do this, we ll need a Socket object.