[lwip-devel] Adding a static route table in LwIP

[Ivan Delamer]

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.

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.

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. You might have to 
periodically refresh your routers' invalidation timers, but that is 
anyways a good idea.

This is how I do it in a project where I manually enter the router 
address.

Cheers
Ivan




> 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