[167142] in North American Network Operators' Group
Re: AT&T UVERSE Native IPv6, a HOWTO
daemon@ATHENA.MIT.EDU (Cutler James R)
Mon Dec 2 17:45:06 2013
From: Cutler James R <james.cutler@consultant.com>
In-Reply-To: <015701ceefab$e45513b0$acff3b10$@tndh.net>
Date: Mon, 2 Dec 2013 17:44:17 -0500
To: Tony Hain <alh-ietf@tndh.net>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
--Apple-Mail=_D9B04755-740F-4B1D-83A6-9C0D66593CEB
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=windows-1252
On Dec 2, 2013, at 5:14 PM, Tony Hain <alh-ietf@tndh.net> wrote:
> Ricky Beam wrote:
>> On Fri, 29 Nov 2013 08:39:59 -0500, Rob Seastrom <rs@seastrom.com>
>> wrote:
>>> So there really is no excuse on AT&T's part for the /60s on uverse
> 6rd...
>>=20
>> Except for a) greed ("we can *sell* larger slices") and b) =
demonstrable
> user
>> want/need.
>>=20
>> 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)
>>=20
>> 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.)
>>=20
>> 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.]
>=20
> 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.=20
>=20
> 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.=20
>=20
> 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.=20
>=20
> Tony
>=20
My kudos to Tony for an excellent summary. =20
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. =20
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 =
=93waste=94 of some integers which potentially will not affect us until =
2090 if at all.
James R. Cutler
james.cutler@consultant.com
--Apple-Mail=_D9B04755-740F-4B1D-83A6-9C0D66593CEB
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - http://gpgtools.org
iEYEARECAAYFAlKdDUEACgkQHzETiNcaVPmzXwCfUR0GoMJjgl4YH1/GE2jtF0No
uasAoJXV8iGsqpW5zmdm4tGXBSEjYvqK
=HPbZ
-----END PGP SIGNATURE-----
--Apple-Mail=_D9B04755-740F-4B1D-83A6-9C0D66593CEB--
