|
|
|
|
| IPv6 Auto Configuration
One of the major advantages of IPv6 over IPv4 is its ability to automate configuration of parameters related to network connectivity of client nodes (network enabled devices such as PCs, PDAs, or printers). With IPv4, when you connect a client node to a TCP/IP based network, there is a fairly complex process required to set things such as the IP address, the netmask, the default gateway and the location of DNS servers. The person configuring these things must have a fairly good understanding of network concepts, including addressing and subnets, in addition to specific details of the network to which the node will be connected. Getting any of this information wrong (say using a subnet mask of 255.255.255.0 when the correct subnet mask is 255.0.0.0) can prevent the connection from working at all, or provide limited or intermittent connectivity. In earlier days, network devices were typically installed within organizations that could afford a network specialist with an adequate working knowledge of the necessary technology. Even so, costs associated with such expert based manual configuration were significant. Many IPv4 networks use a simple auto configuration tool called DHCP (Dynamic Host Configuration Protocol), or DHCPv4 to be more precise, originally defined in RFC 1531 in October 1993, making it a fairly mature Internet standard. The most recent version of the standard is RFC 2131 (March 1997). There have been many RFCs written to extend DHCPv4 in various ways, and it is very widely implemented and used. DHCPv4 solves many of the problems associated with node configuration, but is highly specific to IPv4 in many ways. There are a number of good books on DHCPv4, which cover all the relevant concepts for UNIX and/or Windows. My personal favorite, which covers both platforms, is “DHCP Handbook (2nd Edition),” Ralph Droms and Ted Lemon, Sams Publishing, October 2002. DHCPv4 details The network administrator configures a variety of settings in the DHCP server, which control how it returns configuration details to client nodes upon request. One or more “scopes” are defined, each of which contains details for a particular set of client nodes, including a “pool” of available addresses to assign (e.g. from 10.2.0.1 to 10.2.0.254) and associated other information (e.g. subnet mask of 255.0.0.0, default gateway of 10.0.0.1 and DNS server addresses of 10.1.0.1 and 10.1.0.2). There are dozens of possible settings configurable for each scope. At the highest level, it is possible to specify that a client node is to be manually configured, or automatically configured using DHCP. Assuming DHCP configuration has been selected, no further network configuration settings are required (or in many cases allowed) for that node. When such a client node is powered up, it sends a broadcast message (a packet addressed to all nodes on the segment, with an address such as 10.255.255.255) requesting DHCP configuration data. Assuming a DHCP server exists on that segment, that server will accept the request and process it. If an address has already been allocated for that node (based on its 48 bit MAC, or physical, address), it will immediately respond with the current configuration data for that node from the server’s database. Otherwise, the server will allocate an IP address for that node from its pool of remaining available addresses (assuming the pool is not yet empty). It also updates its database with the address assignment. It will then return information to that node including the allocated address, and relevant scope settings which would be the same for any such client node (network mask, default gateway, etc). The DHCPv4 client uses this returned information to configure its network connectivity settings. Each allocated address is assigned with a maximum lifetime for which it will be exclusively reserved for that client node. Each time that node is powered up prior to the expiration of that lifetime, the same IP address will be returned to it (based on MAC address). Once the lifetime for that address assignment has run out, the address will be returned to the pool of available addresses. The next time the node is powered up, it will be assigned an address all over again, choosing one out of the then available pool of addresses. It is possible for the same address to be assigned, but this is not guaranteed. DHCP allows the network administrator to reserve a specific IP address from the pool for a given MAC address, so that the node with that MAC address will always get that IP address. This removes that address from the pool of available addresses until the reservation is removed by the network administrator on the DHCP server. If the number of potential client nodes is large compared with the size of the available pool (often the case with valid external IPv4 addresses), then the lifetime is typically set very short, so that when the client ends the session (e.g. terminating a modem call to an ISP), the address is immediately returned to the available pool, and may be used by many different client nodes over the course of a day (but by only one node at any given time). This situation is called dynamic IP address assignment. Imagine if every time you lifted your phone off the hook, a new telephone number from a small pool was assigned to your phone just for the duration of that call. Every time you use your phone, it would typically have a different number. This would complicate both Caller ID and publishing directories of people’s phone numbers. The same thing happens with DHCP when the number of client nodes exceeds the size of the available pool of addresses (a not uncommon state of affairs in IPv4 networks). Some ISPs (e.g. a hotel broadband service) may allow you to request a non-routable private IP address (from RFC 1918, including addresses from 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16), or a public routable IP address (not from the RFC 1918 address ranges). The private address will have to be behind NAT (Network Address Translation) using “hide mode NAT”. Potentially many nodes may appear to be using that same address simultaneously. A unique public routable address may also be used with NAT, but if so, you must use “static mode NAT,” which still guarantees your node will be the only one using that IP address. This will still break IPSec and other protocols (NAT almost always causes problems). Allowing uses to choose public or private addresses is accomplished by creating two DHCP scopes, one with a pool of public addresses (e.g. 123.45.67.00/24), and one with a (much larger) pool of private addresses (e.g. 10.0.0.0/8). The pool to be used would be determined by whether or not you request a routable address. If you plan to use software that requires an external address (certain P2P file transfer, VoIP and game software), you should request an external address. If not, chances are all your applications will work OK behind “hide mode” NAT, and a private address will work fine. Some ISPs provide external addresses as a premium, extra cost, option to discourage their use by people not requiring such. With DHCP assigned private addresses, there is no reason not to provide sufficiently large pools to allow permanent (or at least very long lifetime) assignments. Unfortunately for connections that go outside of the private network (e.g. to sites elsewhere on the Internet, or from other ISPs), there is little advantage to having a permanently assigned private address. At some point, before a packet is routed into the Internet (outside of the private network), it must have external routable address (for both source and destination). Since broadcasts never cross from one network segment to another (e.g. across routers), a client node cannot contact a DHCP server anywhere except on its local segment. To prevent having to deploy a DHCP server on every segment, there exists a much simpler server called a DHCP relay. This allows a node on the segment to accept a broadcast from a client node for DHCP service, relay that request with a specific IP address (over TCP) to a real DHCP server on another segment, which can then respond directly to the requesting node. Therefore, there must be a DHCP server or a DHCP relay agent, on every segment. Providing more than one DHCP server for a given node (for redundancy, as with DNS) is beyond the scope of this article. Auto Configuration in IPv6 The good news is that the basic functionality of DHCP has now been integrated into the IPv6 protocol, via stateless auto-configuration. No DHCP server is required to handle this, and no broadcast is required. It is handled with anycast addresses and neighbor discovery. It does depend on some device (typically a router or firewall) to provide Router Advertisements. These inform client nodes of the 64 bit prefix that is valid for the network segment on which a node is located. Stateless IPv6 Autoconfig When a client node in the main network powers up, it would make a router solicitation request to the magic anycast address for routers. The router would respond with a router advertisement including the prefix 2001:dead:beef:0/64. The client node would then build an EUI64 address from its 48-bit MAC address (hardwired into its NIC), and append it to that prefix to create the entire 128-bit address, automatically. A client node in subnet dmz would behave the same way, but build an address with the 64 bit prefix 2001:dead:beef:1/64. Ideally, the address of the default gateway and DNS servers should also be available via Router Advertisements (according to the standards), but this is not currently widely implemented. Today, client nodes locate their default gateway using the router anycast address. DNS server addresses must be manually specified. With Microsoft Windows XP SP2, DNS queries are never done over IPv6 anyway, so only IPv4 DNS server addresses are ever needed (and are configured in the usual way). In Microsoft Vista, IPv6 addresses for DNS can be specified using the command line utility netsh. In FreeBSD, IPv4 and/or IPv6 addresses of DNS servers can be specified in a text startup file called /etc/resolv.conf. There is an IPv6 version of DHCP (called DHCPv6), which is specified in RFC 3315 (July 2003). There are many related RFCs that specify additional details or options with this standard. It is possible to deploy existing (incomplete) DHCPv6 servers to supply various configuration parameters (except for the actual IPv6 address, which is unique for each client node), including the default gateway and DNS server addresses. This is still known as stateless autoconfig, because the DHCPv6 server does not need to keep track of assigned addresses (hence it has no state, or information regarding previously assigned addresses, to keep track of). Stateful IPv6 Autoconfig With IPv6, there are so many possible addresses that there should never be a reason to do dynamic address allocation as is commonly done with IPv4 addresses. The available pools can always be far larger than any possible number of nodes within a subnet. If you really want unpredictable addresses to be assigned, it would be far better for the DHCPv6 server to randomly generate values for the low 64 bits of each address than to reassign addresses randomly out of some small pool (and update DNS accordingly).
|
|
|
