Hi, I’m a new Tablo user (3 months) and I LOVE it. I’ve been using it as a replacement for an older cobbled-together open-source DVR that never quite worked.
I am curious how it would make viewing recordings outside of the home easier. Tablo Connect works well, even using IPv4.
IPv4 addresses aren’t available everywhere anymore. Eventually even the USA will feel the pinch (but likely the last ones to feel the need).
Running a combo stack of IPv4 and IPv6 is pretty trivial Linux wise, but in Windows, it requires a bit more work. In Windows you have to have a complete end to end IPv6 stack (with regards to core services). In Linux you can have a hybrid. Has to do with differences in network stack design.
Tablo Connect is fine, but from a networking perspective, it’s kind of a hack (using network address translation, etc.) IPv6 would make it unnecessary and you would simply use the regular tablo interface. My home connection uses a business-grade router/firewall that works great for so many things, but I’d have to cripple it slightly to use Tablo Connect.
The best part about dual stack is that if your client doesn’t support it, you don’t use it. Doesn’t hurt to support the future. The one challenge would be that you’d actually have to know the address of your DVR if you’re off-net as opposed to using broadcast traffic to locate it on the LAN like today.
The shows recorded for your own use are legal. You can not legally give or sell retransmissions of the shows or the recordings. If the recording is an old movie whose copyright has expired, that would be an exception I think. However, an old movie that has been colorized often gets a new copyright.
That might be one of the reasons for the Tablo on home network prior to using remotely. If we had a login and password, it could be shared/sold for access to your Tablo. They might limit number of connections from remote if they add a username option, and still have unlimited LAN connects.
I am NOT a lawyer and this is not legal advice.
There’s no legal reason why we did pairing vs. other methods. We just thought it would be really great not to have to worry about passwords!
Pairing with no passwords is a great idea for the general consumer. But there are many of us who would like to use Tablo Connect away from home on devices that may never pair locally.
Plus Tablo Connect on the Roky will likely need a username and password similar to how the Plex channel on the Roku connects to remote servers.
That’s exactly why we want to look at alternatives or fallback measures.
So… that’s good. What about the IPv6 part? I’d love to help with a beta
Ordered/shipped 4ch refurb Tablo Friday, arrives Monday, wow!
No, there is no workaround for Tablo Connect.
Not entirely true. You can set up a VPN server at home and then have your wife connect he iPhone to said VPN server. This will let her connect to the Tablo remotely and pair her device. iPhone has a built in VPN client.
I have done this several times to re-pair my iPhone and iPad.
Just another vote for IPv6 capability. I work with IPv6 on a daily basis so I have a test LAN built at home where I review new things and see how well they work in an IPv6 environment. It was sad to see the Tablo lacked any support.
More and more vendors are adding support and more ISPs are adding delegated IPv6 address space to consumers. The time is now to add support!
If you are using a tablo in a LAN versus WAN environment is there currently any compelling reason for support of IPV6. Products that support IPV6 should also be supporting IPV4 via dual TCP/IP stack implementation. And if the product only supports IPV4 a 6to4 tunnel is also suppose to be supported.
Are you asking a question or making a statement? The LAN/WAN nomenclature is about 15 years out of date, although some CE industry manufacturers may still push it on their residential routers. It’s true that most products supporting v6 do also support v4, but I don’t see how that’s relevant. You can’t do native real-time translation between v6 and v4 without very pricey carrier-grade-NAT devices. 4-in-6 is nice if you have an ipv6-only uplink, but you still can’t connect to the device on the other end unless you’re doing hoop-jumping with NAT or you happen to have some precious and expensive public IPv4 space. Native IPv6 support removed the necessity of all of that. You access it via IPv6 if you have it and IPv4 if you don’t. Simple. It just has to be enabled and supported.
For IPV6 wasn’t LAN/WAN replaced by
I thought tablo clients used broadcast to locate tablo servers on the local IPV4 network or for IPV6 link-local. And 6to4 tunnel only requires the ipv6 packet be embedded in the ipv4 payload and a protocol type 41.
IPV4 broadcast to address 255.255.255.255 sends to broadcast to all addresses on the LAN segment. And IPV6 uses multicast for link local addresses. Some with IPV6 you have a prefix site id followed by a subnet id, blah,blah, blah.
True, v6 does host discovery on an L2 domain differently that v4, but as you noted, there is a comparable neighbor discovery technology in v6…which works great for other things. 6-in-4 works great, too. I use it now since my ISP provides only a weak transition technology for v6. The problem is that it doesn’t give you much unless you have something that speaks the v6 part at both ends to actually USE the connection. If tablo were to add native v6 to the device stack, would it be so horrible to have an IP or hostname helper required for remote (or non-network-adjacent) clients to have to access it? I’m not saying it’s the default mode, but when a large chunk of the userbase are cord-cutting tinkerers, not providing a native v6 mechanism is rather a community disservice. I can get to my Plex system via it’s v6 address, for example, and there’s a great integration between plex and Tablo, but the client won’t playout since I’m unreachable from the Tablo’s perspective.
There isn’t anything necessarily bad about supporting IPV6. But when you have a large set of clients, routers, and switches there can be a large testing effort versus any tangible benefit for the average user. Not all devices that access the tablo server may be using a totally IPV4 or IPV6 environement. Thus tablo would need to support mixed mode access. And that leads to all the side affects of single versus dual TCP/IP stack implementation, stacks that prioritize IPV4 over IPV6, TCP/IP stacks that have been totally disabled (IPV6 or IPV4), etc,etc,etc.
There is limited R&D resources. And while I don’t need the feature I would bet most users would pick 5.1 audio over IPV6 support. I’ve been waiting 17 months for the Roku app to reach the same feature level as the WEB app.
I totally agree!!!