I have the same issue with chat protocols. Some of my friends are on iMessage, some on Hangouts, some on Whatsapp. None of these talk to each other and I'd really just rather use TextSecure.
We had a standard for chat, it's called XMPP, and before that we had IRC. I know they're all non-optimal for mobile use but some goddamn standards (tm) would make my life easier.
I can't believe we were better off in the heydays of Trillian - at least all my contact lists were in one program!
Maybe I should go back to SMS.
Now, on home automation. I came to some of the same conclusions as the author - we're screwed when it comes to being at the behest of big companies and proprietary protocols to control devices we should own.
I just dread having to write yet another home automation framework when I do finally automate my doors, windows and lights. Now where did I put my keys again?
Ugh this is the bane of my life. We use basecamp, hipchat, Skype, Skype for business, email and google hangouts all at once. My kids use hangouts, WhatsApp, Facebook messenger.
None of them work properly. None of them has everyone on it. None of them add any value to communication. All of them throw ten minutes to the wind finding everyone to start with. I've missed 20 minutes of many meetings dealing with audio problems, network problems and firewall problems when we could have used a simple dial in conference system that has been around for over 10 years.
And I'm treated like a Luddite because you have to call me, SMS me or email me?!?
I don't want this any more. After a rant yesterday about WiFi and how it sucks and I've switched back to wired ethernet. I have to suggest that there was a technological singularity around 2005 which was 'peak utility' before the proliferation of sharecropped communications, technology with false utility, high cost and pay-per-everything.
To add other things to this problem set is going to cost me more money and time of which both are finite and at least one runs out uncontrollably.
One of the things I was hoping would take off was SIP: URIs - in theory you could "dial" my email address and the call would be routed to wherever I was at that moment. Texting is built in too. Goddamn standards strike again.
Yeah that was a great idea. Until NAT, firewalls, your average contracted out MSP at an SME sysadmin who's idea of admin is lock everything down and pay £300 to open a port (I have to deal with this at least one a week).
Yes that's true although I've lost count of the hours I've thrown out on Skype.
Yes IPv6 definitely FTW. We just migrated our office and two data centres to it. Life is good now. V6 firewalls are just packet filters; all our nets are in the public address space.
May I ask how you deal with multiple redundant Internet connections at your office?
It seems that you either end up with devices having two addresses, and have to deal with all the broken software that assumes a machine only ever has one address, or you use a ULA and NAT which is no better than IPv4 in many ways.
I really don't know how that works - we contracted it out.
There is a router that has an ethernet port on it. That's our internet in. Anything in front of that is ours. Anything behind we don't care about but there is a 100mbit local shared ethernet and a backup FTTP line. I assume it's switched to the same network at the peer end as if either goes down, we only have one address space. We have a couple of front-facing v4 addresses that handles incoming mail.
This all sits in a cabinet we don't touch owned by the provider.
The stupid thing is the LSE and fibre cables leave the building in the same pipe. Wonder how long it'll be before someone digs through it.
You can make a non-routable subnet if you need one by configuring a firewall/access list. Pretty much any router can do that. Plus you get way better granularity in controlling access - office-local subnet, DC-local, branch-local, country-local, whatever-local access - unlike venerable RFC1918.
But never use non-globally-unique addresses as other commentators suggest with wonky probabilistic allocations. There is absolutely zero benefits for that, and it will inevitably end up to be a huge PITA down the line. IPv6 used to have 6-to-6 NAT and site-local addresses, but sanity won, and both were dropped from the current slew of RFCs.
Or, you can use RFC4193 (AKA ULA) space, which allocates a /48 and is designed to be non-routable, unless an admin chooses to make it routable.
RFC4193 specifies a prefix generation method and lays out the probability of collision. If you join two networks together, you've a (1.81x10^-10)% chance of prefix collision. If you join ten-thousand networks together, you have a 0.0045% chance of collision. [0] If my math is right [1], this means that you'd need to join 2,500,000 networks [2] together to have a 1% chance of a prefix collision.
I am squarely in the "If there's a chance that it can happen, it will happen." camp. However, I'm rather okay with those odds.
[0] Either my figures are right here, or you need to take those percentages and divide them by 1000 to arrive at the correct figure.
[1] And it may not be right!
[2] Networks -each with its own /48- as opposed to hosts.
Collision probability is indeed low if you'll assume perfectly generated prefixes, and even in an unlikely case of /48 collision, those themselves would be pretty sparse, so again assuming perfectly random distribution, chance of collision of say fifty /64s on one side with the same amount from the other network is still pretty low.
But bigger point here is that often you will need external connectivity for those ULAs, similar to what everybody used to do in IPv4 world (i.e. NAPT, a.k.a. "nat overload" a.k.a. "IP masquerade"), and that is not something that is available, really. Instead, IPv6 offers prefix translation (a.k.a NPTv6, see RFC6296). So effectively that means that:
- for each LAN segment (i.e. /64) you have to have a "private /64" and a "public /64" (or same at coarser granularity up to /49 or even more). Twice the number of networks to configure and keep track of;
- "NAT as a security measure" argument flies out of the window, as NPTv6 is stateless.
In other words, you get all the hassle of IPv4 NAPT with none of its (meagre) benefits.
> But bigger point here is that often you will need external connectivity for those ULAs...
The whole point of using ULA space is for giving IP addresses to machines that you don't expect to need to contact machines in the globally-routable IP ranges. [0]
From the RFC:
This document defines an IPv6 unicast address format that is globally
unique and is intended for local communications, usually inside of a
site. These addresses are not expected to be routable on the global
Internet.
If it turns out that some of those machines actually need access to globally-routable space, then advertise a globally routable prefix to those machines and either keep advertising the ULA prefix, or -yanno-, don't. :)
Fixing this particular network planning error shouldn't be much harder than unsetting some firewall and/or routing rules that break Internet access for machines that have been assigned a globally-routable address. :)
[0] On my LAN, I advertise a ULA prefix, as well as a globally-routable prefix. Because my globally-routable prefix is not static, [1] I use the ULA prefix as an ersatz poor-man's Provider-Independent allocation. This setup would be probably be somewhere between unreasonable and silly at a site that does have a static prefix assignment.
[1] Well, it's effectively static, but I don't have an SLA, so... ;)
I assume that you're asking "How do I advertise a ULA prefix on my LAN, as a home user?". If you're not, then the following probably won't answer your question. If you're already familiar with ULA prefix generation and IPv6 prefix advertisment, and are just trying to find out how to advertise on your home router, almost all of the following will be redundant information. (I'm happy to read the manual for your make and model of router and try to see if you can easily advertise prefixes on it. :) )
I'm not sure how much experience you have with screwing around with router settings, your level of familiarity with IP networking concepts, or even what software you're using on your router, so I'll give some background information on prefix advertisement, and describe prefix generation and how you might actually advertise a ULA prefix on a router running OpenWRT. Because the underlying software that does the work should be the same regardless of router model, reading about how it is done on OpenWRT might give you a starting point to discover how it's done -if it is at all- on your router model. I'm more than happy to clarify anything that's confusing, give additional information, or track down and read documentation for a particular router!
Background information:
Many routers use a piece of software called radvd to advertise IPv6 routes. Radvd -effectively- takes a list of network interfaces, each with a list of router advertisment options, and transmits advertisements on those interfaces. radvd has a config file whose syntax is documented here [0]. A minimal radvd config file would look like
This would instruct radvd to advertise whatever prefix had been assigned to the interface named eth0 to machines attached to eth0. Note that an interface section can have multiple prefix sections. If you have a particular prefix that you want to advertise, replace "::/64" with that prefix. The overwhelming majority of options in the radvd config file are both entirely optional, and entirely unneeded in most situations.
Now, I suspect that on most routers that support prefix advertisement, you'll never need to touch an radvd config file. Like I said, this is just background information. So, let's get to generating your ULA prefix:
Generating your ULA prefix:
Get the MAC address of a computer that you control.
Go to https://www.sixxs.net/tools/grh/ula/ and plug that MAC address into the MAC address field on the page. You'll get a value back that of the form: fdaa:aaaa:aaaa::/48 This is your ULA prefix.
Advertising a /48 is kind of awkward for downstream devices. You need to carve out a /64. So, take that ULA prefix, add a colon and four zeroes to it and replace the /48 with a /64 like so: fdaa:aaaa:aaaa:0000::/64 You can now go to advertise this on your LAN. [1]
Advertising the prefix:
I actually have no idea what the prefix advertisement option is called on most consumer routers, or if it even exists on your router. A quick look at Belkin's and Linksys's support sites didn't turn up anything promising. I would dig around in the IPv6 settings tabs until I found something that looked promising, or had exhausted all options. [2]
If you're using a recent version of OpenWRT (That is, OpenWRT Barrier Breaker or later), /etc/config/network has a ula_prefix option in the globals section that's used for exactly this. [3][4]
If you're using a version of OpenWRT earlier than Barrier Breaker, you can tell radvd to advertise your ULA on your LAN interfaces. The prefix section of /etc/config/radvd is used for this. /etc/config/radvd is documented here [6]. You can have multiple prefix sections for each LAN interface. [7]
Now, reload the network config (Call /etc/init.d/network with either the reload or restart option, I can't remember which.), wait for a minute or two, and machines on your LAN should have a new IPv6 address in the /64 that we carved out of the ULA.
If everything's working, -optionally- register your newly-generated prefix with SixXS at the page where you generated your ULA prefix.
[4] Though, to be frank, I can't remember if you plug in the /48 and it automatically creates /64s for each LAN interface that you have configured [5], or if you can only plug a single /64 into it. I would try the /48 first.
[5] OpenWRT lets you set up multiple LAN interfaces. I found this useful when I was using VLANs to make isolated WiFi guest networks.
[7] So, if you have IPv6 service from your ISP, you can advertise the ISP-provided prefix and your ULA prefix. Have one prefix section that contains no prefix option, and a second prefix section that contains a prefix option whose value is the /64 that you created earlier.
Yes aware of that. There are some gotchas with that, particularly address space collision between two sites with a tunnel between them. I've never seen one in v6 but one of our clients had a 10.0.0.0/8 and so did we and I don't want to get into that state of affairs again. I'd only use that for totally airgapped networks.
There's a mechanism for randomly generating a /48 with a low probability of collision. [0] SixXS maintains a list of "allocated" prefixes, [1][2] but who knows how complete it is?
Edit: Also, you might be interested in reading about the NETMAP iptables/ip6tables target. See iptables-extensions(8) for more info.
I'm sure that such a book exists, but I have no idea what it is. I've picked up what I know by reading RFCs, Wikipedia pages, and the like and experimenting on my LAN.
It's been quite some time, and the details are hazy, but I remember the process of getting a tunnelbroker.net tunnel configured, and the subsequent (totally optional) series of knowledge tests required to unblock IRC over the tunnel taught me a fair bit about IPv6 and some about (reverse DNS? forward DNS?) glue records.
Figuring out the meaning of all of the options available in an radvd config file was also rather educational. (20->40% of the educational value was in reading about things that were tangentially related to whatever the radvd configuration item was.)
uPnP/NAT-PMP pretty much solves the NAT problem, for the home user. :)
I'm having difficulty parsing your second sentence. So, I'll say this: If you're a tech business and can't manage to cost-effectively manage the settings on your border equipment, you're doing something really wrong. :)
Sorry my bad. You got the point though. You'd be surprised how many messes there are out there. I tripped over a whole network of unpatched windows XP sp1 machines the other day.
I'm not sure I got the point. Were you trying to say that before NAT, businesses contracted out to vaguely-competent third-parties who charged an arm and a leg for changes to firewall configuration?
No I'm saying that still they do that today and always have done. UPnP is always off. And that's £300 and a service case open to turn it on. Then a 48 hour turnaround.
MSP=Managed Service Provider. Basically rip off merchants who charge you for everything because you are trying to run a business with the tech rather than run an operations team.
"Watershed (figurative definition, as used by Illich): A point in the historical process when a particular “tool” creates a quantum shift in society, like the sudden application of gravity feeding water into a terrain basin (literal watershed)."[0]
WiFi is a great win, I think. The problem is just that we have allowed ourselves to think it is a complete solution. That everything should be wireless, that wired has no advantages. In reality WiFi and ethernet complement eachother, each with their own strengths.
In particular, I've found a 10Mb LAN outperforms a 1000Mb WiFi for networked filesystem access.
Might your issue with WIFI be specific to your setup than a problem with WIFI itself? I replied to your comment yesterday, but just how noisy can WIFI get anyway? There's a finite number of people who can live within 50 metres of our homes. So there's a limit to how noisy it can be. I'm saying this because I have no issues with WIFI in a cluttered inner-city suburb full of WIFI. I just got myself a good WIFI modem router, and it's smooth and no drop-outs for multiple users in the house. Nobody expects super reliable HD video to stream through without ever glitching, but it actually does a good job of that anyway using Netflix, Youtube, and Chromecast and other methods like iPads.
I would suggest getting a better router, and making sure other factors are set correctly to maximise signal strength rather than blaming WIFI. Location of the router, whether you use a range extender and so on.
I've had inssider running, channel hopped, tried three different routers (netgear, router board, Asus) to no avail. I've tried several client devices too from high end centrino, apple and Motorola kit.
I don't stream any media, just do file copies. It sucks whatever I try.
In my experience, SMS and Hangouts are equally unreliable messaging protocols. Messages sent through either transport can be delayed for arbitrary lengths of time or lost entirely.
Everything that's happened with Hangouts that's unrelated to video calling just makes me so sad.
Google Talk is still alive, well, and performing bi-directional message delivery between XMPP clients with a Google Talk account and Hangouts clients. (Or maybe alive but for the fact that a Google VP hasn't noticed that it's still up and running. shrug)
Any client that speaks XMPP should work just fine to reach into Google's IM silo for direct messaging. I make frequent, daily use of Pidgin for this purpose. Sadly, the only way to access group chats is through the official client.
Also: If you haven't already, check out TextSecure by Open Whisper Systems. It has the best group-SMS handling of any MMS client I've tried. It's also made and maintained by a group of folks who are really concerned with making secure software that also happens to be as easy to use as is possible.
This is the reason I am pushing myself towards simpler solutions, even if I end up losing some functionality/connections out of it. The added cognitive load of dealing with managing all of these services is becoming really painful.
Yes, I may not have push via the cloud to my latest iGizmo, but at least I don't have to worry that I forgot an important calendar, todo, file, or chat message on one of 5 services that mix and match between what they offer.
Org-mode can run calendar, todo, notes, habits, journal, etc.
Chat is where I still haven't found a solution. Switching to XMPP/SMS semi-exclusively is probably the next step.
I would like that, but the thing with calendar, todos, etc, is that syncing with my iGizmo is what makes them most useful for me. That iGizmo is on my person at all times. At the doctor's office and need to make an appointment or talking to a contractor about getting away during the day to meet them at home? Calendar is right there so I won't schedule over a meeting or other engagement. Grocery shopping? My shopping list is there, no way I'd forget it at home. The syncing is precisely what I need it to do to be useful.
Before my iGizmo I carried around a notebook, but that was larger, more cumbersome and had less flexibility (I can add a grocery list item from my PC in the kitchen or even input it by voice if I realize I need something).
That means that for some of us, a better solution rather than a simpler one is what we desperately hope for.
Hey, at least we've finally gotten to the point where I can reliably guess that probably 80+% of the android phones I encounter will have a microUSB plug!!
SMS is filled with spam? That's honestly news to me - I think I've gotten one spam SMS in the last two years? I get a lot more spam calls, though Google Voice filters them for me now.
It's really too bad that the mythical man-month is really mythical, otherwise everybody here on HN could pitch in 5 minutes and make a successor to XMPP that is optimal for mobile...
I'm rolling out a test network at the university of IoT. Instead of going with XYZ expensive setup, I'm rolling my own using an Arduino (clone) nano, sensors, and nRF24L01+ using mysensors library. On the acquisition end, I'm using node-red with the mysensors en/decoder.
I have node-red generating dynamic HTML, and dumping it in var/www/html and apache serving it up. All I'm waiting for now is 30 more setups for testing purposes.
(nRF24L01+ can generate a self-healing mesh network. Given the weird shape of our building, makes this ideal. And a small change turns a sensor node into a sensor/gateway.)
We had a standard for chat, it's called XMPP, and before that we had IRC. I know they're all non-optimal for mobile use but some goddamn standards (tm) would make my life easier.
I can't believe we were better off in the heydays of Trillian - at least all my contact lists were in one program!
Maybe I should go back to SMS.
Now, on home automation. I came to some of the same conclusions as the author - we're screwed when it comes to being at the behest of big companies and proprietary protocols to control devices we should own.
I just dread having to write yet another home automation framework when I do finally automate my doors, windows and lights. Now where did I put my keys again?