snapcraft updates don't download in an IPv6 + NAT64 environment
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Snapcraft |
New
|
Undecided
|
Unassigned | ||
| snapd |
Triaged
|
High
|
Unassigned | ||
Bug Description
A common environment is IPv6 only with compatibility to IPv4 networks provided by NAT64, which includes the Mythic Beasts Raspberry Pi cloud and various IPv6 only VM offerings. In this environment IPv4 only services (e.g. api.snapcraft.io) have IPv6 addresses synthesized to allow connectivity. e.g.
$ telnet api.snapcraft.io 443
Trying 2a00:1098:
Connected to api.snapcraft.io.
The snap installer appears to ignore this connectivity option and insist on using IPv4 which won't work and doesn't fallback (or better yet, start with) native IPv6.
$ sudo snap install canonical-livepatch
error: cannot install "canonical-
https:/
IPv6 + NAT64 is the required to be supported for iOS applications.
| Peter Stevens (mythicbeasts) wrote | #1 |
| Changed in snapd: | |
| status: | New → Triaged |
| importance: | Undecided → High |
If you drop the A responses for api.snapcraft.io, you correctly then connect to the IPv6 address. So an IPv6 only customer of Mythic Beasts can workaround this with /etc/hosts
2a00:1098:
2a00:1098:
2a00:1098:
This is undesirable - we're now ignoring your DNS and have to maintain fake records locally.
The application should do
if (can_connect_v6) { connect_v6 } else { connect_v4 }
If you want to stick to preferring v4 because the 1990s were *awesome* and you want to stay there, then at least falling back to v6 if the v4 connection fails would be an improvement. That way your software would merely be slow, rather than broken.