[afripv6-discuss] IPv6 In South Africa

[Mark Tinka]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : https://lists.afrinic.net/pipermail/afripv6-discuss/attachments/20120114/29c89eed/attachment.bin