Hi Yannis and list, Yannis Nikolopoulos <dez@otenet.gr> writes:
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
yes, but policies can be circumvented, lobbied out of the way or overridden by legislation, as was effectively the case with the Nortel/Microsoft deal, among others. There used to be a policy that IP addresses can't be traded. Take a look at the recordings from the RIPE meeting last week to see what happens right now.
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
According to Bob Kahn with exactly the same reasoning the original 6 bit addresses in the Arpanet were widely ridiculed; pretty much the same happened again again when they went straight for 32 bit addresses in IPv4 (which was pretty much exactly the 40 years I mentioned ago, so that's where I got that number from). If you plan for future networks by today's demands, without taking into account either some future growth nor some imminent or at least apparent developments, like the currrent growth of networked embedded systems, you won't make it through even the next ten years. And considering the time it took for IPv6 to take off, even if we started on developing its successor today, we'd have to live with IPv6 for another 25 years or more; IPv4 will likely last another five years, making it a total lifetime of 45 years. We might as well accept that whatever we do today will haunt us at that long as well.
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?
Yes, but I'd rather do that in a separate thread/with a new subject...
* 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?
Yes. If somebody decides to remove support for a configurable subnet prefix length, based on the fact that the RFCs mentioned below don't allow anything but a /64 as subnet prefix, an upgrade of a system with a differently configured subnet prefix will blow up in your face. If this happens because of a security hole, this leaves you the choice of either running the vulnerable old version, or taking a (production) system down until you've sorted out your network setup. There are at least two valid reasons to remove support for a configurable subnet prefix length: It adds overhead to the implementation (again, this is particularly troublesome with microcontrollers) and it is yet another option to frustrate end users. As far as your possible successors as sysadmin/netadmin are concerned: If somebody in some not-so-far-away future inherits the systems you have set up and has to handle them, doing something that is not covered by specifications but happens to work with some implementations, this is quite likely to blow up in their faces---and your (former) company's, since this is likely to cost noticeable money. Yes, I've been down that road in several slightly different contexts, and thinking of the trouble it caused I consider these sorts of time bombs reason enough to sack whoever set them up. And no, sorry, I can't provide any more details, except maybe that with BIND4 it was possible to put periods in DNS labels... As far as end users are concerned: When it comes to systems that are operated by end users who don't understand---and shouldn't need to understand---the internals of the stuff they use, every single configuration options is something that at best adds, or rather multiplies, to the number of options they have to try to get things up and running. This is bad for the end user as well as the vendor of the gear, so minimizing the number of configurables is actually one of the key measures to keep non-professional end users happy.
How's a /50 not compliant with RFC 4291?
(One of these days I'll actually make that into a separate three-page RFC, so people who won't or can't read 4291 can be referred to that...) RFC 4291, page 8, section 2.5.1, for all unicast addresses except those starting with 000b, which is currently :: and ::1, and again in RFC 4291, page 10, section 2.5.4 (for global unicast addresses) RFC 4291, page 11, section 2.5.6 (for link-local unicast addresses) RFC 4193, page 3, section 3.1 (for unique-local unicast addresses) Cheers, Benedikt -- Business Grade IPv6 Consulting, Training, Projects Benedikt Stockebrand, Dipl.-Inform. http://www.stepladder-it.com/