AT&T UVERSE Native IPv6, a HOWTO

Mon Dec 2 22:44:17 UTC 2013

On Dec 2, 2013, at 5:14 PM, Tony Hain <alh-ietf at tndh.net> wrote:

> Ricky Beam wrote:
>> On Fri, 29 Nov 2013 08:39:59 -0500, Rob Seastrom <rs at 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
> 

My kudos to Tony for an excellent summary.  

The only thing he missed is the tremendous waste of people resources involved in micro-managing address assignments.  Those who cannot learn from history are condemned to repeat it.  The available IPv6 address space, even constrained to /64 as a maximum prefix, is far beyond concern for decades.  

In addition, really intelligent network service providers calculate the budget for personnel to micro-manage address space. For example, a provider that by default uses a /64 for the CPE WAN link and a separate DHCP-PD assignment for customer networks will almost never have to revisit the issue, but has the flexibility to do so as needed.  And, the lazy user, as cited above, will receive a working network without special effort.

So just do the cost-benefit analysis including business office, deployment, and operations personnel and systems versus a purported “waste” of some integers which potentially will not affect us until 2090 if at all.

James R. Cutler
james.cutler at consultant.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 243 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20131202/3a72e3de/attachment.sig>