Ricky Beam wrote: > On Fri, 29 Nov 2013 08:39:59 -0500, Rob Seastrom <r...@seastrom.com> > wrote: > > So there really is no excuse on AT&T's part for the /60s on uverse 6rd... > > Except for a) greed ("we can *sell* larger slices") and b) demonstrable user > want/need. > > How many residential, "home networks", have you seen with more than one > subnet? The typical household (esp Uverse) doesn't even customize the > provided router. Even a CCIE friend of mine has made ZERO changes to his > RG -- AT&T turned off WiFi and added the static block at install. (I know > NANOG is bad sample as we're all professionals and setup all kinds of weird > configurations at "home". I have 3 nets in continuous use... a legacy public > subnet from eons ago (I never renumbered), an RFC1918 subnet overlapping > that network (because it's too small), and a second RFC1918 net from a > second ISP) > > I wouldn't use the word "generous", but a /60 (16 "LAN"s) is way more than > what 99% of residential deployments will need for many years. We've > gotten by with a single, randomly changing, dynamic IP for decades. Until > routers come out-of-the-box setup for a dozen networks, non-networking > pros aren't going to need it, or even know that it's possible. (and the default > firewalling policy in Windows is going to confuse a lot of people when > machines start landing in different subnets can "see" each other.) > > Handing out /56's like Pez is just wasting address space -- someone *is* > paying for that space. Yes, it's waste; giving everyone 256 networks when > they're only ever likely to use one or two (or maybe four), is intentionally > wasting space you could've assigned to someone else. (or > **sold** to someone else :-)) IPv6 may be huge to the power of huge, but > it's still finite. People like you are repeating the same mistakes from the early > days of IPv4... the difference is, we won't be around when > people are cursing us for the way we mismanaged early allocations. > Indeed, a /64 is too little (aka "bare minimum") and far too restrictive, but it > works for most simple (default) setups today. Which leads to DHCPv6 PD... a > /60 is adequate -- it's the minimal space for the rare cases where multiple > nets are desirable or necessary. The option for /56 or even /48 should exist > (esp. for "business"), but the need for such large address spaces are an > EXCEPTION in residential settings. (and those are probably non-residential > users anyway.) [FWIW, HE.net does what they do as marketing. And it works, > btw.]
The rant above represents a braindead short-sighted thought process. If you focus on the past as justification for current actions, you guarantee that the future will always look exactly like the past. If you even hint at a /64 as the standard for residential deployment, you will find that all the CPE vendors will hard code that, and you will never get it undone when you change your mind. All because you stated up front that they will only ever need what they have been using in the past. You don't see multi-subnet residential today from the consumer viewpoint, but they do widely exist supporting deployment of "watch your dvr from any set-top", where a premise subnet handles that traffic off of the consumer lan. That one example is why there should NEVER be a /64, because you are already at 2 subnets that should be using the same shorter prefix. Trying to develop the automation necessary for consumer plug-n-play subnets shows that even a /56 is virtually unusable. A /55 makes more sense for a topology with moderate constraints, but if you are already shorter than a 56, it doesn't make sense to stop there. This is a hard concept for "professional network engineers", because their market place value is based on the ability to efficiently manage topologies to fit within address resource constraints. Consumers have no desire to understand the technology, they just want to plug stuff together and have it sort out what it needs to do. That unconstrained topology coupled with unmanaged device automation requires excess address resource. YES THAT IS A WASTE. But having the address space sitting on the shelf at IANA when someone comes along with a better idea in the next few hundred years is also a waste. Get over it, the address space excessively larger than we will ever deploy so it is wasted ... The only open issue is how we utilize the resource until the next thing comes along. If it sits on the shelf, you constrain innovation. If you 'waste it' by deploying it before people can really use it, you piss-off the existing engineering staff. From my perspective, the latter will die off, but stifling innovation robs future generations of capabilities they could/should have had to make the world a better place. Tony