On Jul 9, 2015, at 11:08 PM, Owen DeLong <o...@delong.com> wrote: > >> On Jul 9, 2015, at 15:55 , Ricky Beam <jfb...@gmail.com> wrote: >> >> On Thu, 09 Jul 2015 18:23:29 -0400, Naslund, Steve <snasl...@medline.com> >> wrote: >>> That would be Tivo's fault wouldn't it. >> >> Partially, even mostly... it's based on Bonjour. That's why the shit doesn't >> work "over the internet". >> >> (It's just http/https, so it will, in fact, work, but their apps aren't >> designed to work that way. Many 3rd party control apps have no problems.) > > Correct… It _IS_ TiVO’s fault. However, the reality I’m trying to point out > is that application developers make assumptions based > on the commonly deployed environment that they expect in the world. > > If we create a limited environment, then that is what they will code to. > > If we deliver /48s, then they will come up with innovative ways to make use > of those deployments. If we deliver /56s, then innovation will be constrained > to what can be delivered to /56s, even for sites that have /48s. > > Owen >
I would love to see things go Owen's way.. /48s everywhere, everyone agrees it's a good idea, and we can just assume that it will work. We can move on, this is one less thing to stress about. On the other hand, I do wonder how this will work, even if most people are getting /48s. Perhaps in a few years we'll be past all this, and there will be a well accepted standard way. Maybe it will be RIPng. Maybe some thing that we haven't seen yet. Or maybe there will be 800 ways of doing it, because the protocol spec allows that, and so we should complicate our lives further by requiring everyone to support every possibility of combinations. This is the worst possible outcome because it means unnecessary complexity, more work for everyone involved, and less reliability. If you're writing an application, do you bother supporting /48, /56, RA, DHCP, etc, while also supporting an https polling mechanism for the times when none of that stuff works? We can pretend that it doesn't matter and that software should 'just work' with any network, but that's simply not possible for many applications. I think as an application developer, you're much better off aiming for the least common denominator, accepting the limitations of that, and just moving on. This means polling, reflectors, NAT, proxyarp, etc. Things that you can control, to make your app work. Supporting a bunch of different ways is a waste of everyone's time and just makes your application less reliable and harder to test. Unless your specific application benefits greatly from a more capable network, it's probably not worth even thinking about, as long as you know that you will still have to support the 'bad' ones. A music streaming application can use a hardcoded well known server name to access a centralized service. It can even communicate with other users by using that central server as a database or reflector. It would be 'nice' if it could ask the network for a prefix and use a different address for each peer it talks to, but what's the point in developing that, if you still have to support the other case? A wifi hotspot device would benefit from prefix delegation, but it could of course use NAT or proxying without the cooperation of the network. This is one application where it might be worth supporting all the different combinations, but it means that all those different methods need to be tested, and they can break in different ways, and there's no way to be sure it's right. Choice is good, you can run your own network any way you want, etc, but it's not good when people are making choices just for the sake of being different and incompatible. After all, the point of the internet is to communicate with everyone else, which means we all need to agree on how we will communicate. How can we expect everyone to embrace IPv6 if we can't even provide a straightforward procedure to get connected to it? -Laszlo
