[166017] in North American Network Operators' Group
Re: minimum IPv6 announcement size
daemon@ATHENA.MIT.EDU (Cutler James R)
Tue Oct 1 16:45:51 2013
From: Cutler James R <james.cutler@consultant.com>
In-Reply-To: <7DE298C0-996D-4081-AF25-6498DDA7F141@delong.com>
Date: Tue, 1 Oct 2013 16:45:09 -0400
To: Owen DeLong <owen@delong.com>
Cc: Ryan McIntosh <rmcintosh@nitemare.net>, NANOG <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
I try not to think about sinners too much when planning networks. =
Subnets are more interesting.
Maybe many of you like spending time maintaining NAT configurations and =
creatively masking as determined by today's end system count on each =
subnet. This all, of course, in the interest of maximum address =
assignment efficiency, a term of only the most nebulous definition.
Hogwash, I say. The days of counting end systems in order to determine =
addressing is GONE. And I, for one, am much pleased.
Let's optimize the person instead of micro-optimizing bits. Count the =
subnets you really think you need, shift one or two bits left, and ask =
for /whatever as described by Owen. "many many years" is probably =
multiples of the two decades or so of IPv4 we have experienced.
Continuing arguments on NANOG and elsewhere about /64 - Good or Bad - =
check one, are just wasting your time and mine. Get yourself into action =
and just get IPv6 deployed. =20
Owen has the right of it.
Cutler
On Oct 1, 2013, at 4:20 PM, Owen DeLong <owen@delong.com> wrote:
> The original plan was to go from 32 to 64 bits total. The additional =
64 bits were added purely for the sake of EUI-64 based addressing, and =
really, 64 bits of network number is way more than enough.=20
>=20
> The /64 a are not what justify the larger blocks. That's IPv4 think.=20=
>=20
> In IPv6, it is far better to think about the number of sinners without =
regard to counting hosts. The /48 per site is justified because it is =
almost inconceivable that a single site would ever need more than 65536 =
subnets.=20
>=20
> The /32 is a minimum reasonable allocation for an ISP to balance the =
tradeoff between routing table entries and consumption.=20
>=20
> Most estimates say that the vast majority of significant providers =
will end up using a /28 with some outliers on both sides. Many smaller =
providers will end up with /32 and a few medium to large ones will get =
/24 or even /20. A minute (probably less than 20 world wide) number =
might get /16s.=20
>=20
> Absent some novel (and IMHO I'll-advised) approach to semantic =
overloading, we will have plenty of address space to number the internet =
for many many years.=20
>=20
> Owen
>=20
>=20
>> On Oct 1, 2013, at 12:11, Ryan McIntosh <rmcintosh@nitemare.net> =
wrote:
>>=20
>> I'd love to be able to turn the microwave and oven on with my phone..
>> maybe ten years from now lol..
>>=20
>> In all seriousness though (and after skimming some of the other
>> responses), I absolutely understand the ideals and needs amongst
>> conserving memory on our routers for the sake of the future of bgp =
and
>> internal routing. The problem I described has nothing to do with that
>> however, I was mearly pointing out the fact that the basis of the
>> larger allocations are based upon the fact we're handing over /64's =
to
>> each vlan/point to point/lan/etc that we're turning up. In practice, =
I
>> understand, a /64 means that 64 bits can handle a unique ip for every
>> host without having to worry about numbering them, but how many hosts
>> do we truly think will be sitting on one network? Surely not a /64's
>> worth, that alone would cause havoc on a neighbor table's maximum
>> memory limit. Maybe I'm missing the connection here, but I still =
don't
>> see how a /64 is justified for each individual user/host/server/etc
>> sitting on the edge of the internet that's getting ip's from an
>> upstream provider (not arin/ripe/etc).
>>=20
>> It's those smaller blocks that justify handing over larger ones, =
which
>> I do understand there's plenty of, but how long are we going to patch
>> the same problem and not try to fix it right?
>>=20
>> Ryan
>>=20
>>> On Mon, Sep 30, 2013 at 8:37 PM, Larry Sheldon =
<LarrySheldon@cox.net> wrote:
>>>> On 9/27/2013 1:10 AM, Ryan McIntosh wrote:
>>>>=20
>>>> I don't respond to many of these threads but I have to say I've
>>>> contested this one too only to have to beaten into my head that a =
/64
>>>> is "appropriate".. it still hasn't stuck, but unfortunately rfc's =
for
>>>> other protocols depend on the blocks to now be a /64..
>>>>=20
>>>> It's a waste, even if we're "planning for the future", no one house
>>>> needs a /64 sitting on their lan.. or at least none I can sensibly
>>>> think of o_O.
>>>=20
>>>=20
>>>=20
>>> Are you accounting for connections to your refrigerator, water =
heater,
>>> razor, vibrator, and on down to list so the gubermint can tell they =
when you
>>> can use power for them?
>>>=20
>>> --
>>> Requiescas in pace o email Two identifying characteristics
>>> of System Administrators:
>>> Ex turpi causa non oritur actio Infallibility, and the ability =
to
>>> learn from their mistakes.
>>> (Adapted from Stephen =
Pinker)
>>>=20
>=20
