[kictanet] [Community-Discuss] IPv6 Chapter 254

Kevin Kamonye kevin.kamonye at gmail.com
Thu Oct 13 15:03:23 EAT 2016


Hi Andrew,

Your apparent passion and commitment to the migration reminds me of *Plato's
Cave *:) You have clearly seen the promised land of a native v6 world and
it is beautiful.

Now, am hardly poet but am forced to say the above in appreciation of the
amount of work that you have clearly put into this. You have also raised
some very high level points that I will need some more time to fully
research on. I do not have the answers at the moment.

First, I agree that the proposal of having a reserve block for new entrants
is the most rational way forward. Still, some of the reasons why I would
consider stopping the allocation of v4 are below.

1. These v4 IPs will eventually be exhausted anyway and the final goal is
to stop using the current addressing scheme completely

2. Every single v4 IP that is currently/ to be allocated will have to be
swapped eventually - more time and resources will be required

3. To expand on the above, this challenge grows exponentially with every
v4-only device that is sold (and this mostly happens in developing
countries)

4. There are RIRs that have long stopped v4 allocations (certainly not by
choice) and I believe there are still new entrants into those markets and
they still find a way to survive. Let us not underestimate human nature. A
good point in case is that the exhaustion of v4 has been *imminent* for a
long long long time.

​5. For consumers( I include users, developers, Systems/IP guys - all of
us), the costs also include the lost opportunities for better connections (
logical and social) and I can also add that we are also restricting
innovation.

Consider the below especially as regards to 4 & 5. ( I do not necessarily
agree with the simplistic opinions given by the author re ISPs as I know we
all have different values and priorities - but then again I did not want to
create any perception as being subjective on what content to highlight from
the article, being in the industry myself)
​​
​"A lot of CGNs are being deployed. Some recent work I have been doing
shows that upward of 3% of IPv4 users present on a different source IPv4
address within 10 seconds—i.e. a minimum of 3% of users lie behind CGNs
with relatively aggressive address lease timeouts. Secondly, a lot of
shared Web hosting is being deployed. It is evidently commonplace to see
upward of *10,000* Web host environments co-existing on a *single host IP*
server address."​

​​ISPs are playing their cards close to the vest, but it looks like many of
the ones that are planning to start rolling out IPv6 soon will be deploying
IPv6 along with CGN-based IPv4 for new users. They're reluctant to change
anything for existing users, because the first rule of being an ISP is
"don't generate support calls." Providing broadband Internet access is a
very profitable business, but the profit generated by a customer evaporates
faster than you can say "have you tried rebooting your router?" when said
customer calls for support. ISPs that started deploying IPv6 in past years
had access to enough IPv4 addresses to give users their own along with a
range of IPv6 addresses. That is no longer true, or will no longer be true
as soon as ISPs use up their own stashes of IPv4 addresses.

The downside of NAT is that it only works well in one direction: from the
inside to the outside. When connections must be set up from the outside to
the inside, such as in the case of peer-to-peer audio or video
conferencing, additional logic is necessary to find a way to the right
internal system through the NAT. This is bad enough when two users are both
behind their own home NATs so that two NATs must be bypassed, but it gets
much worse as ISPs deploy CGNs, so now four NATs can be in the path. CGNs
also can't open up ports as easily as home NATs. As long as it's not
firewalled too severely, IPv6 has none of these issues; with 2^128
addresses there is no need for NAT. So it makes sense for ISPs to deploy
IPv6 along with CGN-based IPv4. However, there are still ISPs that
pooh-pooh IPv6. Huston again: "The pessimistic view is that so far nothing
much has broken in IPv4-land, so there is still some more time left to do
nothing!"

Unless the ISPs that have been ignoring IPv6 plan to just keep their
existing customers and not sign up any new ones, those ISPs are still going
to be bitten by the IPv4 address exhaustion and will almost certainly be
forced to deploy CGN at some point. With no pressure relief valve in the
form of IPv6, all user traffic will have to flow through the CGN, which can
then easily become a bottleneck and a single point of failure. As a result,*
the quality of service delivered by different ISPs will diverge more and
more*, with the ones providing unshared public IPv4 addresses as well as
IPv6 doing the best and the ones using CGNs with relatively many users per
public IPv4 address and no IPv6 doing the worst.

The good news is that so far, the Internet has always managed to adapt just
before collapse was imminent. In the late 1980s, TCP congestion control
saved the Internet from massive congestion. In the 1990s, classless
interdomain routing and route flap damping kept the routers going. This
time we only have to turn on a feature that's been in our operating systems
for a decade and maybe replace an aging modem or two. Call me an optimist,
but I think it can be done. But only at the very last moment, of course.
(Source
<http://arstechnica.com/information-technology/2014/06/with-the-americas-running-out-of-ipv4-its-official-the-internet-is-full/>
)

​So yes v6 will happen with/out any drastic measures.

On the other hand, Africa finally has a chance to make a bold message that
I can consider to be at the scale of the burning of Ivory in Kenya.​

Before, stopping all allocations was impossible as the RIRs would never
have been able to convince their customers or even each other to do so. But
now that we are the only ones left with a substantive reserve of these
(potentially toxic) IPv4 resources, we could agree to start moving in the
other direction and let all the others follow this time. I would really be
pained to hear the inevitable statements (with very correct language of
course) that the reason v4 still exists is to accommodate the developing
world.

Regards,

*Kevin K.*
*+254720789158*

On 13 October 2016 at 10:00, Andrew Alston <Andrew.Alston at liquidtelecom.com>
wrote:

> Hi Kevin,
>
>
>
> Just another further note on what I said below.
>
>
>
> To quote from Dave Michaud from Rogers Communications yesterday on another
> list (used with kind permission of the author who waived Chatham house
> rules that exist on the list it was posted to allow me to quote this):
>
>
>
> *Once we are done with this phase, we will start migrating some phones to
> IPv6-only operation. The transition will be executed per phone model by a
> logic implemented in a AAA server that is queried by the PGW when the
> PDP/PDN is established. The AAA decides based on IMEI if the phone should
> connect to the network using dual-stack or using IPv6-only with
> DNS64/CGN64.*
>
>
>
> He further sent me the following:
>
>
>
> *To clarify the v6-only service, we will be cherry picking devices for
> this service. Initially, it will be Samsung Galaxy S4, LG G4 and Nexus 5.
> After that, once we are comfortable, we will move more devices to IPv6-only
> operation (likely all newer Samsung, LG and Google/Nexus/Pixel devices).
> Moving forward, all new devices that we start selling will also be launched
> with IPv6-only.*
>
>
>
>
>
> Now – what does this mean.  Firstly, the days of dual-stack as the only
> means are over.  There **IS**  a move towards single-stack v6 with only
> translation to v4.  I believe (but am open to correction) that t-mobile is
> doing the same thing.  Secondly – it emphasises the point of reserving a
> small block of space for new-comers that don’t have in order to facilitate
> the v6 -> v4 translation referred to above.  Thirdly – the implications of
> the above are… quite mind blowing – because while NAT has certain ways to
> transverse back through it (UPNP etc) to enable certain applications to
> work ok behind standard v4 NAT, I am far from convinced the same will work
> with v6 to v4 NAT in the same manner.  (Open to correction and would love
> to hear from someone more knowledgeable in this area).  But what this means
> is – if people aren’t running v6 and pretty fast – life on the Internet is
> going to start getting really interesting – because v6 single stack isn’t a
> thing for tomorrow – it’s already happening.
>
>
>
> Thanks
>
>
>
> Andrew
>
>
>
> *From:* Andrew Alston [mailto:Andrew.Alston at liquidtelecom.com]
> *Sent:* 13 October 2016 09:45
> *To:* Kevin Kamonye <kevin.kamonye at gmail.com>
> *Cc:* General Discussions of AFRINIC <community-discuss at afrinic.net>;
> KICTAnet ICT Policy Discussions <kictanet at lists.kictanet.or.ke>; Barrack
> Otieno <otieno.barrack at gmail.com>
>
> *Subject:* Re: [Community-Discuss] IPv6 Chapter 254
>
>
>
> Hi Kevin,
>
>
>
> I don’t think completely stopping v4 allocations right now would have the
> impact we’re looking for.  If you look at the policy proposal I’ve put
> forward, I propose a /13 reserved entirely for new comers, people who had
> zero space from anywhere before this.  I think this is still an adequate
> number and sufficient, but it is also critical.  The reason for this is
> that it allows sufficient space for entities to do NAT64 / DNS64 for
> translation to legacy equipment in a single-stack v6 environment.  I still
> believe this will be necessary for a few years to come – and I think the
> /13 reservation is sufficient.
>
>
>
> I also think that at the rate of depletion – we won’t actually be gaining
> much time by stopping, and as you say, there are other considerations we
> have to keep in mind.  Rather than focusing on the financial
> considerations, we have to consider the fact that the space that was given
> to AfriNIC by IANA was meant to the serve the people, and I’m pretty sure
> that if AfriNIC decided to just stop allocating and hold onto all of it
> they would run foul of the agreements under which they were given that
> space.  (I could be wrong here, perhaps someone with more insight can
> comment).
>
>
>
> What I’d like to see is a situation where those who need the v4 space
> today, for use on the continent, can get it, use it, and we deplete
> naturally.  There is a lot of evidence that there is plenty of demand on
> the continent, and while some would say that large allocations indicate
> space flowing off the continent, I have yet to see any concrete evidence of
> this and in fact the allocation statistics seem to dispute this fact.  (The
> majority of the really large allocations in recent months looking at the
> publically available data are tending to go to African countries that
> traditionally had far less space than other places, and an analysis of the
> BGP surrounding those allocations gives no indication that they have been
> moved off continent, though of course I say that BGP analysis and latency
> analysis of space to determine actual geographic location is a bit hit and
> miss and far from an exact science).
>
>
>
> If we repeal the current soft landing policy and maintain a limited
> reservation strictly for new-comers (and I do believe a /13 is sufficient),
> this will achieve the necessary in my opinion.  It will ensure the rapid
> depletion of v4 space on the continent, it will ensure that the space that
> is currently within AfriNIC is actually used for proper benefit, it will
> ensure that there is still space available for people who have absolutely
> none to use for single-stack v6 to v4 translation as necessary, and all in
> all, I believe that’s the best solution.
>
>
>
> Thanks
>
>
>
> Andrew
>
>
>
>
>
> *From:* Kevin Kamonye [mailto:kevin.kamonye at gmail.com
> <kevin.kamonye at gmail.com>]
> *Sent:* 12 October 2016 18:36
> *To:* Andrew Alston <Andrew.Alston at liquidtelecom.com>
> *Cc:* Mark Tinka <mark.tinka at seacom.mu>; KICTAnet ICT Policy Discussions <
> kictanet at lists.kictanet.or.ke>; General Discussions of AFRINIC <
> community-discuss at afrinic.net>; Barrack Otieno <otieno.barrack at gmail.com>
> *Subject:* Re: [Community-Discuss] IPv6 Chapter 254
>
>
>
> Hi Andrew,
>
>
>
> Solid points all round.
>
>
>
> I had really not grasped it properly before, but I can now see how the
> concept of actually encouraging the rapid exhaustion of v4 would certainly
> be a game changer.
>
>
>
> To take it further, would you say that STOPPING the allocation of v4
> starting NOW would have more impact? Of course this would have several
> downsides that would need to be mitigated. For instance, I can see that
> this would translate into financial challenges for Afrinic as they do rely
> (not sure about this) on the revenue from the sale of IPs to fund their
> operations. No one likes to lose money, not even a non-profit :)
>
>
>
> I would really like to hear your thoughts on this.
>
>
>
> Hi Mark, very true. v6 on mobile should be pretty much done by now. Also,
> I can already hear that the other big service providers are starting to
> stir due to this challenge from Liquid. Perhaps it will even turn into a
> race that makes us all winners.
>
>
>
> @ Barrack - cheers mate.
>
>
>
> Regards,
>
>
>
> *Kevin K.*
>
> *+254720789158*
>
>
>
> On 12 October 2016 at 16:22, Andrew Alston <Andrew.Alston at liquidtelecom.
> com> wrote:
>
> Hi Mark,
>
>
>
> In the mobile space (LTE), and in the wireless space – while I can’t
> comment on specifics, watch this space.
>
>
>
> In particular in KE and ZM dependent on which technology you’re referring
> to.
>
>
>
> Thanks
>
>
>
> Andrew
>
>
>
>
>
> *From:* Mark Tinka [mailto:mark.tinka at seacom.mu]
> *Sent:* 12 October 2016 15:55
> *To:* Andrew Alston <Andrew.Alston at liquidtelecom.com>; Kevin Kamonye <
> kevin.kamonye at gmail.com>; KICTAnet ICT Policy Discussions <
> kictanet at lists.kictanet.or.ke>
> *Cc:* General Discussions of AFRINIC <community-discuss at afrinic.net>;
> Barrack Otieno <otieno.barrack at gmail.com>
> *Subject:* Re: [Community-Discuss] IPv6 Chapter 254
>
>
>
>
>
> On 12/Oct/16 13:31, Andrew Alston wrote:
>
>
>
> On this map, you will see there are only two countries in Africa that have
> in excess of half a percent v6 penetration levels.  One is Sudan, and one
> in Zimbabwe.  Zimbabwe currently runs at 4.76% penetration and climbing –
> beyond that the rest of Africa has effectively no real penetration.  Now,
> compare that to the rest of the world where v4 is depleted, and you see a
> vastly different picture.  The global average deployment rate is sitting at
> 12% and climbing, whereas all it took to **double** the aggregate
> penetration rate in Africa was the v6 enabling of 10 or 15 thousand FTTH
> users in Zimbabwe.  This speaks volumes, we have v4, and its slowing us
> down in getting v6 deployed.
>
>
> Given that consumers don't generally get a say in when IPv6 can be
> enabled, that helps a lot. Much of Europe, North America and Asia-Pac have
> sufficient broadband into people's homes that makes all the difference.
>
> A number of major mobile operators in that part of the world have also
> turned on IPv6.
>
> The majority of Internet access in Africa happens in the mobile space
> today. If we want to see the needle shift even a hair's width, mobile
> operators in Africa need to enable IPv6. As of today, I have neither seen
> nor heard of any plans from any major or small mobile network operator in
> Africa re: turning on IPv6, never mind have a strategy or plan.
>
> If wire-line and non-GSM wireless service providers in Africa were to
> enable IPv6 for their broadband customers, there would be an improvement in
> the outlook (by your own experience in Zimbabwe), but not as much as if the
> mobile operators came to the party. It is absurd that there is no interest
> from this group, considering that the thinking is that it is cheaper to
> spend millions of $$ to sustain NAT444444444 than it is to roll out IPv6.
>
> Mark.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.kictanet.or.ke/pipermail/kictanet/attachments/20161013/c18f8c1a/attachment.htm>


More information about the KICTANet mailing list