Send connman mailing list submissions to
connman@lists.01.org
To subscribe or unsubscribe via email, send a message with subject or
body 'help' to
connman-requ...@lists.01.org
You can reach the person managing the list at
connman-ow...@lists.01.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of connman digest..."
Today's Topics:
1. Re: [RFC 0/8] Prevent IPv4 VPN data/DNS leak to IPv6 network(s)
(Jussi Laakkonen)
----------------------------------------------------------------------
Date: Mon, 29 Mar 2021 14:41:12 +0300
From: Jussi Laakkonen <jussi.laakko...@jolla.com>
Subject: Re: [RFC 0/8] Prevent IPv4 VPN data/DNS leak to IPv6
network(s)
To: Daniel Wagner <w...@monom.org>
Cc: connman@lists.01.org
Message-ID: <8d2d34da-fc6f-b1ff-28de-5796ccf2d...@jolla.com>
Content-Type: text/plain; charset=utf-8; format=flowed
On 3/29/21 1:15 PM, Daniel Wagner wrote:
> On Mon, Mar 29, 2021 at 12:29:50PM +0300, Jussi Laakkonen wrote:
>> Yeah we have been noticing some oddities here and there. What were your
>> plans exactly? We noticed some issue with DUID which we have as an WIP
>> solution that should be just tested more. In general it works but there may
>> be corner cases with different setups, though. I'm glad we're on the same
>> page here, that disabling IPv6 for the IPv4 VPN will not be an issue :)
>
> Sure, I prefer simple solutions :)
>
>>
>> Yes that IPv6 only is a corner case. I think it only concerns direct
>> connection request via D-Bus, with autoconnect that should not be an issue.
>> But currently I don't have such connection at my disposal (my ISP does not
>> even provide IPv6 on vDSL in 2021!) so it is hard to test what the real
>> implication on enabling such connection would even be.
>
> I have an IPv6 DS-Lite setup here but no IPv6 endpoint with a VPN server
> on it. It's really tricky to test stuff indeed.
Yes, it is tricky. IPv6 does require a completely different mindset from
IPv4 so that brings own challenges as well :).
>
>> But anyways, if IPv6 is to be revisited/fixed in general I guess this might
>> be good to add to TODO list as well? And to document as well of
>> course.
>
> Yes, let's try to solve one problem at the time. I think we need to look
> at the IPv6 implementation anyway soon.
>
Yes, lets. I'll add TODO and documentation notes as well about this when
I push the actual patch-set.
>>
>> With my tests using our implementation of the ofono plugin this approach
>> allowed mobile data to connect in the background with IPv4 only even though
>> it had IPv6 enabled as a dual-stack connection. So IPv6 remains in OFF state
>> and as the old method is not saved at VPN disconnect that connection will
>> get set to AUTO and IPv6 is established. Yes, a bit complex but improves
>> functionality as the connection does not produce an error in network.c
>> making the connection to fail but just sets IPv6 to be simply off.
>>
>> Well to understand how this should work was a quite complex process itself
>> thus, I decided to send this as an RFC first despite our internal reviewing
>> and testing. I changed direction so many times with this that I lost count
>> on how many times I did that. I did have stateful and stateless networks
>> with and without DHCPv6 at my disposal but all of them were dual-stack
>> connections.
>>
>> I think one issue I forgot to raise is that should ConnMan also manage the
>> autoconf value when disabling/enabling IPv6? As that tells kernel whether to
>> assign address for the interface, effectively controlling whether IPv6 is
>> usable or not. With different devices there were different behavior on this
>> if the autoconf was not set, using the system wide all/disable_ipv6 worked
>> on some but not on others and not being an expert on IPv6 (yet) I just
>> suspected that based on incoming traffic kernel does its things as ConnMan,
>> as you said, does not manage all IPv6 as of now.
>
> Yes, we should track per interface if the IPv6 enabling/disabling
> settings, e.g see 'ipconfig: Disable accept_ra on managed interfaces' in
> my IPv6 patches. But this needs a lot more of work :(
>
I see a lot of similarities with your code and my RFC. I need to focus
on that later on.
I did actually experiment with accept_ra for some time. autoconf seems
to be more in control from my experience. And also, accept_ra is an
integer [1] which is trickier to manage - when I still had it as managed
/proc value I was thinking to have it stored with the rest of the
ipconfig settings in order to make it properly set after a crash, for
instance. With our varying lower layer implementations accept_ra set by
other initialization daemon to either 1 or 2 depending on implementation.
I think I should then move that setting of autoconf away from "if
(forced)" and have it always set as on/off depending on desired IPv6 state.
If there isn't more concerns I'll try to wrap up a patch set early this
week.
Cheers,
Jussi
[1] https://www.kernel.org/doc/html/latest/networking/ip-sysctl.html
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list -- connman@lists.01.org
To unsubscribe send an email to connman-le...@lists.01.org
------------------------------
End of connman Digest, Vol 65, Issue 14
***************************************
