Multicast versus IPTV

24 February 2010

I’ve been hearing a lot of buzz about IPTV lately. It’s something that is exciting, useful, and inevitable.

As I understand it, IPTV is defined to be a live television service delivered over multicast (usually RTP) over a broadband Internet connection. Multicast has an advantage over normal traffic (“unicast”) because it avoids the duplication of traffic. Only one copy of the data is ever sent.

TPG currently offer 19 channels over an IPTV service, and TransACT allegedly offer over 50. iiNet is “on the brink of IPTV launch”. There are rumours that Internode are investigating something similar too.

That last paragraph should have triggered alarm bells in your head. It did for me, but maybe I’m just a cynic. Let me explain.

I asked myself: why are the ISPs providing the IPTV service? It sounds wrong to me. I’ve tried to come up with an answer, and my conclusion is that it is because of two reasons: (1) infrastructure (multicast is virtually non-existant in most production networks) and (2) content lock-in.

Having the ISPs provide the infrastructure for the IPTV service (marketing, encoding, distribution, etc.) means the ISP will likely sign a contract to exclusive usage rights with the TV partner for each channel they will provide. If iiNet sign an exclusive deal with Sky News, they sure as heck ain’t going to let Internode or TPG also put the content on their networks.

The infrastructure would also be duplicated. Each ISP needs their own TV receiving equipment (likely a few satellite dishes on top of their data centre), encoding equipment, marketing, private IP multicast network, and whatnot.

With regards to content lock-in, this will also mean that the ISP you choose to use will determine what IPTV channels you are able to watch. Conversely, what IPTV channels you want to watch will determine which ISP you will sign up with.

That sounds all rosy, until you consider that I am not restricted on what websites I can visit based on what ISP I am with. I can watch YouTube or ABC iView from any ISP in Australia. Sure, some ISPs offer better services than others, faster speeds, or more reliable connections, but it’s just the one Internet. This is because the ISP is not in the content provider role. They are merely the gateway to the Internet — the Internet service provider (now where have I heard that term before?).

The way IPTV looks like it is heading is shifting the ISP onto the content provider role. As I’ve already said, this means the service is delivered over the ISP’s private network, available exclusive to that ISP’s customers, and not over the Internet. That’s a Bad Thing™ in terms of net neutrality.

If an ISP “rebroadcasts” content from an IPTV channel that another ISP has signed an exclusive deal on, that would be a copyright violation.

But that still doesn’t explain the title of my post: “Multicast versus IPTV”. The above isn’t actually the crux of what I wanted to get at (apologies to the reader if you’ve managed to read this far in great detail).

I’m supportive of multicast in general. Combined with IPv6 (each /64 subnet has a corresponding multicast subnet), multicast opens up the doorway for anybody to serve high definition audio and video to the Internet at large without the need for exorbitant amounts of bandwidth up their sleeve.

But that’s public multicast. These “IPTV” solutions will be, and currently are, deployed on private multicast networks. On the plus site, private multicast networks mean it is easier for the ISP to deploy the infrastructure — it’s much easier to only have to worry about your own network, than also have to worry about interfacing with others. But it also means less incentive to deploy a public multicast infrastructure, and less incentive for content providers (such as TV networks) to provide their services over multicast themselves. It’s a chicken-and-egg problem.

We don’t need ISPs to “provide IPTV services”. We need a decent multicast network (preferably IPv6) that all Australians can access, so that TV stations themselves can provide the multicast streams with the knowledge that a large percentage of Internet subscribers are able to access their content, and that channel availability discrimination does not occur based on what ISP you choose to sign up with.

That’s the crux of what I’m getting at. I’m sure someone will come along and say “but but but…they have a right to sign exclusive contracts and deliver only over private networks”. My response to that would be that just because you have the right, doesn’t make it right. Nor left. :)

Thoughts?

Tagged: , , | 3 Comments »

IPv6–enabled

19 February 2010

This blog is officially IPv6–enabled, as of a few days ago.

The server-side IPv6 connectivity is admittedly powered by 6to4, which is not quite the real deal, but given that the nearest 6to4 gateway is 0.8msec away, I couldn’t very well pass the opportunity to stress test my new Linode.

I’m a pretty firm believer in the fact that IPv6 adoption is absolutely essential to the continued health and function of the Internet. I’ve been IPv6 tunneling from my house for years, had native IPv6 at my house since November, and though I’m certainly not the first to do so, it’s time to IPv6–enable my blog.

Tagged: , , , | No Comments »

Mandatory filter (Clean Feed) trial results announced

16 December 2009

Well, it’s official. Conroy and the DBCDE (hey, that could be the name of a band!) have released the results of the much-debated Clean Feed.

From the pretty performance graphs in the report, the filter doesn’t appear to be performing too badly. Implemented correctly, this filter could be put to use without a major impact on performance. However, that’s missing the point!

The point being that with the filter in place, it is basically equivalent to being wiretapped all day every day. Wiretapping in itself is not bad — it is sometimes plays an important role in solving crimes, or thwarting conspiracies. However, all wiretapping to date requires prior evidence of criminal activity, and a warrant is needed to perform it.

This “clean feed” is effectively wiretapping without a warrant. In other words, treating the general public like criminals. Guilty until proven innocent.

Once you establish that, how well the filter performs is a moot point. Admittedly, it is entirely possible BGP will be used so that only certain websites will be run through the filter (i.e. selective proxy). However, there is no guarantee that this technique will be used, and it is only a technical difference — the legislation to implement would be exactly the same. So the government could effectively change at will to monitoring all web traffic.

One quote I found interesting from the report:

Telstra reported that heavy traffic sites could overload its trial filtering solution if included in the filtering blacklist. This is also the case for all filters presented in the pilot.

So basically they are admitting the filter will be vulnerable to denial-of-service attacks. This could be exploited by criminals around the world with access to large botnets. Not only that, but a large amount of personal information is still transmitted over HTTP. Though unencrypted, the links between me and the website I am exchanging with are largely trusted. However, putting a filter in the middle that is explicitly designed to read the information suddenly makes the situation far scarier.

I also found no mention of IPv6 in the report. Because the trial has been reported to depend heavily on proprietary software, no mention of IPv6 is made, and of which it is common knowledge that proprietary software is more often than not lagging behind in cutting edge technologies, it is entirely likely that the filter will: (a) possibly hinder IPv6 adoption by ISPs, (b) cut off access to IPv6–enabled sites, or (c) be ineffective at blocking sites that are accessible via IPv6.

Tagged: , , , | 1 Comment »

Native IPv6 ADSL available from Internode

14 November 2009

Internode Logo

On Friday the 6th, Internode went public with the announcement of a native IPv6 trial for their customers. As a fan of IPv6, I’m particularly excited about this, especially seeing as though now Internode is the first ISP in Australia to offer native IPv6 (albeit in an opt-in trial form) to its residential customers.

I’m not going to bore you with details or a dodgy rehash, so I will instead invite you to read the announcement and the IPv6 ADSL Trial pages for yourself.

For those that like to dive in head-first without checking the depth or for the presence of sharp rocks, you can opt-in by changing the @internode.on.net part of your PPP username to @ipv6.internode.on.net.

I got it working on my own connection, and I am very impressed with the performance. The speed of my IPv6 connection is now no slower than my IPv4 connection (unlike connections that use tunnels to get v6 connectivity), and all users are allocated a static /60 subnet, which is absolutely the right way to implement it, in my opinion.

Internode supports up to 4 concurrent PPPoE connections on a single ADSL line, which is handy to know for testing. You can have your IPv4-only “production” connection, and a second IPv6-enabled “experimental” connection that you can play with and not worry about disrupting family members if it breaks. :)

Tagged: , , | 1 Comment »

Why dynamic IPv6 subnet allocations for home users are evil

23 June 2009

Currently, a typical home Internet user will be assigned one IP address from their ISP, and then use NAT (Network Address Translation) to share the Internet connection among all their computers. The IP address assigned by your ISP is dynamic, and that is not a problem for the average home user, or even your typical power user.

Setting static IPs on computers is not all that uncommon, even among home users, excluding only the very most technically-illiterate ones. For example, your home router might be 10.0.0.1, and the other desktops in your house might be 10.0.0.10, 10.0.0.11, and so on. Then, if somebody drops by and wants to use your WiFi, they might be assigned an address via DHCP, such as 10.0.0.121.

This won’t work in IPv6 if, and only if, ISPs choose to make your subnet allocation dynamic. I urge ISPs to assign static IPv6 subnets to all their customers.

Why? Well, let me give my reasons. In IPv4, all the home machines in the above example are behind a NAT. This means the private IP address (10.0.0.121) gets dynamically translated to your public IP address (123.12.134.78).

Because of the absence of NAT in IPv6, this can’t happen! Your machine’s IPv6 address is tied to the subnet allocated to you by the ISP. And if your ISP changes your subnet every time you connect to the Internet as they currently do with IPv4, your static IPs will break horrendously.

I am aware of site-local and unique local addresses. These addresses are designed to be used only in a local situation, and not routed to the Internet. In theory, this could solve the problem, by allowing you to have a static local address, and a dynamic global address. In practice, this will not work because:

  • Site-local addresses have been deprecated by RFC 3879.
  • Unique local addresses are considered to be global addresses by current OSes. Wikipedia says that “despite the restricted, local usage of these addresses, they have a global address scope”, which means that your computer will assume either one can get to the Internet.
  • Thus, your source IP may be wrong, and your packet may be filtered and rejected by your ISP, or you may never get a reply, as the message won’t be able to get back to you.
  • Having both unique local and global addresses are confusing to the end-user, unlike link-local addresses, which are clearly marked as such, and are generally non-routable.

Finally, we must look at the reason why dynamic IPv4 addresses are assigned in the first place. I believe the main reason for this is to conserve space. With most of their address space used up, ISPs would have to count on all of their customers not using their Internet connections at the same time. Dynamic IP addresses means they can effectively over-subscribe their puny IP allocations.

In IPv6, this is not necessary. ISPs typically get a /32 allocation, which if you’re not familiar with CIDR notation, is bleeping huge! With a /32 allocation, an ISP could allocate more than 4 billion /64 subnets (which are suitable for a typical household) to each of their customers. I don’t think any ISP in the world has 4 billion customers, and if they did, they could get a /31 allocation, which would give them about 8 billion /64 subnets. Plenty of space for static allocations for everyone!

In conclusion, I’d like to summarise what I’ve been trying to bring out:

  • People that like to set static IPs on their machines will have them break if their subnet changes.
  • Site-local and unique local addresses only add to the problem, not solve it.
  • There is enough IPv6 address space in a /32 for everybody to have a static subnet.
  • There is no business advantage in giving out dynamic subnets. Do the best thing by your customers and go static.

So, dear ISPs of the world, please make static IPv6 subnets a part of your standard offering — not a “paid upgrade” or anything silly like that. It might work in the NAT’ed world of IPv4, but you will do your IPv6 customers a disservice.

Thanks for reading. :)

Tagged: , , | 5 Comments »

Older Entries