[afripv6-discuss] IPv6 In South Africa

[Ahmed Abu-Abed]

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