[175076] in North American Network Operators' Group
Re: IPv6 Default Allocation - What size allocation are you giving out
daemon@ATHENA.MIT.EDU (Hugo Slabbert)
Thu Oct 9 01:12:31 2014
X-Original-To: nanog@nanog.org
Date: Wed, 8 Oct 2014 22:06:23 -0700
From: Hugo Slabbert <hugo@slabnet.com>
To: Mark Andrews <marka@isc.org>
In-Reply-To: <20141009044007.A75E6212E0D1@rock.dv.isc.org>
Cc: NANOG <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
--IrhDeMKUP4DT/M7F
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Mark,
>> >Only short sighted ISP's hand out /56's to residential customers.
>>
>> I am curious as to why you say it is short sighted? what is the technica=
l or
>> otherwise any other reasoning for such statement ?
>
>256 is *not* a big number of subnets. By restricting the number
>of subnets residences get you restrict what developers will design
>for. Subnets don't need to be scares resource. ISP's that default to
>/56 are making them a scares resource.
The excerpt Royce quoted from RFC6177 (requoted below) seems to back away=
=20
=66rom /48s by default to all resi users and land in a somewhat vague "more=
=20
than a /64 please, but we're not specifically recommending /48s across the=
=20
board for residential" before specifically mentioning /56 assignments.
The general push in the community is towards /48 across the board. Any=20
comments on why the RFC backs away from that? Is this just throwing a bone=
=20
to the masses complaining about "waste"?
btw: hat tip to Peter Rocca for a kind of scale we're talking about for=20
allocatable space.
--
Hugo
>Quoting RFC6177 (successor to RFC3177):
>
> While the /48 recommendation does simplify address space management
> for end sites, it has also been widely criticized as being wasteful.
> For example, a large business (which may have thousands of employees)
> would, by default, receive the same amount of address space as a home
> user, who today typically has a single (or small number of) LAN and a
> small number of devices (dozens or less). While it seems likely that
> the size of a typical home network will grow over the next few
> decades, it is hard to argue that home sites will make use of 65K
> subnets within the foreseeable future. At the same time, it might be
> tempting to give home sites a single /64, since that is already
> significantly more address space compared with today's IPv4 practice.
> However, this precludes the expectation that even home sites will
> grow to support multiple subnets going forward. Hence, it is
> strongly intended that even home sites be given multiple subnets
> worth of space, by default. Hence, this document still recommends
> giving home sites significantly more than a single /64, but does not
> recommend that every home site be given a /48 either.
>
> A change in policy (such as above) would have a significant impact on
> address consumption projections and the expected longevity for IPv6.
> For example, changing the default assignment from a /48 to /56 (for
> the vast majority of end sites, e.g., home sites) would result in a
> savings of up to 8 bits, reducing the "total projected address
> consumption" by (up to) 8 bits or two orders of magnitude. (The
> exact amount of savings depends on the relative number of home users
> compared with the number of larger sites.)
>
> The above-mentioned goals of RFC 3177 can easily be met by giving
> home users a default assignment of less than /48, such as a /56.
--IrhDeMKUP4DT/M7F
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAEBCgAGBQJUNhfPAAoJEJqxD/2xeDE+EHAQAInCCrynf93ECHH90KXTWlt6
9/uj6t2uIvCyUNfVBNyaCOOk5n8a2TzTW/VEGw0/v4hS6beO7Le6zww3B8ZIbt+4
4Wedn2traS/fdtZDfv+6VUu59QUHVr55z8LU8u8Ynyrjloaa72YTJ0H6mfNaiUEb
twWcWhERomS76qkxlvA2eOkmNqr2Ul7BLiC3mk/YHblbd7vWcRxMZrkdg3xk7C3Y
PtQvP1pmyXdyh5YYLMqbNthUKfYGPyEimPJBzYy1pw2VhbT4WRkdztyWCTADobiY
i1+705uD29iiImy4Te29+xIrwGceIFQXAyvHLnK8EJlRdkJMUXp/7Nwumg2KfJiL
3nyB2ciT1uxwmpmJ/nkgg8V5RgQaMRyEkQZPlbZ+eLvbmkTP1HUxT0QR1kU7Cys/
KOvwaAj1ClFLK6dXGvBEfIX8USH8LIdwapuSPYdE6NVIzUzJJa5a/WqXBf4zEMww
sfBueyUS9SfbcAzCaBRxx78uaHfW99CGCZYaNR4u/cICOVfJzG8nYjbWtBuOzAKp
26YrM69IOLgOlDVvov+TY1bjm797KfXEX1CJ/RBZPnBUGCf/0yFxQlXvn6BwLpVG
LjGR1nqmET7QU2ONfgJvfdOCEksTQ+hgWd0kCO5J3c9p6qEkfSteQ/vB0ip2B3p2
SOAOvDCpVhRwLi4dMM6N
=Hhp/
-----END PGP SIGNATURE-----
--IrhDeMKUP4DT/M7F--
