Subject: Re: [homenet] Linux 6724 rule 5.5 (Re: draft-bowbakova-rtgwg-enterprise-pa-multihoming-00)

From: Dave Taht <[email-masked]>
Date: Thu, 28 Jul 2016 06:38:28 +0200

On Wed, Jul 27, 2016 at 8:39 PM, David Lamparter <[email-masked]> 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-masked]> 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