[afripv6-discuss] What are the benefits of IPv6 over IPv4

JORDI PALET MARTINEZ jordi.palet at consulintel.es
Mon Jun 4 00:19:56 SAST 2012

There are many reasons for a home to require a /48, for example IoT
(Internet of Things).

Tony Hain calculations indicate that if we allocate a /48 for every human,
we will have enough IPv6 addresses for the next 500 years or so. So there
is not reason for not doing so, specially, because for sure, in 50-100
years, we will need some new changes, not this time because the runout of
addresses anymore.


-----Mensaje original-----
De: Kivuva <Kivuva at transworldafrica.com>
Responder a: IPv6 in Africa <afripv6-discuss at afrinic.net>
Fecha: lunes 4 de junio de 2012 00:08
Para: IPv6 in Africa <afripv6-discuss at afrinic.net>
Asunto: Re: [afripv6-discuss] What are the benefits of IPv6 over IPv4

>Kondwani, you are right. What about issuing a /8 class A IPv4 for
>private addresses, or issuing /8 for several legacy companies. That is
>16.7million or 2^24 hosts per company. Such a waste.
>The same lack of foresight is seen in allocation of IPv6 by giving
>small entities /48 (that is more than all addressable numbers in v4)
>although that leaves us with 281 trillion /48.
>Mark Elkins! Can someone enlighten me why a home may need a /60? Still
>I don't see how we will exhaust v6 in our lifetime even after.
>On 03/06/2012, Frank Habicht <geier at geier.ne.tz> wrote:
>> Hi,
>> I understand Vint Cerf is accepting part of the blame [about limitations
>> of v4].
>> I believe that it's good (for innovation) to be able to have direct
>> communication between end devices (end-to-end principle).
>> That is gone for IPv4 (NAT), and workarounds [1] are there (none
>> I think IPv6 will take care of it for longer that IPv4 did.
>> I hope we have a common understanding about history and we can go
>> forward. How do we deploy more v6 ?
>> I like Gert Doering's .sig :
>> "have you enabled IPv6 on something today...?"
>> Frank
>> PS: didn't get 2x eBGP up with Cisco 891 [2] today :
>> clear bgp ipv6 unicast * did _not_ help
>> reload _did_ help.     strange....
>> Cisco IOS Software, C890 Software (C890-UNIVERSALK9-M), Version
>> 15.1(4)M1, RELEASE SOFTWARE (fc1)
>> [1]
>> - the one I think about are STUN etc
>> - ipv6 over facebook, over google, don't count
>> - 6to4 should be history, and not in discussions about the future - can
>> we agree?
>> [2]
>> end-user customer, with 2 uplinks to same ISP, in AS 64512
>> yes, i was talking about BGP over v6 and about v6
>> On 6/3/2012 7:52 PM, Kondwani C. Hara wrote:
>>> I believe by design, ipv4 was never supposed to exhaust. But as a
>>> marketing extra, even ipv6 address space will prove too little. Not
>>> every individual requires a public ip. But if every device will require
>>> a public ip, then per individual it should be expected several devices.
>>> I wonder how many ipv6 ip address are implementable? If there is an
>>> upper bound, the seemingly huge number will exhaust.
>>> Unless we come back to the original design of ipv4 we will find that we
>>> would still encounter the same problem. We will also find that ipv4 was
>>> never supposed to exhaust in the first place.
>>> On 3 Jun 2012 14:09, "Mark Tinka" <mark.tinka at seacom.mu
>>> <mailto:mark.tinka at seacom.mu>> wrote:
>>>     On Sunday, June 03, 2012 11:11:39 AM Mark Elkins wrote:
>>>      > At the end of the day - every ISP type service charges
>>>      > for the IP addresses that they 'rent' from their
>>>      > Upstream or RIR. They are all businesses.
>>>     Mark, do you mean as a hidden cost or explicitly?
>>>     Not all ISP's charge their customers for space. But yes,
>>>     some do.
>>>     The operations I've run assign a minimum default for every
>>>     new turn-up. If customers want additional space for their
>>>     expansion, they only need to justify that to us (not as easy
>>>     as I'm making it sound), and if they could, we'd assign more
>>>     to them. Justification for additional space was always in
>>>     line with the policies enforced by the RIR in the respective
>>>     region I worked; which is fair.
>>>     Charging for IPv4 address space isn't terribly useful, as
>>>     that's a dying resource you can't base any sustainable model
>>>     on.
>>>     I know Product & Marketing folks like to charge for IPv4
>>>     addresses as a deterrence to exhaustion, but I always tell
>>>     them that if a customer is desperate, they'll pay anything
>>>     to get it.
>>>     Add to that, the Sales are happy making IPv4 addresses an
>>>     item line because they make more on commissions.
>>>     So the combination of S&M, in this case, is a recipe for
>>>     disaster that needs checking.
>>>     But as a basic means of revenue when offering a service,
>>>     I'll submit it (selling IPv4 space) leaves a foul taste in
>>>     my mouth. As for IPv6, that's just immoral, but that's my
>>>     own opinion.
>>>     Your network, your rules.
>>>     Mark.
>>>     _______________________________________________
>>>     afripv6-discuss mailing list
>>>     afripv6-discuss at afrinic.net <mailto:afripv6-discuss at afrinic.net>
>>>     https://lists.afrinic.net/mailman/listinfo.cgi/afripv6-discuss
>>> _______________________________________________
>>> afripv6-discuss mailing list
>>> afripv6-discuss at afrinic.net
>>> https://lists.afrinic.net/mailman/listinfo.cgi/afripv6-discuss
>> _______________________________________________
>> afripv6-discuss mailing list
>> afripv6-discuss at afrinic.net
>> https://lists.afrinic.net/mailman/listinfo.cgi/afripv6-discuss
>Mwendwa Kivuva
>Business Development
>Transworld Computer Channels
>Cel: 0722402248
>transworldAfrica.com | Fluent in computing
>kenya.or.ke | The Kenya we know
>afripv6-discuss mailing list
>afripv6-discuss at afrinic.net

IPv4 is over
Are you ready for the new Internet ?
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

More information about the afripv6-discuss mailing list