simoncion • today at 12:57 AM

> ...linux, in particular made it really hard to reliably disable

Section 10.1 of that Archi Wiki page says that adding 'ipv6.disable=1' to the kernel command line disables IPv6 entirely, and 'ipv6.disable_ipv6=1' keeps IPv6 running, but doesn't assign any addresses to any interfaces. If you don't like editing your bootloader config files, you can also use sysctl to do what it looks like 'ipv6.disable_ipv6=1' does by setting the 'net.ipv6.conf.all.disable_ipv6' sysctl knob to '1'.

> You aren't running it during an external transitive failure...

I'll assume you meant "transient". Given that I've already demonstrated that the only relevant traffic that is generated is IPv4 traffic, let's see what happens when we cut off that traffic on the machine we were using earlier, restored to its state prior to the updates.

We start off with empty firewall rules:

  root@ubuntu-server:~# iptables-save
  root@ubuntu-server:~# ip6tables-save
  root@ubuntu-server:~# nft list ruleset
  root@ubuntu-server:~# 

We prep to permit DNS queries and ICMP and reject all other IPv4 traffic:

  root@ubuntu-server:~# iptables -A OUTPUT -o enp0s3 -p udp --dport 53 -j ACCEPT
  root@ubuntu-server:~# iptables -A OUTPUT -o enp0s3 -p tcp --dport 53 -j ACCEPT
  root@ubuntu-server:~# iptables -A OUTPUT -o enp0s3 -p icmp -j ACCEPT
  root@ubuntu-server:~# iptables -A INPUT  -i enp0s3 -p udp --sport 53 -j ACCEPT
  root@ubuntu-server:~# iptables -A INPUT  -i enp0s3 -p tcp --sport 53 -j ACCEPT
  root@ubuntu-server:~# iptables -A INPUT  -i enp0s3 -p icmp -j ACCEPT
  root@ubuntu-server:~# iptables -A OUTPUT -o enp0s3 -j REJECT
  root@ubuntu-server:~# iptables -A INPUT  -i enp0s3 -j REJECT
  root@ubuntu-server:~#

And we do an apt-get update, which fails in less than ten seconds:

  root@ubuntu-server:~# apt-get update
  Ign:1 http://security.ubuntu.com/ubuntu questing-security InRelease
  Ign:2 http://us.archive.ubuntu.com/ubuntu questing InRelease
  <snip>
  Could not connect to security.ubuntu.com:80 (91.189.92.23). - connect (111: Connection refused) Cannot initiate the connection to security.ubuntu.com:80 (2620:2d:4000:1::102). - connect (101: Network is unreachable) <long line snipped>
  <snip>
  W: Failed to fetch http://security.ubuntu.com/ubuntu/dists/questing-security/InRelease  Cannot initiate the connection to security.ubuntu.com:80 (2620:2d:4000:1::102). - connect (101: Network is unreachable) <long line snipped>
  W: Some index files failed to download. They have been ignored, or old ones used instead.
  root@ubuntu-server:~# 

In this case, the IPv6 traffic I see is... an unanswered router solicitation, and the multicast querier chatter that I saw before. [0] What happens when we change those REJECTs into DROPs

  root@ubuntu-server:~# iptables -D OUTPUT -o enp0s3 -j REJECT
  root@ubuntu-server:~# iptables -D INPUT  -i enp0s3 -j REJECT
  root@ubuntu-server:~# iptables -A OUTPUT -o enp0s3 -j DROP
  root@ubuntu-server:~# iptables -A INPUT  -i enp0s3 -j DROP
  root@ubuntu-server:~# 

...and then re-run 'apt-get update'?

  root@ubuntu-server:~# apt-get update
  Ign:1 http://security.ubuntu.com/ubuntu questing-security InRelease
  Ign:1 http://security.ubuntu.com/ubuntu questing-security InRelease
  Ign:1 http://security.ubuntu.com/ubuntu questing-security InRelease
  Err:1 http://security.ubuntu.com/ubuntu questing-security InRelease
  Cannot initiate the connection to security.ubuntu.com:80 (2620:2d:4002:1::103). - connect (101: Network is unreachable) <v6 addrs snipped> Could not connect to security.ubuntu.com:80 (91.189.92.24), connection timed out <long line snipped>
  <redundant output snipped>
  W: Some index files failed to download. They have been ignored, or old ones used instead.
  root@ubuntu-server:~#

Exactly the same thing, except it takes like two minutes to fail, rather than ~ten seconds, and the error for IPv4 hosts is "connection timed out", rather than "Connection refused". Other than the usual RS and multicast querier traffic, absolutely no IPv6 traffic is generated.

However. The output of 'apt-get' sure makes it seem like an IPv6 connection is what's hanging, because the last thing that its "Connecting to..." line prints is the IPv6 address of the host that it's trying to contact... despite the fact that it immediately got a "Network is unreachable" back from the IPv6 stack.

To be certain that my tcpdump filter wasn't excluding IPv6 traffic of a type that I should have accounted for but did not, I re-ran tcpdump with no filter and kicked off another 'apt-get update'. I -again- got exactly zero IPv6 traffic other than unanswered router solicitations and multicast group membership querier chatter.

I'm pretty damn sure that what you were seeing was misleading output from apt-get, rather IPv6 troubles. Why? When you combine these facts:

* REJECTing all non-DNS IPv4 traffic caused apt-get to fail within ten seconds

* DROPping all non-DNS IPv4 traffic caused apt-get to fail after like two minutes.

* In both cases, no relevant IPv6 traffic was generated.

the conclusion seems pretty clear.

But, did I miss something? If so, please do let me know.

[0] I can't tell you why the last line in the 'apt-get update' output is only IPv6 hosts. But everywhere there were IPv6 hosts, the reported error was "Network is unreachable" and for IPv4 the error was "Connection refused".