Hi Roger and list, On Fri, Roger Jørgensen <rogerj@gmail.com> writes:
Oct 25, 2013 at 5:24 PM, Benedikt Stockebrand <bs@stepladder-it.com> wrote:
[...] More important however is the question how to deal with them if /when they show up because they have unnecessarily "depleted" their address assignment thanks to encoding stuff in it. [...] If they run out due to size and growth, and they haven't wasted space, used their available /29 wisely by every advice given...give them another prefix.
That's what I meant by "unnecessarily 'depleted'". If they actually grow beyond their /29 or whatever, let them have another prefix. What I wouldn't want to see however is that some big player gets some extra address space because they wasted their existing one. Once that happens, everyone will demand the same. And yes, I've had these discussions. In particular, the idea to bit-encode the services (i.e. significant port numbers) somewhere in the subnet prefix. Eventually these people decided "well, we have a /12 for IPv4, so it's only fair we also get a /12 for IPv6". At that point I pretty much gave up and told them to request that from their RIR...
One way to waste is to give every single customer a /48 when you are really really big. /56 work just fine really, even for techies like me :)
Sorry, but I disagree on that. A /56 is fine for today's requirements, but if this hype about the "Internet of Things" really takes off and you want to put things into different subnets, a /56 may occasionally be a problem even for consumer households. Not today, but think anything from ten to fourty years.
However IPv6 is big enough that most people will not feel any pain with it, some however will start to get into trouble in 5-10years time, guess more like around in 7 years. The reason? They made a too static model on how they wanted to use their available space.
Agreed, but...
But you have to be big to get into that trouble.
I don't see any reason why size has to do with it. The problem is more of a ratio between size and allocated address space---and the technical knowledge around. (And no, unlike somebody else on this list I don't believe it feasible for a consumer to call in a CCIE every time they need some networked deviced hooked up.)
There was major discussion just to get that /56 into the documents. Upto that point there was /64 pr.LAN, /48 for the rest. Now we're relaxing it even more. Are discussion on moving away from /64's on the wire to...
If /64 is given up, all sorts of shit will happen. It has been part of the specs for long enough that a number of implementations will rely on it. It's not just autoconfiguration, but when it comes to embedded system/microcontroller implementations, changing that is rather difficult. Additionally, anything that can be (mis-)configured exponentially adds (or rather, multiplies) to the frustration potential for end users.
Doesn't this sound like A/B/C-class network vs CIDR?
You mean VLSM, I assume?
* For one server running in the cloud I got a /112, that work just fine really.
...until you do an upgrade on the server that relies on RFC 4291.
* Somewhere else I'm using a /50 on the wire, that also work just fine.
Same issue. Yes, at least some implementations support that right now, but you shouldn't rely on that. Additionally, for whoever may have to run that system further later on you set up some ugly surprise that way.
* I have tried to use an entire /48 but failed. I tried to build my own network with VPN, routings and everything across the different servers and routers I have spread around. That /48 was big enough for me:)
Oha. So you have too many machines to fit into a /64 in a single subnet?
* I tried to build a big routed, multisite network using a /56, that also worked upto a certain size :)
Sorry, I don't get what you want to say there. Cheers, Benedikt -- Business Grade IPv6 Consulting, Training, Projects Benedikt Stockebrand, Dipl.-Inform. http://www.stepladder-it.com/