[182067] in North American Network Operators' Group
Re: Dual stack IPv6 for IPv4 depletion
daemon@ATHENA.MIT.EDU (Laszlo Hanyecz)
Thu Jul 9 21:22:34 2015
X-Original-To: nanog@nanog.org
From: Laszlo Hanyecz <laszlo@heliacal.net>
In-Reply-To: <FD2B71BB-5343-4FE3-8E52-F9B2E87D28B5@delong.com>
Date: Fri, 10 Jul 2015 01:19:35 +0000
To: Owen DeLong <owen@delong.com>
Cc: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
On Jul 9, 2015, at 11:08 PM, Owen DeLong <owen@delong.com> wrote:
>=20
>> On Jul 9, 2015, at 15:55 , Ricky Beam <jfbeam@gmail.com> wrote:
>>=20
>> On Thu, 09 Jul 2015 18:23:29 -0400, Naslund, Steve =
<SNaslund@medline.com> wrote:
>>> That would be Tivo's fault wouldn't it.
>>=20
>> Partially, even mostly... it's based on Bonjour. That's why the shit =
doesn't work "over the internet".
>>=20
>> (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.)
>=20
> Correct=85 It _IS_ TiVO=92s fault. However, the reality I=92m trying =
to point out is that application developers make assumptions based
> on the commonly deployed environment that they expect in the world.
>=20
> If we create a limited environment, then that is what they will code =
to.
>=20
> 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.
>=20
> Owen
>=20
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
