Part III: Supporting IPv6 emulation
2 The Emulation Router
3.5. System Calls
if(skb->nh.ipv6h->daddr.s6_addr16[0] != htons(0x3fff) &&
skb->nh.ipv6h->saddr.s6_addr16[0] == htons(0x3fff)) {
skb->ip_summed = CHECKSUM_UNNECESSARY;
If the packet is from the simulated host to the real host, its checksum should be set to unnecessary.
Thus, the packet would not be dropped during transmission.
}
…
3.5. System Calls
A system call 280 is added in the Linux kernel for registering the divert-socket
information of IPv6. The data passed by system 280 is the filtering rules, the specified action, and the specified hook. When the packet is transmitted through any one of the five hooks and delivered into the callback function, the packet would be filtered according to the rules registered by system call 280. How the system call is called and implemented is shown below.
I. The IPv6 emulation daemon (emudiv.c):
The IPv6 emulation daemon is a program performing the job of translating the simulated IPv6 address to the real IPv6 address and vice versa. In the beginning of the emulation daemon, some system calls are called to register or flush the information of the packet-filtering rules in the specified hook. The details are explained as follows:
ipv6_addr_set(&de_ipv6.smask,0,0,0,0);
memcpy((void *)&de_ipv6.dstip, (const void *)&myipv6, sizeof(struct in6_addr));
ipv6_addr_set(&de_ipv6.dmask,0xffffffff, 0xffffffff,0xffffffff,0xffffffff);
syscall(280, DIVERT_ADDTAIL, divfs, NF_IP6_LOCAL_IN, (char
*)&de_ipv6, len_ipv6);
The daemon fills in some data, such as packet-filtering info, the wanted action, and the specified hook. Then, it passes them to the kernel by system call 280.
…
… }
After the info is sent from the user-level program to the kernel, the kernel will perform some correspondent works according to the system call 280. How the kernel implements the system call 280 is introduced in the part II below.
II. The system calls (nctuns_syscall.c):
The kernel defines a series of system calls, and one of the system calls, system call 280, is used in the IPv6 emulation. After the info is passed from the emulation daemon to the kernel by the system call 280, the kernel will store or flush the packet-filtering info. How this system call is implemented in the kernel is explained in the following.
Implementations of system call 280:
When the system call 280 is called by the user-level program, the data will be passed from the application to the kernel function of sys_NCTUNS_divert_ipv6.
Then, in sys_NCTUNS_divert_ipv6(), the other kernel function － nctuns_reg_divert_rule_ipv6()－ will be called.
In the kernel function (nctuns_reg_divert_rule_ipv6()), a series of actions are implemented, such as DIVERT_ADD, DIVERT_FLUSH, etc. The kernel takes the correspondent action according to the choice passed from the user-level program by system call 280.
Example:
On condition that the action of DIVERT_ADD is chosen, the packet-filtering info passed by the user-level program will be stored in the correspondent hook. Then, when a packet is transmitted through that hook, it will be filtered according to the info stored in the hook. The detailed kernel codes are listed as follows:
asmlinkage int sys_NCTUNS_divert_ipv6(int action, int fd, u_long hook, struct divert_entry_ipv6 *de, int addr_len)
{
…
ret = nctuns_reg_divert_rule_ipv6(action, sock ? sock->sk : NULL, hook, de,addr_len);
return ret;
}
int nctuns_reg_divert_rule_ipv6(int action, struct sock *sk, u_long hook, struct divert_entry_ipv6 *de, int addr_len)
{
This is the system call 280.
This kernel function is called for further processing of the info passed from the user-level program.
The correspondent works are performed according to the action passed by the user-level program.
case DIVERT_ADDTAIL:
…
memcpy((void *)&dr->srcip, (const void *)&myde->srcip, sizeof(struct in6_addr));
memcpy((void *)&dr->smask, (const void *)&myde->smask, sizeof(struct in6_addr));
memcpy((void *)&dr->dstip, (const void *)&myde->dstip, sizeof(struct in6_addr));
memcpy((void *)&dr->dmask, (const void *)&myde->dmask, sizeof(struct in6_addr));
dr->sport = myde->sport;
dr->dport = myde->dport;
...
if (action == DIVERT_ADDHEAD) list_add(&dr->nextdr, &rule_table[hook]);
else if (action == DIVERT_ADDTAIL)
list_add_tail(&dr->nextdr, &rule_table[hook]);
break;
…
}
The packet-filtering info is stored in the hook which the user-level program chooses.
Future Work
Although the simulation and emulation environment of IPv6 has been built up, there are still some valuable topics needed to be implemented in NCTUns. These uncompleted works, such as mobile IPv6, RIPv6, OSPFv6, and so forth, are listed in the table below for further development by others who are interested in these topics.
The Mobile IPv6 Not done
The QOS of IPv6 Not done
RIPv6 Not done
OSPFv6 Not done
Optical Networks of IPv6 Not done
VoIPv6 Not done
Command console Not done
Conclusions
Due to the exponentially increasing internet users and newly designed devices, such as 3G mobile phones, embedded vehicular network devices, and so on, the next generation network protocol (IPv6) is becoming increasingly important in the future.
Therefore, we provide an environment for users to conduct their interested IPv6-related topics at low costs in NCTUns. In the previous sections and chapters, we explain what we did to support the IPv6 simulation and emulation in NCTUns. That is to say, the environment of the simulation and emulation of IPv6 has already been built up. Therefore, researchers can now conduct any IPv6-related study in the environment that we have developed. To make the readers more clearly understand how much work we have done, completed works are listed in the table below.
Phase one Modify the current traffic generator to generate IPv6 packets
We modify the ttcp, stg , rtg, stcp and rtcp to support IPv6 traffic generator.
The pure IPv6 simulation with simple network topology
The simulation of all of these types of packets
(TCP/UDP/ICMPv6) is OK.
In this stage, we modify the Linux kernel and simulator codes to support the basic IPv6 simulation.
Modify the Linux kernel to support the function of broadcast for IPv6
This part is completed.
Modify the AODV module to support the IPv6 simulation
This part is completed.
Add modules to support mixed simulation of IPv4 and IPv6
This part is completed.
Phase two
Support IPv6 emulations This part is completed
As shown in the above table, we can see how much we have achieved for the IPv6 simulation. Currently, NCTUns is capable of supporting simulations of fixed networks and wireless networks with AODV and GOD routing protocols, and simulations with mixed IPv4 and IPv6 networks. In addition, NCTUns supports the emulation of the mixed IPv4 and IPv6 networks as well.
Appendix
1. The IPv6 Routing
To make the IPv6 packets be routed correctly, there is one topic worth to be paid attention to－the IPv6 forward system variables need to be set. How these variables are set is listed below.
sysctl –w net.ipv6.conf.all.forwarding=1 sysctl –w net.ipv6.conf.default.forwarding=1
If we don’t set these system variables, the packets will not be forwarded by the middle node. Therefore, the works of setting these system variables are necessary. For the purpose of saving the efforts for users to set these two variables, we have added these actions in nctuns.cc, the file of simulator engine.
2. Traffic Generators for IPv6
Due to the traffic generators supplied by NCTUns all in IPv4 protocol, if these user-level programs are not modified to support the network protocol of IPv6, the IPv6 packet cannot be generated, and the environment of IPv6 we develop cannot be tested. Therefore, before the environment of IPv6 is built up, traffic generators, such as ttcp_v6, stcp_ipv6, and so on, are modified to support the protocol of IPv6. By the way, the ping, an application program generating the ICMP packets, is needless to be
modified because there is a real one supported by Linux called ping6.
3. The Added Broadcast Function for IPv6
Unlike the protocol of IPv4, no broadcasting function exists in the protocol of IPv6. The network protocol of IPv6 replaces the ability of broadcast with the ability of multicast; nevertheless, that mechanism is hard to be supported in NCTUns. Based on this, we implement a mechanism by assigning a specially designed address as the destination address to emulate the broadcast function in NCTUns. If the destination address format is like the format listed below, we will regard this type of packet as the broadcast.
z The special address Format:
3fff:00:00:DstNetID:00:00:ffff:ffff
The destination address in the special address format will be accepted by all of its neighbors. To make this scheme function correctly, the kernel function of tun_get_user() needs to be modified. The modifications are listed as follows:
static __inline__ ssize_t tun_get_user(struct tun_struct *tun, struct iovec *iv, size_t
count) The address with special
word (0xffff) will be replaced with the address of this node.
Therefore, this special address could be accepted by every node.
{
… …
if((ipv6_hdr->daddr.s6_addr16[7] & 0xffff)==0xffff)
{
memcpy((void *)&ipv6_hdr->daddr, (const void *)&ipv6, sizeof(struct in6_addr));
} … }
To better understand of this scheme, an example is given below.
Example:
When node 1 wants to broadcast the packet to its neighbors within the specified subnet it belongs to, it sends the packet with the destination address of 3fff::0001::ffff:ffff. This kind of packet would be accepted by all of its neighbors (node2, node3 and node4).
Node2: 3fff::0001::0100:0102
Node3: 3fff::0001::0100:0103 Node1: 3fff::0001::ffff:ffff
Hub
Node4: 3fff::0001::0100:0104
Figure 4.1: Supporting the broadcast function for IPv6
Reference
[1] Thomson & Narten, IPv6 Stateless Address Autoconfiguration, RFC 2462, December 1998
[2] Hinden & Deering, Internet Protocol Version 6 (IPv6) Specification, RFC 2460, December 1998
[3] Hinden & Deering, IP Version 6 Addressing Architecture, RFC 2373, July 1998
[4] IAB & IESG, IPv6 Address Allocation Management, RFC 1881, December 1995
[5] Hinden & Deering, IPv6 Multicast Address Assignments, RFC 2375, July 1998
[6] McCann, Deering & Mogul, Path MTU Discovery for IP version 6, RFC 1981, August 1996
[7] Conta & Deering, Generic Packet Tunneling in IPv6, RFC 2473, December 1998
[8] Gilligan & Nordmark, Transition Mechanisms for IPv6 Hosts and Router, RFC 2893, August 2000
[9] Carpenter & Moore, Connection of IPv6 Domains via IPv4 Clouds, RFC 3056, February 2001
[10] K.C. Liao, Porting the NCTUns Network Simulatior to Linux and Supporting Emulation, June 2004
[11] S.Y. Wang, C.L. Chou, C.H. Huang, C.C. Hwang, Z.M. Yang, C.C. Chiou, and C.C. Lin, The Design and Implementation of the NCTUns 1.0 Network
Simulation Engine, Computer Networks, Vol. 42, Issue 2, June 2003, pp.
175-197
[12] Porting applications to IPv6 How To,
http://gsyc.escet.urjc.es/~eva/IPv6-web/ipv6.html#RFC2731
[13] Tomohiro Fujisaki and Junya Kato, Tech Tutorials, http://www.ipv6style.jp/en/tech/20050509/index.shtml