From: CCIEin2006 (ciscocciein2006@gmail.com)
Date: Thu Dec 22 2005 - 16:48:38 GMT-3
Speaking of multihoming, how does that affect the address aggregation? Does
it force each provider to punch a hole in their address block?
On 12/20/05, Scott Morris <swm@emanon.com> wrote:
>
> Actually, it's more reminiscent of IPX. You know, the 32 bit network ID
> plus your MAC address. And since the network ID was announced by servers,
> your workstations could be less intelligent and you have magical
> networking.
> IPv6 isn't all that much different. New colors, same basic flavor. :)
>
> Anyway, the /64 was used in order to make things more magical with the
> automatic addressing. Why 64 bits instead of 48? Great question, haven't
> got a clue. My theory on the insertion of the FFFE is that someone
> figured
> that with everyone throwing away old devices and (in theory) MAC addresses
> only being used once, we'dd run out of them too. FFFE is a starting
> point.
> IMHO, it would seem to make sense to have different codes for different
> media types, and it's likely spelled out someplace, I just haven't been
> bored enough to research that part!
>
> Every company/enterprise/customer is supposed to get a /48 which gives you
> 64K of subnets to use which should suffice for damned near
> everyone. There
> are always exceptions, and there's nothing saying that you CANNOT have
> subnets different than a /64 (like a /128 for loopbacks or /127 on P2P
> links
> or whatever your heart (or lab) desires), but if every company aggregates
> to
> a /48 the thought was that route summarization throughout the global table
> would be easier.
>
> Now this was done before multihoming was big. IPv6 was designed 10-12
> years
> ago. A few things have changed since then as we make stuff work! (grin)
>
> But otherwise yes, there should be plenty of addresses to go around for a
> long long time! Although currently they've only released a small portion
> of
> "all" the addresses (2000-3FFF range) for unicast global address space.
> Even as registries are handing out /48's, that's still bigger than the
> full
> 32-bit space we have now. So that means we can have somewhere in the
> neighborhood of 281,474,976,710,656 (281 trillion'ish) individual
> companies/enterprise customer networks. We'll have plenty so that your
> wireless toothbrush can still catch a virus without any need for NAT!
>
> Yay.
>
> Scott
>
> PS. When the United Federation of Planets becomes a reality, someone,
> someplace wanted to be sure we still had address space available! ;)
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> CCIEin2006
> Sent: Tuesday, December 20, 2005 3:46 PM
> 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?
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Mon Jan 09 2006 - 07:07:52 GMT-3