Re: [arin-ppml] Draft Policy ARIN-2019-4: Allow Inter-regional IPv6 Resource Transfers

Fri, 05 Apr 2019 08:23:44 -0700

The statement sounds better than before, but I am still opposed to allowing Inter-regional transfers of IPv6 Resources.
As pointed out by others, the reasons why IPv4 and ASN transfers that are currently permitted DO NOT exist with IPv6. These are: 

1) There is a shortage of 16bit ASN numbers.

2) There is a shortage of IPv4 addresses.


However there is NO shortage of IPv6 addresses, and therefore no need to 
permit RIR transfers like in the above cases.



If one has moved their assets around and now wants their resources 
administered by the RIR where they have moved, let them get numbers 
directly from that RIR.



Even with virtual servers, the actual server is physically in one of the 
existing RIR regions, and that region is the one where resources should be 
obtained in most cases.  If in fact there will be a physical server move 
to a different RIR region, renumbering is going to be a fact of life 
anyway, unless everything is being moved at once at one time.  This is 
rarely done due to the downtime that such a move would incur.



I see this more as a proposal that will permit forum shopping.  One does 
not like the policies of RIR1, so I will take my ball (and my numbers) to 
RIR2.  I am opposed to permitting IPv6 transfers, especially of PA space. 
Fragmentation is also going to often result if this is permitted.


Albert Erdmann
Network Administrator
Paradise On Line Inc.


On Fri, 5 Apr 2019, David Farmer wrote:


Jordi,

No problem, what I'm asking the community is if people support the
use-cases you brought up. If they do, it seems like those use-cases need to
be added to the problem statement. In my opinion, the current problem
statement seems overly focused on the RPKI issue even to the point where it
could be implying RPKI is the only reason you might want to transfer IPv6
resources to another region.

I'd propose the following rewrite of the problem statement;

There are operational reasons to allow transfers of IPv6 resources between
RIRs with an equivalent transfer policy.

ARIN???s RPKI Trust Anchor (TA) is measurably less widely deployed than TAs
from other RIRs. As a consequence, RPKI ROAs published through ARIN offer
less value. Operators seeking to extract the most value from their
investment in IPv6 would benefit from the ability to transfer IPv6
resources to RIRs with more widely deployed RPKI Trust Anchors.

Apart from RPKI, an organization may wish to consolidate or manage the
entirety of their resources, including IPv6, via a single RIR. For example,
after acquiring an entity in another region or being acquired by an entity
based in another region.

Or, an organization may wish to move its resources, including IPv6, to more
accurately reflect where their resources are now in use. For example, if
the organization is no longer operating within the ARIN region, it seems
reasonable to move its resources to a region where they continue to operate.


Comments or suggestions, please.

Thanks

On Wed, Mar 27, 2019 at 3:28 AM JORDI PALET MARTINEZ via ARIN-PPML <
[email protected]> wrote:


???Hi David,



Sorry if somehow my input was ???miss procedural??? ??? the reason for that is
because I???ve proposed an equivalent policy in several RIRs (in terms the
final result: allowing IPv6 transfers), and this was one of the examples
I???ve used.



And just to make it clear, I also support the policy proposal for the
reasons indicated in the actual proposal text.



Here is a message about that with some other examples:




https://mailman.apnic.net/mailing-lists/sig-policy/archive/2019/03/msg00003.html





Regarsds,

Jordi







El 27/3/19 2:40, "David Farmer" <[email protected]> escribi??:



As one of the shepherds for this policy, beyond support for the policy as
written, I'm interested to hear if there is support for the use case Jordi
describes?



The use case Jordi describes seems meaningfully different than the use
case described in the original problem statement. It seems plausible that
there are resolutions, other than the transfer of IPv6, to the RPKI issues
described in the current problem statement. However, for the use
case that Jordi describes, some kind of the inter-RIR M&A transfer, the
transfer of IPv6 resources seems like it could be reasonable, even if the
RPKI issues are resolved by means other than this policy.



So, should Jordi's use case be included in addition to the current problem
statement?



Are there other use cases for the inter-RIR transfer of IPv6 resources
that should be considered in the problem statement as well?



Thanks.





On Tue, Mar 26, 2019 at 4:46 PM JORDI PALET MARTINEZ via ARIN-PPML <
[email protected]> wrote:

In favor of the proposal.

My point of view is on the other way around.

This policy is needed, because if there is a company under an M&A or
reorganization, it seems clear that then it is transferred IPv4, IPv6, ASN.
But there may be cases where is not entirely failing into that category.

For example, a "relocation". A company having VMs in data centers, in
Europe (with resources from RIPE NCC) and moving to US (for whatever
reasons). I don't expect they will renumber the VMs, they will just copy &
synchronize the VMs and switch off the old VMs.

It will not make sense to tell them "you can transfer" your IPv4
resources, but you need to renumber IPv6.

There may be other cases which similar needs.

Regards,
Jordi



???El 26/3/19 22:35, "ARIN-PPML en nombre de John Santos" <
[email protected] en nombre de [email protected]> escribi??:


    On 3/26/2019 3:52 PM, ARIN wrote:
   > There is an operational need to allow RIR transfers of IPv6
resources
   > between RIRs with an equivalent transfer policy. ARIN???s RPKI Trust
   > Anchor (TA) is measurably less widely deployed than TAs from other
   > RIRs. As a consequence, RPKI ROAs published through ARIN offer less
   > value. Operators seeking to extract the most value from their
   > investment in IPv6 would benefit from the ability to transfer IPv6
   > resources to RIRs with more widely deployed RPKI Trust Anchors.
    Wouldn't it make more sense to increase the deployment of RPKI in the
    ARIN region than to open this can of worms?

    --
    John Santos
    Evans Griffiths & Hart, Inc.
    781-861-0670 ext 539

    _______________________________________________
    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.




**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or
confidential. The information is intended to be for the exclusive use of
the individual(s) named above and further non-explicilty authorized
disclosure, copying, distribution or use of the contents of this
information, even if partially, including attached files, is strictly
prohibited and will be considered a criminal offense. If you are not the
intended recipient be aware that any disclosure, copying, distribution or
use of the contents of this information, even if partially, including
attached files, is strictly prohibited, will be considered a criminal
offense, so you must reply to the original sender to inform about this
communication and delete it.



_______________________________________________
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
===============================================

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or
confidential. The information is intended to be for the exclusive use of
the individual(s) named above and further non-explicilty authorized
disclosure, copying, distribution or use of the contents of this
information, even if partially, including attached files, is strictly
prohibited and will be considered a criminal offense. If you are not the
intended recipient be aware that any disclosure, copying, distribution or
use of the contents of this information, even if partially, including
attached files, is strictly prohibited, will be considered a criminal
offense, so you must reply to the original sender to inform about this
communication and delete it.

_______________________________________________
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.






















					Reply via email to