[181973] in North American Network Operators' Group
Re: Dual stack IPv6 for IPv4 depletion
daemon@ATHENA.MIT.EDU (Owen DeLong)
Thu Jul 9 04:17:34 2015
X-Original-To: nanog@nanog.org
From: Owen DeLong <owen@delong.com>
In-Reply-To: <559DDADD.7000606@lugosys.com>
Date: Thu, 9 Jul 2015 01:17:19 -0700
To: "Israel G. Lugo" <israel.lugo@lugosys.com>
Cc: NANOG <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
> On Jul 8, 2015, at 19:22 , Israel G. Lugo <israel.lugo@lugosys.com> =
wrote:
>=20
>=20
>=20
> On 07/09/2015 02:31 AM, Owen DeLong wrote:
>> Here=E2=80=99s the problem=E2=80=A6 You started at the wrong end and =
worked in the wrong direction in your planning.
>>=20
>> [...get larger allocation...]
>>=20
>> We are now left with only 1,041,888 /20s remaining. You still =
haven=E2=80=99t 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 =
norm.
Poor allocation practice and/or policy in RIPE is something that should =
be solved through education and policy change where needed.
The fact that such is apparently commonplace in RIPE is probably an =
artifact of the RIPE region having deployed IPv6 a bit ahead of much of =
the world. In part, it=E2=80=99s probably cultural artifact.
In any case, since there=E2=80=99s still a lot of networks that =
haven=E2=80=99t really deployed IPv6, let=E2=80=99s stop teaching bad =
ways to do things and focus on doing better going forward.
>=20
>=20
>> It=E2=80=99s not=E2=80=A6 It=E2=80=99s a great example of how not to =
plan your address space in IPv6.
>>=20
>> However, if we repeat the same exercise in the correct direction, not =
only 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 still don=E2=80=99t 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.
Sure=E2=80=A6 And if you need larger allocations, they should be very =
easy to get.
I haven=E2=80=99t yet built anything that needed more than a /24. =
However, I have now obtained 3 /24s from ARIN for 3 different networks =
and not had significant difficulty with any of the 3.
> 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.
Yes, but each of those wouldn=E2=80=99t require its own =
subscription/network. Most of those things would aggregate into one or =
more of your wireless networks. By subscriptions, I was literally =
talking about different ISP connections. 32 is massive overkill=E2=80=A6 =
Very few people today have more than 5.
Each cellular device is essentially one since there=E2=80=99s no real =
local aggregation available. However, everything on the wired and =
wireless networks in your home would probably share a single attachment. =
Your car might be its own attachment or might use one or more of your =
cellular attachments. Your soda cans, refrigerators, wearables, etc. =
would most likely use one of your fixed or mobile attachments.
> 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.
What I think will become more common than refrigerators ordering things =
is refrigerators providing inventory management capabilities (including =
load cells in the shelves that work with positional RFID sensors so that =
you not only know that you have 3 bottles of milk in the fridge, but =
can tell where in the fridge and how much in each bottle).
Zap a QR-Code for a recipe with your cell phone, and the fridge checks =
in with the cabinets and sends back a list of what you need to buy vs. =
what you already have in inventory.
> 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.
The additional consumptions you=E2=80=99re talking about all fit within =
the model I described. You=E2=80=99re either expanding the number of =
things in the house that are hosts or you=E2=80=99re expanding the =
number of hosts attached to one of the mobile attach points. I used 32 =
attach points per person on the planet with the full population of =
planet earth to be deliberately conservative in the potential number of =
ISP connections required.
> 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).
I don=E2=80=99t think I did. Nor did I talk about individual /48s.
> 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.
Given that prefix length is baked into the protocol and very hard to =
change, I=E2=80=99m not eager to abandon what progress has been made =
deploying IPv6 to go chasing a larger bit field any time soon.
If you think you=E2=80=99ve got something that will convince everyone to =
rewrite all their software again, go for it, but I=E2=80=99m skeptical =
as to the potential success of such an endeavor. However, if you do, I =
have just one request=E2=80=A6 Please add a 64-bit field to the packet =
header for =E2=80=9Crouting destination identifier=E2=80=9D so we can do =
something more intelligent than LISP without encapsulation.
Owen
