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 <[email protected]> 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, <[email protected]> wrote: On Aug 27, 2019, at 22:07 , Fernando Frediani <[email protected]> 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 ([email protected]). Unsubscribe or manage your mailing list subscription at: https://lists.arin.net/mailman/listinfo/arin-ppml Please contact [email protected] if you experience any issues. -- =============================================== David Farmer Email:[email protected] 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 ([email protected]). Unsubscribe or manage your mailing list subscription at: https://lists.arin.net/mailman/listinfo/arin-ppml Please contact [email protected] if you experience any issues.
