ipv6 plans for ns-3

[Tom Henderson-2]

Sebastien,
I'd like to put the IPv6 code back on track for merging into ns-3-dev.  Can
you please provide a status update on the repos that you or your group are
maintaining at https://svnet.u-strasbg.fr/hg/ and what you might suggest
for next steps?  Also, I'd like to know where the effort to refactor the
transport protocols and network layer to allow a common transport protocol
implementation to use IPv4 and IPv6 ended up-- I see that the current
ns-3-ipv6 repo has separate IPv4 and IPv6 implementations for TCP.

Thanks,
Tom

[Sébastien Vincent]

Hi Tom,

Tom Henderson a écrit :

> Sebastien,
> I'd like to put the IPv6 code back on track for merging into ns-3-dev.  Can
> you please provide a status update on the repos that you or your group are
> maintaining at https://svnet.u-strasbg.fr/hg/ and what you might suggest
> for next steps?  Also, I'd like to know where the effort to refactor the
> transport protocols and network layer to allow a common transport protocol
> implementation to use IPv4 and IPv6 ended up-- I see that the current
> ns-3-ipv6 repo has separate IPv4 and IPv6 implementations for TCP.
>
>  

Currently,  https://svnet.u-strasbg.fr/hg/ns-3-ipv6 is very outdated.
Two day ago I begin to work with up-to-date ns-3-dev and port some of
the IPv6 components. It is located at
https://svnet.u-strasbg.fr/hg/ns-3-ipv6-2nd (not publicly available yet
but I will unlock access tomorrow or next monday).

For the next release, I really would like to have IPv6 routing, ICMPv6
(+ neighbor discovery protocol), UDP, IPv6 applications such as UdpEcho,
basic examples. If I had time radvd application to have IPv6 address
autoconfiguration, multihoming.
The features delayed will be TCP (if we can not find a good and easy
solution to integrate it nicely), IPv6 header extension (fragmentation,
loose routing, ...).

As I have a lot of work for my job arround wireless sensor network, I
can not work as long as I want on ns-3. But I will do my best during my
spare time on my holidays (tomorrow) to propose a working IPv6 stack.


For ns-3-ipv6-2nd repo I have also integrated Ipv6InterfaceAddress,
Ipv6Interface, NdiscCache. For routing code located in src/node, I think
it will be exactly the same for IPv6 (except changing Ipv4* to Ipv6* ).

For transport protocol, the main problem is (if I remember correctly)
that Tcp/UdpL4Protocol' and Tcp/UdpSocketImpl functions take Ipv4Address
arguments. We already have some discusses here with Mathieu but we have
not found a good solution to handle this. By the way same problem for
IPv4EndPoint / Ipv4EndPointDemux which majority of code will be duplicated.


To resume, I will open my private repository next couple of days. I will
continue to read code about recent IPv4 refactoring and implement
routing stuff (Ipv6L3Protocol), ICMPv6 (and neighbor discovery protocol)
and wait about transport protocol problem. Now all of us interrested in
IPv6 can begin to find a nice way to handle transport protocol in both
IPv4 and IPv6 without copy/paste code. And to finish It will be really
good if we can put great efforts on IPv6 integration for ns-3.6 to bring
ns-3 users the power of IPv6 ;)

Regards,
--
Seb

> Thanks,
> Tom
>
>  

[Sébastien Vincent]

Hi all,

Some notes about IPv6 progress.

I have ported many part of the initial IPv6 work : Ipv6Interface,
Ipv6InterfaceAddress, Ipv6Route, NdiscCache, Icmpv6L4Protocol, ... and
adapted other ones to fit work that has been done (IPv4 refactoring).

Now I have a working example that used IPv6 raw socket: ping6 (./waf
--run ping6). This implementation is a work in progress, there are
additionnal work in routing to manage special multicast address
(all-nodes, all-routers, all-hosts) directly in Ipv6RoutingProtocol
subclasses instead of Ipv6L3Protocol (especially to allow L4 protocol to
send to these addresses).

You will find current work at https://svnet.u-strasbg.fr/hg/ns-3-ipv6-2nd.

Files noted with (*) is a pure copy/paste/adapt from IPv4 ones.

Files added:
src/node/ipv6.cc,h (*)
src/node/ipv6-interface-address.cc,h
src/node/ipv6-raw-socket-factory.cc,h (*)
src/node/ipv6-route.cc,h
src/node/ipv6-routing-protocol.cc,h (*)

src/internet-stack/icmpv6-header.cc,h
src/internet-stack/icmpv6-l4-protocol.cc,h
src/internet-stack/ipv6-end-point.cc,h
src/internet-stack/ipv6-end-point-demux.cc,h
src/internet-stack/ipv6-interface.cc,h
src/internet-stack/ipv6-l3-protocol.cc,h
src/internet-stack/ipv6-l4-protocol.cc,h
src/internet-stack/ipv6-raw-socket-factory-impl.cc,h (*)
src/internet-stack/ipv6-raw-socket-impl.cc,h (*)
src/internet-stack/ndisc-cache.cc,h

src/routing/static-routing/ipv6-routing-table-entry.cc,h
src/routing/static-routing/ipv6-static-routing.cc,h (*)
src/routing/list-routing/ipv6-list-routing.cc,h (*)

src/helper/ipv6-address-helper.cc,h
src/helper/ipv6-interface-container.cc,h
src/helper/ipv6-list-routing-helper.cc,h (*)
src/helper/ipv6-routing-helper.cc,h (*)
src/helper/ipv6-static-routing-helper.cc,h (*)
src/helper/ping6-helper.cc,h

Files modified:
src/helper/internet-stack-helper.cc,h
=> add IPv6 stack directly with IPv4 ones (make dual stack node), I
think about adding methods to enable/disable IPv4 or IPv6 stack in order
to have IPv4 or IPv6 only node.

As you see many files have been copy/paste/adapt, but for the routing
part I think it will have some changes.

Next steps are :
- handle link-local multicast in routing part;
- handle Router Advertisement (receive, parse, extract prefix and
autoconfigured global address with it + timer);
- radvd application like;
- UDP and TCP protocol and implementation (need to be discussed here to
avoid duplicate code);
- IPv6 global routing.

Feedbacks are welcome.

Regards,
--
Sebastien Vincent

Sébastien Vincent a écrit :

> Hi Tom,
>
> Tom Henderson a écrit :
>> Sebastien,
>> I'd like to put the IPv6 code back on track for merging into
>> ns-3-dev.  Can
>> you please provide a status update on the repos that you or your
>> group are
>> maintaining at https://svnet.u-strasbg.fr/hg/ and what you might suggest
>> for next steps?  Also, I'd like to know where the effort to refactor the
>> transport protocols and network layer to allow a common transport
>> protocol
>> implementation to use IPv4 and IPv6 ended up-- I see that the current
>> ns-3-ipv6 repo has separate IPv4 and IPv6 implementations for TCP.
>>
>>  
>
> Currently,  https://svnet.u-strasbg.fr/hg/ns-3-ipv6 is very outdated.
> Two day ago I begin to work with up-to-date ns-3-dev and port some of
> the IPv6 components. It is located at
> https://svnet.u-strasbg.fr/hg/ns-3-ipv6-2nd (not publicly available
> yet but I will unlock access tomorrow or next monday).
>
> For the next release, I really would like to have IPv6 routing, ICMPv6
> (+ neighbor discovery protocol), UDP, IPv6 applications such as
> UdpEcho, basic examples. If I had time radvd application to have IPv6
> address autoconfiguration, multihoming.
> The features delayed will be TCP (if we can not find a good and easy
> solution to integrate it nicely), IPv6 header extension
> (fragmentation, loose routing, ...).
>
> As I have a lot of work for my job arround wireless sensor network, I
> can not work as long as I want on ns-3. But I will do my best during
> my spare time on my holidays (tomorrow) to propose a working IPv6 stack.
>
>
> For ns-3-ipv6-2nd repo I have also integrated Ipv6InterfaceAddress,
> Ipv6Interface, NdiscCache. For routing code located in src/node, I
> think it will be exactly the same for IPv6 (except changing Ipv4* to
> Ipv6* ).
>
> For transport protocol, the main problem is (if I remember correctly)
> that Tcp/UdpL4Protocol' and Tcp/UdpSocketImpl functions take
> Ipv4Address arguments. We already have some discusses here with
> Mathieu but we have not found a good solution to handle this. By the
> way same problem for IPv4EndPoint / Ipv4EndPointDemux which majority
> of code will be duplicated.
>
>
> To resume, I will open my private repository next couple of days. I
> will continue to read code about recent IPv4 refactoring and implement
> routing stuff (Ipv6L3Protocol), ICMPv6 (and neighbor discovery
> protocol) and wait about transport protocol problem. Now all of us
> interrested in IPv6 can begin to find a nice way to handle transport
> protocol in both IPv4 and IPv6 without copy/paste code. And to finish
> It will be really good if we can put great efforts on IPv6 integration
> for ns-3.6 to bring ns-3 users the power of IPv6 ;)
>
> Regards,
> --
> Seb
>
>> Thanks,
>> Tom
>>
>>  
>
>

[Tom Henderson-2]

Sébastien Vincent wrote:

> Hi all,
>
> Some notes about IPv6 progress.
>
> I have ported many part of the initial IPv6 work : Ipv6Interface,
> Ipv6InterfaceAddress, Ipv6Route, NdiscCache, Icmpv6L4Protocol, ... and
> adapted other ones to fit work that has been done (IPv4 refactoring).
>
> Now I have a working example that used IPv6 raw socket: ping6 (./waf
> --run ping6). This implementation is a work in progress, there are
> additionnal work in routing to manage special multicast address
> (all-nodes, all-routers, all-hosts) directly in Ipv6RoutingProtocol
> subclasses instead of Ipv6L3Protocol (especially to allow L4 protocol to
> send to these addresses).
>
> You will find current work at https://svnet.u-strasbg.fr/hg/ns-3-ipv6-2nd.

Hi Sebastien,
I reviewed this repo and I think it is probably close to merging.  A few
comments:

- I noticed that many functions need the gnu style space before
parentheses (the -pcs option in indent)

- Can you please start a file "ipv6-test.cc" in internet-stack/ and
start to add some unit tests?  I started this for ipv4-test.cc recently;
not much there yet but we can add in the future.  In general, we need to
add unit test support for these protocols.


>
> Files modified:
> src/helper/internet-stack-helper.cc,h
> => add IPv6 stack directly with IPv4 ones (make dual stack node), I
> think about adding methods to enable/disable IPv4 or IPv6 stack in order
> to have IPv4 or IPv6 only node.

I agree with this default, and with the notion of adding options to
disable each stack in the helper class.

What would you prefer the default to be for address autoconfiguration
once that piece is enabled?  Do you care about the distinction of host
vs. router and making routers send advertisements (and configuring a
helper to auto-configure router prefixes) or just something like the
static address allocation that is there presently?

>
> As you see many files have been copy/paste/adapt, but for the routing
> part I think it will have some changes.
>
> Next steps are :
> - handle link-local multicast in routing part;
> - handle Router Advertisement (receive, parse, extract prefix and
> autoconfigured global address with it + timer);
 > - radvd application like;

- I am guessing that the DAD stuff commented out in
icmpv6-l4-protocol.cc can be enabled once the router advertisements are
enabled?  Maybe we can avoid to merge these commented out code blocks
until then.

> - UDP and TCP protocol and implementation (need to be discussed here to
> avoid duplicate code);

I would like to prioritize the above and aim for having the ability to
send TCP and UDP on a local link by the next release.  Static unicast
routing would be a bonus (see below).

> - IPv6 global routing.
>

I think that global and dynamic routing protocols, autoconfigured
addresses, and multicast/broadcast could wait until the transport
protocols and static routing are dealt with.

Other:

- I think that we should explicitly add something equivalent to
inet_select_addr() for source address selection (both to IPv4 and IPv6).
  For IPv6 it seems more important given the higher probability of
multi-address interfaces and RFC 3484.

- regarding the static routing, I would like to avoid just
copy/paste/edit the Ipv4 static routing, as there have been some
complaints about its lack of longest prefix matching, and we should
consider whether the API needs some improvement or extension.

Regards,
Tom

[Sébastien Vincent]

Hi Tom,

Tom Henderson a écrit :

> Sébastien Vincent wrote:
>> Hi all,
>>
>> Some notes about IPv6 progress.
>>
>> I have ported many part of the initial IPv6 work : Ipv6Interface,
>> Ipv6InterfaceAddress, Ipv6Route, NdiscCache, Icmpv6L4Protocol, ...
>> and adapted other ones to fit work that has been done (IPv4
>> refactoring).
>>
>> Now I have a working example that used IPv6 raw socket: ping6 (./waf
>> --run ping6). This implementation is a work in progress, there are
>> additionnal work in routing to manage special multicast address
>> (all-nodes, all-routers, all-hosts) directly in Ipv6RoutingProtocol
>> subclasses instead of Ipv6L3Protocol (especially to allow L4 protocol
>> to send to these addresses).
>>
>> You will find current work at
>> https://svnet.u-strasbg.fr/hg/ns-3-ipv6-2nd.
>
> Hi Sebastien,
> I reviewed this repo and I think it is probably close to merging.  A
> few comments:
>
> - I noticed that many functions need the gnu style space before
> parentheses (the -pcs option in indent)

Done.

>
> - Can you please start a file "ipv6-test.cc" in internet-stack/ and
> start to add some unit tests?  I started this for ipv4-test.cc
> recently; not much there yet but we can add in the future.  In
> general, we need to add unit test support for these protocols.
>

OK I will add unit test.

>
>>
>> Files modified:
>> src/helper/internet-stack-helper.cc,h
>> => add IPv6 stack directly with IPv4 ones (make dual stack node), I
>> think about adding methods to enable/disable IPv4 or IPv6 stack in
>> order to have IPv4 or IPv6 only node.
>
> I agree with this default, and with the notion of adding options to
> disable each stack in the helper class.
>

I added SetIpv4StackInstall and SetIpv6StackInstall methods to
InternetStackHelper.

> What would you prefer the default to be for address autoconfiguration
> once that piece is enabled?  Do you care about the distinction of host
> vs. router and making routers send advertisements (and configuring a
> helper to auto-configure router prefixes) or just something like the
> static address allocation that is there presently?

For the moment host or router distinction is made via
Ipv6L3Protocol::m_ipForward variable (which is true by default see Ipv6
attribute IpForward, same as Ipv4 ones).
In simulation static address are used, see
src/helper/ipv6-address-helper.cc,h.

In old ns-3-ipv6 repository, we made an application (radvd) to send
router advertisements (RA). We did it to mimic Linux, but it could be
also interresting if somebody wants to put extension to RA like for
example DNS servers information (RFC 5006) => no changes to IPv6 stack
itself just the application. What do you think ?

>
>>
>> As you see many files have been copy/paste/adapt, but for the routing
>> part I think it will have some changes.
>>
>> Next steps are :
>> - handle link-local multicast in routing part;
>> - handle Router Advertisement (receive, parse, extract prefix and
>> autoconfigured global address with it + timer);
> > - radvd application like;
>
> - I am guessing that the DAD stuff commented out in
> icmpv6-l4-protocol.cc can be enabled once the router advertisements
> are enabled?  Maybe we can avoid to merge these commented out code
> blocks until then.

DAD is working and router solicitation (RS) is also sent after DAD is
completed. But like all nodes start at the same time, they do their DAD
and sent RS at approximately 1 second of simulation time, so a lot of
messages at the beginning of the simulation. We think about this last
year and solution was to temporary disable sending RS. As radvd
application can be configured to sent periodically RA the problem is not
very important for static nodes but for Mobile IPv6 ones it is critical
to have an address quickly and not wait for next period of RA sending.

>
>> - UDP and TCP protocol and implementation (need to be discussed here
>> to avoid duplicate code);
>
> I would like to prioritize the above and aim for having the ability to
> send TCP and UDP on a local link by the next release.  Static unicast
> routing would be a bonus (see below).
>
>> - IPv6 global routing.
>>
>
> I think that global and dynamic routing protocols, autoconfigured
> addresses, and multicast/broadcast could wait until the transport
> protocols and static routing are dealt with.
>
> Other:
>
> - I think that we should explicitly add something equivalent to
> inet_select_addr() for source address selection (both to IPv4 and
> IPv6).  For IPv6 it seems more important given the higher probability
> of multi-address interfaces and RFC 3484.

Yes.
>
> - regarding the static routing, I would like to avoid just
> copy/paste/edit the Ipv4 static routing, as there have been some
> complaints about its lack of longest prefix matching, and we should
> consider whether the API needs some improvement or extension.

I need to have static routing because it is used to send/receive on
link-local as well as global address (link-local routes are in unicast
routing table => ip -6 route show). Like I said I will try to add
special multicast address (all-nodes, all-routers, all-hosts) handling
into it.

For nodes with multiple interfaces (and thus multiple link-local
address), we should use the "uint32_t oif" paramter of RouteOutput()
methods to know on which interface we want to send packets. Otherwise it
will take the first matching link-local routes (as there all in
fe80::/64 form, just output interface changes) and maybe with the wrong
interface. So application that send to link-local or special multicast
address  should choose on which interface they want to send packet
(Remember ping6 -Ieth0 fe80::1234).

>
> Regards,
> Tom
>
Regards,
--
Sebastien

[Fabian Mauchle]

Hi all

-----Ursprüngliche Nachricht-----
Von: ns-developers-bounces@... [mailto:ns-developers-bounces@...] Im Auftrag von Sébastien Vincent
Gesendet: Freitag, 24. Juli 2009 10:19
An: Tom Henderson
Cc: ns-developers@...
Betreff: Re: [Ns-developers] ipv6 plans for ns-3

In old ns-3-ipv6 repository, we made an application (radvd) to send
router advertisements (RA). We did it to mimic Linux, but it could be
also interresting if somebody wants to put extension to RA like for
example DNS servers information (RFC 5006) => no changes to IPv6 stack
itself just the application. What do you think ?

>
>>
>> As you see many files have been copy/paste/adapt, but for the routing
>> part I think it will have some changes.
>>
>> Next steps are :
>> - handle link-local multicast in routing part;
>> - handle Router Advertisement (receive, parse, extract prefix and
>> autoconfigured global address with it + timer);
> > - radvd application like;
>
> - I am guessing that the DAD stuff commented out in
> icmpv6-l4-protocol.cc can be enabled once the router advertisements
> are enabled?  Maybe we can avoid to merge these commented out code
> blocks until then.

DAD is working and router solicitation (RS) is also sent after DAD is
completed. But like all nodes start at the same time, they do their DAD
and sent RS at approximately 1 second of simulation time, so a lot of
messages at the beginning of the simulation. We think about this last
year and solution was to temporary disable sending RS. As radvd
application can be configured to sent periodically RA the problem is not
very important for static nodes but for Mobile IPv6 ones it is critical
to have an address quickly and not wait for next period of RA sending.
--------------

During my study and simulation (based on the old ns-3-ipv6) of Mobile IPv6 (RFC 3775) I found the following:

- The DAD and RS messages at the beginning was no problem. I usually start the applications some seconds into the simulation, and give the network time to 'organize' itself (do the DAD stuff...).
- When thinking about Mobile Nodes, it is basically important that there is a configurable radvd application. For Mobile IPv6, it is recommended to send RA's every 30-70ms to help Mobile Nodes get an address quickly. The radvd application in the old repo did this job perfectly. Nevertheless, Mobile IPv6 is not defined to be fast or fulfill any QoS requirements. So it's not that critical.
- For fast moving Mobile Nodes which eg. have a running VoIP session, other methods like Media Independent Handover are needed to be fast enough. Basically, for this scenario, the address configuration is not the basic problem, but updating the Mobile Node's location and redirecting its traffic.

So, from My point of view, I would keep the DAD behavior as it was in the old repo. I would also keep the radvd application. Maybe it's configuration could be simplified.

Regards
Fabian

[Sébastien Vincent]

Hi all,

Here the latest news about ns-3-ipv6-2nd:

- Move some link-local routing handling from Ipv6L3Protocol to
Ipv6Static|ListRouting;
- Routing has been tested;

  => by the way I find an error in IPv4's
src/routing/static-routing/ipv4-static-routing.cc, line 261 about
default route:
         rtentry->SetSource (SourceAddressSelection (interfaceIdx,
route->GetDest ()));

         It should be route->GetGateway(). In case of a default route
route->GetDest() is 0.0.0.0.

- By default all nodes is IPv6 host (Ipv6::IpForward attribute false
now) => RS will be sent after DAD for host;
- SetRouter function in Ipv6InterfaceContainer => RS will not be sent on
interface which have forwarding enabled;
- Routing example (examples/simple-routing-ping6.cc);
- Modify ping6 example to send an echo request to all-nodes (ff02::1);
- Basic unit test in src/internet-stack/ipv6-test.cc;
- Function() => Function () style.

Regards,
--
Sebastien

Fabian Mauchle a écrit :

> Hi all
>
> -----Ursprüngliche Nachricht-----
> Von: ns-developers-bounces@... [mailto:ns-developers-bounces@...] Im Auftrag von Sébastien Vincent
> Gesendet: Freitag, 24. Juli 2009 10:19
> An: Tom Henderson
> Cc: ns-developers@...
> Betreff: Re: [Ns-developers] ipv6 plans for ns-3
>
> In old ns-3-ipv6 repository, we made an application (radvd) to send
> router advertisements (RA). We did it to mimic Linux, but it could be
> also interresting if somebody wants to put extension to RA like for
> example DNS servers information (RFC 5006) => no changes to IPv6 stack
> itself just the application. What do you think ?
>
>  
>>> As you see many files have been copy/paste/adapt, but for the routing
>>> part I think it will have some changes.
>>>
>>> Next steps are :
>>> - handle link-local multicast in routing part;
>>> - handle Router Advertisement (receive, parse, extract prefix and
>>> autoconfigured global address with it + timer);
>>> - radvd application like;
>>>      
>> - I am guessing that the DAD stuff commented out in
>> icmpv6-l4-protocol.cc can be enabled once the router advertisements
>> are enabled?  Maybe we can avoid to merge these commented out code
>> blocks until then.
>>    
>
> DAD is working and router solicitation (RS) is also sent after DAD is
> completed. But like all nodes start at the same time, they do their DAD
> and sent RS at approximately 1 second of simulation time, so a lot of
> messages at the beginning of the simulation. We think about this last
> year and solution was to temporary disable sending RS. As radvd
> application can be configured to sent periodically RA the problem is not
> very important for static nodes but for Mobile IPv6 ones it is critical
> to have an address quickly and not wait for next period of RA sending.
> --------------
>
> During my study and simulation (based on the old ns-3-ipv6) of Mobile IPv6 (RFC 3775) I found the following:
>
> - The DAD and RS messages at the beginning was no problem. I usually start the applications some seconds into the simulation, and give the network time to 'organize' itself (do the DAD stuff...).
> - When thinking about Mobile Nodes, it is basically important that there is a configurable radvd application. For Mobile IPv6, it is recommended to send RA's every 30-70ms to help Mobile Nodes get an address quickly. The radvd application in the old repo did this job perfectly. Nevertheless, Mobile IPv6 is not defined to be fast or fulfill any QoS requirements. So it's not that critical.
> - For fast moving Mobile Nodes which eg. have a running VoIP session, other methods like Media Independent Handover are needed to be fast enough. Basically, for this scenario, the address configuration is not the basic problem, but updating the Mobile Node's location and redirecting its traffic.
>
> So, from My point of view, I would keep the DAD behavior as it was in the old repo. I would also keep the radvd application. Maybe it's configuration could be simplified.
>
> Regards
> Fabian
>
>
>  

[Sébastien Vincent]

Hi all,

New features:
- RA handler to autoconfigure address and default route;
- Radvd application made scratch (not reused radvd stuff from ns-3-ipv6
old repository);
- Two new examples: radvd and radvd-two-prefix. The last ones advertise
two prefixes in RA.

By the way I added in Ipv6RoutingProtocol, two methods for adding
routes. It is needed for ICMPv6 redirect (which add a host route to
redirected target), and to configure the default route when receive
first RA's prefix: NotifyAddRoute and NotifyRemoveRoute.

To summarize what is done now in
https://svnet.u-strasbg.fr/hg/ns-3-ipv6-2nd:
- IPv6 interface;
- IPv6 layer;
- IPv6 raw socket;
- Static IPv6 routing;
- ICMPv6 layer;
- Some ICMPv6 error messages (destination unreachable, ...);
- Neighbor Discovery Protocol (NS/NA, RS/RA, redirection);
- Ping6 application (send Echo  request);
- Radvd application (send RA);
- Examples (ping6, simple-routing-ping6, radvd, radvd-two-prefix,
icmpv6-redirect).

My holidays ends by monday, as I already said I will not have much time
to work on ns-3 after.

I think that we can first review current work and give feedback. And
maybe try to merge it before continue to work on UDP/TCP. It will be
great to finally enable ns-3 users to begin make IPv6 simulations with
ICMPv6 in next ns-3 release.

Best regards,
--
Sebastien Vincent

Sébastien Vincent a écrit :

> Hi all,
>
> Here the latest news about ns-3-ipv6-2nd:
>
> - Move some link-local routing handling from Ipv6L3Protocol to
> Ipv6Static|ListRouting;
> - Routing has been tested;
>
>  => by the way I find an error in IPv4's
> src/routing/static-routing/ipv4-static-routing.cc, line 261 about
> default route:
>         rtentry->SetSource (SourceAddressSelection (interfaceIdx,
> route->GetDest ()));
>
>         It should be route->GetGateway(). In case of a default route
> route->GetDest() is 0.0.0.0.
>
> - By default all nodes is IPv6 host (Ipv6::IpForward attribute false
> now) => RS will be sent after DAD for host;
> - SetRouter function in Ipv6InterfaceContainer => RS will not be sent
> on interface which have forwarding enabled;
> - Routing example (examples/simple-routing-ping6.cc);
> - Modify ping6 example to send an echo request to all-nodes (ff02::1);
> - Basic unit test in src/internet-stack/ipv6-test.cc;
> - Function() => Function () style.
>
> Regards,
> --
> Sebastien
>
> Fabian Mauchle a écrit :
>> Hi all
>>
>> -----Ursprüngliche Nachricht-----
>> Von: ns-developers-bounces@...
>> [mailto:ns-developers-bounces@...] Im Auftrag von Sébastien Vincent
>> Gesendet: Freitag, 24. Juli 2009 10:19
>> An: Tom Henderson
>> Cc: ns-developers@...
>> Betreff: Re: [Ns-developers] ipv6 plans for ns-3
>>
>> In old ns-3-ipv6 repository, we made an application (radvd) to send
>> router advertisements (RA). We did it to mimic Linux, but it could be
>> also interresting if somebody wants to put extension to RA like for
>> example DNS servers information (RFC 5006) => no changes to IPv6
>> stack itself just the application. What do you think ?
>>
>>  
>>>> As you see many files have been copy/paste/adapt, but for the
>>>> routing part I think it will have some changes.
>>>>
>>>> Next steps are :
>>>> - handle link-local multicast in routing part;
>>>> - handle Router Advertisement (receive, parse, extract prefix and
>>>> autoconfigured global address with it + timer);
>>>> - radvd application like;
>>>>      
>>> - I am guessing that the DAD stuff commented out in
>>> icmpv6-l4-protocol.cc can be enabled once the router advertisements
>>> are enabled?  Maybe we can avoid to merge these commented out code
>>> blocks until then.
>>>    
>>
>> DAD is working and router solicitation (RS) is also sent after DAD is
>> completed. But like all nodes start at the same time, they do their
>> DAD and sent RS at approximately 1 second of simulation time, so a
>> lot of messages at the beginning of the simulation. We think about
>> this last year and solution was to temporary disable sending RS. As
>> radvd application can be configured to sent periodically RA the
>> problem is not very important for static nodes but for Mobile IPv6
>> ones it is critical to have an address quickly and not wait for next
>> period of RA sending.
>> --------------
>>
>> During my study and simulation (based on the old ns-3-ipv6) of Mobile
>> IPv6 (RFC 3775) I found the following:
>>
>> - The DAD and RS messages at the beginning was no problem. I usually
>> start the applications some seconds into the simulation, and give the
>> network time to 'organize' itself (do the DAD stuff...). - When
>> thinking about Mobile Nodes, it is basically important that there is
>> a configurable radvd application. For Mobile IPv6, it is recommended
>> to send RA's every 30-70ms to help Mobile Nodes get an address
>> quickly. The radvd application in the old repo did this job
>> perfectly. Nevertheless, Mobile IPv6 is not defined to be fast or
>> fulfill any QoS requirements. So it's not that critical. - For fast
>> moving Mobile Nodes which eg. have a running VoIP session, other
>> methods like Media Independent Handover are needed to be fast enough.
>> Basically, for this scenario, the address configuration is not the
>> basic problem, but updating the Mobile Node's location and
>> redirecting its traffic.
>>
>> So, from My point of view, I would keep the DAD behavior as it was in
>> the old repo. I would also keep the radvd application. Maybe it's
>> configuration could be simplified.
>>
>> Regards
>> Fabian
>>
>>  
>
>

[Tom Henderson-2]

On Thu, 30 Jul 2009 20:45:39 +0200, Sébastien Vincent
<vincent@...> wrote:

> Hi all,
>
> New features:
> - RA handler to autoconfigure address and default route;
> - Radvd application made scratch (not reused radvd stuff from ns-3-ipv6
> old repository);
> - Two new examples: radvd and radvd-two-prefix. The last ones advertise
> two prefixes in RA.
>
> By the way I added in Ipv6RoutingProtocol, two methods for adding
> routes. It is needed for ICMPv6 redirect (which add a host route to
> redirected target), and to configure the default route when receive
> first RA's prefix: NotifyAddRoute and NotifyRemoveRoute.
>
> To summarize what is done now in
> https://svnet.u-strasbg.fr/hg/ns-3-ipv6-2nd:
> - IPv6 interface;
> - IPv6 layer;
> - IPv6 raw socket;
> - Static IPv6 routing;
> - ICMPv6 layer;
> - Some ICMPv6 error messages (destination unreachable, ...);
> - Neighbor Discovery Protocol (NS/NA, RS/RA, redirection);
> - Ping6 application (send Echo  request);
> - Radvd application (send RA);
> - Examples (ping6, simple-routing-ping6, radvd, radvd-two-prefix,
> icmpv6-redirect).
>
> My holidays ends by monday, as I already said I will not have much time
> to work on ns-3 after.
>
> I think that we can first review current work and give feedback. And
> maybe try to merge it before continue to work on UDP/TCP. It will be
> great to finally enable ns-3 users to begin make IPv6 simulations with
> ICMPv6 in next ns-3 release.

Hi Sebastien,
I agree with your suggestion that we should move on reviewing and merging
all of the above now before tackling new features.  I am busy with
something else the remainder of the week but I will prioritize a review
next week.

- Tom

[Tom Henderson-2]

On Thu, 30 Jul 2009 20:45:39 +0200, Sébastien Vincent
<vincent@...> wrote:

> Hi all,
>
> New features:
> - RA handler to autoconfigure address and default route;
> - Radvd application made scratch (not reused radvd stuff from ns-3-ipv6
> old repository);
> - Two new examples: radvd and radvd-two-prefix. The last ones advertise
> two prefixes in RA.
>
> By the way I added in Ipv6RoutingProtocol, two methods for adding
> routes. It is needed for ICMPv6 redirect (which add a host route to
> redirected target), and to configure the default route when receive
> first RA's prefix: NotifyAddRoute and NotifyRemoveRoute.
>

I am not sure about the above Ipv6RoutingProtocol changes.  It seems like
what you want to do is to get a handle on a static routing object and add a
host route directly, but you are instead providing a notification to all
routing protocols (as in RTM_NEWROUTE).  

> To summarize what is done now in
> https://svnet.u-strasbg.fr/hg/ns-3-ipv6-2nd:
> - IPv6 interface;
> - IPv6 layer;
> - IPv6 raw socket;
> - Static IPv6 routing;
> - ICMPv6 layer;
> - Some ICMPv6 error messages (destination unreachable, ...);
> - Neighbor Discovery Protocol (NS/NA, RS/RA, redirection);
> - Ping6 application (send Echo  request);
> - Radvd application (send RA);
> - Examples (ping6, simple-routing-ping6, radvd, radvd-two-prefix,
> icmpv6-redirect).
>
> My holidays ends by monday, as I already said I will not have much time
> to work on ns-3 after.
>
> I think that we can first review current work and give feedback. And
> maybe try to merge it before continue to work on UDP/TCP. It will be
> great to finally enable ns-3 users to begin make IPv6 simulations with
> ICMPv6 in next ns-3 release.
>

I've posted this repository on ns-3-reviews in case people would like to
review it there.  Please review it by next Wed. or ask for more time; if no
major comments, I will try to merge this later next week.
http://codereview.appspot.com/105054

Many thanks for this contribution,
Tom

[Sébastien Vincent]

Tom Henderson a écrit :

> On Thu, 30 Jul 2009 20:45:39 +0200, Sébastien Vincent
> <vincent@...> wrote:
>  
>> Hi all,
>>
>> New features:
>> - RA handler to autoconfigure address and default route;
>> - Radvd application made scratch (not reused radvd stuff from ns-3-ipv6
>> old repository);
>> - Two new examples: radvd and radvd-two-prefix. The last ones advertise
>> two prefixes in RA.
>>
>> By the way I added in Ipv6RoutingProtocol, two methods for adding
>> routes. It is needed for ICMPv6 redirect (which add a host route to
>> redirected target), and to configure the default route when receive
>> first RA's prefix: NotifyAddRoute and NotifyRemoveRoute.
>>
>>    
>
> I am not sure about the above Ipv6RoutingProtocol changes.  It seems like
> what you want to do is to get a handle on a static routing object and add a
> host route directly, but you are instead providing a notification to all
> routing protocols (as in RTM_NEWROUTE).  
>
>  
>> To summarize what is done now in
>> https://svnet.u-strasbg.fr/hg/ns-3-ipv6-2nd:
>> - IPv6 interface;
>> - IPv6 layer;
>> - IPv6 raw socket;
>> - Static IPv6 routing;
>> - ICMPv6 layer;
>> - Some ICMPv6 error messages (destination unreachable, ...);
>> - Neighbor Discovery Protocol (NS/NA, RS/RA, redirection);
>> - Ping6 application (send Echo  request);
>> - Radvd application (send RA);
>> - Examples (ping6, simple-routing-ping6, radvd, radvd-two-prefix,
>> icmpv6-redirect).
>>
>> My holidays ends by monday, as I already said I will not have much time
>> to work on ns-3 after.
>>
>> I think that we can first review current work and give feedback. And
>> maybe try to merge it before continue to work on UDP/TCP. It will be
>> great to finally enable ns-3 users to begin make IPv6 simulations with
>> ICMPv6 in next ns-3 release.
>>
>>    
>
> I've posted this repository on ns-3-reviews in case people would like to
> review it there.  Please review it by next Wed. or ask for more time; if no
> major comments, I will try to merge this later next week.
> http://codereview.appspot.com/105054
>
>  

I have updated repository (fix one bug and recent ns-3-dev changes).
Feel free to review it.

Tom, I have also added text from RELEASE_NOTES/CHANGES.html  you made in
http://codereview.appspot.com/105054

Regards,
--
Sebastien

> Many thanks for this contribution,
> Tom
>
>
>  

[Tom Henderson-2]

Sebastien Vincent wrote:

> Tom Henderson a écrit :
>> On Thu, 30 Jul 2009 20:45:39 +0200, Sébastien Vincent
>> <vincent@...> wrote:
>>  
>>> Hi all,
>>>
>>> New features:
>>> - RA handler to autoconfigure address and default route;
>>> - Radvd application made scratch (not reused radvd stuff from
>>> ns-3-ipv6 old repository);
>>> - Two new examples: radvd and radvd-two-prefix. The last ones
>>> advertise two prefixes in RA.
>>>
>>> By the way I added in Ipv6RoutingProtocol, two methods for adding
>>> routes. It is needed for ICMPv6 redirect (which add a host route to
>>> redirected target), and to configure the default route when receive
>>> first RA's prefix: NotifyAddRoute and NotifyRemoveRoute.
>>>
>>>    
>>
>> I am not sure about the above Ipv6RoutingProtocol changes.  It seems like
>> what you want to do is to get a handle on a static routing object and
>> add a
>> host route directly, but you are instead providing a notification to all
>> routing protocols (as in RTM_NEWROUTE).
>>  
>>> To summarize what is done now in
>>> https://svnet.u-strasbg.fr/hg/ns-3-ipv6-2nd:
>>> - IPv6 interface;
>>> - IPv6 layer;
>>> - IPv6 raw socket;
>>> - Static IPv6 routing;
>>> - ICMPv6 layer;
>>> - Some ICMPv6 error messages (destination unreachable, ...);
>>> - Neighbor Discovery Protocol (NS/NA, RS/RA, redirection);
>>> - Ping6 application (send Echo  request);
>>> - Radvd application (send RA);
>>> - Examples (ping6, simple-routing-ping6, radvd, radvd-two-prefix,
>>> icmpv6-redirect).
>>>
>>> My holidays ends by monday, as I already said I will not have much
>>> time to work on ns-3 after.
>>>
>>> I think that we can first review current work and give feedback. And
>>> maybe try to merge it before continue to work on UDP/TCP. It will be
>>> great to finally enable ns-3 users to begin make IPv6 simulations
>>> with ICMPv6 in next ns-3 release.
>>>
>>>    
>>
>> I've posted this repository on ns-3-reviews in case people would like to
>> review it there.  Please review it by next Wed. or ask for more time;
>> if no
>> major comments, I will try to merge this later next week.
>> http://codereview.appspot.com/105054
>>
>>  
>
> I have updated repository (fix one bug and recent ns-3-dev changes).
> Feel free to review it.
>
> Tom, I have also added text from RELEASE_NOTES/CHANGES.html  you made in
> http://codereview.appspot.com/105054

Sebastien, I checked in the new code earlier today.  Thanks again for
this contribution.  Here is a brief list of the open issues that we need
to tackle:

- need to find clean way to reuse transport layer implementations across
address families
- link change callback issue (bug 560-- I just left a fresh comment)
- improve static routing implementation along the lines of what Antti
has done in bug 659
- possibly a better solution for handling the static routes generated by
ICMPv6 redirects (than the current NotifyAddRoute).
- handle link-local multicast in static routing
- handle Router Advertisement (receive, parse, extract prefix and
autoconfigured global address with it + timer)

Then, more features
- TCP/UDP
- IPv6 global routing

Plus, we should start a manual chapter on IPv6 stack, add some
regression tests, and add something to the tutorial.

Others I'm forgetting?

Tom

[Sébastien Vincent]

Hi,

Tom Henderson a écrit :

> Sebastien Vincent wrote:
>> Tom Henderson a écrit :
>>> On Thu, 30 Jul 2009 20:45:39 +0200, Sébastien Vincent
>>> <vincent@...> wrote:
>>>  
>>>> Hi all,
>>>>
>>>> New features:
>>>> - RA handler to autoconfigure address and default route;
>>>> - Radvd application made scratch (not reused radvd stuff from
>>>> ns-3-ipv6 old repository);
>>>> - Two new examples: radvd and radvd-two-prefix. The last ones
>>>> advertise two prefixes in RA.
>>>>
>>>> By the way I added in Ipv6RoutingProtocol, two methods for adding
>>>> routes. It is needed for ICMPv6 redirect (which add a host route to
>>>> redirected target), and to configure the default route when receive
>>>> first RA's prefix: NotifyAddRoute and NotifyRemoveRoute.
>>>>
>>>>    
>>>
>>> I am not sure about the above Ipv6RoutingProtocol changes.  It seems
>>> like
>>> what you want to do is to get a handle on a static routing object
>>> and add a
>>> host route directly, but you are instead providing a notification to
>>> all
>>> routing protocols (as in RTM_NEWROUTE).  
>>>> To summarize what is done now in
>>>> https://svnet.u-strasbg.fr/hg/ns-3-ipv6-2nd:
>>>> - IPv6 interface;
>>>> - IPv6 layer;
>>>> - IPv6 raw socket;
>>>> - Static IPv6 routing;
>>>> - ICMPv6 layer;
>>>> - Some ICMPv6 error messages (destination unreachable, ...);
>>>> - Neighbor Discovery Protocol (NS/NA, RS/RA, redirection);
>>>> - Ping6 application (send Echo  request);
>>>> - Radvd application (send RA);
>>>> - Examples (ping6, simple-routing-ping6, radvd, radvd-two-prefix,
>>>> icmpv6-redirect).
>>>>
>>>> My holidays ends by monday, as I already said I will not have much
>>>> time to work on ns-3 after.
>>>>
>>>> I think that we can first review current work and give feedback.
>>>> And maybe try to merge it before continue to work on UDP/TCP. It
>>>> will be great to finally enable ns-3 users to begin make IPv6
>>>> simulations with ICMPv6 in next ns-3 release.
>>>>
>>>>    
>>>
>>> I've posted this repository on ns-3-reviews in case people would
>>> like to
>>> review it there.  Please review it by next Wed. or ask for more
>>> time; if no
>>> major comments, I will try to merge this later next week.
>>> http://codereview.appspot.com/105054
>>>
>>>  
>>
>> I have updated repository (fix one bug and recent ns-3-dev changes).
>> Feel free to review it.
>>
>> Tom, I have also added text from RELEASE_NOTES/CHANGES.html  you made
>> in http://codereview.appspot.com/105054
>
> Sebastien, I checked in the new code earlier today.  Thanks again for
> this contribution.  Here is a brief list of the open issues that we
> need to tackle:
>
> - need to find clean way to reuse transport layer implementations
> across address families
> - link change callback issue (bug 560-- I just left a fresh comment)

You mean bug 653 I think. I will update patch latter today and by the
way set the link change callback for NdiscCache (in icmpv6-l4-protocl.cc).

> - improve static routing implementation along the lines of what Antti
> has done in bug 659
> - possibly a better solution for handling the static routes generated
> by ICMPv6 redirects (than the current NotifyAddRoute).
> - handle link-local multicast in static routing

OK

> - handle Router Advertisement (receive, parse, extract prefix and
> autoconfigured global address with it + timer)
>

This one is already in this chunk and works (see
Icmpv6L4Protocol::ReceiveRA (), Ipv6L3Protocol::AddAutoconfiguredAddress
() and Ipv6AutoconfiguredAddress class for timer stuff).


> Then, more features
> - TCP/UDP
> - IPv6 global routing
>
> Plus, we should start a manual chapter on IPv6 stack, add some
> regression tests, and add something to the tutorial.

OK.

>
> Others I'm forgetting?
>

IPv6 extensions support:
- headers (hop-by-hop, destination, fragment, routing (type 0, type 2),
AH (authentication) and ESP (confidentiality);
- parsing;
- processing (routing, fragmentation, ...).

You can see at old repository (https://svnet.u-strasbg.fr/hg/ns-3-ipv6)
what it looks like  (files src/internet-stack/ipv6-extension* and
src/internet-stack/ipv6-l3-protocol.cc).

Best regards,
--
Sebastien

> Tom
>