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

[Tom Henderson]

Sébastien Vincent wrote:
> 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.

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.

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?

 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.

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.

Thanks again for initiating all of this work,
Tom