[182074] in North American Network Operators' Group
Re: Dual stack IPv6 for IPv4 depletion
daemon@ATHENA.MIT.EDU (Owen DeLong)
Thu Jul 9 22:15:04 2015
X-Original-To: nanog@nanog.org
From: Owen DeLong <owen@delong.com>
In-Reply-To: <C42A61CC-E3D4-48AF-A743-5F1287508DB6@heliacal.net>
Date: Thu, 9 Jul 2015 19:14:17 -0700
To: Laszlo Hanyecz <laszlo@heliacal.net>
Cc: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
> On Jul 9, 2015, at 18:19 , Laszlo Hanyecz <laszlo@heliacal.net> wrote:
>=20
> On Jul 9, 2015, at 11:08 PM, Owen DeLong <owen@delong.com> wrote:
>=20
>>=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
>=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.
>=20
> 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.
>=20
> 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.
Which is why I=92m arguing that we should try not to implement the bad =
ones in IPv6.
> 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?
Will you always have to support that case? Do you really want to say =
that the current state of IPv4 should drive all development decisions =
for all future products?
> 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.
>=20
> 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?
This is all true. Seems to me DHCP-PD receiving a /48 from upstream is a =
pretty straightforward approach. Dynamic topologies inside the home =
still require some development work, but any router ought to be able to =
accept a /48 and assign /64s to the local-facing port(s) fairly easily.
Owen
