Search RPD Archives
Limit search to: Subject & Body Subject Author
Sort by:

[AfriNIC-rpd] IPv4 BoF report

Fri May 18 21:20:31 UTC 2007

As I tried to explain in the document that I'm working on, using NAT is not
necessarily bad.

In fact, it may be even good for developing regions.

If ISPs have enough addresses to number the basic pieces of their
infrastructure (routers that connect to the upstreams and servers), then
using only-IPv6 in the rest of the network, or only-IPv6 + private IPv4 +
NAT, actually works.

Of course, you need to use IPv4-to-IPv6 proxies, but especially on those
regions where upstream is expensive, there are already IPv4-to-IPv4 proxies
in order to save bandwidth cost. Those proxies can be transparent enough to
be able to see with and IPv6-only infrastructure (including IPv6 only at the
CPE WAN) + private IPv4 + NAT at the edge (customers LANs), all the
IPv4-only contents of the existing Internet.

Then when some of the applications are not able to use the proxy, you are
still able to use an automatic IPv4-in-IPv6 tunnel (softwires) to reach
those applications from the private IPv4+NAT side. Again, this is
transparent, and it doesn't changes anything that is not already today the
situation (being behind NAT and it works for client-to-server applications).

At this way, as much IPv6 deployment is a reality, more chances to have some
innovative applications being developed that take advantage of IPv6.

So from this perspective, you don't increase the *actual* cost of NAT, but
you provide means for pushing for a somehow faster transition that is *GOOD*
for the region.

So, amplification of NAT is going to happen, and is part of the picture, and
actually is a good one to help the IPv6 deployment.

The incentive for ISPs to deploy IPv6 is to be able to keep providing
existing services and still be able to grow in terms of number of customers
and services, NOT depending anymore in IPv4.

I think is a good incentive, I will say more than enough. Of course, I also
agree and understand that this is not an overnight task, and it may require
even a couple of years (it very much depends on each network case). It is in
your hands, yes *ALL YOU* to wake up now and make it happen NOW, in an
ordered manner, incrementally, possibly without extraordinary investments,
instead of being forced to stop services, stop accepting customers, or
having to pay a huge cost for doing it in weeks.

The key is planning ahead. Have you started already ?


> De: Alain Patrick AINA <aalain at>
> Organización: technologies réseaux et Solutions (
> Responder a: <aalain at>, AfriNIC Resource Policy Discussion List
> <rpd at>
> Fecha: Fri, 18 May 2007 19:49:37 +0000
> Para: <rpd at>
> CC: John Hay <jhay at>
> Asunto: Re: [AfriNIC-rpd] IPv4 BoF report
>> I agree with Andrew, we should stop putting our energy in ipv4 and rather
>> spend it on ipv6. Maybe we should change the policy for getting ipv4
>> addresses to require ISPs to implement ipv6 before they can get more ipv4
>> addresses?
>> Something like the ARIN proposal that Adiel forwarded a few days ago, but
>> on an even shorter timeframe. And without the part that try to conserve
>> ipv4 addresses. I think it way past the time to put effort into that.
> It is probably the way to go. But i suggest that in everything  we do, keep in
> mind how  hard it is to get thing move in Africa for various we all know.
> We may end up with  the amplification of IPv4 NAT in our region.
>> I think the biggest problem with IPv6 is the ISPs not implementing it.
>> Most operating systems shipping today have IPv6 enabled or an easy way
>> to enable it.
> What should be the incentives to get ISPs to deploy it ?
> --alain
> _______________________________________________
> rpd mailing list
> rpd at

The IPv6 Portal:

Bye 6Bone. Hi, IPv6 !

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 RPD mailing list