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

hostmaster at uneedus.com hostmaster at uneedus.com
Fri Sep 6 01:42:43 EDT 2019

Been distracted by hurricane preps, so my response is a bit delayed.

I agree that a policy requiring IPv6 resources before allowing IPv4 
directed transfers have to be "objective" so that ARIN staff can easily 
determine if the requirement is being met.

At the low end of my proposal, the receiver having an IPv6 assignment 
before the transfer of IPv4 resources is easily determined by staff. 
However I think we need to go further, and require actual use of IPv6 
before allowing IPv4 transfers and that would require additional effort. 
This is because the receiver may simply accept an IPv6 allocation, but 
make no effort whatsoever to actually use it to pass traffic on the 
Internet, making this level of proposal useless in the objective of 
promoting the use of IPv6.

The issue is how to objectively determine if someone is "using" IPv6 on 
their allocation.  I have thought about using the various IPv6 looking 
glasses around the internet to "prove" the receiver's IPv6 allocation is 
being advertised and used, but can see many issues with staff time spent 
with verification, or these resources not showing use because the packets 
were never seen by the looking glass.

I think that an easier way is to require the receiver to provide a list of 
IPv6 addresses in their allocation that are currently being used to 
provide public accessable services, along with the type of service and 
port number that each of these hosts are listening on.  This would allow 
staff to verify that the receiver had set up at least enough IPv6 
connectivity to allow the hosts cited in the application to operate using 
IPv6 between themselves and ARIN.

Another way to verify might be the use of Arin Online for the request or 
even the regular ARIN website, using an IPv6 address from the allocated 
block, and the allocated addresses appearing in the access log.  While 
this does not verify inbound use of the IPv6 allocation, it does verify 
the outbound use of the IPv6 allocation which proves IPv6 connectivity 
exists from the allocated IPv6 block.  A dedicated host at ARIN where the 
access log is easily available to ARIN staff could be used instead for 
this purpose.

I am also considering adding language for a waiver upon a showing that 
IPv6 is not available from any of the receiver's current upstreams. 
Letters from each current IPv4 upstream would have to submitted stating 
that they do not offer IPv6 transit/peering in order to apply for the 
waiver. I agree that it is not fair to prevent someone that cannot get 
IPv6 except via tunneling from receiving additional addresses.  However, 
most commercial circuits set up in the last 10 years are able to get IPv6 
transport included, so I do not see very many waivers granted, even in 
small places.

Any other ideas of a better way to verify use of IPv6 for this proposal?

Albert Erdmann
Network Administrator
Paradise On Line Inc.

On Wed, 28 Aug 2019, David Farmer 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
> _______________________________________________
> 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
> ===============================================

More information about the ARIN-PPML mailing list