On Wed, Jul 27, 2016 at 8:39 PM, David Lamparter <[email protected]> wrote: > On Thu, Jul 21, 2016 at 09:49:46AM +0200, Lorenzo Colitti wrote: >> On Wed, Jul 20, 2016 at 2:54 PM, David Lamparter <[email protected]> wrote: >> > Hence, I hacked it up for the Linux (4.5.0) kernel; patches are attached >> > to this mail. I've been able to gleam a little more detail on the idea: >> > >> >> David, do you intend to keep working on the patches? Think you could send >> them to netdev as an RFC patchset, with proper signoff? Once it's on netdev >> other people can iterate on them, even if you lose interest :-) > > I've uploaded the patches (with signoffs) to: > https://aurora.nox.tf/tmp/rule55/
Thank you for posting the patches. I will try them out the next time I get time. I think I object to landing IPV6_SADDR_RULE_OIF_RTR in the middle of the existing enum rather than at the end, but will twiddle further. > NB: patch 2 of 3 is slightly different from the version I mailed, I > accidentally lost a NULL check in ipv6_rt_get_saddr(). > > I do _not_ intend to continue working on these since I now believe the > functionality should be put on neighbor cache entries. This requires > some (minor IMHO) rework to make these neighbor entries stay alive until > their prefix information times out. By putting it there, it can support > addresses that are configured from dhcpv6 or static/admin. I think I agree, but looking over the existing patches is a goodness. I was only just made aware that getting source specific routing to work well in other base ipv6 protocols had entered ietf consideration in this past ietf, and have some catching up to do. Has there been any work on improving how the std APIs might work on choosing a better source address for a given destination? I see some work has happened in mptcp.... > The code > linked above only works for SLAAC. One thing that has bothered me of late has been the lack of symmetry regarding address assignment's sources, vs how routes are handled. ip -6 route add fd01::1 via fe80::1 dev whatever proto static # rip/babel/dhcp/etc vs ip -6 addr add fd01::2/64 dev whatever # with no means to specify that it came from slaac/dhcpv6/static/hncp/background radiation. The existing bits for things like tmpaddr, mgmt_tmpaddr and scope seems to be breaking down in the representability... > > => the patches are intended purely for testing, for example if someone > hacks on the router side and wants to use Linux VMs to test the full > picture. > > Cheers, > > > -David -- Dave Täht Let's go make home routers and wifi faster! With better software! http://blog.cerowrt.org _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
