Re: Dual stack IPv6 for IPv4 depletion

[Owen DeLong <owen () delong com>]

In short, much of what you say below has been discussed before and with the general conclusion “geography != topology 
and no, geographic allocation would not improve summarization”.

I’m not saying that assignments need to be static, but I am saying that we need to put the default size somewhere that 
doesn’t inhibit future development and close off options at the application level.

That’s why I’m arguing for a default /48.

Owen

> On Jul 9, 2015, at 12:24 , Naslund, Steve <SNaslund () medline com> wrote:
>
> 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.
>
> 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.
>
> 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.
>
> 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).
>
> 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.  From 
> 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.
>
> 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.
>
> Steven Naslund
> Chicago IL
>
>
>
> > > On Jul 9, 2015, at 09:16 , Matthew Huff <mhuff () ox com> wrote:
> > >
> > > When I see a car that needs a /56 subnet then I’ll take your use case seriously. Otherwise, it’s 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.
>
> > When I see a reason not to give out /48s, I might start taking your argument seriously.
>
> > > We have prefix delegation already via DHCP-PD, but some in the IPv6 world don’t 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.
>
> Clearly the quality of IPv6 in embedded devices needs to improve. There’s clearly work being done on LWIP IPv6, but I 
> don’t think it’s ready for prime time yet. (LWIP is one of the most popular embedded IP stacks. You’ll find it in a 
> wide range of devices, including, but not limited to the ESP8266).
>
> > > 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’t let the prefect be the enemy of the good.
>
> /48s for end sites are NOT new… 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.
>
> The good news is that it’s 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).
>
>
> Owen