On 10/27/2013 09:54 AM, Benedikt Stockebrand wrote:
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: 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.
that's the second time I read this in this thread. Why would this happen? All allocations are subject to RIR policy
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.
40 years from now? Many, more significant changes will probably overshadow this. Otherwise, 256 different policies in a home sound just fine
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... It's not just autoconfiguration, but when it comes to embedded system/microcontroller implementations, changing that is rather difficult.
care to elaborate on that?
* 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.
again, care to elaborate a bit? How's a /50 not compliant with RFC 4291?
Cheers, Benedikt
cheers, Yannis