Theory and History

   

Theory and History

By the late 1980s, members of the IETF (Internet Engineering Task Force) started discussing the possible future limitations and conceptual problems of IPv4. With the invention of the World Wide Web protocol by Tim Berners-Lee in the early 1990s came an explosion of interest in the Internet outside the academic and research oriented non-commercial Internet user base. Much of that explosion hastened the discussions of the successor to IPv4. The end result was the creation of the IPv6 protocol family whose RFCs began rolling out in 1995.

Note

Note that there was an IPv5 specification produced in the late 1980s. However, even within the RFCs defining IPv5 it was referred to and considered as an "experimental" protocol. It was never really intended for general public consumption. Much like the Linux development kernel series, you were free to play with it but it was not expected to work or be compatible. Some of the ideas from that protocol family ended up driving some of the designs of IPv6.


IPv6 drew upon many of the ideas and lessons learned from many protocol families, not just IPv4. The auto-addressing facilities of IPX, hierarchical routing structures from OSI and SNA, and the speed of fixed packet header structures in link-layer switching are but a few of the collective condensations of ideas. The flurry of ideas resulted in many RFCs, draft RFCs, and informational documents in 1994 as the IETF began the process of codifying the steps towards IPng (Internet Protocol Next Generation). IPng was to become IPv6 when ratified. Many of the ideas flying around in these documents were initially coalesced into the first set of IPv6 RFCs released in 1995.

RFC-1883 first specified IPv6 as a standard in December of 1995. The range of RFCs from 1883 through 1888 was the first release of the new IPv6 protocol family as proposed standards. These initial RFCs have been superseded by newer developments, but most of the newer developments are merely refinements of the structures. To understand IPv6 you should obtain and read through the current standard RFC-2460. To date there are several dozen RFCs that are standards or draft standards for many aspects of IPv6. A good reference site is at http://www.ipv6.org.

Many popular notions of IPv6 abound, especially in the various trade groups and magazines. For your purposes the core reasons are that IPv6 contains 128-bit autoconfiguring addresses, an aggregatable address space, and automatic routing configuration capabilities. The streamlined header and packet design refinements fix nagging issues with IPv4 such as network autoconfiguration, mobile IP, IP security, fragmentation, and source routing, and allow for very large packets known as jumbograms.

IPv6 Addresses

IPv6 addresses are 128 bits long. While this fact has been used to try to scare small children by various groups who had problems implementing IPv4, IPv6 addresses are actually very easy to use. You must remember that IPv4 addresses are not defined by dotted decimals. Dotted decimal notation (192.168.1.1) is merely an easy way to humanly state an IPv4 address. IPv4 addresses, as with IPv6 addresses, are more properly considered as large binary numbers . When dealing with IPv4 addresses in many cases, as you saw to some degree when you used the u32 classifier in Chapter 6, "Complex Network Examples," you specify them in hexadecimal equivalent (192.168.1.1 = 0xC0A80101). This is also the key to, and the standard definition of, IPv6 addresses.

There are three defined types of IPv6 addresses as specified in RFC-2373 and quoted as follows :

Unicast ” An identifier for a single interface. A packet sent to a unicast address is delivered to the interface identified by that address.

Anycast ” An identifier for a set of interfaces (typically belonging to different nodes). A packet sent to an anycast address is delivered to one of the interfaces identified by that address (the " nearest " one, according to the routing protocols'measure of distance).

Multicast ” An identifier for a set of interfaces (typically belonging to different nodes). A packet sent to a multicast address is delivered to all interfaces identified by that address.

Note that the broadcast address type extensively used in IPv4 is not defined. Although it could be considered a form of the multicast address type, there is no need for broadcast addressing within IPv6 because there is no need to reach every single IPv6 device.

The convention for writing down IPv6 addresses has a specification but the universally accepted method has become the coloned hex with zeros collapsed . The best way to define this is to run through a quick example.

A fully defined IPv6 address is written in human notation as eight 16-bit segments separated by colons (coloned hex notation) as follows:

 
 1111:2222:3333:4444:5555:6666:7777:8888 
 

Most actual addresses will contain contiguous sections of zeros. These zeros may be collapsed once and only once within the address by using a pair of colons. Consider the following full address:

 
 1111:2222:0000:0000:5555:0000:0000:8888 
 

This address may be specified in either of the following two ways:

1111:2222::5555:0:0:8888 ”First set of zeros are double colons

1111:2222:0:0:5555::8888 ”Second set of zeros are double colons

But the following representation is wrong:

1111:2222::5555::8888 ”This is illegal!

In normal usage you will usually see that the specification of the address places the double colons in the network portion of the address. That is, if the address previously had a CIDR mask of /64 then you would probably write the address as

 
 1111:2222::5555:0:0:8888/64 
 

This allows for the network portion to be noted as 1111:2222::/64 while the host portion is ::5555:0:0:8888/64 .

All of this discussion of addressing also brings up the entire notion of routing scoping and aggregation. As you have just implicitly seen, an IPv6 address has the notion of netmask as defined by a CIDR specification. I would strongly recommend that you read through RFC-2373 because it covers both the addressing and the aggregation references.

IPv6 does contain a mechanism for auto-addressing. Auto addresses are assigned in one primary use with another definition covering the concept of local addresses as you had used in IPv4 from RFC-1918. In IPv6 this is the link-local and site-local address formats (see RFC-2373 for details).

A link-local address is designed for exactly what the name implies. It is a valid address within the scope of the physical link itself. The other defined prefix, site-local, takes the place roughly of the local addressing space in IPv4 as defined in RFC-1918. A link-local address is automatically formed from a defined prefix, fe80: , and the MAC address or alternate globally defined unique number of the interface. So, for example, if you had an ethernet card with MAC address 11:22:33:44:55:66 , you would calculate your link-local address as

 
 fe80::1122:33ff:fe44:5566 
 

Note that this can be boiled down to the following set of steps:

  1. Place the link-local ID first with a pair of colons:

     
     fe80:: 
     
  2. Place the first three octets of your MAC address next:

     
     fe80::1122:33 
     
  3. Add on fffe

     
     fe80::1122:33ff:fe 
     
  4. Finish off with the last three octets of your MAC:

     
     fe80::1122:33ff:fe44:5566 
     

Note that if your MAC address contains leading zeros, it is usually up to the particular IPv6 implementation as to how it handles the creation. In Linux, a 2 is added as a placeholder so that you have:

MAC = 00:11:22:33:44:55

Link-Local = fe80::211:22ff:fe33:4455

Note that when you consider most of the automatic routing structures under IPv6, the last 64 bits of the address are also automatically computed according to the preceding steps.

IPv6 Routing and Neighbors

One of the more interesting parts of IPv6 lies in the extension of the auto-address configuration to the routing structure. In RFC-2461 much of the actual terminology and structure of IPv6 Neighbor Discovery is covered and is well worth reading through if only to better understand some of the conversations on IPv6.

Essentially, IPv6 provides a mechanism for hosts and routers to discover each other. You may think of ARP on IPv4, which is the link-local address mapping mechanism. If you then consider what integrating ARP with RIP would do then you have an inkling of what IPv6 Neighbor Discovery covers.

As you just saw in IPv6 addressing there are addresses that are automatically defined on your system using the MAC address of your NIC card. These link-local addresses function to ensure that there is no need for an ARP protocol in IPv6. But they also provide a means for all IPv6 devices on a local network to communicate without any further setup. The logical next step in convenience would be to have your system automatically find the routers on the network.

This next step is provided as part of the Neighbor Discovery mechanism. A router in IPv6 may be configured to send out periodic router advertisements. These advertisements are sent and received using a designated set of prefixes for routers and provide autoconfiguration of the local network for the designated advertised network prefixes. A router does not have to advertise to perform routing. Think of it more in the style of a services advertising network such as NetWare SAP on IPX or the SLP (Service Location Protocol) on IPv4.

When an IPv6 host is enabled on a network, it first sends out a Neighbor solicitation, which is a query to determine what types of neighbors it has on that link. It will send out this type of query every time an address is added. It will follow this query up with a Router Solicitation query. If a router is configured to advertise on this network, the router will respond to the Router Solicitation with a Router Advertisement. If the host hears a Router Advertisement, it will create a route to that prefix on the interface it received the advertisement on.

The actual processes of this interchange and the results are determined by the configuration of the host. You can configure a host to not listen to router advertisements on certain interfaces. But for most networking where you have a single interface host and a router connecting the local network to the rest of the world, this system works very well.

Now that you have some understanding of the basics of IPv6 addressing and have read through some of the RFCs, you decide to revisit your test network and try to set up a simple IPv6 network.

First you just want to test out the link-local autoconfiguration of the various machines on the network. Recalling your test network from Chapter 6 (see Figure 9.1), you ensure that each of the machines has a kernel with the IPv6 support compiled in. You watch the network traces while you reboot the machines. When you reboot each machine, you see that it first sends an ICMPv6 Neighbor Solicitation followed by a Router Solicitation. In all cases you then see that the systems have configured link-local addresses on their interfaces.

Figure 9.1. Policy Routing testing network.

graphics/09fig01.gif

You then use the ping6 utility to ping from one machine to the others on the local networks. This is a real pain because you have to type out the entire address. You place the link-local addresses into the hosts file and this allows you to ping by name to make it easier.

You try to ping across router1 but, as expected, that does not work. So now you decide to try router autoconfiguration on router1 and see how it works.

RADVD ”Router Advertisement Daemon

In Linux, radvd provides the router advertisement function under IPv6. radvd only runs under the 2.2 series kernels. There is ongoing work to make sure that it will run under the 2.4 series kernels as well as an attempt to enable the router advertisement function within the IPv6 kernel code. In order to test radvd you ensure that the kernel on router1 is 2.2.12 and you obtain the radvd-0.5 source and compile it.

Once you have the daemon compiled you go about setting up a configuration file. The options for configuring radvd are numerous but there are only three options, AdvSendAdvert , AdvOnLink , and AdvAutonomous , that must be present in the configuration file. After studying the man page and the sample configuration file, you come up with the following simple configuration located in /usr/local/etc/:

 
 interface eth0 {      AdvSendAdvert on;      prefix dead:1::0/64      {           AdvOnLink on;           AdvAutonomous on;      }; }; interface eth1 {      AdvSendAdvert on;     prefix dead:2::0/64      {           AdvOnLink on;           AdvAutonomous on;      }; }; 
 

This will advertise the dead:1::/64 prefix on interface eth0 and prefix dead:2::/64 on interface eth1 . Now that you have this setup you start radvd while watching the traces on the networks.

As soon as you start up the daemon, you note that both interfaces send out router advertisements. These advertisements contain the prefix and the source MAC address of router1's appropriate interface.

Now you look at the routing tables on net1. You had saved the IPv6 routing tables to a file before starting the radvd daemon. This pre- radvd routing table looked like the following:

 
 fe80::/10 dev eth0  proto kernel  metric 256  mtu 1500 rtt 375ms ff00::/8 dev eth0  proto kernel  metric 256  mtu 1500 rtt 375ms 
 

Now, after you have started the radvd daemon on router1 you look at the table again and see the following:

 
 dead:1::/64 dev eth0  proto kernel  metric 256  mtu 1500 advmss 1440 fe80::/10 dev eth0  proto kernel  metric 256  mtu 1500 advmss 1440 ff00::/8 dev eth0  proto kernel  metric 256  mtu 1500 advmss 1440 default via fe80::2a0:ccff:fe21:eed0 dev eth0  proto kernel  metric 1024  }         expires -1095sec mtu 1500 advmss 1440 
 

You note that there is now a default route via the link-local address of router1's eth0 interface. Also, there is a route to the prefix dead:1::/64 via eth0 . This is exactly what router1 was advertising. Because you know the MAC address of host2 you decide to try to ping it. You know that the prefix you told router1 to advertise on that side was dead:2::/64 , so you try to ping as follows:

 
 [root@net1 /root]#  ping6 dead:2:2a0:5aff:fe05:e828  PING dead:2::2a0:5aff:fe05:e828 from fe80::210:5aff:fe05:e828 : 56 data bytes 64 bytes from dead:2::2a0:5aff:fe05:e828: icmp_seq=0 hops=64 time=1.124 msec 64 bytes from dead:2::2a0:5aff:fe05:e828: icmp_seq=1 hops=64 time=430 usec 64 bytes from dead:2::2a0:5aff:fe05:e828: icmp_seq=2 hops=64 time=416 usec 64 bytes from dead:2::2a0:5aff:fe05:e828: icmp_seq=3 hops=64 time=416 usec --- dead:2::2a0:5aff:fe05:e828 ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max/mdev = 0.416/0.596/1.124/0.305 ms 
 

Just to make sure, you try once more to ping the link-local address of host2 and you get no response. Now you know you have not even been logged in to host2 since you rebooted it with the new kernel back in Chapter 6. So the IPv6 routing is now fully functional just by having router1 advertising. Quite an impressive feat if you have only dealt with IPv4 networks in the past.

But the entire trial has also left you with an uneasy feeling. You know on the networks you have dealt with that you could always figure out the addresses of systems. If necessary, you could always ping the broadcast address for the local IPv4 network and see who answered . Under IPv6 you would ping the link-local all hosts address ff02::1 , which is the rough equivalent to IPv4 broadcast. However, for individual system location your testing implies that you will need to remember the MAC addresses for all of your machines as well as know which prefix is valid for that network.

This brings up the question of defined addressing. You wonder how the routing structure would be done manually and whether under such a routing structure you could assign addresses that are easier to use. To this end you decide to recode the test network using manual addressing and routing.

You first reboot router1 back into the 2.4.0 kernel. You then decide to use the same prefixes as you had just used in the radvd testing. So you set up the following logical implementation:

 
 # net1         eth0: dead:1::1/64         route added to dead:2::/64 through router1 # router1         eth0: dead:1::e0/64         eth1: dead:2::e1/64 # host1         eth0 dead:2::1/64         route added to dead:1::/64 through router1 # host2         eth0: dead:2::2/64         route added to dead:1::/64 through router1 
 

This setup is easily implemented using the ip utility as follows for each system:

 
 # net1  ip -6 addr add dead:1::1/64 dev eth0   ip -6 route add dead:2::/64 via dead:1::e0  # router1  ip -6 addr add dead:1::e0/64 dev eth0   ip -6 addr add dead:2::e1/64 dev eth1  # host1  ip -6 addr add dead:2::1/64 dev eth0   ip -6 route add dead:1::/64 via dead:2::e1  # host2  ip -6 addr add dead:2::2/64 dev eth0   ip -6 route add dead:1::/64 via dead:2::e1  
 

Now you get onto net1 and try your ping6 command to host1:

 
 [root@net1/root]#  ping6 dead:2::1  PING dead:2::1(dead:2::1) from dead:1::1 : 56 data bytes 64 bytes from dead:2::1: icmp_seq=0 hops=63 time=1.627 msec 64 bytes from dead:2::1: icmp_seq=1 hops=63 time=517 usec 64 bytes from dead:2::1: icmp_seq=2 hops=63 time=507 usec --- dead:2::1 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/mdev = 0.507/0.883/1.627/0.526 ms 
 

Now you are getting somewhere. This is much easier both in the command lines and in the addresses. So you now set up the hosts file on net1 to contain the addresses of both host1 and host2 using these new addresses, and you can simply issue a ping6 host2 command and get results.

The more you now consider the impact of IPv6 in your networks, the more you realize that there are several evil residues of IPv4 that will probably come back into play. Specifically the DHCP (Dynamic Host Configuration Protocol) and the DDNS (Dynamic DNS) protocols. DHCP was invented to save the hassle of running around to all the various computers on a network and coding in the IPv4 address and related information. DDNS was invented to keep current DNS mappings for all of those addresses assigned by DHCP.

You must remember that IPv6 has provided a simple and easy-to-use automatic addressing and routing structure for you if you want to just have everything plug in, turn on, and network. As with IPX, in such an environment you can assign addresses to the core servers and set them up in a DNS server and have everybody work without any need for extra configuration.

And as with IPX, you have no real control over the actual addressing that the hosts end up with although you do control the routing. This last point is most important. You do control the routing through the assignment of prefixes in the advertising routers. You can also control the actual advertising of the various prefixes to each other and to the hosts. So your extensive experience in IPX networks is a great boon to using IPv6.

On the other hand, if you want the control and need to make sure that hosts are assigned only the addresses that you would like them to have, you can. So your extensive use of DHCP in your current IPv4 networks can carry right over into the new IPv6 as well. Thus, IPv6 allows you to do whatever you want to do on the network and with the infrastructure.

This level of flexibility also allows you to have both types of configurations running side by side. You can allow most of the hosts to autoconfigure and manage the routing structure for controlling their access. And you can have select groups of hosts that obtain addresses and configuration information from DHCP. This dual personality becomes important when you start to consider the usage and interconnection of IPv6 onto the Internet.

Internet IPv6 routing does not allow for NAT and thus requires that communicating hosts have assigned legal prefixes. Under this type of configuration you can limit full Internet access on the basis of assigned prefixes and addressing. The rest of the access can be via proxy servers, thus allowing those auto-addressed hosts access to the Internet services as mediated by the routing and the proxy system.

All of this is possible because IPv6 from the beginning has allowed for, and even to some extent demanded, multiple addressing on the host. You saw some of this when you added in the static addresses and noted that the link-local addresses were still present and usable. This entire subject of multiple addressing should be old hat to you by now because it derives from the Address element of the Triad. It is also the hottest topic of discussion in the implementation mailing lists due to the source address selection mechanisms (RFCs 2460, 2461, 2462) for routing and hosts.

As one final test of your IPv6 network, you remember that Zebra (see Chapter 7, "Dynamic Routing Interactions") had a module for both RIPng and OSPFv3 (OSPF for IPv6). You dig the source code out on router1 and compile the ospf6d, OSPFv3 for IPv6 , module. Then you give it the basic configuration used in radvd and note that the packet traces show the OSPF IPv6 packets being issued from router1. Since you do not yet have any other routers that speak OSPF6, you decide to try again when you do.


   
Top


Policy Routing Using Linux
Policy Routing Using Linux
ISBN: B000C4SRVI
EAN: N/A
Year: 2000
Pages: 105

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net