[182051] in North American Network Operators' Group
Re: Dual stack IPv6 for IPv4 depletion
daemon@ATHENA.MIT.EDU (Owen DeLong)
Thu Jul 9 18:12:34 2015
X-Original-To: nanog@nanog.org
From: Owen DeLong <owen@delong.com>
In-Reply-To: <9578293AE169674F9A048B2BC9A081B401C7097B15@MUNPRDMBXA1.medline.com>
Date: Thu, 9 Jul 2015 15:07:28 -0700
To: "Naslund, Steve" <SNaslund@medline.com>
Cc: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
Because vendor pressure depends on a userbase that knows enough to =
demand fixes.
Simple fact is that if most ISPs deploy degraded services, vendors will =
code to the lowest common denominator of that degraded service and =
we=E2=80=99ll all be forced to live within those limitations in the =
products we receive.
This is already evident in the IPv4 world. Even though my TiVO is 100% =
reachable from the internet, I can=E2=80=99t use any of TiVO=E2=80=99s =
applications to access it directly, I have to work through their proxy =
servers that depend on periodic polling from my devices to work because =
they assume everyone is stuck behind NAT.
Can you offer one valid reason not to give residential users /48s? Any =
benefit whatsoever?
Owen
> On Jul 9, 2015, at 14:51 , Naslund, Steve <SNaslund@medline.com> =
wrote:
>=20
> So, why not demand that firmware accepts ANY mask length just like =
VLSM v4. I don't see what possible difference it will make if it is a =
/56 or /48 and I don't think you should make ANY assumption based on =
either of those being correct for any particular application. An =
assumption you make today is only applicable to your network not mine, =
it has no certainty of permanence at all. If one of my software =
engineers came to me and asked I would tell them they need to handle all =
possible mask lengths...period. Even if they are not in common use =
today, if its legal under the v6 spec then you should expect to support =
it. Not engineering for change is how we end up with software that =
won't handle a 2xxx year or a leap second.
>=20
> If a vendor decides to code something like the ff02:: scoping into =
their systems in a way that can't easily change then it is at their own =
risk. Would it be very difficult to change that depending on the =
DHCP-PD response you got? Why do you want to be the guy to make the bad =
assumption instead of them? That's what you are doing in the /56 vs /48 =
argument is it not? A little early in the IPv6 game to be making =
permanent rules on allocation sizes for future generations and hard =
coding them don't you think?
>=20
> All of statements you make regarding "enable some development" and =
"reasonable end-site boundary" are the network equivalents of the "no =
one will need more that 640k of RAM" and "32 bits will be more addresses =
than we ever need"
>=20
> As far as opening up my mind a bit how about opening your mind and =
demanding that IPv6 compatibility means accepting ALL possible =
allocation lengths.
>=20
>=20
> Steven Naslund
> Chicago IL
>=20
>> Sigh=E2=80=A6
>>=20
>> Home gateways are an application in this context. How the firmware =
gets written in those things will be affected.
>>=20
>> Further, applications do care about things like =E2=80=9CCan I assume =
that every home is reachable in its entirety via a packet to =
ff02::<group>?=E2=80=9D which is, for example, already baked into many =
products as the current mDNS default scope.
>>=20
>> SSDPv6 also seems to default to ff02:: scoping.
>>=20
>> Whether or not applications come into existence that can take =
advantage of diverse topology in the home will depend entirely on =
whether or not we make diverse topology possible going forward.
>>=20
>> /56 will enable some development in this area, but it will hinder =
several potential areas of exploration.
>>=20
>> /48 is a reasonable end-site boundary. It allows enough flexibility =
for dynamic topologies while still leaving enough prefix space to have =
lots of extra room for sparse allocations and everything else.
>>=20
>> So, instead of focusing on the narrowest possible definition of =
=E2=80=9Capplication=E2=80=9D by todays terms, try opening your mind =
just a little bit and recognize that anything that requires software and =
interacts with the network in any way is a >better definition of =
application in this context.
>>=20
>> Owen
>=20
