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

[Sébastien Vincent]

Hi,

Tom Henderson wrote:
>
> Sebastien,
>
> Mathieu hit on some of these already and I'm sure more will arise as 
> we start to test it more, but I just had a few higher level questions 
> and comments:
>
> - I think it will be a great help to researchers to start to make 
> available and maintain these IPv6 models in the main tree.  To that 
> end, one way we could do this is to isolate some small chunks and 
> schedule their merge with ns-3-dev.  For instance, start with IPv6 
> address class definition, then perhaps adding the addresses to 
> interfaces, IPv6 address generation for scripts, basic link-local 
> operations, etc.

Yes,  we think also to split up code and merge it.

>
> The other option would be to try to do a big merge of everything you 
> have.  I think it would be nice to try to do things incrementally 
> because, as you note, there will need to be more testing with each 
> portion (e.g., your focus on CSMA NetDevice).  How might you propose 
> to define smaller mergeable chunks?
>
We propose the following chunks :

1)
- Ipv6Address
- IPv6Prefix
- CsmaNetDevice changes (+ other changes in *NetDevice => 
GetMulticast6() methods)
- Inet6SocketAddress
- Ipv6Header
- Ipv6Route
- IcmpSocket (abstract class)
- Test file that show basic Ipv6Address manipulation like 
tutorial/testipv4.cc

2)
- Ipv6L4Protocol
- Ipv6StaticRouting
- Ipv6Interface (abstract)
- NdiscIpv6Interface (without Send function)
- Ipv6L3Protocol (without Ipv6Extension)
- Icmpv6L4Protocol (without DAD handling, NS/NA, RA/RS)
- Test file that add Ipv6Address on a Node.
- InternetStackv6
- Helper classes (Ipv6InterfaceContainer, Ipv6AddressHelper, 
InterfaceStackv6Helper).

3)
- Icmpv4L4Protocol with DAD, NS/NA and RA/RS.
- NdiscCache  and all Icmpv6Socket things (factory, impl, ...)
- Ipv6EndPoint
- Ipv6EndPointDemux
- Ping6 application, helper and example.
- Radvd application, helper and example
- Icmpv6TestError application, helper and example

4)
- UDP / TCP protocol + all sockets related things (wait to have done the 
UDP/TCP independant work)
- UdpEcho6 application, helper and example
- TcpEcho6 application, helper and example


5)
- IPv6ExtensionHeader
- Ipv6Extension
- Ipv6Option (option in the extension)
- Ipv6OptionDemux
- Ipv6OptionHeader
- Loose routing example
- Fragmentation example


IPv6 is closely related to Neighbor Discovery protocol (which use 
ICMPv6). This protocol is used for retrieve layer 2 address from IPv6 
address (similar to ARP features), detecting a duplicating address on 
the link, error reporting, information (ping6), ...

It would be very very good if we could unify and merge 2) and 3) in same 
time. I don't know if it will be too much code to review but with  2) 
and 3) we have a basic functionnal IPv6 core. Otherwise we will have to 
cut a lot of things in the 2)'s code.

What do you think ?

> From my perspective, this is code we will want to merge but we have a 
> lot in our queue already so we need to try to weave it into the schedule.
>
> - I've noticed (and you mentioned in your email) that you have taken a 
> non-intrusive approach to the existing codebase.  I am curious, 
> though, whether there are particular aspects that you feel could 
> benefit from refactoring, or even better API choices to facilitate 
> IPv4 and IPv6 coexistence.  One area that leaps out is how to make TCP 
> and UDP implementations work across address families; it would be nice 
> to come up with a plan to avoid duplicating those transport protocols 
> entirely.
> (I see you are discussing that on IRC even this morning)  But I'm also 
> curious whether there are parts of the simulator where you think that 
> the design is too slanted towards IPv4.
>

Except few things (neighbor discovery, DAD, Addresses, extensions ), the 
behavior of IPv4 and IPv6 is quite the same. So I had not see API to 
change at layer 3. We could have done something in layer 4 (share 
TCP/UDP code) but we wanted to have a working implementation in order to 
write a paper for WNS2. And as you say after, having one Interface 
classes which manage IPv4 and IPv6 addresses would be very interesting.

> Mathieu already raised the IPv4 multihoming problem and discussed your 
> solution for IPv6 (which I think is reasonable), and this is an issue 
> that I'd like to try to work out once we get past this next release. 
> So, from my standpoint, it might be nice to work towards a goal of 
> having both IPv4 and IPv6 addresses on interfaces, with multihoming 
> support for both, as a focus for next month.
>
> - Also, if you could come up with some priority lists for next steps 
> identify any area where help is needed or how other researchers might 
> contribute.  Maybe if you could post a wiki page to describe your 
> evolving roadmap.  Particularly, I'm interested in your plans for 
> routing support, tunneling protocols, and also mobile Ipv6.
>

We will update our wiki and add roadmap with task duration.

ENST Bretagne team are in the very early stage of a Mobile IPv6 design. 
We think also about MLDv2 (Multicast Listener Discovery) and it would be 
very interesting if someone could contribute. Other things that comes in 
my mind : port the src/routing/global-routing and src/routing/olsr in 
IPv6 (also by sharing code).

Now we concentrate on the integration of IPv6 in NS-3 mainline 
(preparing code chunks). Personally I work on UDP/TCP to make it more 
independant from the network layer.

> Thanks again for initiating all of this work,
> Tom
>
Regards,
--
Sebastien Vincent
Network and Research Team - University of Strasbourg