News items for tag ipv6 - Koos van den Hout

2019-12-08 Out of IPv4 addresses, way past time to start using IPv6 1 day ago
Based on the fact that RIPE has really run out of IPv4 addresses it is way overdue to start using IPv6.

To help that I wanted to have a way to show visitors to my site whether they can use the new protocol. The current box on the righthandside is based on the connection with the webserver and most browsers prefer the fastest connection to just give the user the best experience. The so-called 'happy eyeballs'.

But I want to show visitors whether their browser/system/network supports the new Internet protocol. So I'm looking into ways to check for IP versions with Javascript. Ages ago their was a test (mainly to test for systems with broken IPv6 connectivity) but that one is gone and not completely what I want.

So I asked around and Iljitsch van Beijnum responded with his version of the IP version test.

So my current version is at ipv6test.idefix.net. Plan is to add an option to have true/false values in javascript available and make updates to parts of the page using that.

I could imagine turning a page black-and-white if you only have 'old' Internet protocols. I just have to learn a lot more javascript to do that.

Tags: ,
2019-11-21 First setup of the remoterig interfaces 2 weeks ago
The remoterig set I ordered arrived.

At first I found the box somewhat empty: no manuals. But the entire manual can be found on-line: User manuals - RemoteRig. The manual is about 200 pages so printing it would be a bad idea. The remoterig site is somewhat slow so I downloaded the PDF manual to my computer.

Most of the setup is done via a webinterface, but the initial network setup needs either the right IP addresses hardcoded or a USB connection and the Microbit setup software which is only available for Windows. I did try to see whether one of the four com-ports via USB that showed up would allow me to do a minimal setup via a terminal program but that wasn't true. So I booted Windows to change the units to DHCP. For the radio-side I made an address allocation in the DHCP server, for the client side it is fine to have any usable address.

And for my next minor issue: they only use IPv4. So my inner linux and networking geek is a bit dissapointed, but my inner radio geek will do just fine.

After that bit I went back to Linux, the rest of the software setup is via a webbrowser. For the hardware setup, which is how it connects to the radio (which pin has audio, which pin has power) it needs a number of internal jumpers and jumper wires connected.

Tags: , , ,
2019-09-19 Real IPv6 port scan/network mapping attempts 2 months ago
I noticed some interesting traffic in my home network this morning, an attempt at finding IPv6 systems. Since IPv6 privacy enhancements are enabled on most systems this is exactly like finding a needle in a haystack.

I noticed an amount of outgoing icmpv6 traffic, and looking at the destination addresses and the type of traffic found lots of 'unreachable route' messages to a few Chinese IPv6 addresses. Searching for the netblock '240e:f7:4f01:c' finds more reports of portscanning activity.
10:14:27.761704 IP6 (hlim 239, next-header TCP (6) payload length: 24) 240e:f7:4f01:c::3.12980 > 2001:980:14ca:1:5054:ff:feae:17.902: Flags [S], cksum 0xd0a9 (correct), seq 3726392987, win 29200, options [mss 1460], length 0
10:14:28.278108 IP6 (hlim 239, next-header TCP (6) payload length: 24) 240e:f7:4f01:c::3.19933 > 2001:980:14ca:1:5054:ff:feae:8003.12587: Flags [S], cksum 0xe1cc (correct), seq 95632679, win 29200, options [mss 1460], length 0
10:14:29.219766 IP6 (hlim 239, next-header TCP (6) payload length: 24) 240e:f7:4f01:c::3.41487 > 2001:980:14ca:1:5054:ff:feae:fff2.902: Flags [S], cksum 0x3c31 (correct), seq 500442149, win 29200, options [mss 1460], length 0
10:14:33.637405 IP6 (hlim 239, next-header TCP (6) payload length: 24) 240e:f7:4f01:c::3.35832 > 2001:980:14ca:1:5054:ff:feae:15.902: Flags [S], cksum 0xa6ea (correct), seq 2324914849, win 29200, options [mss 1460], length 0
10:14:34.468975 IP6 (hlim 239, next-header TCP (6) payload length: 24) 240e:f7:4f01:c::3.12470 > 2001:980:14ca:42::ffe8.16992: Flags [S], cksum 0x5a72 (correct), seq 3249792078, win 29200, options [mss 1460], length 0
10:14:34.469038 IP6 (flowlabel 0x63971, hlim 64, next-header ICMPv6 (58) payload length: 72) 2001:980:14ca:61::13 > 240e:f7:4f01:c::3: [icmp6 sum ok] ICMP6, destination unreachable, unreachable route 2001:980:14ca:42::ffe8
10:14:35.230776 IP6 (hlim 239, next-header TCP (6) payload length: 24) 240e:f7:4f01:c::3.63145 > 2001:980:14ca:1:20d:56ff:fece:8006.19: Flags [S], cksum 0xb87b (correct), seq 4259180220, win 29200, options [mss 1460], length 0
10:14:35.952841 IP6 (hlim 239, next-header TCP (6) payload length: 24) 240e:f7:4f01:c::3.9056 > 2001:980:14ca:42::8013.16992: Flags [S], cksum 0xbb3b (correct), seq 2896438720, win 29200, options [mss 1460], length 0
10:14:35.952880 IP6 (flowlabel 0x63971, hlim 64, next-header ICMPv6 (58) payload length: 72) 2001:980:14ca:61::13 > 240e:f7:4f01:c::3: [icmp6 sum ok] ICMP6, destination unreachable, unreachable route 2001:980:14ca:42::8013

Tags: , ,
2019-08-01 IPv6 growing up: ssh attempts to an inside machine 4 months ago
IPv6 is growing up: I saw an ssh attempt to an inside machine, reachable only via IPv6. The source was a Chinese IPv6 address which had not tried anything on any other public service.
Jul 30 18:39:02 ritchie sshd[27454]: Bad protocol version identification '\026\003\001' from 240e:d9:d800:200::212 port 44926

Tags: , ,
2019-07-26 My Android phone gets an IPv6 address from t-mobile... but no routing 4 months ago
I just noticed in Network Info II that my android phone does get an IPv6 address from t-mobile. The address is something like 2a02:498:1fe1:9a02:2:3:xxxx:xxxx which is indeed in IPv6 address space allocated to T-Mobile Netherlands.
% Information related to '2a02:498::/29'

inet6num:       2a02:498::/29
netname:        NL-T-MOBILE-20080609
country:        NL
So I tested directly whether I could make an IPv6 connection to my website, but it fell back to IPv4. Network Info II saw no IPv6 route on the phone, but in later checking I also saw no IPv6 route when connected to the wifi at home, where IPv6 works fine. And doing a traceroute to that address from home shows that a core router at xs4all says network unreachable:
 3  0.ae22.xr4.1d12.xs4all.net (2001:888:1:4032::1)  6.105 ms !N  6.063 ms !N *
So T-Mobile has activated some IPv6 address management in their network, but stopped at that point.

Tags: , ,
2019-06-20 De afhankelijkheid van xs4all verminderen 5 months ago
Sinds april 1993 heb ik een xs4all login account (ja, van voor de start, mijn account is met de hand aangemaakt door Rop Gonggrijp). Sinds begin 1992 had ik al een xs4all uucp account voor kzdoos.xs4all.nl, tegenwoordig omgezet naar een bsmtp account (waarbij mail binnenkomt bij de xs4all mailservers en na de spamfiltering doorgestuurd wordt naar mijn server). Maar met de laatste plannen van KPN om het merk xs4all te gaan stoppen en zaken samen te voegen ben ik toch bang dat de unieke redenen om daar te blijven langzaam zullen vervallen.

Wat ik nodig heb is een plek met vast IPv4/IPv6 en een aardige uplink snelheid. Via xs4all kan dat gewoon thuis, maar misschien is op den duur een virtuele private server en een goedkope thuisaansluiting met daartussen een vorm van vpn ook een werkende oplossing.

Dus dan is het ook tijd om langzaam minder afhankelijk te worden van de bsmtp service voor kzdoos.xs4all.nl en langzaam maar zeker mijn eigen domeinnaam idefix.net voor e-mail in te voeren als primair adres. Wie weet heeft de bsmtp dienst bij KPN ook niet het eeuwige leven. De extra opties die van xs4all een goede provider maken voor een hobbyist zitten bij andere providers vaak in een zakelijk pakket of worden niet aangeboden.

Ik kon altijd beweren dat ik het e-mail adres wat ik gebruik gewoon ouder was dan spam e-mail.

Tags: , ,
2018-12-30 First annoyance with systemd on thompson 11 months ago
On reinstalling thompson I was not sure whether to pick ubuntu (with lots of package support for amateur radio) or devuan (without systemd). I chose ubuntu to keep access to lots of amateur radio packages but as expected the first systemd problem already got me. Names in the internal network with RFC1918 addresses weren't resolvable.

After some searching I found out systemd-resolved had decided the last nameserver advertised via IPv6 was the one to use. As I could not find a lot of information on how to do the ordering I just decided to kick it all out and switch to normal resolving. Some searching found How to disable systemd-resolved in Ubuntu? - ask ubuntu which has the right steps. Back to somewhat normal, the next step is to convince NetworkManager to use IPv6 resolving before IPv4.

Tags: , , ,
2018-12-07 Trying to kick spamassassin and perl into the 21st century and prefer IPv6 for DNS traffic 1 year ago
Or in short: Perl considered harmful

I want applications to use and prefer IPv6 whenever possible, so I have a /etc/resolv.conf with IPv6 addresses of the nameserver(s) listed first. But I noticed queries from the spamassassin processes still coming in over the legacy IP protocol. Even when listing them in order in /etc/spamassassin/local.cf spamassassin prefers IPv4. And I want it to prefer IPv6 without leaving out IPv4. I like the redundancy but I want to change the preference. Also: I only want to maintain the list of nameservers in /etc/resolv.conf and not in other locations.

I wrote a simple test program to understand what the perl Net::DNS::Resolver is doing. With a standard test program like:
#!/usr/bin/perl -wT

use strict;
use Net::DNS;
my $resolver = new Net::DNS::Resolver();

print join ' ', $resolver->nameservers();

print "\n";
The IPv4 addresses will be listed first, independent of the order in /etc/resolv.conf. Only after changing to:
#!/usr/bin/perl -wT

use strict;
use Net::DNS;
my $resolver = new Net::DNS::Resolver();
$resolver->prefer_v6(1);

print join ' ', $resolver->nameservers();

print "\n";
I will see the IPv6 resolver listed first. But now to convince spamassassin to do the same. Browsing the Net::DNS::Resolver shows the RES_OPTIONS="inet6" option but does not document it. This option confuses spamassassin when starting:
export RES_OPTIONS="inet6"
root@gosper:/etc/default# service spamassassin restart
Restarting SpamAssassin Mail Filter Daemon: Bad arg length for NetAddr::IP::Util::mask4to6, length is 128, should be 32 at /usr/lib/x86_64-linux-gnu/perl5/5.24/NetAddr/IP/Lite.pm line 647.
Compilation failed in require at /usr/lib/x86_64-linux-gnu/perl5/5.24/NetAddr/IP.pm line 8.
BEGIN failed--compilation aborted at /usr/lib/x86_64-linux-gnu/perl5/5.24/NetAddr/IP.pm line 8.
Compilation failed in require at /usr/share/perl5/Mail/SpamAssassin/Util.pm line 70.
BEGIN failed--compilation aborted at /usr/share/perl5/Mail/SpamAssassin/Util.pm line 70.
Compilation failed in require at /usr/share/perl5/Mail/SpamAssassin/Conf.pm line 85.
BEGIN failed--compilation aborted at /usr/share/perl5/Mail/SpamAssassin/Conf.pm line 85.
Compilation failed in require at /usr/share/perl5/Mail/SpamAssassin.pm line 71.
BEGIN failed--compilation aborted at /usr/share/perl5/Mail/SpamAssassin.pm line 71.
Compilation failed in require at /usr/sbin/spamd line 240.
BEGIN failed--compilation aborted at /usr/sbin/spamd line 240.
So that was a bad idea and is not the answer. Looking at the resolv.conf manpage shows that the option indeed does different things which explains why that was wrong.
  inet6  Sets RES_USE_INET6 in _res.options.  This has the
		 effect of trying an AAAA query before an A query inside
		 the gethostbyname(3) function, and of mapping IPv4
		 responses in IPv6 "tunneled form" if no AAAA records
		 are found but an A record set exists.  Since glibc
		 2.25, this option is deprecated; applications should
		 use getaddrinfo(3), rather than gethostbyname(3).
So if I want perl programs to do what I want, I have to change every one of them to set $resolver->prefer_v6(1);. There is no sane default or a global "get into the 21st century" flag.

Changing /usr/share/perl5/Mail/SpamAssassin/DnsResolver.pm to include $res->prefer_v6(1); does help, but will need to be redone when updating spamassassin.

Tags: , , ,
2018-05-03 The preferring IPv6 policy is working 1 year ago
Yesterday I changed some IPv4 addresses on virtual machines on the new homeserver to make autofs work. This is a known issue with autofs: autofs does not appear to support IPv6 hostname lookups for NFS mounts - Debian Bug #737679 and for me the easy solution is to do NFS mounts over rfc1918 ipv4 addresses. I prefer autofs over 'fixed' NFS mounts for those filesystems that are nice to be available but aren't needed constantly.

It took about 9 hours before arpwatch on the central router noticed the new activity. I guess the policy to try to do everything over IPv6 is working.

Tags: , , ,
2018-04-06 Keeping squid webproxy running for network mismatches 1 year ago
I considered stopping using squid when upgrading to the new homeserver but I have now changed that decision: I need to keep it running for applications that want to do http connections to IPv6-only systems but can't handle those. There are some old scripts running that need it but it's also the way to fix the problem I noticed with linuxcounter.

Tags: , ,
2017-10-11 Haproxy on the new home server and devuan upgrades 2 years ago
I got around again to working on the new homeserver 2017 and I worked on the installation of a 'testing' virtual machine with virt-install. This test machine also runs devuan linux. The first application I was testing on there is haproxy.

haproxy I noticed some defaults I did not expect (such as preferring IPv4 over IPv6). It seems the 'stable' devuan has the same age issues as 'stable' debian. Otherwise haproxy does what it is supposed to and I may standardize on it.

Upgrading was easy, I looked at Upgrading Devuan Jessie to Ascii and just changed jessie to ascii in /etc/apt/sources.list and did an apt-get dist-upgrade. The only minor issue afterwards is that the system now insists on using framebuffer video, which I find overkill for a virtual machine. VGA 80x25 is fine.

Tags: , , ,
2017-10-09 Interesting NFS exports problem 2 years ago
I am used to being unable to unmount filesystems as long as they are NFS exported. It took me a while to find out how to correctly unexport filesystems before trying to unmount them. The easy solution would be to unexport everything and just export the other filesystems, but I'd rather not interrupt NFS availability of other filesystems.

So it was time to check some large filesystems again and I'd rather not do that during boot as it can delay booting for up to an hour. Currently those filesystems are exported via IPv4 and IPv6. Removing the export for IPv4 is easy:
# exportfs -u 192.168.1.0/255.255.255.0:/export
But for IPv6 it gets harder:
# exportfs -u 2001:db8:a::/64:/export
exportfs: Invalid unexporting option: 2001
So it is still exported via IPv6. And next thing I try to unmount it and notice it's ok to unmount a filesystem that is only exported via IPv6. I guess this shows some interesting bug.

Tags: , ,
2017-09-28 Duelling standards and anti-spam measures 2 years ago
In today's mail problems:
   ----- Transcript of session follows -----
... while talking to ecp-nl.mail.protection.outlook.com.:
>>> DATA
<<< 450 4.7.26 Service does not accept messages sent over IPv6 [2001:980:14ca:61::13] unless they pass either SPF or DKIM validation (message not signed) [VE1EUR01FT036.eop-EUR01.prod.protection.outlook.com]
<info@ecp.nl>... Deferred: 450 4.7.26 Service does not accept messages sent over IPv6 [2001:980:14ca:61::13] unless they pass either SPF or DKIM validation (message not signed) [VE1EUR01FT036.eop-EUR01.prod.protection.outlook.com]
Warning: message still undelivered after 4 hours
Will keep trying until message is 5 days old
Rerouting mail for ecp.nl via xs4all servers in the hopes of getting it delivered.

Some research shows me that the xs4all outgoing mailservers (smtp.xs4all.nl) do offer incoming connectivity via IPv6 but don't connect to the IPv6 addresses of mailservers they are trying to reach.

Tags: , ,
2017-07-17 Now NetworkManager generates resolv.conf .. and starts with legacy IP 2 years ago
I removed rdnssd and resolvconf and fixed the symlink linking /var/run/NetworkManager/resolv.conf and /etc/resolv.conf by hand. The file /etc/NetworkManager/NetworkManager.conf now says:
dns=none
rc-manager=file
But now I run into the 'NetworkManager prefers IPv4 resolvers' again, leaving me with the resolvers from the DHCP answer before those from the IPv6 route advertisment. The search domains are fine now.

Tags: , ,
2017-07-15 More resolving via IPv6 2 years ago
I was reading Debian Stretch - Het Lab Henk van de Kamer (in Dutch) which mentions removing package rdnssd to avoid a dependency problem. But I like rdnssd as it helps use the nameservers available via IPv6 in a network with only SLAAC and no DHCPv6.

Right away I had to check on my own laptop with Ubuntu 16.04 and noticed all traffic was going to the IPv4 address of the local resolver. Which is not what I want, I want to prefer IPv6 when possible. Searching found Bug #936712 “NetworkManager should put IPv6 DNS servers before I...” : Bugs : network-manager package : Ubuntu which is indeed what I saw, and it's still showing in Ubuntu 16.04 Xenial.

My solution was to stop using dnsmasq, and switch to a generated resolv.conf from NetworkManager. To do that I had to update /etc/NetworkManager/NetworkManager.conf to have:
#dns=dnsmasq
dns=none
rc-manager=file
And now I have a resolv.conf with only 3 IPv6 nameservers and no search domains. Not exactly what I want, but at least IPv6 is preferred. I considered something using only the first three resolvers because that is a maximum somewhere but just advertising two resolvers via radvd also makes two show up in the generated resolv.conf. This is not perfect. The generated resolv.conf has comments that it is generated by resolvconf so maybe this is a conflict between resolvconf and NetworkManager not in 'use resolvconf' mode.

Tags: , ,
2017-07-10 Raspbian mirrors sometimes fail when IPv6-only 2 years ago
Just happening:
Err http://mirrordirector.raspbian.org/raspbian/ jessie/main libgcrypt20 armhf 1.6.3-2+deb8u4
  Cannot initiate the connection to raspbian.42.fr:80 (163.172.250.246). - connect (101: Network is unreachable) [IP: 163.172.250.246 80]
It seems mirrordirector.raspbian.org redirects to IPv4-only sites even when the client connects via IPv6. My Raspberry Pi systems have IPv4 disabled. It's a known problem in Bug #1595563 “Native IPv6 client redirected to IPv4-only mirror” : Bugs : Raspbian where people seem to rather ignore the problem. I could reverse the statement there to "a service that can only be accessed by v4 nodes cannot be reasonablly considered to be available on the internet." but I guess that's "different".
Read the rest of Raspbian mirrors sometimes fail when IPv6-only

Tags: , ,
2017-03-10 Keeping an eye on planes in the air 2 years ago
I usually keep dump1090 running on a raspberry pi. It seems it is quite easy to share the data from dump1090 with Plane Finder so I decided to give that a try.

With the installation instructions via the Share your data with Plane Finder page I had the software installed easily. But I needed to visit the configuration page of the software via IPv4... while I disabled IPv4 on the raspberry so it took some changes to make it work again. Next thing the software was reporting the data was available fine but not uploading to the Plane Finder server. Checking with strace shows that the software tries to upload via an IPv4-only connection which will not work. Temporary re-enabling IPv4 fixes things, so it's purely an IPv4/IPv6 thing.

Tags: , ,
2017-01-20 APRS on the Raspberry Pi: trying to decode APRS packets 2 years ago
So the mobilinkd is now connected to serial over bluetooth on the Raspberry Pi, but now to get APRS data into aprx.

So far aprx does start but I see absolutely no data coming in, even when aprsdroid will see traffic. Something strange.
koos@joy:~ $ sudo aprx -v
2017-01-20 22:05:10.593 aprx start - 2.9.0
2017-01-20 22:05:10.594 TTY /dev/rfcomm0 opened
2017-01-20 22:05:20.624 CONNECT APRSIS aprsc.pa4tw.nl:14580
^C
2017-01-20 22:18:06.115 aprx ending (SIG 2) - 2.9.0
2017-01-20 22:18:06.116 aprx ending (SIG 2) - 2.9.0
It's a good thing aprsc.pa4tw.nl has an IPv6 address as this Raspberry Pi is only configured for IPv6.

Testing with minicom on /dev/rfcomm0 does show the startup messages from the mobilinkd but absolutely no APRS data in KISS format,,,
== BeRTOS AVR/Mobilinkd TNC2
== Version 2.0.1.571
== Voltage: 4019mV
== Starting.
Switching the mobilinkd between the Raspberry Pi and the smartphone with aprsdroid does seem to confuse something, it's not always showing data in aprsdroid either.

Installing the Linux ax25-tools and using kissattach and configuring aprx to use that interface doesn't help either.

Back to the KISS over serial port over bluetooth config I changed the setting 'bluetooth tracking' on the mobilinkd, which is advised for digipeater setups. And now I am seeing something:
koos@joy:~ $ sudo aprx -v
2017-01-20 23:12:17.568 aprx start - 2.9.0
2017-01-20 23:12:17.569 TTY /dev/rfcomm0 opened
9621    PE4KH-8   R     DB0NY>APZ17,DB0KX-2*,PE0FK-10*,PI1SHB*,PA7J-2*,WIDE2*,PI1APU*,LOCAL:!5103.84N/00736.63E#www.g07.de
2017-01-20 23:12:30.378 CONNECT APRSIS aprsc.pa4tw.nl:14580
9728    PE4KH-8   R     PI1APU>APND13:>W3,NL7      PAradigm    operation!
9831    PE4KH-8   R     PA3BXR-9>UQ5QW1,PA7J-2*,WIDE1*,PI1APU*,WIDE2-1:`zDKnA8>/]"3m}431.275MHz=
9867    PE4KH-8   R     PI1SHB>APRX29,PI1APU*,WIDE2-1:!5142.02N/00520.78E#PHG3460/2m Digi/IGate 's-Hertogenbosch
9934    PE4KH-8   R     PA5JB>APU25N,PE2KDK*,PI1APU*,WIDE2*:>202317zDX: PI1SHB 51.42.02N 5.20.78E 76.3km 133 23:13
9942    PE4KH-8   R     PI1DFT>APMI01,PI1SHB*,PI1APU*,WIDE2*:@202317z5159.70N/00420.17E#WX3IN1 Digipeater 2 mtr. pi1dft ziggo.nl
10007   PE4KH-8   R     PI1APV-2>APMI04,PI1DFT*,PA7J-2*,WIDE1*,PI1APU*,LOCAL:@202318z5130.81N/00344.00EI digi vliegveld MIDDEN ZEELAND
10018   PE4KH-8   R     DB0OTV-2>APOT21,DB0KX-2*,PE0FK-10*,PI1SHB*,PI1APU*,WIDE2*:>FILL IN DIGI + D-Star + C4FM QRG = 439,500 MHz -7,6 MHz
10122   PE4KH-8   R     PE9R>APX204,PI1APU*,WIDE2-1:=5202.5 N/00439.0 E-PHG2290QRV PI6NOS/ PI2NOS
10175   PE4KH-8   R     PA7J-2>APMI01,PI1APU*,WIDE2*:@210000z5149.68N/00450.43E-WX3IN1 PA7J Digi & I-gate Hardinxveld
10209   PE4KH-8   R     PD0JAC-10>UQ4XS8,PI1SHB*,PI1APU*,WIDE2-1:`{Mym>5#/>"4/}=
10227   PE4KH-8   R     PA3BI-10>APRS,PI1DFT*,WIDE1*,PA7J-2*,WIDE2*,PI1APU*,LOCAL:!5214.65N/00426.30E-000/000www.isemann.nl/A=000696
10277   PE4KH-8   R     PI1APV-2>APMI04,PI1DFT*,PA7J-2*,WIDE2*,PI1APU*,LOCAL::PI1APV-2 :BITS.11111111,Telemetry
10316   PE4KH-8   R     PI1SHB>APRX29,PI1APU*,WIDE2-1:!5142.02N/00520.78E#PHG3460/2m Digi/IGate 's-Hertogenbosch
And the results are showing up via the aprsc dashboard on aprsc.pa4tw.nl. Almost all packets I receive and forward are rejected as duplicate packets, but I have seen some packets accepted. So I guess I'm not really needed as an I-gate.

Tags: , , ,
2016-11-12 Disabling IPv4 on the Raspberry Pi 3 years ago
I have two Raspberry Pi's running in the house, currently with IPv4 still enabled on them. They both run Raspbian 8.0. I was wondering whether I can disable IPv4 on the Raspberry Pi, but a google search does not yield very helpful answers, most of the search terms I try still find pages about disabling IPv6. I want to disable the legacy IP protocol.

Only one way to find out: go for it. Now rebooting one with the statement ipv6only in /etc/dhcpcd.conf.

First thing I noticed was that the searchdomain was not set in /etc/resolv.conf which was indeed only available via the DHCP process for IPv4. So now radvd advertises the search domain via the DNSSL option in /etc/radvd.conf:
   RDNSS 2001:980:14ca:42::18 {
   };
   DNSSL idefix.net {
   };
The first results are:
  • It turned out the ntp config on the raspberry had one IPv6-only and one IPv4-only server. Added a dual-stack server.
  • And ndpmon really does not like the DNSSL option, even when I add it in the config_ndpmon.xml file as
                      <dnssl>
                        <domain lifetime="600">idefix.net</domain>
                      </dnssl>
    
    Fixed by changing it to
                      <dnssl>
                        <domain lifetime="600">^Fidefix^Cnet</domain>
                      </dnssl>
    
    yes, with literal ctrl-F and ctrl-C characters, showing that there is some error in the parsing somewhere.
  • rwhod is IPv4-only so the status is not visible in my network anymore. A workaround for that is not disabling IPv4 completely but just removing the default route, not using ipv6only in /etc/dhcpcd.conf but using the option nooption routers.

Tags: , , ,
2016-11-07 The future of the Internet is IPv6 3 years ago
Just read Internet Architecture Board Statement on IPv6 with:
The IAB expects that the IETF will stop requiring IPv4 compatibility in new or extended protocols. Future IETF protocol work will then optimize for and depend on IPv6.

Preparation for this transition requires ensuring that many different environments are capable of operating completely on IPv6 without being dependent on IPv4 [see RFC 6540]. We recommend that all networking standards assume the use of IPv6, and be written so they do not require IPv4. We recommend that existing standards be reviewed to ensure they will work with IPv6, and use IPv6 examples. Backward connectivity to IPv4, via dual-stack or a transition technology, will be needed for some time.

Tags: , ,
  Older news items for tag ipv6 ⇒
, reachable as koos+website@idefix.net. PGP encrypted e-mail preferred.

PGP key 5BA9 368B E6F3 34E4 local copy PGP key 5BA9 368B E6F3 34E4 via keyservers pgp key statistics for 0x5BA9368BE6F334E4 Koos van den Hout
RSS
Other webprojects: Camp Wireless, wireless Internet access at campsites, The Virtual Bookcase, book reviews