<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 01/22/2013 08:37 AM, august forsakov
wrote:<br>
</div>
<blockquote
cite="mid:CAHT2OAFPb6J1Cu-mMWRFeNzSOSJF3JYJ8mzXfBtGgi4=u7vPtA@mail.gmail.com"
type="cite">
<meta http-equiv="Context-Type" content="text/html;
charset=windows-1252">
<div class="gmail_quote">
<blockquote class="gmail_quote">
<div lang="EN-AU">
<div>
<p class="MsoNormal">
<span>IPv6 addresses are assigned to organizations in
much larger blocks as compared to IPv4 address
assignments—the recommended allocation is a</span><span> </span><span>/48</span><span> </span><span>block
which contains 2<sup>80</sup>addresses, being 2<sup>48</sup></span><span> </span><span>or
about</span><span> </span><span>2.8×10<sup>14</sup></span><span> </span><span>times
larger than the entire IPv4 address space of 2<sup>32</sup></span><span> </span><span>addresses
and about</span><span> </span><span>7.2×10<sup>16</sup></span><span> </span><span>times
larger than the</span><span> </span><span>/8</span><span> </span><span>blocks
of IPv4 addresses, which are the largest allocations
of IPv4 addresses. The total pool, however, is
sufficient for the foreseeable future, because there
are 2<sup>128</sup></span><span> </span><span>or about</span><span> </span><span>3.4×10<sup>38</sup></span><span> </span><span>(340</span><span> </span><span><a
moz-do-not-send="true"
href="http://en.wikipedia.org/wiki/10%5E12"
title="10^12" target="_blank"><span>trillion</span></a></span><span> </span><span>trillion
trillion) unique IPv6 addresses.</span></p>
<p class="MsoNormal">
<span>Each RIR can divide each of its multiple</span><span> </span><span>/23</span><span> </span><span>blocks
into 512</span><span> </span><span>/32</span><span> </span><span>blocks,
typically one for each ISP; an ISP can divide its</span><span> </span><span>/32</span><span> </span><span>block
into</span><span> </span><span>65536</span><span> </span><span>/48</span><span> </span><span>blocks,
typically one for each customer;<sup><a
moz-do-not-send="true"
href="http://en.wikipedia.org/wiki/IPv6_address#cite_note-16"
target="_blank"><span>[16]</span></a></sup></span><span> </span><span>customers
can create</span><span> </span><span>65536</span><span> </span><span>/64</span><span> </span><span>networks
from their assigned</span><span> </span><span>/48</span><span> </span><span>block,
each having 2<sup>64</sup></span><span> </span><span>addresses.
In contrast, the entire IPv4 address space has only 2<sup>32</sup></span><span> </span><span>(about4.3×10<sup>9</sup>)
addresses.</span></p>
<p class="MsoNormal">
<span>...</span><span></span></p>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>However many trillion, quadrillion or quintillion ip
addresses are possible with IPv6 there will always be a
shortage at some point...</div>
<div>Any technological renewal wave will show that to be true,
so we _will_ run out of IPv6...</div>
<div>Maybe we'll want to assign each gene an ip address as will
as its associated body cell... hahaha</div>
</div>
</blockquote>
<br>
I think quoting the number of addresses in IPv6 ranges rather than
number of subnets is misleading at best and dangerous at worst.<br>
<br>
No one is going to use <span>2<sup>64</sup> MAC addresses in a /64.
They're going to use somewhere between 2<sup>1</sup></span> and
maybe 2<sup>24</sup><span> at the outside in the very largest L2
data centre deployments. (Assuming they find some way of dealing
with broad-/multicast issues and are using something like MAC
address rewriting [1].)<br>
<br>
We should be talking in terms of numbers of /64 subnets. Using
the figures above, /23 == 512 ISPs, each of which has 65536
customers (/48), each of which has 65536 subnets (/64). That
corresponds exactly with the number of /24 subnets available to
organisations using the 10.0.0.0/8 block internally under IPv4
today (with the obvious advantage of not needing NAT).<br>
<br>
When i see those sort of numbers i'm glad Jeff Doyle is suggesting
that each building gets a /48 instead of each customer - i can see
it not being enough even within a short space of time, given
current industry talk about in-car networks (CANs?) and the
"Internet of things".<br>
<br>
Regards,<br>
Paul<br>
<br>
[1] </span><a class="moz-txt-link-freetext" href="http://www.cs.duke.edu/courses/fall10/cps296.2/lectures/16RoutingTopology.pdf">http://www.cs.duke.edu/courses/fall10/cps296.2/lectures/16RoutingTopology.pdf</a><br>
<br>
</body>
</html>