[182030] in North American Network Operators' Group
Re: Dual stack IPv6 for IPv4 depletion
daemon@ATHENA.MIT.EDU (Owen DeLong)
Thu Jul 9 16:05:13 2015
X-Original-To: nanog@nanog.org
From: Owen DeLong <owen@delong.com>
In-Reply-To: <9578293AE169674F9A048B2BC9A081B401C70977FD@MUNPRDMBXA1.medline.com>
Date: Thu, 9 Jul 2015 13:05:03 -0700
To: "Naslund, Steve" <SNaslund@medline.com>
Cc: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
In short, much of what you say below has been discussed before and with =
the general conclusion =E2=80=9Cgeography !=3D topology and no, =
geographic allocation would not improve summarization=E2=80=9D.
I=E2=80=99m not saying that assignments need to be static, but I am =
saying that we need to put the default size somewhere that doesn=E2=80=99t=
inhibit future development and close off options at the application =
level.
That=E2=80=99s why I=E2=80=99m arguing for a default /48.
Owen
> On Jul 9, 2015, at 12:24 , Naslund, Steve <SNaslund@medline.com> =
wrote:
>=20
> Seems to me that the problem might be thinking that the allocation =
toward the customer is a static thing. I think it is limiting to think =
that was going forward. Our industry created DHCP so we didn't have to =
deal with statically configured users who did not want to deal with IP =
addressing. Seems to me that a natural progression is to hand a network =
block to the CPE (DHCP-PD) and let it deal with it. No reason a CPE =
device cannot be created that will request more addresses when it needs =
them and dynamically receive a larger assignment.
>=20
> When you think about it long term our network infrastructure is pretty =
archaic in that we have to do paperwork to get an block assignment from =
the regional numbering authority and then manually chop that up. I =
would expect that model to die over time and become more of a hierarchy =
whereby addresses are dynamically assigned top to bottom. Seems like =
the numbering authority could be a lot more effective if a network could =
tell them about its utilization and have additional addresses =
assignments happen automatically. The converse would be true as well, a =
network could reconfigure to free underutilized blocks on its own. If a =
customer CPE needs more addresses it will request them. If you add a =
pop to your network it should automatically get an allocation from an =
upstream device.
>=20
> The only reason why anyone cares what their address is results from =
the fact that our name to address mapping via DNS is so slow to update. =
The end user does not care what addresses they get as long as everyone =
can reach what they need to. Your customers would not care about =
renumbering pain if there wasn't any. Today they could care less if it =
is V4 or V6 as long as everyone can see each other. My dad gets V6 on =
his cell phone and he can't even spell IP.
>=20
> Another inefficient legacy is the assignment of address space on a =
service provider basis when geographic assignment would allow for better =
summarization. If that happened you could create a better model where =
less routers need to carry a "full table" view of the Internet. As long =
as I know how to get around my area and to regional routers that can =
reach out globally, that is all we need. Now you would not have the =
limitation that a wide variety of routers need to carry every route and =
the /64 routing limitation goes away. Today our routing is very much =
all or nothing. Either use defaults or get a whole table via are =
probably the two most common options (yeah, I know there are others but =
those are the main two).
>=20
> The ideas on the reasons for building VLANs is pretty out of date too. =
It drives me nuts when I see the usual books giving you the usual =
example that "accounting and their server are on one VLAN and =
engineering and their server are on another VLAN" and that this is for =
performance and security reasons. Some of the biggest vendors in the =
business use examples like this (yes, Cisco, I'm looking at you) and it =
just does not work that way in the real world. Who gets to what server =
is most often decided by the server (AD membership or group policy of =
some type). If the accounting and engineering department are both going =
to a cloud service VLAN separation is pretty moot. In a world where my =
refrigerator wants to talk to the power company and send a shopping list =
to my car, VLAN based security is not really a solution. In the =
"Internet of things" we keep hearing about, everything is talking to =
everything. Security is highly dependent in that world on a device =
defending itself and not relying on a VLAN boundary. =46rom what I am =
seeing out there today, there are usually far too many VLANs and too =
much layer three going on in most large networks.
>=20
> In the future it would seem that systems would create their own little =
networks ad-hoc as needed for the best efficiency. I know this is not =
all out there today but planning address allocation 10 years down the =
road might be an exercise in futility. I would suggest plan for today =
and build it so you can easily change it when your prediction invariably =
prove wrong or short-sighted.
>=20
> Steven Naslund
> Chicago IL
>=20
>=20
>=20
>>> On Jul 9, 2015, at 09:16 , Matthew Huff <mhuff@ox.com> wrote:
>>>=20
>>> When I see a car that needs a /56 subnet then I=E2=80=99ll take your =
use case seriously. Otherwise, it=E2=80=99s just plain laughable. Yes, I =
could theorize a use case for this, but then I could theorize that =
someday everyone will get to work >>using jetpacks.
>=20
>> When I see a reason not to give out /48s, I might start taking your =
argument seriously.
>=20
>>> We have prefix delegation already via DHCP-PD, but some in the IPv6 =
world don=E2=80=99t even want to support DHCP, how does SLAAC do prefix =
delegation, or am I missing something else? I assume each car is going =
to be running as RA? Given quality of implementations of IPv6 in =
embedded devices so far, I found that pretty ludicrous.
>=20
> Clearly the quality of IPv6 in embedded devices needs to improve. =
There=E2=80=99s clearly work being done on LWIP IPv6, but I don=E2=80=99t =
think it=E2=80=99s ready for prime time yet. (LWIP is one of the most =
popular embedded IP stacks. You=E2=80=99ll find it in a wide range of =
devices, including, but not limited to the ESP8266).
>=20
>>> Seriously, the IPv6 world needs to get a clue. Creating new =
protocols and solutions at this point in the game is only making it more =
difficult for IPv6 deployment, not less. IPv6 needs to stabilize and get =
going.. instead it seems everyone is musing about theoretical world =
where users need 64k networks. I understand the idea of not wanting to =
not think things through, but IPv6 is how many years old, and we are =
still arguing about these things? Don=E2=80=99t let the prefect be the =
enemy of the good.
>=20
> /48s for end sites are NOT new=E2=80=A6 They have been part of the =
IPv6 design criteria from about the same time 128-bit addresses were =
decided. It is these silly IPv4-think notions of /56 and /60 that are =
new changes to the protocol.
>=20
> The good news is that it=E2=80=99s very easy to deploy /48s and if it =
turns out we were wrong, virtually everyone currently advocating /48s =
will happily help you get more restrictive allocation policies when =
2000::/3 runs out. (assuming any of us are still alive when that =
happens).
>=20
>=20
> Owen
>=20
