IPv6 deployment:campus network
Introduction to IPv6
Implementing a simple SOHO network using IPv6
Implementing a small development network using IPv6
Implementing a medium-sized IPv6 campus network
http://dons.usfca.edu/buckwalt/ipv6/image030.gif
Infrastructure requirements and layout
In this section, we describe the network layout, design, and example implementation for a network used by a medium-sized law firm. The requirements for this office represent those of technology-aware professionals whose needs include:
- All requirements of a SOHO office, as described in the earlier section
- The ability to keep information and technology resources safe behind a firewall
- The ability to separate traffic based on local geographic divisions, for instance, floors in a building, in an effort to increase network efficiency (reduction in broadcasts, etc)
Again, everything that we wish to accomplish for IPv6 can be done with "off the shelf" components, including Linux as the firewall/router.
Implementation strategy in IPv4
If we were deploying this architecture for an IPv4 environment, we would include our "small development network" configuration from the previous section, with a few notable exceptions:
- We would use private Internet addresses since we do not require direct connections to the Internet
- Since there are multiple routers, we would employ a routing protocol among the routers.
- We may configure a DNS server to answer DNS requests locally for our growing network. However, as before, this is probably not necessary because our ISP likely provides DNS and mail service for us.
- The firewall’s outside interface (A) is a globally accessible Internet address. The firewall’s inside interface (C) is a private IP address pool which is not routable. All backbone routers (D) on the network are on the same subnet as the firewall’s inside interface. All web traffic takes place through the web proxy (B) to take advantage of filtering, virus scanning, and caching. Each backbone router is responsible for its own subnet (E).
Implementation strategy in IPv6
Once again, the IPv6 implementation strategy is an extension of the IPv4 strategy. Thus the IPv6 strategy must include:
- Each router must be configured with its own unicast address.
- Each backbone router must advertise its site-local addresses (which can be routed within the company's network) to its end nodes.
- Each backbone router (and the firewall) must share routing information. In our case, we can assume the use of the RIPng routing protocol.
In the hands-on example given below, we introduce a new server that acts as a pure router and functions as a backbone router, as in the diagram. The firewall, proxy server, and backbone routers will communicate on the network fec0::/64. The four backbone routers in our diagram will communicate on networks fec0:0:0:1::/64, fec0:0:0:2::/64, fec0:0:0:3::/64, and fec0:0:0:4::/64 respectively. (We choose 64 bit address spaces since stateless autoconfiguration requires 64 bits for the node address.) We will concentrate on the configuration of the router for fec0:0:0:1::/64 only. The other backbone routers are similar.
First, we must configure our firewall to use its new address space. We do this by once again changing the /etc/rc.d/init.d/IPv6-init script so that it looks like this:
/sbin/ifconfig eth0 inet6 add fec0::192.168.1.6/64 /sbin/ifconfig sit0 up /sbin/ifconfig sit0 tunnel ::64.71.128.82 /sbin/ifconfig sit1 up /sbin/ifconfig sit1 inet6 add 2001:470:1f00:ffff::759/127 /sbin/route -A inet6 add ::/0 dev sit1
Also, we must configure our Router Advertisement daemon to broadcast the new address space. Thus /etc/radvd.conf looks like this:
interface eth0 {
AdvSendAdvert on;
MinRtrAdvInterval 3;
MaxRtrAdvInterval 10;
AdvSourceLLAddress on;
AdvDefaultLifetime 300;
AdvHomeAgentFlag off;
prefix fec0::/64 { # this is subnet0 on our site network
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr off;
};
};
Once again, note that we have configured the use of Router Advertisement using the ICMP protocol. This is a built-in function of IPv6 and allows our router to tell its clients the network addresses for which it is responsible during the autoconfiguration process. Additionally, the router tells the end nodes about a subset of available routes. This is not to be confused with routing protocols, which are used by routers to share routing table information among each other.
After configuration of Router Solicitation, we reboot the machine (of course).
Next, we need to setup a second Linux machine which acts as a backbone router. Because the machine is not a firewall, the configuration is quite simple. We need only to install the radvd software and make the following configurations:
/etc/rc.d/init.d/IPv6-init:
#!/bin/bash ## ## ## The following lines are for a complex network ## in which this machine is a router (and not a host) ## /sbin/sysctl -w net.IPv6.conf.all.forwarding=1 /sbin/ifconfig eth1 inet6 add fec0::192.168.1.16/64 /sbin/ifconfig eth0 inet6 add fec0:0:0:1::192.168.1.16/64
And then our radvd.conf file looks like this:
interface eth0 {
AdvSendAdvert on;
MinRtrAdvInterval 3;
MaxRtrAdvInterval 10;
AdvSourceLLAddress on;
AdvDefaultLifetime 300;
AdvHomeAgentFlag off;
prefix fec0:0:0:1::/64 { #this is the 2nd site-local netw.
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr off;
};
};
Finally, we should create a routing protocol so that all backbone routers (and the firewall) can share routing information. Many textbooks state that an administrator "must" configure a routing protocol, but in high-society, we are also told that if we go to Paris, we must see the Louvre. In fact, just as there is no law regarding the necessity of tourists seeing the Louvre, there is no absolute requirement that a routing protocol must be configured. However, there are some good reasons to do it.
The best reason to implement a routing protocol is for administrative efficiency. A routing protocol allows an administrator to rapidly propagate changes to the network. The changes could be due to adding new equipment to enhance performance or could be due to link failure, in which case redundant links would be used to propagate the information about the failure. Imagine if an administrator added a router to a backbone system of a very large network. In a manually configured architecture, routing entries would have to be changed in potentially hundreds of places (introducing a greater chance of error).
A second reason for using a routing protocol is that, when used in combination with stateless autoconfiguration, the administrator can take advantage of dynamic IP readdressing. IP readdressing would be necessary, for instance, if the ISP for the user's network changes.
Finally, routing protocols (especially cost-based protocols like OSPF and EIGRP) allow multiple routes for traffic and can compensate for slow links, etc. Manual routing tables do not provide any easy way to express that 80% of traffic should take one route and the remaining 20% should take another route, based on bandwidth utilization. However, using cost-based routing, traffic can be dynamically shaped to best use the resources. Thus gives the designer of the network some flexibility in its implementation.
Fortunately, the Linux community has a software package that allows use of many different routing protocols, including RIPng, which is the simplest dynamic routing protocol and is appropriate for our simple network. The package is called "zebra" and is available at zebra.
Installation of the software is quite simple.
1. Download the source zebra source
2. Extract the source files from the tar ball with the following command:
$ tar xzf zebra-0.93b.tar.gz
This creates a directory called zebra-0.93b
3. Enter the directory and configure the source:
$ cd zebra-0.93b $ ./configure
4. Compile the source:
$ make
5. Install the compiled binaries as the "root" user:
$ su – root –c ‘make install’
6. Next, edit the zebra configuration file:
# vi /usr/local/etc/zebra.conf ! -*- zebra -*- ! ! zebra configuration file ! this is for one of the backbone routers ! in our example hostname beduin.jspears.org password SEKRETPASSWORD enable password SEKRETPASSWORD log syslog ! interface lo ! ! this is because the backbone is on eth1 interface eth1 IPv6 nd send-ra !
! ! Zebra configuration saved from vty ! 2003/04/25 23:20:13 ! this is the configuration on the firewall ! hostname sparta.jspears.org password ANOTHERSEKRETPASSWORD enable password ANOTHERSEKRETPASSWORD log syslog ! interface lo ! interface sit0 IPv6 nd suppress-ra ! interface eth0 IPv6 nd send-ra ! ! no other interfaces are listed ! because they don’t need ! to send routing updates. line vty
7. In our example environment, we have a very simple network layout. The backbone router has a single path to each endpoint machine, and each path has an identical cost. Because of this simplicity, we want to use RIPng as our routing protocol. To enable the RIPng protocol, we need to edit the ripngd configuration file:
# vi /usr/local/etc/ripngd.conf ! -*- rip -*- ! ! RIPngd sample configuration file ! This file resides on one of the backbone routers ! ! $Id: ripngd.conf.sample,v 1.12 1999/02/19 17:35:39 ! developer Exp $ ! hostname beduin.jspears.org password SEKRETPASSWORD ! router ripng network eth1 ! This is the route we are advertising: route fec0:0:0:1::/64 ! this is where we are sending it: distribute-list local-only out eth1 ! log syslog
! -*- rip -*-
!
! RIPngd sample configuration file
! This is the ripng for my firewall
!
hostname sparta.jspears.org
password ANOTHERSEKRETPASSWORD
!
!
router ripng
network eth0
route ::/0
route fec0::/64
log syslog
We can start the routing protocols by creating a startup script:
#!/bin/bash
case “$!” in
start)
/usr/local/sbin/zebra –d
/usr/local/sbin/ripngd –d
;;
*)
echo “No other functions supported”
;;
esac
After the router protocols are started on both hosts, we should be able to see static and dynamic routes:
$ telnet sparta.jspears.org 2601 # this is the zebra port
Trying 192.168.1.6...
Connected to sparta.jspears.org.
Escape character is '^]'.
Hello, this is zebra (version 0.93a).
Copyright 1996-2002 Kunihiro Ishiguro.
User Access Verification
Password:
sparta.jspears.org> enable
Password:
sparta.jspears.org# show IPv6 route
Codes: K - kernel route, C - connected, S - static,
R - RIPng, O - OSPFv3,
B - BGP, * - FIB route.
K>* ::/0 is directly connected, sit1
C>* ::1/128 is directly connected, lo
C>* 2001:470:1f00:1040::/64 is directly connected, eth0
C>* 2001:470:1f00:ffff::758/127 is directly connected, sit1
C * fe80::/10 is directly connected, eth2
C * fe80::/10 is directly connected, eth1
C * fe80::/10 is directly connected, eth3
C * fe80::/10 is directly connected, vmnet8
C * fe80::/10 is directly connected, eth0
C>* fe80::/10 is directly connected, sit1
C>* fec0::/64 is directly connected, eth0
R>* fec0:0:0:1::/64 [120/0] via fe80::203:5cff:fe20:2e8,
eth0, 00:00:28
sparta.jspears.org# exit
Connection closed by foreign host.
$ telnet beduin.jspears.org 2601 # this is the zebra port
Trying 192.168.1.16...
Connected to beduin.jspears.org.
Escape character is '^]'.
Hello, this is zebra (version 0.93b).
Copyright 1996-2002 Kunihiro Ishiguro.
User Access Verification
Password:
beduin.jspears.org> enable
Password:
beduin.jspears.org# show IPv6 route
Codes: K - kernel route, C - connected, S - static,
R - RIPng, O - OSPFv3,
B - BGP, * - FIB route.
C>* ::1/128 is directly connected, lo
C * fe80::/10 is directly connected, eth0
C>* fe80::/10 is directly connected, eth1
C>* fec0:0:0:1::/64 is directly connected, eth0
R>* fec0::/64 [120/0] via fe80:: 201:3ff:fe31:aadd, eth1,
00:00:16
This concludes the IPv6 implementation strategy for the medium-sized IPv6 campus network.
Internal links
Next section: Conclusion
Main article: IPv6 deployment