[afripv6-discuss] IPv6 In South Africa

[Latif LADID ("The New Internet based on IPv6")]

Agree with Ahmed!

South Africa is well poised for a good offering.

However, we need to get v6 access at this stage for total Africa without investment in infrastructure for the sake of learning and training.

This will create demand in the region from the end-users perspective.

Cheers
Latif
-----Original Message-----
From: afripv6-discuss-bounces at afrinic.net [mailto:afripv6-discuss-bounces at afrinic.net] On Behalf Of Ahmed Abu-Abed
Sent: Montag, 16. Januar 2012 08:28
To: mtinka at globaltransit.net
Cc: Pierre Van Vuuren (ZA); afripv6-discuss at afrinic.net
Subject: Re: [afripv6-discuss] IPv6 In South Africa

Hi Mark,

FWIW, gogo6 license their CPE code for IPv6 transition mechanisms to other vendors CPEs. Their business focus is not to sell CPEs, which have very low margin, but the tunnel servers at ISP core that go with them. Each tunnel server can serve 50K CPEs or s/w clients (which are free).

As for NAT64/DNS64, all I have to say that this is a good idea, except that you need to turn OFF dual-stack on your PC ! NAT64 needs an IPv6-only host to work, and good luck trying to do that with todays operating systems that have apps with socket code and networks they need to connect to over IPv4.

So, practically, efficient tunneling is the best way for rapid transition for now. And the more you shorten the tunnel, the more efficient it is.

All the best,
-Ahmed


On Saturday, January 14, 2012 03:13:14 PM Ahmed Abu-Abed
wrote:

> >> Au contraire, the gogo6 IPv6 tunnel terminates inside the ISP. The 
> >> gogo6 business model is to sell tunnel server hardware to ISPs, and 
> >> they also provide software & CPE clients to cover the solution 
> >> end-to-end. There is a Freenet6 global tunnel broker service that 
> >> uses gogo6 gear and services, and everyone can use that freely, but 
> >> that doesn't generate revenue for them.

That's what I said, it's another tunnel that terminates inside the ISP's network.

So it's an implementation of standards-based transition mechanisms that are being developed by several vendors, big and small.

Ubiquity will be when a decent vendor can be used to terminate tunnels in the core, and anybody can pick up cheap CPE which will quickly and easily inter-op with the tunnel server in the core.

While I applaud the work gogo6 are doing, we need to see even more CPE in the market, as this is what will drive prices down, increase deployment, help with bug fixes, and with any luck, make v6 more pervasive.

> >> Since IPv6 interconnect is directly from the ISP to the global 
> >> network, and the tunnel broker server terminates inside the ISP, 
> >> then that's not necessarily the case. Also gogo6 servers handle 
> >> reverse tunneling, i.e. IPv4-in-IPv6 , which gets further 
> >> resiliency if necessary.

There are transition mechanisms that go 6-in-4, while othes go 4-in-6. The case for v4 failure being disruptive is which method the ISP chooses to use with their customers, especially those that are unwilling to roll-out v6 widely, and want to maintain v4 as much as possible.

> >> I agree, while such a solution helps spread IPv6 quickly over 
> >> legacy IPv4-only networks which will be around for a long time to 
> >> come. Plus IPv4-in-IPv6 tunneling mode (which is essentially 
> >> DS-Lite) you can deploy v6 now without much public v4 address 
> >> needed.
> >> And in case someone doubts about performance, Australia’s IPv6 Now 
> >> service to enterprises showed that such ISP-terminated tunnels have 
> >> very low latency. See http://www.ipv6now.com.au/tunnels.php , and 
> >> they also use gogo6 h/w according to their website.

Personally, I don't like tunnels because they make troubleshooting hard due to topology hiding. That said, they do have their place.

We're focusing on NAT64, because it is pretty much "the"
transition mechanism which encourage adoption of v6 in the Access, on a long-term basis.

Other transition mechanisms that encourage maintenance of some v4 in the access mean that operators (and their
customers) will need to, at some point in the future, migrate - yet again - fully to v6. This is going to be more work.

> >> It implements RFC5572, the TSP protocol. This is unique in that it 
> >> can be implemented in both h/w and s/w, so in theory one can have 
> >> mobile phones now accessing IPv6 content with a s/w client in them 
> >> connecting to a tunnel server at the mobile operator core, 
> >> regardless of the intermediate node v6 readiness.

You already know how I feel about tunnels :-).

That said, any v6 standards can be implemented by whichever vendor chooses to implement them. There are just a couple of issues that need solving:

    a) How soon will vendors start pushing product out.

    b) How soon will operators start testing these
       products?

    c) How soon will operators start deploying these
       products.

    d) How soon will customers start getting their hands
       on these products, cheaply?

    e) How inter-operable will these products be among
       vendors?

    f) Which solutions will be more popular, as that
       will determine where future development will be?

> >> And with TSP each customer can also advertise their own /56 or /48 
> >> prefixes to devices on the LAN.

Which is what v6 CPE's are meant to do anyway :-).

> >> If dual-stack is implemented up to the customer sites then such 
> >> tunnel mechanisms may not be needed,...

Not entirely true. Dual-stack doesn't just mean providing v4 and v6 and everything works. There are two deployment
methods:

    o static.
    o dynamic.


Static deployment is very easy.

Dynamic deployment, less so.

Moreover, don't bet on dual-stack being the optimum solution, because at some point, there won't be anymore v4 left to hand to customers along with their v6 assignments.
This means that eventually, we shall only be single-stack (not taking NAT44 or NAT444 into account, of course).

So when the last public v4 address is assigned to some customer, subsequent customers will only be able to get v6 addresses. And with those, they must somehow be able to communicate both with the growing v6 Internet, as well as the legacy v4 one.

> >> but
> >> given how pervasive IPv4 only nodes and CPEs are, then such 
> >> mechanisms will be around for a long while.

No one disputes that.

My only concern with a solution like gogo6 is that it "adds"
another device into the home. Operators are having a hard enough time supporting one CPE device, and now you have two (or maybe even more).

Of course, if you're a power user and you go out and buy the
gogo6 on your own to mess around with, then the ISP isn't on the hook. But knowing how large ISP's run, endorsing a product means supporting it. In the majority of cases, ISP's want to maintain the least number of devices in their customers' networks.

> >> Transition mechanisms will not go away until IPv6-only content AND 
> >> networks are the norm, which will take many years to realize.

This is very well understood.

Mark.


-----Original Message-----
From: Mark Tinka
Sent: Saturday, January 14, 2012 11:58 AM
To: Ahmed Abu-Abed
Cc: afripv6-discuss at afrinic.net ; Pierre Van Vuuren (ZA)
Subject: Re: [afripv6-discuss] IPv6 In South Africa

_______________________________________________
afripv6-discuss mailing list
afripv6-discuss at afrinic.net
https://lists.afrinic.net/mailman/listinfo.cgi/afripv6-discuss