[Ns-developers] Implementation of an IPv6 stack for NS-3

[Sébastien Vincent]

Dear ns-3 devs,

We are glad to announce the first release of our functional IPv6 stack 
for ns-3. You can retrieve this implementation from our mercurial 
repository:

hg clone https://svnet.u-strasbg.fr/hg/ns-3-ipv6/

A website about the implementation is available at http://ns3v6.enstb.fr/

This work has been achieved by the University of Strasbourg, France and 
Telecom Bretagne, France.

Our implementation supports basic IPv6 operations (IPv6 address format, 
routing, etc.) and several layer 4 protocols (UDP, TCP and ICMPv6). We 
also support the Neighbor Discovery protocol, which is used in IPv6 for 
address resolution, address autoconfiguration, etc. In addition, we 
provide various IPv6 extensions such as fragmentation, routing header 
type 0 (loose routing) and others. We also implement an IPv6 Raw socket 
which can be used to forge packet and/or forward all IPv6 packets 
received at layer 3 directly to the application.

Our mercurial repository is synchronized daily with the ns-3-dev 
repository. You can find some more details about the implementation at 
the end of this email.

Any feedback is very welcome in order to improve our implementation.

Best Regards,
Sébastien Vincent
Network and Protocol Team, University of Strasbourg, France

----

Technical details about the implementation:

- We try to avoid radical changes in existing classes from ns-3, but 
here are the major (and required) changes:

# *-net-device
-> adding methods to get the multicast Ethernet representation for IPv6 
("33:33:00:00:00:00")

# csma-net-device
-> adding an attribute for setting the MTU (required to test some ICMPv6 
error)
-> adding an EnumValue "IPV6" for attribute EncapsulationMode
-> in ::Receive methods, forward up ethernet multicast representation of 
IPv6 multicast destination (solicited multicast, all-nodes, all-routers 
and all-hosts)

# udp-header and tcp-header
-> some changes for checksum calculation (required in IPv6) for both 
IPv6 and IPv4

- We add icmp-socket.cc,h in the node module to provide an abstract ICMP 
socket (this can be reused to implement ICMPv4 protocol later in ns-3)

- We duplicate and adapt TCP and UDP code to provide our IPv6 version of 
these protocols , we know that it is not the best thing to do. We will 
discuss about it on the mailling-list later.

- We have developped the following applications:

# UdpEcho6Server and UdpEcho6Client: UDP Echo client and server (note 
that this application can also send fragmented packets or add source 
routing extension headers)
# TcpEcho6Server and TcpEcho6Client: TCP Echo client and server
# Icmpv6TestError: application that send bogus IPv6 packets to test 
ICMPv6 errors
# Ping6: send ICMPv6 Echo Request message


- We provide several example files:

# ping6.cc: one node pings another (these nodes are on the same link)
# udp6-echo: one node sends UDP messages to another (these nodes are on 
the same link)
# udp6-echo-link-local : a router between two nodes sends a UDP echo to 
their link-local address
   => needs of settings the interface index on the application side 
(remember ping6 -Ieth0 fe80::1:2:3:4)
# tcp6-echo: one node sends TCP messages to another (two are on the same 
link)
# simple-routing-udp6: one node sends UDP messages to another (these 
nodes are on different links)
# icmpv6-redirect: illustration of ICMPv6 redirect usage
# fragmentation-ipv6: one node sends big UDP packet and it results of 
fragmented  IPv6 packets.
# loose-routing-ipv6: illustration of routing header type 0 (note that 
the routing type 0 extension is deprecated, this is just for test cases)
# wns2-scenario1: illustration of stateless address autoconfiguration 
when a node receives a Router Advertisement
# wns2-scenario2: two routers send Router Advertisements on different 
links (configuration of the default route)
# wns2-scenario3: illustration of multihoming with two routers on the 
same link
# wns2-scenario4: dual stack (IPv4 / IPv6) scenario


- Known issues - to be fixed:

# We assume that Neighbor Solicitation and Advertisement always come 
with the link-layer address option
# We assume that the header of Router Advertisement is followed by a MTU 
option, a list of prefix and a link-layer address option
# Some fields of the Router Advertisement header are not processed 
(CurHopLimit, RouterLifeTime, ReachableTime and RetransTimer)
# The Radvd application needs some design improvement
# We focus our tests on CsmaNetDevice/Channel, it may not work when 
using other device types (e.g. Wifi, PointToPoint)


We are currently working on these issues.