[182365] in North American Network Operators' Group
Re: Dual stack IPv6 for IPv4 depletion
daemon@ATHENA.MIT.EDU (Doug Barton)
Wed Jul 15 16:19:32 2015
X-Original-To: nanog@nanog.org
To: George Metz <george.metz@gmail.com>
From: Doug Barton <dougb@dougbarton.us>
Date: Wed, 15 Jul 2015 13:19:27 -0700
In-Reply-To: <CANjVB-hktATZdcHLhUgEuZx5nYkSCixvYR-xsQiKC76W9QRJZw@mail.gmail.com>
Cc: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--om4IqIBpvXH1jltHU46R0qTS2G8MobmQx
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
On 7/15/15 12:43 PM, George Metz wrote:
>
>
> On Wed, Jul 15, 2015 at 2:11 PM, Doug Barton <dougb@dougbarton.us
> <mailto:dougb@dougbarton.us>> wrote:
>
> On 7/15/15 8:20 AM, George Metz wrote:
>
>
>
> Snip!
>
> Also, as Owen pointed out, the original concept for IPv6 networking=
> was a 64 bit address space all along. The "extra" (or some would
> say, "wasted") 64 bits were tacked on later.
>
> Still oodles of addresses, but worth
> noting and is probably one reason why some of the "conservation=
ists"
> react the way they do.
>
>
> It's easy to look at the mandatory /64 limit and say "See, the
> address space is cut in half to start with!" but it's not accurate.=
> Depending on who's using it a single /64 could have thousands of
> devices, up to the limit of the broadcast domain on the network
> gear. At minimum even for a home user you're going to get "several"=
> devices.
>
> Allow me to rephrase: "A single /32 could have thousands of devices, up=
> to the limit of a 10/8 NATted behind it". This, plus the fact that it
> WAS originally 64-bit and was expanded to include RA/SLAAC, is why I
> chose that analogy.
Sure, so in that context it's a valid analogy, but my point still=20
stands. We're not talking about routable/PI space for customers, even at =
the /48 level.
Now it is true that the CW seems to be leaning towards /48 being the=20
largest routable prefix *for commercial networks*, but that's orthogonal =
to the issue of home users.
> I do see that as a possibility, however in this world that you're
> positing, how many of those molecules need to talk to the big-I
> Internet? Certainly they need to communicate internally, but do the=
y
> need routable space? Also, stay tuned for some math homework. :)
>
>
> So, you're advising that all these trillions of nanites should, what,
> use NAT? Unroutable IP space of another kind? Why would we do that when=
> we've already got virtually unlimited v6 address space?
>
> See what I mean? Personally I'd suspect something involving quantum
> states would be more likely for information passage, but who knows what=
> the end result is?
I very carefully tried to skirt the issue, since NAT is a hot-button=20
topic for the most ardent of the IPv6 zealots. You were positing a world =
where we need addressing at a molecular level, my point is simply that=20
in that world we may or may not be dealing with publicly routable space; =
but *more importantly*, even if we are, we're still covered.
> I wrote my email as a way of pointing out that maybe the
> concerns (on
> both sides)- aren't baseless,
>
>
> Please note that I try very hard not to dismiss anyone's concerns a=
s
> baseless, whether I agree with them or not. As I mentioned in my
> previous message, I believe I have a pretty good understanding of
> how the "IPv6 conservationists" think. My concern however is that
> while their concerns have a basis, their premise is wrong.
>
> I wasn't intending yourself as the recipient keep in mind. However, IS
> their premise wrong? Is prudence looking at incomprehensible numbers an=
d
> saying "we're so unlikely to run out that it just doesn't matter"
Yeah, that's totally not what I'm saying, and I don't think even the=20
most ardent IPv6 zealot is saying it either. What I'm saying is that=20
there is a very solid, mathematical foundation on which to base the=20
conclusion that ISPs handing out /48s to end users is a very reasonable=20
thing to do.
> or is
> prudence "Well, we have no idea what's coming, so let's be a little les=
s
> wild-haired in the early periods"? The theory being it's a lot harder t=
o
> take away that /48 30 years from now than it is to just assign the rest=
> of it to go along with the /56 (or /52 or whatever) if it turns out
> they're needed. I personally like your idea of reserving the /48 and
> issuing the /56.
Thanks. :) I do recognize that even with all of the math in the world=20
we don't know what the world will look like in 20 years, so *some=20
degree* of pragmatism is valuable, especially as we're ramping up=20
deployment.
But your argument that it'll be hard to take away the /48 is almost=20
certainly wrong. This isn't like handling out "Class A's" and "Class=20
B's" in the early days of IPv4, when we're talking home users we're=20
talking about PA space, which can be withdrawn at will.
Even at the RIR level, assuming some unimaginable future where 400+ /48s =
per human on the planet isn't enough, they can simply revise their=20
policies to require justification at some other level per user than /48, =
thereby proclaiming that an ISP's existing space is "adequate" by=20
administrative fiat.
In that sense I actually believe that we've learned the lessons from the =
early days of IPv4, and that we've adequately accounted for them in the=20
current set of policies.
=2E.. and not to flog the expired equine, but we're still only talking=20
about 1/8 of the available space. I'm not being snarky when I say that=20
we really are dealing with numbers that are so large that it's hard for=20
the human mind to comprehend them.
> That's not splitting the difference. :) A /56 is half way between =
a
> /48 and a /64. That's 256 /64s, for those keeping score at home.
>
>
> It's splitting the difference between a /56 and a /48. I can't imagine
> short of the Nanotech Revolution that anyone really needs eight thousan=
d
> separate networks, and even then... Besides, I recall someone at some
> point being grumpy about oddly numbered masks, and a /51 is probably
> going to trip that. :)
The issue is more nibble boundaries than odd-numbered masks. But my=20
point wasn't really to say "/56 is the right answer," since it's not,=20
/48 is. :)
> I think folks are missing the point in part of the conservationists, an=
d
> all the math in the world isn't going to change that. While the... let'=
s
> call them IPv6 Libertines... are arguing that there's no mathematically=
> foreseeable way we're going to run out of addresses even at /48s for th=
e
> proverbial soda cans, the conservationists are going, "Yes, you do math=
> wonderfully. Meantime is it REALLY causing anguish for someone to only
> get 256 (or 1024, or 4096) networks as opposed to 65,536 of them? If
> not, why not go with the smaller one? It bulletproofs us against the
> unforeseen to an extent."
The short answer to your question is, "Yes." The longer answer is that=20
we are only just starting down the road of what's going to be possible=20
for home users with IPv6. There is already a desire to use multiple=20
different subnets, and nested routers. My personal feeling is that 256=20
networks (a /56) is going to be enough for the foreseeable future, but=20
the point Owen has made quite eloquently is that we don't want to=20
hamstring these efforts from the outset with something ludicrously small.=
So it really isn't a matter of not understanding the conservationists,=20
it's more a matter that the math really does work. But even given all=20
that, I still advise to reserve the /48, and allocate the /56, then as=20
the next couple of years go by it will become increasingly obvious what=20
the right answer is, and no matter who was "right" we'll still have all=20
the space we need. I'm glad that we seem to have reached agreement on=20
that point at least. :)
Doug
--=20
I am conducting an experiment in the efficacy of PGP/MIME signatures.=20
This message should be signed. If it is not, or the signature does not=20
validate, please let me know how you received this message (direct, or=20
to a list) and the mail software you use. Thanks!
--om4IqIBpvXH1jltHU46R0qTS2G8MobmQx
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQEcBAEBCAAGBQJVpsBPAAoJEFzGhvEaGryEtmMH/j0zMVPxWc8nbKaBtOFWdNkf
lUhDHopZPUMO6N/m7aeiHo9kqVTUCEQhnEiOXZyGbPnkFHCI3XKim8tOOFuYGLEI
jM67DSfoMZAhgI1pTEazP0xeEgmx48ptU+sVO3xdYq7pr46YiqPVP97Qxm4rPN0Y
As9XOiQfn8uhYcAyf0inMiF/INRfhLV21jcaM+mMHpFHE9VzAwj+EtUzkZQP0Hvh
KFYMx0ewMbviDCsnUi0raQzvC1dIV5z0iioagY5Qjt43M/Z7Ej6SDzz8EDd1EeSH
DmqqqNL0IJ/Cop3fOtfjcoxjIZ0gzbl+ejw9FVTpSBGHJB4G72pQlWtxBvy2t+w=
=vT47
-----END PGP SIGNATURE-----
--om4IqIBpvXH1jltHU46R0qTS2G8MobmQx--
