<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0cm;
margin-right:0cm;
margin-bottom:0cm;
margin-left:36.0pt;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:404648859;
mso-list-type:hybrid;
mso-list-template-ids:873201884 -423714186 134807577 134807579 134807567 134807577 134807579 134807567 134807577 134807579;}
@list l0:level1
{mso-level-number-format:alpha-lower;
mso-level-text:"%1\.\)";
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l1
{mso-list-id:1139879254;
mso-list-type:hybrid;
mso-list-template-ids:2122190294 769291050 134807577 134807579 134807567 134807577 134807579 134807567 134807577 134807579;}
@list l1:level1
{mso-level-number-format:alpha-lower;
mso-level-text:"%1\.\)";
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l1:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l1:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l2
{mso-list-id:1252471774;
mso-list-template-ids:-725344;}
@list l2:level1
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:36.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l2:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:72.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l2:level3
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:108.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l2:level4
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:144.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l2:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:180.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l2:level6
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:216.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l2:level7
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:252.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l2:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:288.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l2:level9
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:324.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
ol
{margin-bottom:0cm;}
ul
{margin-bottom:0cm;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-GB" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US">Andre,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US">I must join with Owen in opposition to this policy, for pretty much all the reasons he has stated, the reasons I have stated in the past, and for
a few other points. But – let me try and put this in point form to be brief, and to also address the point as regards /18s.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<ol style="margin-top:0cm" start="1" type="a">
<li class="MsoNormal" style="margin-left:0cm;mso-list:l1 level1 lfo3"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US">There are multiple networks on this continent who are involved in massive and costly rollouts, to
serve customers. Irrespective of the stance of v6 on those operators, they still have a requirement for v4 resources today to continue to connect customers on the ground. In the case of our own network, while substantial work is on going towards being able
to do a combination of 464XLAT and NAT64 in an effort to move away from v4, and while we have the highest percentage of v6 to v4 traffic to customers on the continent (by a LONG way), we have a need for v4 *<b>today</b>* to continue our expansion as we move
ever closer towards a v6 centric environment.<o:p></o:p></span></li><li class="MsoNormal" style="margin-left:0cm;mso-list:l1 level1 lfo3"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US">The above point in no way suggests that work is not being done to minimize the use of v4 and use
it prudently as we move in this direction, indeed, I will state publically and on the record, we have significant sections of our network running IPv6 only with zero ipv4 – and while that has slowed our burn rate on v4 addresses and slowed down our need to
do another application – it has not eliminated the burn rate entirely – and we’re still eating up space such that limitations of a /18 would effectively force us into the secondary market within 60 days of receiving said space.<o:p></o:p></span></li><li class="MsoNormal" style="margin-left:0cm;mso-list:l1 level1 lfo3"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US">The costs involved in turning to the secondary market would have to be born by someone – namely
the consumer – and this would be detrimental to growth and detrimental to the people on the ground.<o:p></o:p></span></li><li class="MsoNormal" style="margin-left:0cm;mso-list:l1 level1 lfo3"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US">The fact is – the infrastructure is there to connect consumers today – the money is invested – vast
amounts of it – why should we, and our customers, be prejudiced by those who have not yet got around to building networks to utilize the space, particularly in light of the fact that there is zero substantiation or factual statistics that show when and if
the utilization of this space by these mythical networks will occur.<o:p></o:p></span></li><li class="MsoNormal" style="margin-left:0cm;mso-list:l1 level1 lfo3"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US">I point to the fact that one particular group on this list has been consistently announcing for
2 years about a coming network – to this day – where is it? The /22 allocated to that organisation is to this day, years after being allocated, still only 25% announced in the global table. So we must hold back space, damage the consumer and the market in
places where the networks are ready, for people who talk the talk – but aren’t walking the walk?<o:p></o:p></span></li><li class="MsoNormal" style="margin-left:0cm;mso-list:l1 level1 lfo3"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US">I am also hopeful that with the coming of certain protocols (segment routing being high on that
list), and with the new code coming available in various router operating systems, that the ability to properly do 4PE (IPv6 over IPv4) will arrive soon – that will also slow burn rates considerably and allow for some reallocation of space – so basically –
what I’m saying is – probably 6 to 12 months from now, I would recon it would be possible to start releasing v4 from further portions of the network and recycling it to places where its truly needed – but right now – more v4 is needed – today – to address
consumers – and it is blatantly prejudicial to not allow providers who can, within the bounds of current needs based policy, utilize the space today, to have what they need to the detriment of the consumer.<o:p></o:p></span></li></ol>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US">As I have stated time and again with this policy – and it is a point that has *<b>NEVER</b>* been addressed by the authors of this policy – we have
to make a decision – are we in this for the consumer on the ground – who needs the space today – or are we in this to protect the interests of ISP’s who either do not yet exist, or who have not been able to create sufficient infrastructure to utilize the space
today. I argue that AFRINIC is meant, under its mandate, to promote the penetration of Internet in Africa – and this policy runs in direct contravention of said mandate – since it slows down that development and will ultimately lead to additional costs that
have to be born by the consumer on the ground.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US">I would also point out that in the absence of an inter-region transfer policy, AfriNIC is a de-facto monopoly, potentially in contravention of certain
competition acts that exist in various countries. By holding onto space and refusing to give it to those who have a real need for it, while not allowing space to be brought in from outside the region, that monopoly is being abused to the detriment of the
ISP’s who need the space today, and could well end up placing Afrinic at legal risk, because there are certain facts that have to be acknowledged should this come to pass<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<ol style="margin-top:0cm" start="1" type="a">
<li class="MsoListParagraph" style="margin-left:0cm;mso-list:l0 level1 lfo4"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US">AFRINIC has resources available – they are refusing to distribute them
<o:p></o:p></span></li><li class="MsoListParagraph" style="margin-left:0cm;mso-list:l0 level1 lfo4"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US">AFRINIC through its lack of inter-region transfer policy is denying ISP’s access to the secondary
markets – and thereby putting their businesses in jeopardy<o:p></o:p></span></li><li class="MsoListParagraph" style="margin-left:0cm;mso-list:l0 level1 lfo4"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US">While an internal in-region transfer policy exists – there is no guarantee that there will
be willing sellers on the continent – nor is there any indication of what the pricing will be like. In the event that space is available on the international secondary market and there is none in Africa – and while AFRINIC does not have an inter-region transfer
policy – and while they are sitting on resources that they will not allocate to those who need them – you better believe that it creates a bit of a legal predicament.<o:p></o:p></span></li></ol>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US">So for all those reasons, and everything I’ve stated before, including many reasons which have gone ignored by the authors – I continue to oppose
this policy – and my objections are at present, sustained and unaddressed.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US">Andrew<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Andre van Zyl [mailto:vanzyla@bcxcomms.net]
<br>
<b>Sent:</b> 31 July 2017 00:58<br>
<b>To:</b> Owen DeLong <owen@delong.com><br>
<b>Cc:</b> rpd List <rpd@afrinic.net><br>
<b>Subject:</b> Re: [rpd] IPv4 Soft Landing BIS<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">On Sat, 29 Jul 2017 09:05:12 -0700<br>
Owen DeLong <<a href="mailto:owen@delong.com">owen@delong.com</a>> wrote:<br>
<br>
> <br>
> <br>
> > On Jul 28, 2017, at 17:13, Andre van Zyl <<a href="mailto:vanzyla@bcxcomms.net">vanzyla@bcxcomms.net</a>> wrote:<br>
> > <br>
> > Hi Owen,<br>
> > <br>
> > It might just be me, but I'm struggling to understand your actual position at the moment.
<br>
> > <br>
> > In the first part of your response below, you seem to argue for doing away with IPv4 as soon as possible, yet later, in your egg analogy, you seem to be making the case that restricting existing operators' access to further IPv4 resources is damaging their
business?<br>
> <br>
> Yes. Both are presently true. The sooner the internet moves away from this IPv4 dependency, the better it will be. The IPv4 dependency does, however unfortunately, exist today. So yes, you have summarized the facts surrounding my position accurately.
<br>
> <br>
> <br>
> > <br>
> > For the record, I am very much in favor of the move to IPv6 as far and as fast as is practical. However, there is no denying that IPv4 will not go away soon, so I am in favor of protecting IPv4 resources for new operators to be able to connect to the legacy
internet, from an IPv6 network. Does that merit reserving the size of block as per this proposal? Perhaps not, but I think some needs to be reserved.<br>
> <br>
><br>
<br>
Just to make it clear, I would not be in favour of adopting this proposal as-is. I question some of the allocations, and I don't think it does enough to steer operators down the path of IPv6. I am not at all in favor of giving out our last IPv4 resources for
operators to continue building out IPv4 access and maintain the status quo. But, it does have some parts I very much agree with, like ensuring that new entrants, who will invariably be IPv6-based, have some way to reach the IPv4 internet.<br>
<br>
><br>
> This is my point. This proposal doesn't protect resources, it prevents them from being used.<br>
><br>
<br>
If you are referring to the /13 reserved for future use, I tend to agree. Why have a block that size just sitting around?<br>
<br>
In phase one, existing operators can still get /18 allocations, so resources are being used.
<br>
<br>
Then in phase two the protection of new entrants kicks in. It is not so much the protection of new entrants' ability to build an IPv4 network that I would want to protect, but their ability to connect their shiny new IPv6 network to the legacy IPv4 internet.
I initialy questioned the size of a single /22 allocation as too small, but on second thoughts, it may actually be a positive step to ensuring that it gets used only for IPv4 legacy access and not to maintain the IPv4 status quo. They could well go to the
transfer market to get v4 resources to build out a v4 only network, but then thats a decision they make, and they'll pay for that.
<br>
<br>
> <br>
> > <br>
> > See further comments in-line below.<br>
> > <br>
> > <br>
> > On Fri, 28 Jul 2017 12:02:53 -0700<br>
> > Owen DeLong <<a href="mailto:owen@delong.com">owen@delong.com</a>> wrote:<br>
> > <br>
> >> <br>
> >>> On Jul 28, 2017, at 04:18 , Jackson Muthili <<a href="mailto:jacksonmuthi@gmail.com">jacksonmuthi@gmail.com</a>> wrote:<br>
> >>> <br>
> >>> On Fri, Jul 28, 2017 at 9:32 AM, Owen DeLong <<a href="mailto:owen@delong.com">owen@delong.com</a>> wrote:<br>
> >>>> <br>
> >>>>> On Jul 27, 2017, at 22:45 , Jackson Muthili <<a href="mailto:jacksonmuthi@gmail.com">jacksonmuthi@gmail.com</a>> wrote:<br>
> >>>>> <br>
> >>>>> On Thu, Jul 27, 2017 at 1:16 AM, Owen DeLong <<a href="mailto:owen@delong.com">owen@delong.com</a>> wrote:<br>
> >>>>>> <br>
> >>>>>> Frankly, IMHO, the preservation of IPv4 is strictly a way of inflicting<br>
> >>>>>> additional cost and pain on the majority of the internet. Unfortunately,<br>
> >>>>>> much like toxic polluters of the 70s and 80s, most of the cost and pain is<br>
> >>>>>> inflicted on those who are ready for IPv6 rather than those who remain<br>
> >>>>>> unprepared for that future. The good news is that if the current adoption<br>
> >>>>>> rates continue, the holdouts that haven’t implemented IPv6 will become<br>
> >>>>>> mostly irrelevant relatively soon and when the rest of us start turning off<br>
> >>>>>> IPv4, they will be the ones left out in the cold wondering what happened<br>
> >>>>>> instead of inflicting costs and pain on the rest of us.<br>
> >>>>>> <br>
> >>>>>> The sooner the internet moves on from its unhealthy IPv4 addiction the<br>
> >>>>>> better. I’m pretty sure you know this as well as I do, despite all of your<br>
> >>>>>> apparent protestations to the contrary.<br>
> >>>>> <br>
> >>>>> - Our region is still a young and growing region relative to yours.<br>
> >>>> <br>
> >>>> Like it or not, Jackson, I’m part of this region, too. Nonetheless,<br>
> >>>> <br>
> >>>>> - IPv6 is the end. But IPv4 is still a means to the end.<br>
> >>>> <br>
> >>>> No… IPv4 is a temporary means of survival and is to some extent the status quo. Nothing more.<br>
> >>> <br>
> >>> It can be looked at as a temporary means of survival and that very<br>
> >>> premise makes it the means to the IPv6 end. Because the internet still<br>
> >>> operates mostly on IPv4 and an IPv6 only island cannot be reached to<br>
> >>> by an IPv4 only island unless there a mechanism to make the two<br>
> >>> co-exist has been applied. So semantics aside we seem to agree in<br>
> >>> principle.<br>
> >> <br>
> >> No, the IPv6 end can be achieved without any IPv4 at all if one desires to do so.<br>
> > <br>
> > How would this IPv6-only network connect to the legacy IPv4 internet?<br>
> <br>
> It doesn't. If we are at the IPv6 "end" being described, there isn't really an IPv4 internet to connect to. My point isn't that about connecting v6 and v4. It's about the fallacy that v4 resources are necessary or even particularly useful for deploying IPv6.
There was a time when this was somewhat the case, but today, v4 resources are really only useful for communicating with the legacy internet and nothing more.
<br>
> <br>
><br>
<br>
If I understand you correctly, then I agree, which is why I would like to see more explicit wording in the policy around how any new allocations can be used. I fail to see the point of handing out resources to simply continue the IPv4 status quo at this late
stage. <br>
<br>
> > <br>
> >> <br>
> >> IPv4 doesn’t do anything to help you deploy IPv6.<br>
> >> <br>
> >> Therefore, IPv4 is not an means to the IPv6 end. IPv4 is a means to communicate<br>
> >> with the legacy internet. Nothing more, nothing less.<br>
> > <br>
> > Ah, so you kinda DO need IPv4 then.<br>
> <br>
> I never said you didn't need IPv4 today. I'm saying it is becoming less and less necessary and making sure that there's a bunch of it still on the shelf when it becomes useless by denying it to operators with a clear and present need is simply bad resource
management. <br>
> <br>
><br>
<br>
As far as the /13 is concerned, I agree with you. <br>
<br>
As far as the other two phases of this specific policy go, operators have known for years that IPv4 allocations would run out. Under phase one, allocations of up to /18 continue on a needs basis. Granted, that is not a lot of resources to build out IPv4 infrastructure
on, but, it is plenty enough to deploy NAT64, dual-stack critical infrastructure etc. So, in light of the inevitable cliff that we all know is coming, if you are continuing to request IPv4 resources to use for maintaining the IPv4 status quo, then I really
cannot help you. If you are requesting IPv4 resources to interconnect the IPv4 and IPv6 worlds, then I think that the /18 will go a long way towards that end.
<br>
<br>
> > <br>
> >> <br>
> >>>>> - If IPv6 were the absolute solution we would not have a booming a<br>
> >>>>> billion dollar IPv4 market.<br>
> >>>> <br>
> >>>> That’s the same kind of logic currently being used by the climate change deniers.<br>
> >>>> <br>
> >>>> In the 1960s and 1970s, in my other region, the argument was that if dumping toxic chemicals<br>
> >>>> into waterways was a real problem, it wouldn’t be so cheap to do so. Fortunately, the<br>
> >>>> EPA was created and huge fines were put in place and the superfund was created to try and<br>
> >>>> shift some of the costs of these toxic waste dumpings back on to the sources instead of<br>
> >>>> the down-stream victims.<br>
> >>> <br>
> >>> I don't think we should parade IPv4 at the same level as toxic and<br>
> >>> hazardous waste.<br>
> >> <br>
> >> I’m not. I’m parading the use of IPv4<br>
> <br>
> That should have bee placing instead of parading. Damn autocorrect. <br>
> <br>
> >> combined with the failure to implement IPv6<br>
> >> at a similar level because it has the same kind of cost-shifting effect.<br>
> >> <br>
> >>> But using your analogy, please help me understand how the two liken,<br>
> >>> who is dumping what on who, and which side is facing any costs as a<br>
> >>> result.<br>
> >> <br>
> >> By failing to implement IPv6 and continuing to operate IPv4 only, an organization is<br>
> >> forcing everyone else that wants to communicate with them to continue to maintain and<br>
> >> in some cases expand their own IPv4 infrastructure at an ever increasing cost, much the<br>
> >> way that those dumping toxic waste were saving money by not paying for hazmat disposal<br>
> >> while shifting costs on to the downstream public in the form of medical bills, cleanup<br>
> >> costs, etc.<br>
> > <br>
> > I actually agree with this. On the flip side though, is it not just as toxic if we do not ensure that new entrants have at least limited access to IPv4 resources to reach the legacy internet from their IPv6 networks without having to resort to the (out
of region) transfer market?<br>
> <br>
> Not at all. New entrants are facing increased costs to communicate with the IPv4 internet, but these are not costs shifted on to them by the malfeasance of others. They are the rising cost of a limited resource running out. Further, these costs are predictable
and mostly a one-time expense where the costs being shifted above are unpredictable and recurring until such time as these other entities implement IPv6.
<br>
> <br>
><br>
<br>
I don't think I follow here - why does the new operator going to the transfer market result in a predictable and mostly one-time cost, but the existing operator doing the same results in unpredictable and recurring costs?<br>
<br>
> > <br>
> >> <br>
> >> Do you understand now?<br>
> >> <br>
> >>>>> - As the growing region transits to IPv6 there will still be need for<br>
> >>>>> IPv4 meantime. If our IPv4 is not well and meticulously managed during<br>
> >>>>> this period it will cost our operators more to buy from the market as<br>
> >>>>> AfriNIC runs out completely.<br>
> >>>> <br>
> >>>> I actually agree with you here. That’s why I oppose the terrible mismanagement<br>
> >>>> proposed in the soft landing BIS proposal which would deprive operators of networks<br>
> >>>> in the region of the addresses they need in the present in order to protect imaginary<br>
> >>>> future operators who may never materialize.<br>
> >>> <br>
> >>> OK, if you opt to think in binary, you will be right. But you of<br>
> >>> course know that this is not how planning and forecasting works. The<br>
> >>> region is growing. AfriNIC member numbers are increasing year on year<br>
> >>> and most are small players. And when you look at those numbers in each<br>
> >>> country and other metrics like internet penetration rates per country<br>
> >>> to mention but a few, you know that the forecasts are based on facts.<br>
> >>> If dinner was served at your table and you got home before your kids,<br>
> >>> would you eat all of it because they are not yet home?<br>
> >> <br>
> >> That’s not a valid analogy here and you known it. These speculative future<br>
> >> startups that are in your forecast aren’t my children. They’re other customers<br>
> >> going to the same store that I am going to.<br>
> >> <br>
> >> Let’s use a better analogy… This is more like a store being operated in a time of shortage.<br>
> >> Let’s use eggs for the example.<br>
> >> <br>
> >> As a store owner, you know that there is a looming shortage of eggs because of some horrible<br>
> >> disease that has afflicted all of the local chickens and egg production is less than 1/4 of<br>
> >> normal.<br>
> >> <br>
> >> Would you limit the number of cartons of eggs each customer can buy and prohibit customers from<br>
> >> getting in line again if they need more eggs? Would you tell the commercial bakery down the street<br>
> >> that you will not sell them 12 dozen eggs because you might have families coming in tomorrow that<br>
> >> might need eggs?<br>
> >> <br>
> >> No, you’re going to pocket the cash as fast as you can and sell the eggs to whoever wants to buy<br>
> >> them.<br>
> >> <br>
> >> Obviously this is still a flawed analogy in that we do actually place some limits and only allow<br>
> >> each person to buy the eggs that they can show they actually intend to use and need. (the store<br>
> >> owner would not accept or place such restrictions on his commerce)<br>
> >> <br>
> >> However, it’s at least a little closer. Now, let’s suppose that you do actually tell the baker<br>
> >> that he can only have 1 dozen eggs same as everyone else and that he can’t buy any more eggs<br>
> >> for 2 years. Let’s assume that these families you expected don’t come for eggs, but are, instead,<br>
> >> all lined up outside the bake shop trying to buy bread. Unfortunately, the baker already sold all<br>
> >> the bread he could make from a dozen eggs and now he has no more source of revenue. The bake shop<br>
> >> closes for lack of revenue and all of those families you thought you were going to help are now<br>
> >> going hungry because they cannot get the bread they wanted.<br>
> > <br>
> > This is where you start to lose me, because your analogy says that if existing operators don't get the IPv4 resources they require, it will hurt their business. You make no mention of IPv6 in the analogy, and I think that is where the analogy falls flat.
<br>
> > <br>
> > Existing operators with IPv4 resources are highly unlikely to go out of business because IPv4 resources ran out. However, a new entrant with only IPv6 space is going to have a tough time retaining customers because they cannot reach the whole internet,
and are probably far more likely to fail than the operator who couldnt get more IPv4 resources.
<br>
> <br>
> But that isn't what we are talking about here. What we are talking about is really should an existing provider be forced to pay a higher price for addresses in the transfer market in order to preserve and effectively subsidize possible future competitors
ability to obtain addresses at a lower cost?<br>
> <br>
><br>
<br>
Actually, nobody is subsidizing anyone. The bill comes due, for everyone - existing and new operator alike. If the new operator requires more than a /22 he's going to have to go to the transfer market, just like the existing operator.
<br>
<br>
> > <br>
> >> <br>
> >>>> Forcing present operators to pay higher rates in the transfer market because they cannot<br>
> >>>> get the addresses they need in order to preserve inventory for operators that don’t actually<br>
> >>>> exist is nonsensical and quite far from anything I would consider to be “meticulous management”<br>
> >>> <br>
> >>> It is also a bit nonsensical to pretend that there will be no new<br>
> >>> operators. This is oblivion at its best. The continent still has many,<br>
> >>> many businesses (and other projects such as schools, community<br>
> >>> networks etc) that are upcoming within this transition phase that will<br>
> >>> NOT afford IPs from the transfer market and they need to be catered<br>
> >>> for. Of course an IPv6 only option will not be their solution as you<br>
> >>> are aware.<br>
> >> <br>
> >> I am not pretending there will be no new operators. I am saying that the protection<br>
> >> of new operators which may or may not come into being (surely some will, but can you<br>
> >> guarantee it will be enough to consume the amount of address space this policy proposes<br>
> >> to set aside for them? Didn’t think so) at the expense of existing operators. Let the<br>
> >> new operators and the existing operators compete for the addresses on a level first come<br>
> >> first served playing field. When the address space is gone, it is gone. C’est la vie.<br>
> > <br>
> > I think this is a matter of perspective, but I cannot agree with you here. Requiring a new entrant to potentially shop the transfer market at the get-go to get IPv4 resources to have full internet reachability for their customers significantly raises the
barrier to entry for newcomers, and is a sure-fire way to stunt the growth of new operators. And what about non-profit, education and community networks?
<br>
> <br>
> So it is your opinion that we need a "Robin Hood" policy that effectively takes money from existing operators (by prematurely forcing them to the transfer market) in order to subsidize cheaper addresses for possible future competitors.
<br>
> <br>
> <br>
><br>
<br>
No, that is not my opinion. My opinion is that we need a policy that stops greedy corporates gobbling up our last IPv4 space, without any thought further than the buck they can make off that IPv4 space now. We need a policy that protects the ability of those
who deploy IPv6 networks off the bat to be able to access the IPv4 internet. We need a policy that does not undermine the not unsubstantial non-commercial internet initiatives on this continent to protect corporate greed. What you are arguing does none of
that, protects the corporate balance sheet in the here-and-now, but does absolutely nothing to ensure universal internet access provisioning in Africa.
<br>
<br>
And again, nobody is subsidizing anyone. The bill comes due, for everyone.<br>
<br>
The difference is that the existing operator has had the benefit of 1 to X applications for cheaper IPv4 resources, with their last being up to a /18 as per the policy.
<br>
<br>
Under this policy the new operator in phase 2 gets the benefit of exactly ONE resource application for a maximum allocation of a /22.
<br>
<br>
Then both have to hit the transfer market to get more. <br>
<br>
IPv4 is running out, plain and simple. Any existing operator knows this, and if they hit their last phase 1 /18 allocation, and have not done anything to use that, or a prior allocation, for IPv6/IPv4 access enablement, then I am sorry, but they are in that
position of their own doing, and it is not fair to make new entrants into the market pay for their inaction.<br>
<br>
As an example: There is a residential ISP in South Africa who has over 500 IPv4 prefixes. How many IPv6 prefixes do they announce? None. ZERO. You are saying that this operator should be allowed as much more IPv4 space as they can get, until it runs out, and
tough luck to the new IPv6 operator down the line who needs IPv4 to connect to the legacy Internet. I'm sorry, I can not, and won't support the continued distribution of IPv4 resources to existing operators to maintain the IPv4 status quo.<br>
<br>
I disagree with your argument that this taxes the existing operator to subsidize the new entrant. If anything, this places an additional tax on new entrants because the existing operators are dragging their heels in deploying IPv6. In keeping with the "Robin
Hood" theme, is that not a "Prince John" policy?<br>
<br>
><br>
> I suppose if that is your intent, then supporting this proposal makes sense. However, I consider that to be a form of graft and I cannot support it.
<br>
><br>
><br>
<br>
I have to admit I tried to make the connection to graft here, and failed miserably. Can you explain how anyone is benefitting untowardly here?
<br>
<br>
><br>
> > <br>
> >> <br>
> >>>>> - A mechanism to put in place a carefully managed runout which ensures<br>
> >>>>> fair allocation specifically for a region like Africa that has many<br>
> >>>>> late business and startups is very critical for us.<br>
> >>>> <br>
> >>>> If I were to see such a proposal, I would support it. The proposal that is the subject<br>
> >>>> of this thread is pretty far from that.<br>
> >>> <br>
> >>> It does to some extent Owen. It applies limitations to slow down<br>
> >>> consumption rates. Your only strong argument is that those operators<br>
> >>> are imaginary, which you very well know us a flawed argument because<br>
> >>> it defeats the very existence of the concept of planning and<br>
> >>> forecasting.<br>
> >> <br>
> >> But these limitations don’t reduce need, they only reduce consumption. They create an<br>
> >> artificial shortage early in order to prolong the duration of the real shortage later.<br>
> >> <br>
> >> That’s not carefully managing runout, that’s screwing the entire community to protect<br>
> >> a small part of the community that doesn’t even exist yet and may never exist.<br>
> > <br>
> > Can you explain what you mean here? I don't understand how these are different - surely the nett effect is that there is still a shortage, irrespective of how it was induced.
<br>
> <br>
> Today, there is a free pool and no actual shortage. If we prevent people who need it from obtaining addresses while we still have them, then we have created an artificial shortage at least for those who are denied addresses.
<br>
> <br>
> Yes, there is inevitably a real shortage coming at some point. However, the argument has been made that this proposal postponed shortages. The reality is that it increases the duration of shortages by delaying the end of the free pool and making the effective
beginning of shortages much much earlier. <br>
> <br>
> > <br>
> >> <br>
> >> I’m not saying that there will be no new operators. I’m saying that you don’t know how<br>
> >> long the space will last under the limitations proposed and that you can only implement<br>
> >> those limitations if you prevent people who actually need addresses today from getting<br>
> >> them. <br>
> >> <br>
> >>> <br>
> >>>>> - Irrespective and irrelevant of evolution of the proposal and<br>
> >>>>> bickering of authors the proposal has the best interests of African<br>
> >>>>> network operators and Africa region in general.<br>
> >>>> <br>
> >>>> Here we couldn’t disagree more. This proposal has the best interests of imaginary operators<br>
> >>>> that don’t even exist and may never exist being placed above the needs of real operators that<br>
> >>>> actually have networks and customers they are trying to serve today.<br>
> >>>> <br>
> >>>> I don’t deny that the authors genuinely believe that they are acting in the best interests of<br>
> >>>> the community. I’m not accusing anyone of malfeasance or malicious action beyond the ad hominem<br>
> >>>> and hostile rhetoric which has served only to make it more difficult for the community to find<br>
> >>>> common ground.<br>
> >>> <br>
> >>> Yes at this stage let us continue to reason within what is the long<br>
> >>> term best interest of our community. In this case I mean Africa. In<br>
> >>> the same faith, your analogy of imaginary operators is still baffling<br>
> >>> me. I wonder what makes you think the internet in the continent has<br>
> >>> stopped growing and that no new operators will emerge.<br>
> >> <br>
> >> I never said anything of the sort.<br>
> >> <br>
> >> What I mean by “imaginary operators” is that you are setting aside a vast amount of address space<br>
> >> out of the reach of clear and present need today in favor of operators that don’t (yet) exist, with<br>
> >> no clear evidence to support any belief that a sufficient number of operators will exist within the<br>
> >> useful lifetime of the IPv4 protocol to actually consume that amount of address space before IPv4<br>
> >> becomes readily available again due to being generally useless.<br>
> >> <br>
> >> Protecting the free pool from legitimate use strictly for the sake of procrastinating the official<br>
> >> date of runout is like pretending that a bond-issue is free money because it doesn’t immediately<br>
> >> raise taxes. I’ve got news for you… Those bonds eventually have to be paid back, so either taxes<br>
> >> go up, or, the government cuts services.<br>
> >> <br>
> >> Depriving today’s providers of addresses deprives real customers of those same addresses today. Is<br>
> >> it really so important that whatever small startup may arise 3, 5, 10 years from now be able to get<br>
> >> a /24 that it is worth keeping 200+ existing households from getting internet service today?<br>
> >> <br>
> >> Really?<br>
> >> <br>
> >> If your answer to that is “no”, then you need to realize that you have been defending a proposal<br>
> >> which seeks to do exactly that and consider changing your position.<br>
> >> <br>
> >> If your answer is “yes”, then likely we have no common ground, my objection is valid, reasonable,<br>
> >> and sustained and we should agree that we will continue to disagree.<br>
> > <br>
> > Actually, my answer is yes, for two reasons:<br>
> > 1) Based on your own defence of IPv6 in this mail trail, why can't these households be serviced using IPv6 at this time? Why defend the use of IPv4 right until there really are no more IPv4 addresses? What exactly is the difference, for an existing operator,
between a) no more IPv4 resources due to policy and b) no more IPv4 resources due to there physically not being any more IPv4 resources? They still have no more IPv4 resources either way.<br>
> <br>
> The difference is whether or not it is fair. If everyone faces "no more v4 due to policy" then that's silly, but fair. On the other hand, if you are making operations more expensive for existing providers in order to subsidize their possible future competitors,
then that only seems fair if you buy into the whole Robin Hood myth. <br>
> <br>
><br>
<br>
But I would argue that everyone IS facing "no more V4 due to policy". All a new operator will get in phase 2 is a /22. What can you realistically see a new operator do with a /22 besides use it to bridge v4/v6 - that will be critical internet infrastructure
for an operator in the coming times until v4 is switched off. And that is years out still.<br>
<br>
To me, letting existing operators have unlimited access to v4 resources, to continue the v4 status quo, is monopolistic and no more fair than giving new operators an opportunity to get a fraction of the v4 resources that existing operators have already received,
at the same cost.<br>
<br>
><br>
><br>
> > 2) That /24 could indeed light up an IPv4 internet service for 200+ households, however, it could also provide legacy internet access for many more IPv6 users. Which you think is more important probably depends on your perspective, but I'd rather use that
/24 to service a couple of thousand IPv6 users than use it to service < 250 IPv4 users.<br>
> <br>
> This is nonsensical. First, it's just as likely to provide NAT64 to many more IPv6 households at an existing provider as it is with a new entrant. Possibly more likely. There's. Nothing in this proposal to drive the "new entrant" to actually use the addresses
in that manner. So the real question is whether it is better to light up however many households today with an established provider or to leave them in the dark until some theoretical new entrant arises to serve them with these subsidized addresses.
<br>
><br>
><br>
<br>
Either you have now you have moved the goalposts here, or I misunderstood you initially. My response was in the context of your question of whether I would use that /24 to light 200+ households with v4, or keep it for future use by a new operator. My argument
is that it is better in the long run to serve thousands of v6 households than to serve <250 v4 households.<br>
<br>
However, if you meant that the /24 would be used by the existing operator for NAT64 or the like, then I could agree with that, provided the could demonstrate the need and planning beyond "oh gosh, we didnt make any provision in our /14 for v4/v6 access, let
me have another /16 and maybe I'll get around to it". This would probably include things like demonstrating that the operator was unable to refarm any of his existing v4 allocation for v4/v6 access enablement.<br>
<br>
You are quite right though about nothing in the Soft Landing BIS proposal to drive how the final allocations get used, and I think that a proposal of this kind should address that.
<br>
<br>
> <br>
><br>
> Second, I find the idea that you are using IPv4 to connect IPv6 households to "the internet" to be a reflection of a gross mischaracterization of the terms. There are, in fact, two internets. There is a vibrant and rapidly growing IPv6 internet which is not
yet as large as the IPv4 internet, but gaining ground rapidly. Beyond that, there is a haphazardly connected legacy internet full of second class citizens who lack the option of ad hoc end-to-end connectivity due to NAT which has become the hallmark of IPv4.
For this brief period in history, the IPv4 internet is larger than the IPv6 internet. But it already has a much slower growth rate and it's growth is inherently constrained. As such it will be overtaken by the IPv6 internet sooner rather than later.
<br>
><br>
><br>
<br>
No, it's very much a reality in my part of the world.<br>
<br>
So, to test your assertion here, I did a quick, simple check. I made up a (short, only 10 or so )list of important vendors, customers and companies that I interact with daily, and checked to see v6 reachability. I didnt include anything like Facebook, Twitter
etc, only companies that I need to interact with for "real-life" things like work, banking etc.<br>
<br>
TL;DR - I'd be screwed without some form of v4 access.<br>
<br>
To be honest, some of the results surprised me. For example, my MPLS core router vendor? Nope, no v6 MX. But how can that be, they're in the big 3 in the mobile world, AND they are on Office365? Oh snap, so strike 4 companies off my list that I email regularly.<br>
<br>
Next up, my banking & medical insurance - no luck there either, web or mail.<br>
<br>
To be honest, I gave up at this point because at this stage I was 0/8 from the sites I had checked.<br>
<br>
In the end it was still a useful exercise for me, because it reaffirmed, that, at least in my world right now, v4/v6 access enablement will remain a reality, and I remain convinced that we should ensure that v6 operators continue to have access to v4 resources
to do just that.<br>
<br>
I really think that we have an opportunity to do things differently in this region, and that includes take the lead in v6 deployment. But that is only going to happen if operators, both existing and new, can feel confident that, at least while there are two
simultaneous internets as your say, that they can come and go as they please between them, without undue financial burden. I think some sort of policy that protects a portion of our last v4 resources to achieve that, is a step in the right direction.
<br>
<br>
Andre<br>
<br>
><br>
><br>
<br>
> Owen<br>
> <br>
> > <br>
> > Regards, <br>
> > Andre<br>
> > <br>
> >> <br>
> >> Owen<br>
> >> <br>
> >> <br>
> >> _______________________________________________<br>
> >> RPD mailing list<br>
> >> <a href="mailto:RPD@afrinic.net">RPD@afrinic.net</a><br>
> >> <a href="https://lists.afrinic.net/mailman/listinfo/rpd">
https://lists.afrinic.net/mailman/listinfo/rpd</a><br>
> > <br>
> <br>
<br>
<br>
-- <br>
Andre van Zyl <<a href="mailto:vanzyla@bcxcomms.net">vanzyla@bcxcomms.net</a>><br>
<br>
_______________________________________________<br>
RPD mailing list<br>
<a href="mailto:RPD@afrinic.net">RPD@afrinic.net</a><br>
<a href="https://lists.afrinic.net/mailman/listinfo/rpd">https://lists.afrinic.net/mailman/listinfo/rpd</a><o:p></o:p></p>
</div>
</body>
</html>