[rpd] Policy areas to consider

[Andrew Alston]

I 100% agree that networks SHOULD be rolled out with dual-stack and for
myself, I have attempted to do that at every turn (to the point where the
network I am involved in runs single-topology to enforce IPv6 deployment)

That being said, I disagree that re-tooling for ipv6 makes one
impenetrable to the proverbial iceberg, because there are STILL
technologies which are critical for large providers which cannot be run
over pure IPv6.  

Yes, there are ways to work around them (you could run 6VPE, you could run
your core on private v4 and cross connect across it, etc etc), but all of
these things are still hacks in the grand scheme of things. This is a HUGE
problem.

To tell a story, the other day, I was rather excited by the fact that a
certain vendor released certain code that purported to support LDP6
(Something I have waited for, for a great deal of time).  So, I went and
got the new version, and upgraded lab devices to support itŠ and then
discovered much to my dismay that the LDP6 support that was there, still
did not allow an entire RANGE of functionality that I needed and wanted.

Yes, SR is coming and you shouldn¹t NEED LDP6 with SR, but its not
available in most hardware yet.  Yes, LDPv6 is coming, but again, its not
available in a lot of hardware and sadly certain vendors have even removed
it from the roadmaps of commonly used MPLS edge devices.

We can say IPv6 is the solution, and long term it is, but let us also not
forget the realities, until things like MPLS have full v6 and v4 parity,
we are going to continue to face an up hill battle and IPv4 addressing in
SOME form will remain necessary.

(And believe me, it hurts  to even write this, because I really long for
the day that I can remove v4 from large segments of the network I run, and
in reality, all it would require is some very basic MPLS support over v6)

Andrew


On 7/2/15, 9:12 AM, "Owen DeLong" <owen at delong.com> wrote:

>With all due respect, instead of debating whether or not to rearrange the
>deck chairs when we hit the ice berg before we leave port, perhaps it
>would be best to redesign the ship so that it won¹t sink now that we know
>what is coming.
>
>For those having trouble following the analogyŠ
>
>	IPv4 is like the Titanic. It¹s going to go down, just a matter of when.
>	Free Pool runout is one of the icebergs that can take IPv4 out.
>	AfriNIC has such a low burn rate and such a large free pool that we
>effectively
>		haven¹t left port yet.
>	If we retool the ship for IPv6, it becomes impenetrable to the existing
>icebergs.
>
>The AfriNIC region has the unique opportunity to leapfrog the rest of the
>internet by making their greenfield deployments dual-stack and/or
>IPv6-primary. There¹s more opportunity to do the initial build of the
>internet on IPv6 in Africa than anywhere else in the world. Instead of
>focusing on where, exactly, we want the deck chairs to be lined up when
>we hit the IPv4 iceberg, let¹s just deploy IPv6 so we don¹t have to care.
>It¹s a much better use of resources.
>
>Just my $0.02.
>
>Owen
>
>> On Jul 1, 2015, at 20:19 , Dr Paulos Nyirenda <paulos at sdnp.org.mw>
>>wrote:
>> 
>> On 1 Jul 2015 at 18:52, Seun Ojedeji <seun.ojedeji at gmail.com> wrote:
>> 
>>> With ARIN getting close to end of it's v4 addresses, it recently
>>>activated an
>>> interesting policy that attempts to address requests that are beyond
>>>available IP
>>> block in ARIN's pool.
>>> 
>>> https://www.arin.net/announcements/2015/20150701.html
>>> 
>>> - Will be good to see our region preparing for such day as well
>> 
>> At the current uptake if IP resources in the AFRINIC region such a day
>>is likely to be
>> more than 5 to 10 years from now - which is many "Internet light years"
>>away ! ...
>> unfortunately :-)
>> 
>>> - Will be good to see new policies emerge as a result of the emerging
>>>global
>>> realities. 
>> 
>> I think we do indeed need new policies that deliberately target to
>>speed up the IPv4
>> exhaustion in the AFRINIC region - Africa - in a useful productive way
>>that improves the
>> sustainability of AFRINIC, its LIRs and end users in a profitable manner
>> 
>> The Academic Allocation Policy draft that was rejected a few moons ago
>>tried to do this
>> but was not acceptable to the community. I do not think "reservation"
>>will yield such
>> productive and profitable sustainability while speeding up exhaustion.
>> 
>> I know that there are a few ideas floating around that could yield that
>>deliberate
>> speeding up of the IPv4 exhaustion in AFRINIC while at the same time
>>boosting the income
>> generation for our cash strapped AFRINIC and LIRs across the region. I
>>hope that someone
>> will gather the courage to write these up into a policy and face the
>>community with it !
>> 
>> Regards,
>> 
>> Paulos
>> ======================
>> Dr Paulos B Nyirenda
>> NIC.MW & .mw ccTLD
>> http://www.registrar.mw
>> 
>> 
>>> Regards
>>> sent from Google nexus 4
>>> kindly excuse brevity and typos.
>> 
>> 
>> ----------------------------------------------------------
>> Malawi SDNP Webmail: http://www.sdnp.org.mw
>> Access your Malawi SDNP e-mail from anywhere in the world.
>> ----------------------------------------------------------
>> 
>> _______________________________________________
>> rpd mailing list
>> rpd at afrinic.net
>> https://lists.afrinic.net/mailman/listinfo.cgi/rpd
>
>_______________________________________________
>rpd mailing list
>rpd at afrinic.net
>https://lists.afrinic.net/mailman/listinfo.cgi/rpd