« Return to Thread: ipv6 plans for ns-3
Re: ipv6 plans for ns-3
by Sébastien Vincent
::
Rate this Message:
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
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
« Return to Thread: ipv6 plans for ns-3
| Free embeddable forum powered by Nabble | Forum Help |
