Hi Ivan,
Thanks for the response.
On Thu, May 21, 2015 at 12:59 PM, Ivan Delamer <address@hidden> wrote:
> Hi Pradip,
>
> I think a static IPv6 route table is a nice feature to have. I think some
> people have implemented something similar for IPv4. Also someone has
> implemented a NAT.
>
> I would recommend that you implement this in a separate file than nd6,
> instead of using lots of conditional blocks.
The bulk of the APIs would reside in ip6.c. Currently, adding a new router in the default router list is a static method in nd6.c and so I have a public wrapper for adding a gateway in that file. I did not want to expose nd6_new_router() as a non-static public function. The only other change in nd6.c would be in the logic for selecting the next hop (after the outgoing netif has been selected by ip6_route()) because now the next hop could be a specific gateway as given in a matching static route entry rather than one among a list of default routers.
>
> neighbour discovery is usually called from netif->output_ip6, what you can
> do is: in your implementation of this function, before calling nd6 you can
> check with your static routing table for the next hop.
>
> You might have to hack ip6_route() like you propose if you need to use a
> static router.
>
As part of hacking ip6_route(), I am deferring the static route table lookup to be done just before the check to see if a default router exists(after the other address matching checks with the netif have failed).
Furthermore, ip6_route() only returns the outgoing netif. So, if a matching static route exists that has a specific gateway as the next hop, that gateway(if reachable) needs to be preferentially picked from within nd6_get_next_hop_entry() instead of forwarding to any default router.
> But all of this seems really similar to me to the current routing system,
> except we don't have an API for adding static entries. What I would do is
> simply expose some of the nd6 methods (make them non-static) and add your
> routers and next-hop entries.
Unfortunately, there is no mechanism to add route prefix entries into a routing table for future lookup. Routes are entirely calculated based on (whole 128bit address/64bit prefix) matching on netifs failing which one among a list of default routers is picked.
> You might have to periodically refresh your
> routers' invalidation timers, but that is anyways a good idea.
So, when I add a gateway in a static route, I also add it to the default-routers-list so that it can participate in the periodic neighbor discovery process, e.g., respond to RS/NS packets. Do I need to explicitly refresh the invalidation timers?
>
> This is how I do it in a project where I manually enter the router address.
>
> Cheers
> Ivan
>
>
Thanks,
Pradip
>
>
>> Date: Wed, 20 May 2015 17:20:08 -0700
>> From: pradip de <address@hidden>
>> To: address@hidden
>> Subject: [lwip-devel] Adding a static route table in LwIP
>> Message-ID:
>>
>> <address@hidden>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Hi,
>> As part of my current project, I am working on an LwIP enhancement of
>> adding a static route table and wanted to share in this forum and get
>> feedback.
>>
>> The static route table entry would have a prefix, a netif and an optional
>> gateway.
>> The APIs would look something like:
>>
>> 1) s8_t ip6_add_route_entry (struct ip6_prefix *ip6_prefix, struct netif
>> *netif, ip6_addr_t *gateway);
>>
>> 2) err_t ip6_remove_route_entry (struct ip6_prefix *ip6_prefix);
>>
>> 3) s8_t ip6_find_route_entry (ip6_addr_t *ip6_dest_addr);
>>
>> When adding a route entry, if a gateway is passed, then it would be added
>> to the default router list with the neighbor cache netif entry pointing to
>> the netif passed. I believe neighbor discovery performed every second
>> would
>> send router solicitations to fetch the link address for that entry.
>> A route lookup using ip6_find_route_entry would be invoked from within
>> ip6_route before the check to find a default router.
>> Currently, only a netcmp of the entire 64 bit prefix is done for matching
>> prefixes. However, in this enhancement, a prefix match up to a specific
>> prefix byte boundary would be made possible and a longest prefix match
>> performed.
>> All of these changes would be encapsulated within a conditional
>> compilation
>> flag.
>>
>> Please let me know if there are any concerns around this feature or any
>> suggestions in this regard.
>>
>> Thanks,
>> Pradip
>
>
>
> _______________________________________________
> lwip-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/lwip-devel