Launchpad is not available over IPv6

This is a fair question but not a code bug with launchpad - launchpad runs behind stock apache servers in the Canonical datacentre; I'm not sure if/when we're going to IP6 enable the datacentre, but when we do LP shouldn't need any changes. As such I'm going to close this.

You should be able to use 6to4 to file bugs; I suggest filing a bug on Ubuntu itself if that isn't working.

I've had it pointed out to me that 6to4 is not what my vague memories of it were. Still - nat64 is apparently the right thing to use to interoperate with services that are not yet ipv6 enabled.

I don't think closing bugs based on whether they need Launchpad upstream code changes or not is the right line. Whether it does or not, it's a user-affecting issue and it's useful to have a public handle for it, so that we can see how many people are affected etc, and if that's not a bug there's no obvious other place for it. I guess ultimately it will turn into an IS request, but that's not accessible to users and perhaps not worth opening far in advance.

We could do a FAQ, but as the bug tracker is the work queue for
developers, I think its harmful to have non-code things in the
tracker.

I talked a bit to Robert because I was concerned about closing user-affecting issues as invalid with no way to progress, just on the grounds that one Canonical team would have to change them rather than another or that we'd have to make a configuration rather than code change.

This bug is closed because the state of ipv6 deployment as of 2011, as we understand it, is that it's just not a reasonable or common case to have a machine that cannot reach ipv4 servers, through either having an an ipv4 route too or having a nat64 gateway at your ISP. If/when that changes (or if it's wrong now) and people are happily using ipv6-only machines, we can reconsider it.

Now it is 2013, and we have basically run out if IPv4 space. Please reconsider.

I said two years ago

> it's just not a reasonable or common case to have a machine that cannot
reach ipv4 servers

and I've seen no evidence it's not still true.

Martin: The Asia-Pacific region has been out of IPv4 addresses since 2011, Europe and the Middle-East since 2012. In those regions more and more IPv6-only networks are appearing. I run such networks as well. I am very happy that archive.ubuntu.com is reachable over IPv6 so that normal updates work in an IPv6-only environment. Launchpad is now the next site that I run into.

Please re-open this ticket, now that IPv4 addresses have run out in multiple regions of the world this is very much needed.

Thank you,
Sander Steffann]

Hi Sander,

My impression is that IPv6-only networks without an http proxy or NAT64 are
still very rare and not practical for general use. A network configured as
in rfc6586 would probably work fine with Launchpad.

I can't see any data on how many sites are strictly-IPv6-only. I would be
interested if you know of any.

Practically: I'm no longer involved with Launchpad, so it's not for me to
reopen it, nor is it possible for me to do anything about it. I doubt that
the Canonical team will allocate time to fix this.

I too am no longer active on the LP project, but:
 - this still isn't a code bug in LP: it's entirely possible to run it IPv6 - *there is nothing to fix here* : it's an operational deployment issue, and best raised as a support ticket.
 - There are a growing number of environments where obtaining IPv4 addresses is impossible, but as Martin says there is little evidence that such environments have no access to either NAT64 or an http[s] proxy on a dual-stack machine, so this really sits in the category of 'migration to IP6 requires access to the IPv4 internet via a proxy - thats the standard for deployment'.

As a data point, AWS EC2 still doesn't support IPv6 at all - thats one of the largest public clouds in existance. They do support IPv6 ELB, but not direct to EC2 instances. So there's a huge amount of things out there for which IPv4 connectivity is required: the onus is on people migrating to arrange connectivity (thats the whole point of the migration).

Guys, please, fix this! Enable ppa.launchpad.net over IPv6... I already have lots of servers that already are IPv6-Only... IPv4 is dead.... :-P

Please, fix this bug. If you don't have IPv6 you don't ready for the future. IPv4 is dead, wake up.

Perhaps this should be added to the IPv6 issue open with Canonical IS per #1260855 ?

In Finland we recently had national IPv6 launch day and currently two biggest (W)ISPs provide dualstack (lite) meaning native IPv6 + IPv4 with CGN.

The carrier grade NAT (or NAT66) could have performance issues and as IPv4 addresses have ran out years ago it would be important to be ready for IPv6 by supporting it at Launchpad.

At least ppa.launchpad.net already has a ticket open with Canonical IS (RT#75360). We can't do much more than that from our end.

pls.. 2 years ago and no change?! Still no IPv6 for launchpad :'(

Now that this is assigned to someone, is there any progress? T'is not that hard.

Any News? apport-collect and ubuntu-bug and so on won't work on my ipv6 only host.

Hi all, sorry this is taking so long. It's still on my radar. I will keep you posted.

Anything?

This should be done by EOY.

The last 1/12 of this year will start soon. Will the planning be met?

Going to be tough, but I'm actively working on it.

@Junien: you have some IPv6 experts subscribed to this ticket. Let us know if there is anything we can do :)

@sander-steffann : thanks for the offer ! The problem isn't IPv6 in itself though, just the complexity of Launchpad. I'm also decoupling hosts and services, which wasn't done for everything in IPv4.

There's good news though, the production frontend *hosts* now have an IPv6. I'm going to let that brew for a bit, and then it'll just be a matter of adding an IPv6 for the vhosts. Targeting January 2019 for this.

I have (finally) enabled IPv6 on the launchpad vhosts present on the web frontends. I believe you should be able to run "apport-collect" and "ubuntu-bug" from IPv6-only hosts now, but if that's not the case please let me know.

I still have some more work to do to enable IPv6 on the remaining services (notably codebrowse), so I'll keep this bug opened for now.

Hi Junien,

> I have (finally) enabled IPv6 on the launchpad vhosts present on the web
> frontends. I believe you should be able to run "apport-collect" and
> "ubuntu-bug" from IPv6-only hosts now, but if that's not the case please
> let me know.
>
> I still have some more work to do to enable IPv6 on the remaining
> services (notably codebrowse), so I'll keep this bug opened for now.

Thanks! I'll try it out when I'm back in the office.

Cheers!
Sander

😄👍🏽😁🏅🙏🏽🏆

This issue is not fixed as ppa.launchpad.net is not reacheable over IPv6, as it lacks IPv6 address.

$ host ppa.launchpad.net
ppa.launchpad.net has address 91.189.95.83

No IPv6 support, so PPA archive is not accessible by IPv6 only hosts :-(

Err:7 http://ppa.launchpad.net/scaleway/stable/ubuntu bionic InRelease
  Could not connect to ppa.launchpad.net:80 (91.189.95.83), connection timed out

@slansky: In the meantime, have you tried to use public DNS64/NAT64 resolvers (see https://serverfault.com/a/596637/346625) in order to work around this, as implicitly/explicitly mentioned in previous postings here? Did that not do the trick?

@Markus Ueberall: of course you can resort to NAT64, but that means the connection will be ultimately over IPv4. Yes, there are some public NAT64 gateways that you can even use for that, but that doesn't solve the problem that ppa.launchpad.net is missing an AAAA record.

The blocker for ppa.launchpad.net is bug 1807662 (since otherwise adding an AAAA record to ppa.launchpad.net would break uploads for anyone with IPv6). Shouldn't be too hard, but we need to get suitable tests written and then get it landed and deployed.

@Colin, what is required to move that issue along? I just set up an ipv6-only node but still had to add an ipv4 address just because of ppa.launchpad.net

Perhaps, for the time being, you could add a ppa6.launchpad.net that has got an AAAA-record? That way, people just using PPA's to install packages (over http) could do so on ipv6-only nodes, while uploads could use ppa.launcpad.net as always.

@freeaqingme, I made some progress on bug 1807662 today. I'd much rather get that fixed properly than hack around with alternate DNS names that would realistically have to stay in our configuration forever because they'd end up embedded in people's setups.

Just adding my name to the requests for an IPv6 address for ppa.launchpad.net. Thanks :-)

The blocker 1807662 seems to be in state fix released, can this bug proceed?

ppa.launchpad.net is now reachable over IPv6.

There are still some other items on our to-do list, which are mostly less important:

 * bazaar.launchpad.net
 * git.launchpad.net
 * lists.launchpad.net
 * keyserver.ubuntu.com

(On Ubuntu 18.04 and earlier, add-apt-repository relies on keyserver.ubuntu.com, so currently still requires IPv4. On Ubuntu 18.10 and later, add-apt-repository fetches keys from Launchpad instead, so will now work on IPv6-only systems.)

As a person running Ubuntu on a IPv6 only network, Thank you so much @cjwatson.

I should say, credit to our sysadmins (Junien and Haw in particular) for most of the work; I'm just keeping bugs up to date really ...

Thanks! 👍🏽

As someone who does a lot of IPv6-only work I really appreciate this. Thanks!

Thank you. Really important! But please, do not forget about:

MX record!

Email is important too, and your MX record is still IPv4-only.

On Sun, Oct 27, 2019 at 05:01:51PM -0000, T Jeske wrote:
> Email is important too, and your MX record is still IPv4-only.

Noted, thanks. I've added this to our internal task tracker.

Next: an AAAA-record for www.ubuntu.com and ubuntu.com?

:-)

We really don't need the scope of this question to creep any further. (www.)ubuntu.com isn't operated by the Launchpad team.

Any news on the MX record front though?

Not yet no, sorry

I'm afraid that IPv6 access is broken.

Not sure which part is broken, though: For a very long time, I've been unable to add repos with commands like

add-apt-repository ppa:gluster/glusterfs-7

(Just tried that one - but it invariably fails no matter the repo)

If I disable IPv6 completely, I can add the repo. After having added it, I can reenable IPv6 and add packages and do updates/upgrades.

So fetching packages using IPv6 works - but adding new PPAs with IPv6 enabled fails.

It's quite a hassle having to disable IPv6 node by node on a Kubernetes cluster...

Lars Skjærlund <email address hidden> wrote:
    > add-apt-repository ppa:gluster/glusterfs-7
    > (Just tried that one - but it invariably fails no matter the repo)

can you tcpdump what IPv6 is occuring then?
Can you blackhole route that destination and then does it succeed?
Sounds like some front-end IPv6 is answering, but has no back end
connectivity.

@larsskj : thanks for your feedback. I emailed you yesterday to get more details (but got no reply so far). Let's debug this :)

keyserver.ubuntu.com supports IPv6 now, thanks to our sysadmins.