Hi! I recently received my v4 probe and I'm very happy with it. But unfortunately it doesn't support DHCPv6. I present a practical reason for implementing a DHCPv6 client on the probe. You see, my ISP doesn't send router advertisements with the prefix for stateless autoconfiguration set, and instead DHCPv6 must be used. I believe their decision could have something to do with the fact that the regulating body here requires ISP's to prevent IP address spoofing in consumer plans. And to meet that requirement my ISP may be using a feature similar to Cisco's IP source guard, where switch ports and/or mac addresses are passively associated to leased ip's or prefixes, breaking SLAAC. Unfortunately they hate letting consumers talk with their engineers so it's difficult to speculate this further. For now, I've put a stateful firewall appliance in front of the probe which provides SLAAC, it works just fine. Do you think a DHCPv6 client should be implemented?
+1 for DHCP6 support Cheers Jiri ______________________________________________________________
Od: "Aleksi Pirttimaa" <aleksipirttimaa@protonmail.com> Komu: "ripe-atlas@ripe.net" <ripe-atlas@ripe.net> Datum: 02.01.2020 10:16 Předmět: [atlas] Probe DHCPv6 support
Hi!
I recently received my v4 probe and I'm very happy with it. But unfortunately it doesn't support DHCPv6. I present a practical reason for implementing a DHCPv6 client on the probe.
You see, my ISP doesn't send router advertisements with the prefix for stateless autoconfiguration set, and instead DHCPv6 must be used.
I believe their decision could have something to do with the fact that the regulating body here requires ISP's to prevent IP address spoofing in consumer plans. And to meet that requirement my ISP may be using a feature similar to Cisco's IP source guard, where switch ports and/or mac addresses are passively associated to leased ip's or prefixes, breaking SLAAC. Unfortunately they hate letting consumers talk with their engineers so it's difficult to speculate this further.
For now, I've put a stateful firewall appliance in front of the probe which provides SLAAC, it works just fine.
Do you think a DHCPv6 client should be implemented?
Hi, On Fri, Dec 27, 2019 at 10:03:29PM +0000, Aleksi Pirttimaa wrote:
I recently received my v4 probe and I'm very happy with it. But unfortunately it doesn't support DHCPv6. I present a practical reason for implementing a DHCPv6 client on the probe.
After quite a bit of fruitless debugging "why does my Atlas probe not succeed in getting a DHCPv6 IA_NA lease?" today, google showed this old thread from 2019. Dear RIPE Atlas folks, why doesn't Atlas probes support DHCPv6 in 2023? All the stubborn reasons given why Android can't support DHCPv6 do not apply, and for the environment my v4 probe is running in, DHCPv6 is what we use - so it's DHCPv6 or no v6... Gert Doering -- grumpy old man -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Dear RIPE Atlas folks, why doesn't Atlas probes support DHCPv6 in 2023?
All the stubborn reasons given why Android can't support DHCPv6 do not apply, and for the environment my v4 probe is running in, DHCPv6 is what we use - so it's DHCPv6 or no v6...
A random question about the state of the art in this area. Does OpenWRT out of the box support DHVPv6? Did you ever try that? If it does, it may help the Atlas team to just add the relevant OpenWRT packages. It seems that networks that support only DHCPv6 IN_NA for IPv6 are quite rare.
On 5/9/23 16:44, Philip Homburg wrote:
Does OpenWRT out of the box support DHVPv6? Did you ever try that? If it does, it may help the Atlas team to just add the relevant OpenWRT packages.
Sure, it does (also prefix delegation works here). - Daniel
Hi, On Tue, May 09, 2023 at 04:44:05PM +0200, Philip Homburg wrote:
It seems that networks that support only DHCPv6 IN_NA for IPv6 are quite rare.
Enterprises love DHCPv6 (because, among others, reverse DNS, some amount of control, and no pesky privacy addresses). That you do not see more of it is mostly Android's fault - because enterprises get told "it will not work with half the mobile devices", so they go and postpone IPv6 deployment instead (in places where the control bit is strictly required)... Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
In your letter dated Tue, 9 May 2023 19:17:41 +0200 you wrote:
That you do not see more of it is mostly Android's fault - because enterprises get told "it will not work with half the mobile devices", so they go and postpone IPv6 deployment instead (in places where the control bit is strictly required)...
Android devices show up at relatively untrusted wifi networks. I can see the problem there. Or are you saying the these days enterprises are 100% cloud based, and the only networks they have left are wifi? In many cases untrusted devices only communicate with the internal network over a VPN. In that case, the local access protocol doesn't matter much. The VPN can hand out IPv6 address even if the host is IPv4-only. In any case, Atlas probes run a stripped down version of OpenWRT. It may help if somebody can figure out which OpenWRT packages need to be added to enable DHCPv6.
That should be "odhcp6c" https://openwrt.org/packages/pkgdata/odhcp6c https://github.com/openwrt/odhcp6c BR, Simon On 09.05.23 20:22, Philip Homburg wrote:
In any case, Atlas probes run a stripped down version of OpenWRT. It may help if somebody can figure out which OpenWRT packages need to be added to enable DHCPv6.
Hi, Good discussion! I’m currently looking at basing all the probes (3, 4 and 5) on OpenWRT 22.03 which is the latest stable. What I’ll do is take this along in the deliberations, and see if I can fit this into the firmware image somehow. Simon: can you provide the exact setup you use for testing? (Config snippets etc) I typically don’t have a problem on my setup here, but thats RA + DHCPv6, I don’t use DHCPv6 for the actual assignment. Regards, Michel
On 9 May 2023, at 20:27, Simon Brandt via ripe-atlas <ripe-atlas@ripe.net> wrote:
That should be "odhcp6c"
https://openwrt.org/packages/pkgdata/odhcp6c https://github.com/openwrt/odhcp6c
BR, Simon
On 09.05.23 20:22, Philip Homburg wrote:
In any case, Atlas probes run a stripped down version of OpenWRT. It may help if somebody can figure out which OpenWRT packages need to be added to enable DHCPv6.
-- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Hi Michel, sorry, i don't have an OpenWrt device that's using DHCPv6 in client mode. But it should be easy. Make sure the 'odhcp6c' package is installed (which is the case by default). Then change the protocol option for the interface: /etc/config/network config interface 'eth0' option proto 'dhcpv6' Check out this link to see als available options for the DHCPv6 client mode: https://openwrt.org/docs/guide-user/network/ipv6/configuration#protocol_dhcp... As far is i can see, you can only use OpenWrt in DHCPv4 client mode _OR_ in DHCPv6 client mode. So i guess, you have to write a small script. First try DHCPv6 and check if you can successfully get a configuration. If not, fall back to DHCPv4. Continuously toggle between DHCPv6 and DHCPv4 as long as you don't get a configuration. I would begin this loop with DHCPv6. Also keep in mind, that some DHCP server respond slow, so better wait a little bit, before switching the protocol. BR, Simon On 15.05.23 09:12, Michel Stam wrote:
Hi,
Good discussion!
I’m currently looking at basing all the probes (3, 4 and 5) on OpenWRT 22.03 which is the latest stable. What I’ll do is take this along in the deliberations, and see if I can fit this into the firmware image somehow.
Simon: can you provide the exact setup you use for testing? (Config snippets etc) I typically don’t have a problem on my setup here, but thats RA + DHCPv6, I don’t use DHCPv6 for the actual assignment.
Regards,
Michel
On 9 May 2023, at 20:27, Simon Brandt via ripe-atlas <ripe-atlas@ripe.net> wrote:
That should be "odhcp6c"
https://openwrt.org/packages/pkgdata/odhcp6c https://github.com/openwrt/odhcp6c
BR, Simon
On 09.05.23 20:22, Philip Homburg wrote:
In any case, Atlas probes run a stripped down version of OpenWRT. It may help if somebody can figure out which OpenWRT packages need to be added to enable DHCPv6.
-- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
On 15 May 2023, at 19:57, Simon Brandt via ripe-atlas wrote:
As far is i can see, you can only use OpenWrt in DHCPv4 client mode _OR_ in DHCPv6 client mode.
IIUC, this is true per interface, but it's possible to configure more than one interface on a single hardware device. The WAN link on my Turris Omnia uses both DHCPv4 and DHCPv6 (IA-PD). Here's how the good folks at NIC.CZ configured that: config interface 'wan' option proto 'dhcp' option ipv6 '1' option device 'eth2' config interface 'wan6' option proto 'dhcpv6' option noserverunicast '1' option device 'eth2' For IA-NA, I don't know what needs to be changed. lgdg, /Niall
Hi Simon, I was actually thinking about the server side, not the client side. The client side I’ll figure out, I have some experience with OpenWRT ;) Do you have examples for that on relevant DHCPv6 implementations? Regards, Michel
On 15 May 2023, at 20:57, Simon Brandt via ripe-atlas <ripe-atlas@ripe.net> wrote:
Hi Michel,
sorry, i don't have an OpenWrt device that's using DHCPv6 in client mode. But it should be easy. Make sure the 'odhcp6c' package is installed (which is the case by default). Then change the protocol option for the interface:
/etc/config/network
config interface 'eth0' option proto 'dhcpv6'
Check out this link to see als available options for the DHCPv6 client mode: https://openwrt.org/docs/guide-user/network/ipv6/configuration#protocol_dhcp...
As far is i can see, you can only use OpenWrt in DHCPv4 client mode OR in DHCPv6 client mode. So i guess, you have to write a small script. First try DHCPv6 and check if you can successfully get a configuration. If not, fall back to DHCPv4. Continuously toggle between DHCPv6 and DHCPv4 as long as you don't get a configuration. I would begin this loop with DHCPv6. Also keep in mind, that some DHCP server respond slow, so better wait a little bit, before switching the protocol.
BR, Simon
On 15.05.23 09:12, Michel Stam wrote:
Hi,
Good discussion!
I’m currently looking at basing all the probes (3, 4 and 5) on OpenWRT 22.03 which is the latest stable. What I’ll do is take this along in the deliberations, and see if I can fit this into the firmware image somehow.
Simon: can you provide the exact setup you use for testing? (Config snippets etc) I typically don’t have a problem on my setup here, but thats RA + DHCPv6, I don’t use DHCPv6 for the actual assignment.
Regards,
Michel
On 9 May 2023, at 20:27, Simon Brandt via ripe-atlas <ripe-atlas@ripe.net> <mailto:ripe-atlas@ripe.net> wrote:
That should be "odhcp6c"
https://openwrt.org/packages/pkgdata/odhcp6c https://github.com/openwrt/odhcp6c
BR, Simon
On 09.05.23 20:22, Philip Homburg wrote:
In any case, Atlas probes run a stripped down version of OpenWRT. It may help if somebody can figure out which OpenWRT packages need to be added to enable DHCPv6.
-- ripe-atlas mailing list ripe-atlas@ripe.net <mailto:ripe-atlas@ripe.net> https://lists.ripe.net/mailman/listinfo/ripe-atlas
-- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Hi, On Thu, May 18, 2023 at 04:41:58PM +0200, Michel Stam wrote:
Do you have examples for that on relevant DHCPv6 implementations?
With ISC-DHCPv6, it's very straightforward # global options option dhcp6.name-servers 2001:608::2, 2001:608::1; option dhcp6.domain-search "space.net", "test.space.net"; default-lease-time 86400; preferred-lifetime 7200; # Set preference to 255 (maximum) in order to avoid waiting for # additional servers when there is only one option dhcp6.preference 255; # SpaceNet TestNetz wifi subnet6 2001:608:0:99::/64 { range6 2001:608:0:99:a000::100 2001:608:0:99:a000::500; ddns-rev-domainname "ip6.arpa"; ddns-domainname "test.space.net"; } Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Thanks Gert, That will do nicely for a test bed. I will add that to the ticket. Cheers, Michel
On 19 May 2023, at 08:51, Gert Doering <gert@space.net> wrote:
Hi,
On Thu, May 18, 2023 at 04:41:58PM +0200, Michel Stam wrote:
Do you have examples for that on relevant DHCPv6 implementations?
With ISC-DHCPv6, it's very straightforward
# global options option dhcp6.name-servers 2001:608::2, 2001:608::1; option dhcp6.domain-search "space.net", "test.space.net"; default-lease-time 86400; preferred-lifetime 7200;
# Set preference to 255 (maximum) in order to avoid waiting for # additional servers when there is only one option dhcp6.preference 255;
# SpaceNet TestNetz wifi subnet6 2001:608:0:99::/64 { range6 2001:608:0:99:a000::100 2001:608:0:99:a000::500; ddns-rev-domainname "ip6.arpa"; ddns-domainname "test.space.net"; }
Gert Doering -- NetMaster -- have you enabled IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
participants (8)
-
Aleksi Pirttimaa -
Daniel Suchy -
Gert Doering -
Michel Stam -
Niall O'Reilly -
Philip Homburg -
ripe.net＠toppas.net -
ripe＠brite.cz