[arin-ppml] Is it time to start requirement to have IPv6 in place before receiving Section 8.5 transfered IPv4 addresses?

[John]

I think it is possible that many organizations are or will be fully invested in ipv6 but will announce little or none of it to the Internet at large.  Most of my customers don’t announce most of their internal IPv4 networks and I can see no reason why they wouldn’t do the same with IPv6.  So I disagree with the requirement to announce IPV6 as a prerequisite to receiving from the various ipv4 pools. Announcement doesn’t correlate with use.


Sent from my iPad

> On Aug 28, 2019, at 9:19 AM, Owen DeLong <owen at delong.com> wrote:
> 
> 
> 
>> On Aug 27, 2019, at 22:07 , Fernando Frediani <fhfrediani at gmail.com> wrote:
>> 
>> I may be wrong but it looks like that for some people at some point the only thing that matters is the sensation someone may be trying to tell them how to do things than if IPv6 should be deployed or not.
>> Right, how long more will we be in this back and forth of "I know I have to deploy IPv6 but I will do on my own time" ? How long more we will hear things like "there is no other way out of transfer market" and "it is natural thing to buy more IPv4 to be in business" and then right after "Don't tell me I have to deploy IPv6".
>> 
>> There have been times in the past when deploying IPv6 had challenges, concerns or limitations, but now a days let's be honest, there are probably none.
>> 
> In fairness, this is not entirely true. The following challenges still remain in some situations:
> 
> +	Providers with a heavy reliance on MPLS for traffic engineering have no good path to managing IPv6 traffic engineering with their existing tools.
> +	There are still a significant number of providers that are not offering IPv6 to their customers
> 	-	There are workarounds for this, but they come with significant tradeoffs and in some cases real costs.
> +	Human Factors
> 	-	Perception that NAT==Security
> 	-	Limited familiarly with IPv6
> 	-	Fear of the unknown
> 	-	Other priorities
> 	-	Perceived lack of a business case
> 	-	Engineers not well able to articulate the business case to the C-Suite
> 	-	Entrenched software base that is not yet ported, especially custom internal applications and large legacy systems
> 
> I’m not saying that these issues are insurmountable, and I’m not saying we don’t need to deploy IPv6. Indeed, I’ve been beating the IPv6 drum pretty hard for many years now. However, statements like “there are probably no remaining challenges” do not reflect reality and reduce the credibility of your other statements in this regard.
>> We are in 2019, nearly 2020 and it seems there are still a significant amount of people that wishes to keep supporting the transfer market rather than do the obvious that we all know will make the Internet ecosystem to keep evolving, perhaps with less conflicts.
>> And what Albert is proposing to discuss is fair and very much reasonable, nothing out of order: simply the organization to show it is doing its job (or is there anyone the believes IPv6 is still just accessory and can wait another 20 years ?) in order that is can use the transfer mechanism of IPv4. He didn't suggest anything different than that.
>> 
> 
> There’s lots of monetary interest in the transfer market, and where there’s a perception of money to be made, voices and advocacy will follow. This is an unfortunate side-effect of capitalism and market economies.
> 
> I never said Albert was out of line, but I do not think Albert’s proposal will yield the desired results, nor do I think it is good registry policy. (See my previous comments on the proposal).
> 
> Owen
> 
> 
> _______________________________________________
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20190828/b2366c5b/attachment.htm>