2.1 IPv6 features in Betasite
Addressing in IPv6 Betasite
In our IPv6 Betasite, we have employed the automatic stateless addressing scheme [20] for address configuration. Most of the betasite users have end systems with native IPv6 support. They obtain an IPv6 address by the following procedure: The betasite core router (as shown in figure 1) helps nodes in the autoconfiguration process by sending RAs (Router Advertisements). A RA is an ICMPv6 message periodically sent by the core router or on request of a node. When a node is powered on, it first derives its link-local address from its MAC address.
With this address, the node can communicate within the link since link-local addresses are not routed. Then, the node tries to discover local routers by sending an ICMPv6 message called Router Solicitation (RS). Betasite core router on the link will answer with a RA. RA will include Prefix options, which the node will use to configure itself with additional IPv6 addresses derived from the advertised prefixes. In the meanwhile, when a host name to an IPv6 address needs to be resolved, host can make a DNS query using IPv4 and receive quad A resource records.
Routing in IPv6 Betasite
In our IPv6 Betasite, we have employed dynamic routing protocols RIP, OSPF, BGP for routing IPv4 traffic while RIPng, OSPFv3 [21, 22] for routing IPv6 traffic. As IPv6 is already initialized on the system, IPv6 routing table is generated automatically. IPv6 routing tables essentially represent the routes which are as follows: (a) Host routes: that identify a specific IPv6 node and contain 128-bit prefixes (b) Network routes which are directly attached: that identify the adjacent links and contain 64-bit prefixes (c) Remote network routes: that identify the remote links and they have varying prefixes (d) Default route: this is used when a host route cannot be determined. It uses the network prefix ::/0. When an IPv6 packet arrives at a network interface, the host adopts one of the following methods in order to determine how to forward the packet to its destination: (a) checking the destination cache which should match with the address in the packet header.
5
In such cases, host forwards the packet directly to the address and the routing process ends. (b) If the destination address in the packet header and the destination cache do not match, then the host uses local routing table to determine the forwarding mechanism using next-hop address and next-next-hop interface which work in tandem.
Multicasting in IPv6 Betasite
In our IPv6 Betasite, we employ the Protocol Independent Multicast Sparse Mode (PIM-SM) multicast routing protocol [23] for routing multicast streams between VLANs, and subnets. It is responsible for constructing distribution trees and forwarding multicast packets and facilitates the exchange of information between routers. A detailed description on how multicast packets are transmitted in IPv6 betasite is given in next chapter.
Roles of IPv6 Betasite key players
In our IPv6 Betasite, there are three key players whose concerns need to be addressed in a systematic manner. The key players are: (1) Vendor (2) Betasite user (3) Network administrator.
(1) Vendor
The role of a vendor is of an experimentalist who requires an appropriate and customized testing ground for testing various IPv6 supported network devices.
(2) Betasite user
In our campus, totally there are three services provided for easy access to internet: The first one is a regular network and the second one is NCTU wireless. The third one is Betasite network, provided by Network Benchmarking Lab in association with Computer Center, which has about 1000 users. In this project, it is proposed to adopt all the students who have subscribed to Betasite network as users.
(3) Network administrator
The roles of a network administrator in this project are multi-faceted, beginning with the testing of a device to balancing the requirements of user and vendor.
6
The roles which are most crucial for this project are as follows: (a) check DUT for stability issues such as: crash, reboot, lowering speed and others (b) check DUT supported features (c) check DUT incompatibility issues (d) maintain balance between user and vendor.
2.2 Concerns in Building an IPv6 Betasite
From the point of view of Vendor, the possible concerns are as follows:
Array of test zones
Due to the growing number of IPv6 supported network devices such as: L3 switches, core routers, security appliances, residential gateways and so on, the Betasite must provide wide range of environments to test these devices.
Debugging
The facility that Betasite extends through IPv6 in a few instances may not fulfill the demands of the vendor. In some cases, vendor may design new features and would want to test them. Betasite must provide such facility which would assist in fixing the defects.
From the point of view of Betasite User, the possible concerns are as follows:
Easy migration to IPv6
Noticing the number of devices that have become web-enabled (smart phones and other electronic equipment such as televisions, cameras and even cars), it becomes unbearable to provide internet access to them using IPv4. If those devices should continue to function in the same way, IPv6 is the ideal solution. However, expecting users to configure their IPv6 address, like the way they do for IPv4 is impractical, since IPv6 has 128-bit addressing scheme. Hence for user convenience, Betasite must provide mechanisms for easy transfer to IPv6.
Access to IPv6 enabled services
As we move to IPv6, there is an increasing demand for bandwidth-intensive applications such as online video, IP-based telephony services from the users. Betasite must provide support for IPv6 enabled applications and services.
From the point of view of Network administrator, the possible concerns are as follows:
7
Speedy network recovery
Minimizing network downtime is a critical task. It is obvious that a network topology consisting of many network components may incur failures such as link failure, node failure and others. Hence, it is necessary to ensure that there are fewer network failures and more productivity. In addition to providing adequate hardware support for IPv6, Betasite must provide mechanisms for speedy network recovery thereby maintaining connectivity.
Status reporting and maintenance team
Delivery of desired service with appropriate feedback mechanism from customers would assist network administrators in understanding user necessities and technical hitches. Betasite must have a maintenance team for its continued growth and success.
2.3 Protocol procedure formats
Node Layer 2 Switch Layer 3 Switch Router
IPv6 Addressing Mechanism
Router Solicitation (To all-routers multicast group)
Router Advertisement (Prefix info. option)
Working:
· Node enables multicast capable IPv6 interface & generates a link-local address
· Interface ID (MAC addr) + link-local prefix FE80:: = Link-local address
· Check address is unique or not using Duplicate address detection (DAD)
· Node sends Router solicitation (RS)
· Router sends router advertisement (RA)
· Forms globally unique IPv6 address using prefix from RA
Figure 1: Protocol procedure format (Addressing)
8
Client Layer 2 Switch
Layer 3 Switch Master (IP Address)
VRRP Mechanism
(ARP request)
Backup
VRRP Advertisement (Priority)
Working: IP Multicast datagrams (protocol messaging)
· Each VRRP virtual router has a MAC address – Source (enable bridging in LAN)
· Virtual router has virtual router identifier and set of IP addresses
· Priority value: 255: master router owns IP address. Value 0: backup will takeover
· Master sends periodic VRRP Advertisement message
· Backup will preempt master if it has higher priority
Traffic redirect to backup (Virtual MAC address)
(Master) VRID: 1 IP address: 192.168.1.1 MAC: 00-00-5E-00-01-01
Priority: 255
(Backup) VRID: 1 IP address: 192.168.1.1 MAC: 00-00-5E-00-01-01
Priority: 100
Figure 2: Protocol procedure format (Network recovery)
9