simon_vetter
Joined 13 years ago
Karma
267
Submissions
79
Member since
Jan 30
Recent submissions
Comment · 10 years ago
They're doing dual stack, not ipv6-only with nat64/dns64.
Comment · 10 years ago
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.
Comment · 10 years ago
> 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.
Comment · 10 years ago
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
Comment · 11 years ago
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.
[1] https://tools.ietf.org/html/draft-ietf-secsh-filexfer-13
Comment · 11 years ago
> * 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.
[1] https://osmc.tv
Comment · 11 years ago
This is fairly common, if not ubiquitous.
Use key-based authentication, disable password auth in sshd_config and install sshguard.
Comment · 11 years ago
That's only a management interface tho, the modem will still happily forward ipv4.
Comment · 11 years ago
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.
Comment · 11 years ago
This. Running dual stack networks is harder and more expensive to manage, secure and troubleshoot.
The faster we get to single stack ipv6 only, the better.
Comment · 11 years ago
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.
Comment · 11 years ago
Add the score of the duplicate (being deleted) to that of the original story, and keep the highest rank of the two?
Comment · 11 years ago
Implementing other protocol handlers into existing web browsers and operating systems would be a good start IMO.
Taking ipfs/ipns [1] as an example, having handlers inside web browsers would allow people to link from http[s]:// to ipfs:// and vice versa in a seamless way, lowering the barrier to migrate.
From there on, there's nothing preventing you from distributing your application code (html/css/javascript/whathaveyou) over ipfs, and make use of WebRTC for user-to-user interactions.
Obviously http[s] is going to stick around for a while as it has its use cases (basically anything that deals with a centralized service, from online banking to search engines to apis), but having a secondary, peer to peer means of distributing content and applications would be a major plus.
[1] http://ipfs.io (they have a working implementation in Go with an HTTP gateway as well as a FUSE filesystem)
Comment · 11 years ago
hulbee.ch uses an invalid security certificate. The
certificate is only valid for the following names:
*.hulbee.com, hulbee.com