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

Fri Sep 6 02:44:00 EDT 2019

I agree with David. Whilst I wish people would use IPv6, RIPE tried
something similar (although didn’t truly measure operational use) and
failed miserably. They rolled back conditioning the provisioning if IPv4
resources upon IPv6 because recipients were just receiving IPv6 and never
using it...

Sent from my iPhone

On Aug 29, 2019, at 05:12, David Farmer <farmer at umn.edu> wrote:

Those are nice words, but I don't see how ARIN can measure ”a real
commitment that organization is doing its part,” at least for most
organizations.  It is possible for some organizations, especially those
that have subjected themselves to public measurement, but I don't think it
is fair, or good policy, to effectively required public measurement of your
IPv6 progress to entitle you to receive additional IPv4 resources.

Note: the University of Minnesota participates in the World IPv6 Launch
Measurements, currently ranked 125th with an almost 62% deployment, along
with around 350 other entities. As a public institution, it is part of our
mission to participate in these kinds of activities, but even we have to
pick and choose what we participate in, no one can participate in all
such activities.

However even those measurements don't tell the whole story, most of our web
content is not IPv6 enabled at this time. I won't bore you with the
details, but suffice it to say the IT people at the University don't own
the web content, I think this is a common story. FYI, our content
management provider is moving to a new CDN later this fall, coincidentally
the new CDN is IPv6 enabled, this is happening because of market forces,
not by any planning or ability to influence planning by anyone in our
organization that even knows what IPv6 is.

Believe me, I’d like it to be as simple as tying the receiving of IPv4 to
your IPv6 deployment, but there is no simple or accurate way to measure
IPv6 deployment generally, let alone an organization’s commitment to such.
Even if there was, I'm not convinced such a policy would be effective in
increasing IPv6 deployment, and even if it would be effective, I'm further
not convinced such a policy is fair.

Thanks.

On Wed, Aug 28, 2019 at 11:12 AM Fernando Frediani <fhfrediani at gmail.com>
wrote:

> Thanks Owen for the great inputs.
>
> I would say that probably nobody would expect a 100% deployment in minimal
> details and in every device but rather a prove that it has been deployed,
> is being routed and used. In other words a real commitment that
> organization is doing its part.
>
> I think also in a eventual proposal there could be well defined exceptions
> at the discretion of ARIN's staff when properly justified the unavoidable
> limitations.
>
> Fernando
>
> On Wed, 28 Aug 2019, 12:20 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.
>

-- 
===============================================
David Farmer               Email:farmer at umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

_______________________________________________
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/20190906/d10e7bb5/attachment.htm>