IPv6 support

[kyle95wm]

Hi,

I just tried to install this release using a 2GB SD card. I downloaded the image and flashed it to my SD card and I seem to have encountered a boot loop of sorts...

The error Im getting could be seen here: http://prntscr.com/9jbwol

What is going on exactly? Why am I getting this error?

[diederikdehaas]

Do you have a combination of IPv4 and IPv6 in your local network?

[Mausy5043]

Or a VM? 192.168.101.0/24 is typically used on VLANs. Please provide us with more context. What does your network look like? What equipment must the data pass to get from the "the cable in the street" to your Pi?

[kyle95wm]

Yes my network currently uses both IP 4 and 6. The network ID mentioned in the other comment was correct. Should I be disabling ip 6?

[diederikdehaas]

The reason I thought of that was the following message on IRC:

Long story… but indeed… messed up ipv6 config.  
Router was advertising ipv6, but the routing failed. And debian would not fallback to ipv4. 
Were unable to fix it, disabled everything, now it worked

So it looks like the 'quick fix' is indeed disabling IPv6. I don't know whether the installer can deal with IPv6 properly or that it is your (and the other user's) router config is not functioning 100%.

[kyle95wm]

Ive disabled IP6 on my network and everything seems to be working fine. Is there not a way to make the instal fall back to IP4 if IP6 fails?

[diederikdehaas]

Maybe. But I have hardly any experience with IPv6, so it may take a while (my router does support IPv6, but my ISP doesn't). Also, this issue could have pointed out an issue with your IPv6 configuration. Not saying it does, just that it could as it was the case of that other user.

[Mausy5043]

Why use IPv6 for your LAN anyway?

[diederikdehaas]

Because you can? Or experimenting with it to learn about it?

[dragetd]

Why use a total legacy protocol like IPv4? :-P

[diederikdehaas]

LOL. We still have to support those people who are stuck with legacy ISPs, like me :stuck_out_tongue_closed_eyes:

[Mausy5043]

@kyle95wm : is this still an issue for you?

It is not entirely clear to me if the IPv6 support of this repo is "incomplete" or whether your router might be "defective".

[goranche]

I highly doubt there is anything wrong with IPv6 support in Debian (which of course includes this installer), as I have used IPv6 at home as well... of course, not just locally (although that works as well), but through both a provider with full IPv6 support and using tunnel providers (through an Apple Time Capsule)...

[kpfleming]

Same here, I use IPv6 with two RPis installed using this installer, although I have no clue if IPv6 was used during the installation.

[Mausy5043]

Closing: not related to debian or this repo.

If you believe I closed this issue in error, please re-open.

[diederikdehaas]

I highly doubt there is anything wrong with IPv6 support in Debian

I totally agree with that. What I am less sure about is whether we provide all the necessary components in the installer for full IPv6 support. So far we have had a couple of users who 'fixed' their installation issue by disabling IPv6 ... which I don't consider a real solution.

So I am reopening this issue until I/we get confirmation from several people that it does indeed work properly with IPv6.

[kpfleming]

I can reinstall on my B+, there's nothing on it of value right now. My network has both IPv4 and IPv6. I'll do that this weekend and report back.

[Mausy5043]

:+1:

[kpfleming]

Keep in mind though that IPv6 on my network works, I won't be able to replicate the OP's problem of having IPv6 enabled but routing broken. Many (hundreds or thousands) of applications do not handle v6-to-v4 fallback at all, especially when the failure mode is just timeouts due to broken connectivity.

As a first test, I'll do an install with only IPv6 enabled on the network, which will confirm whether the installer works properly using IPv6. If it does, then there's nothing left for the raspbian-ua-netinst team to deal with.

[Mausy5043]

Exactly my thoughts. If an IPv6 address is acquired in the absence of IPv4 that would be a good sign. If, then, the installer works and gets its job done... That would indeed mean we have nothing to fix.

[diederikdehaas]

Indeed. Thanks in advance @kpfleming :+1:

[kpfleming]

OK, first test report: test was done using the 1.0.8.1 installer image. I started the install with the network configured for IPv6 only (SLAAC + RDNSS, no DHCPv6 (either stateful or stateless)). The installer booted, and then sat waiting for a DHCPv4 response on eth0. I let it sit for two minutes, then re-enabled the DHCPv4 server. Within a few seconds an IPv4 address was obtained and the installation continued, and produced a successful install. As a result, I don't know whether IPv6 was used during the installation process, but having it enabled certainly didn't cause any harm. If there's a desire to have the installer be able to operate in an IPv6-only environment, we'll have to open a separate issue and discuss how to accomplish that. This effort would be complicated by the fact that there are three ways (all standards compliant) to obtain an IPv6 address and recursive DNS resolver address in such an environment, and the installer would have to be prepared to support all of them.

[Mausy5043]

@kpfleming :+1: Can you access your DNS logs? See what kind of query it got, if any?

The IP-address used by during the installation should be recorded at the start of the raspian-ua-netinst.log.

[diederikdehaas]

Thanks :+1:

I'm probably showing my ignorance regarding IPv6 here, but why didn't you enable the DHCPv6 server? Do you need a different /etc/network/interfaces configuration when you use IPv6? If so, how?

btw: why do you think that we need a separate issue for IPv6 support? I do think a better name for this issue is a good idea, but it looks like this issue has always been about IPv6.

I just looked a bit further and I think that busybox' udhcpc doesn't even support IPv6 :open_mouth:

[kpfleming]

@Mausy5043: Actually, I'll go even further. I can setup my switch to mirror all of the traffic generated by the Pi during the install, and capture it with Wireshark. I'll do that in the next couple of days, and we'll have a definitive answer as to whether IPv6 was used during the installation.

@diederikdehaas: There are three methods of providing IPv6 addresses and network information to clients. I chose the simple option, which is SLAAC+RDNSS, which uses Router Advertisements from the subnet's router to tell the clients the network prefix (which they use to autogenerate an address), the default gateway address, and the recursive DNS server address. Most operating systems handle this just fine, so there's no need to run a DHCPv6 server. On Linux, a line like 'iface eth0 inet6 auto' is sufficient to get the prefix/address and router information, but the DNS server information must be obtained by using the rdnssd daemon in combination with resolvconf. Mac OSX and other platforms work with this configuration as well.

The other modes involve DHCPv6; in stateless mode, the Router Advertisement is still used to provide subnet prefix and default gateway information, and the client autogenerates its own address, but it uses DHCPv6 to get other information (recursive DNS server, NTP server, etc.). In stateful mode, the Router Advertisement is used to provide subnet prefix and default gateway information, but the client does not autogenerate an address; instead, it uses DHCPv6 the same way it would use DHCPv4, to get an address lease and all of the other network information.

All three modes are driven by Router Advertisements, unlike on IPv4 networks. The RA tells the clients which mode is in use. I've never setup a Linux system in a network that used either mode of DHCPv6, though, so I don't have any knowledge about how to do that.

[diederikdehaas]

On Linux, a line like 'iface eth0 inet6 auto' is sufficient

Now I'm quite sure that IPv6 does NOT work with this installer. As I said earlier, I'm pretty sure that udhcpc (from busybox) doesn't support IPv6. And the code for using a static address is as follows: ifconfig eth0 up inet $ip_addr netmask $ip_netmask broadcast $ip_broadcast || fail Note the hardcoded inet which is not inet6 as mentioned by @kpfleming

It would probably interesting to see whether it does/could work with a static IPv6 configuration.

Thanks for the tests and the info @kpfleming :+1:

[kpfleming]

Agreed, based on that it appears that IPv6 won't be used during the installation at all, unless the default configuration in the kernel assigns an address. I'll do the second test anyway, to see if I see any IPv6 traffic during the install.

[diederikdehaas]

Another test you could try is using a static address, but replace inet with inet6 at https://github.com/debian-pi/raspbian-ua-netinst/blob/master/scripts/etc/init.d/rcS#L198 But you'd have to build a new installer for that to work. If that's a problem, I can create one for you if you like.

Not sure whether more should be adjusted for it to work though ...

[kpfleming]

I'd have to specify the gateway and DNS server addresses as well. Manually specifying gateway addresses on IPv6 networks is uncommon, so I wouldn't want to suggest that people actually do that to do an installation :-) Instead, I might experiment with a patch that allows the user to specify automatic IPv6 addressing and gateway determination (by configuring the kernel to listen for RAs) but requires manual specification of the DNS server address. Building a custom installer shouldn't be an issue.

[diederikdehaas]

Any test that would indicate that the software in the installer is at least capable of doing IPv6 would be much appreciated :+1: If it is not, we need to figure out which packages need to be added/replaced and that's very useful info to have/know.

[kpfleming]

Umm... well, I should have checked this before, but neither archive.raspbian.org nor archive.raspberrypi.org have AAAA records in DNS, so they are not reachable over IPv6. There's no point in testing IPv6 in the installer if the package repositories can only be reached over IPv4 :-)

[diederikdehaas]

https://raspbian.org/RaspbianMirrors indicates there are various/lots of IPv6 capable mirrors (indicated with *), so use mirrordirector.raspbian.org as mirror or use a IPv6 capable mirror explicitly (the latter is probably better to test with)

[kpfleming]

Will do!

[Mausy5043]

Just me being ignorant here: I thought IPv6 was only still available for LAN-traffic. My ISP gives me an IPv4 address. How, then does one access IPv6 servers on the interwebs? Does that require an ISP that hands out IPv6?

[diederikdehaas]

Does that require an ISP that hands out IPv6?

Yes. And optionally gear (modem/router) that supports it.

[Mausy5043]

I see. Or you could set up a raspberry pi running dnsmasq for LAN-side support.

[kpfleming]

I have a (free) IPv6 tunnel from Hurricane Electric, which gives me access to the IPv6 Internet. Many public sites (including majors like Google, Facebook, etc.) are accessible over IPv6, and hundreds of millions of mobile devices use IPv6 natively as well. It's in much more use than you might think!

[diederikdehaas]

I should have checked this before, but neither archive.raspbian.org nor archive.raspberrypi.org have AAAA records in DNS

What made you think that?

https://www.whatsmydns.net/#AAAA/archive.raspberrypi.org https://www.whatsmydns.net/#AAAA/archive.raspbian.org https://www.whatsmydns.net/#AAAA/mirrordirector.raspbian.org They all seem to indicate support for IPv6.

[BenjaminHae]

For experiments with ipv6 I recommend sixxs.net . They offer free ipv6 tunnels so you can try 6 when your isp only offers 4.

[diederikdehaas]

That is interesting! Thanks :+1:

[kpfleming]

Now I'm confused indeed. I'll recheck from my build server tonight, it didn't report any AAAA records when I tested.

I'll be building a test installer this weekend with some patches to provide basic IPv6 support, as it's clear that IPv6 won't be used at the moment. If things go well, expect a PR soon :-)

[diederikdehaas]

If things go well, expect a PR soon :-)

\o/

Please do so against v1.1.x if you can, as the development is focused on that branch now. Otherwise, I'll forward-port it myself. Not an problem :-)

[kpfleming]

I'm building the patch against v1.1.x, and it's nearly done. I just need to ensure that the configuration used during the installation is properly persisted into the resulting installed system, which is a bit tricky. Still, quite close.

I have confirmed at this point that with the current installer, if the network has an IPv6 router that is issuing Router Advertisements, the kernel will auto-assign an IPv6 address and enable a default route to that router. This means that IPv6 can definitely be used during the installation.

I've also confirmed that it's not possible to do an installation using only IPv6, at least on my network, because sometimes DNS lookups return A records, which of course are not reachable without an IPv4 address and route. That's not something the installer can address though, it's a more fundamental problem in many tools and libraries used on Linux systems.

[diederikdehaas]

As I was going through @kpfleming PRs ( :+1: ) the thought came to my mind whether it wouldn't be better to properly think through our network stack.

The current busybox implementation we're using now seems hackish and limited already and rather then hack into it even further, we should consider alternative solutions/packages. One thing is for sure, Debian properly supports all kinds of network configurations. I'd rather use that then hack our own custom solution.

In that regard, we should probably also evaluate whether dhcpcd etc, what raspberrypi.org is using in their images, is a worthy candidate.

[kpfleming]

The flexibility offered by the Debian networking system (ifupdown, parts of which are already copied into the initramfs but not used as far as I can tell) is quite nice, but providing a way for the user to inject configuration could be a bit tricky.

[kpfleming]

This can be closed again, for two reasons:

• Since March, the kernel build has had IPv6 support in a module, not in the kernel itself. Since the installer does not load this module, IPv6 support will not be used at all in installers built from the current branches.
• I've submitted PR #425 to add substantial IPv6 support (although not complete, as it does not support DHCPv6, since that would require substantial additions to the installer).

[Mausy5043]

Closing this issue. To quote @kpfleming :

Supporting DHCPv6 would require using a full-blown DHCP client in the installer (probably dhclient, the same one that is used in the installed system) instead of udhcpc. While I haven't tried it, this would likely increase the size of the installer image quite noticeably, so as a result it's probably best to wait until the community expresses a real need for DHCPv6 support.