[181898] in North American Network Operators' Group
Re: Dual stack IPv6 for IPv4 depletion
daemon@ATHENA.MIT.EDU (Mel Beckman)
Thu Jul 9 03:19:00 2015
X-Original-To: nanog@nanog.org
From: Mel Beckman <mel@beckman.org>
To: "Israel G. Lugo" <israel.lugo@lugosys.com>
Date: Thu, 9 Jul 2015 02:32:35 +0000
In-Reply-To: <559DDADD.7000606@lugosys.com>
Cc: NANOG <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
Israel,
You have to draw the limbs somewhere. Why not 512 bits? 1024? The IETF engi=
neers that thought about this long and hard and discussed the topic we've j=
ust had, and a thousands of other topics, decided on 128. I'm inclined to g=
ive them the benefit of the doubt. :)
-mel via cell
> On Jul 8, 2015, at 7:23 PM, Israel G. Lugo <israel.lugo@lugosys.com> wrot=
e:
>=20
>=20
>=20
>> On 07/09/2015 02:31 AM, Owen DeLong wrote:
>> Here=92s the problem=85 You started at the wrong end and worked in the w=
rong direction in your planning.
>>=20
>> [...get larger allocation...]
>>=20
>> We are now left with only 1,041,888 /20s remaining. You still haven=92t =
put a dent in it.
>=20
> I am aware of the math, and how it can fit. I will concede that a /20 is
> sufficient.
>=20
> Note, however, the difference in orders of magnitude for typical
> allocations. I realize in ARIN side you've got e.g. Comcast with
> multiple /20s, but in RIPE that is not so common. My home ISP has 3x
> /32s. As I said, default ISP/LIR allocation here is from /32 to /29.
> Yes, shorter prefixes can be justified and obtained, but it's not the nor=
m.
>=20
>=20
>> It=92s not=85 It=92s a great example of how not to plan your address spa=
ce in IPv6.
>>=20
>> However, if we repeat the same exercise in the correct direction, not on=
ly does each of your end-sites get a /48, you get the /20 you need in order=
to properly deploy your network. You get lots of space left over, and we s=
till don=92t make a dent in the IPv6 free pool. Everyone wins.
>=20
> You basically just said "get a larger allocation"... Which was my point
> all along. /32 is not enough, and even /24 could be made much roomier.
>=20
> Speaking of IPv6's full potential: we're considering 32 subscriptions
> per client. I've read people thinking of things like IPv6-aware soda
> cans. Refrigerators. Wearables. Cars and their internal components...
> You could have the on-board computer talking to the suspension via IPv6,
> and reporting back to the manufacturer or whatnot.
>=20
> Personally, I'm not particularly fond of the whole "refrigerators
> ordering milk bottles" craze, but hey, it may very well become a thing.
> And other stuff we haven't thought of yet.
>=20
> My point is: we're changing to a brand new protocol, and only now
> beginning to scratch its full potential. Yes, everything seems very big
> right now. Yes, 128 bits can be enough. Even 64 bits could be more than
> enough. But why limit ourselves? Someone decided (corretly) that 64
> would be too limiting.
>=20
> Please don't fall into the usual "you've got more addresses than
> atoms"... I've heard that, and am not disputing it. I'm not just talking
> about individual addresses (or /48's).
>=20
> What I am proposing here, as food for thought, is: what if we had e.g.
> 192 bits, or 256? For one, we could have much sparser allocations. Heck,
> we could even go as far as having a bit for each day of the month. What
> would this be good for? I don't know. Perhaps someone may come up with a
> use for it.
>=20
