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

Mukom Akong T. mukom.tamon at gmail.com
Mon Jun 4 13:17:43 SAST 2012

On Sun, Jun 3, 2012 at 7:44 PM, Kondwani C. Hara <kondwa at m-hi.org> wrote:
> While direct communication seems a good idea, direct communication exposes
> devices to direct attack. Where NAT existed, it was easier to limit the
> attacks by opening up to the public only services that are accessible to the
> public.

Stateful packet inspection (SPI), which tends to be bundled with NAT
is *not* a part of NAT (actually NAPT or PAT as few people actually do
real NAT). If you really wanted it there's no reason you can't do SPI
on a public IPv4 or IPv6 address.

> Linux or most Unix machines operating as servers, are hardened against
> remote attacks. Workstations are hardened against local access. Putting
> these on ipv6 will leave many workstations very vulnerable.

Actually, a thoughtful well planned IPv6 implementation should
replicate the same security policies, techniques and mechanisms you
already have in place.

> The attacks on smartphones especially Android, seem to have been worse and
> difficult to manage due the little attention on security they might have
> received owing to the fact that its still work in progress.
> Exposing these to the chainability of ipv6 is really a Security disaster.

> That's a big bug ipv6 has.
> Kondwani.
> On 3 Jun 2012 19:34, "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 perfect).
>> 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,
>> [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
> _______________________________________________
> afripv6-discuss mailing list
> afripv6-discuss at afrinic.net
> https://lists.afrinic.net/mailman/listinfo.cgi/afripv6-discuss

Mukom Akong [Tamon]

“We don't LIVE in order to BREATH. Similarly WORKING in order to make
MONEY puts us on a one way street to irrelevance.“

[In Search of Excellence & Perfection] - http://perfexcellence.org
[Moments of TechXcellence] - http://techexcellence.net
[ICT Business Integration] - http://ibiztech.wordpress.com
[About Me] - http://about.me/perfexcellence

More information about the afripv6-discuss mailing list