Re: Dual stack IPv6 for IPv4 depletion

[Laszlo Hanyecz <laszlo () heliacal net>]

On Jul 9, 2015, at 11:08 PM, Owen DeLong <owen () delong com> wrote:

> > On Jul 9, 2015, at 15:55 , Ricky Beam <jfbeam () gmail com> wrote:
> >
> > On Thu, 09 Jul 2015 18:23:29 -0400, Naslund, Steve <SNaslund () 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