Requiring all apps to work on ipv6-only DNS64/NAT64 networks will let Apple do without 464xlat entirely, as no ipv4-only app will be left on the app store.
> Even if it existed, it would bring very little value to the users, as operating a radio device with modified firmware on public networks without recertification is prohibited in most jurisdictions of the world and privacy concerns in cellular networks are mostly related to what happens on the network side, not inside the device.
Not entirely true, publishing the code isn't the same as allowing its modification. Code signing can be used to limit which versions are allowed to run.
Reproducible builds of the source would allow one to ensure that the binary, certified version of the code their baseband processor is running is legit (i.e. not backdoored). It would also help audit the code and spot security holes.
> Not entirely true, publishing the code isn't the same as allowing its modification. Code signing can be used to limit which versions are allowed to run.
If I can't run my home-compiled versions of your code - whether because of code signing restrictions or because of federal law prohibiting firmware that hasn't been certified - it's not free[0]. So without without reproducible builds, providing the source code for the firmware provides very little benefit (since I have no way to prove that the code corresponds to what's actually running on the device, nor any legal way to install and run it on the device myself.)
Reproducible builds could in theory work, but actually getting builds to be bit-for-bit reproducible is not an easy feat. I'd be very surprised if firmware were capable of this.
[0] This is a great example of why a free software license doesn't necessarily mean that the software is free. It means that the author has waived his/her ability to restrict your freedom to use/modify/distribute the software, but that doesn't mean that third parties (ie, the government, or a patent troll) have done the same.
Not free, but open. I'd argue the latter is significantly more important than the former if you're trying to protect against the code working against you. At least if the code is open, you can inspect it and verify its operation.
This.
At least, if you're not ready to accept incoming v6 connections (which really isn't hard to do), use connection tracking to let outbound v6 through and add the necessary icmpv6 accept rules.
ufw comes pre-installed on ubuntu and is dead simple to use, there's really no reason not to use it.
# ufw allow 22/tcp
# ufw enable
should be all you need to have connection tracking on both v6 and v4, have a tried and trusted icmpv6 accept list, and keep your v6 and v4 firewalls in sync.
I like to use a limit rule (ufw limit 22/tcp) for SSH, to discourage brute force attacks. If nothing else, it will help reduce the noise in the log files.
This isn't a replacement for basic precautions such as disabling root login and not allowing password authentication, of course.
I'd strongly recommend against using ftp in 2015.
sftp [1] should do everything that ftp did in with a good level of security (encryption, server authentication and key based user auth).
It uses ssh as transport protocol which means that if you have an ssh server set up, you don't need anything else.
To answer your question, lftp [2] on the command line, cyberduck [3] on osx. Both of these tools are capable of connecting to sftp servers, too.
Also, sshfs (+ osxfuse for osx) [4] is definitely worth a try.
> * via Raspbmc, which I just found out has apparently ceased to exist...
Try OSMC [1], it's a massive improvement over Raspbmc and is being developed actively. Works like a charm.
If I'm correct, the main Raspbmc dev went over to OSMC a while back.
I have been running the Pi since 2012 from the early days of Raspbmc to OSMC and sometime in 2013 starting watching and recording television using it.
I have ATSC (North American Over-The-Air TV) which is similar to DVB-T. I use an HDHomerun Network TV tuner. I watch using my Pi running OSMC and an Add-on for DVBLink, and when I select record, I use DVBLink software which runs on my Synology NAS. DVBLink however is paid software that can run on the Pi, as well as many other platforms (Windows, Linux, Asustor, Netgear, QNAP, Synology, Western Digital).
I tried using TVHeadend but found the interface and support of DVBLink to be better.
My other Pi currently runs Volumio (https://volumio.org) for music streaming.
what icebraining said: use a nat64+dns64 at the edge of your network and make all your endpoints ipv6 only.
If you're an ISP, you could probably put multiple nat64 boxes in the core so that all your customers benefit from it and can gradually switch ipv4 off (since they can transparently reach ipv4 endpoints through the nat64 gateway).
Then there are a few applications that don't handle ipv6 properly (i.e. skype), and Apple's decision of mandating ipv6 support is meant to fix just that.
Then there is 4XLAT, ds-lite and others which allow for a single stack ipv6 network and carry ipv4 on top of it to the endpoints which need it.
iOS8 has been reported to be dual stacked (v6 + v4 addresses) on the cellular side of things on Verizon and a bunch of other (mostly European) networks.
What Apple did with iOS9 is improve its address selection algorithm to prefer ipv6 in a majority of cases (if both the device and the server are dual stacked and unless v6 path latency is much greater than its v4 counterpart, v6 will be used).
In contrast, ios8 would prefer v4 over v6 when both endpoints were dual stacked.
Also, from what I've seen, iOS devices won't provision ipv6 addresses on their cellular interface unless their Carrier Profile says they should, so you might have encountered devices not getting ipv6 addresses even though they were connected to a dual stack network. Wifi always uses v6 if the network supports it.
