From: Alexander Arsenyev \(GU/ETL\) (alexander.arsenyev@ericsson.com)
Date: Wed Dec 21 2005 - 05:46:23 GMT-3
AFAIK, the IPv6 address subnet portion was made 64-bit long (or 16
half-bytes/nibbles long) in order to accommodate for automatic
conversion/embedding of ITU E.164 addresses (which are up to 15 decimal
digits long). Each half-byte/nibble can represent one decimal digit.
Pretty much the same principle is used in ATM E.164 addressing scheme,
see http://www.mfaforum.org/ftp/pub/approved-specs/af-ra-0105.000.pdf
and/or http://www.mfaforum.org/ftp/pub/approved-specs/af-ra-0106.000.pdf
.
Bottom line is that one could have an IPv6 address with own (cell|home)
telephone number embedded in last 8 bytes!
HTH
Cheers
Alex
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
CCIEin2006
Sent: 20 December 2005 20:46
To: lab
Subject: IPv6 Address Allocation Excessive?
According to the Cisco Press book "Implementing Cisco IPv6 Networks",
RIR's allocate /32 prefixes to ISP's. ISP's allocate /48 prefixes to
each customer site. Each customer site uses /64 prefixes for each
subnet.
Isn't that a little excessive?
Why does every subnet need a /64?!? Isn't that 1.8 quintillion addresses
per subnet?!? What a waste!
On the other hand If the average ISP has a /32 and he is allocating /48
that means he only has 2^16 or 65536 prefixes to allocate. Doesn't seem
that much at all.
I know IPv6 is supposed to provide plenty of addresses, but aren't these
large allocations reminiscent of the 1980's when IPv4 registries were
handing out Class A and Class B subnets to every Tom, Dick and Harry
that asked for one?
What I'm saying is that even though the IPv6 address space can
accommodate
3.4*10^38 addresses, if the registries keep handing out such large
chunks of address most of the addresses will be wasted.
I'm just concerned that in the future there won't be any addresses left
to assign to my wireless electric toothbrush!
Any thoughts?
This archive was generated by hypermail 2.1.4 : Mon Jan 09 2006 - 07:07:51 GMT-3