AT&T UVERSE Native IPv6, a HOWTO

Mon Dec 2 22:14:38 UTC 2013

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