[arin-ppml] Draft Policy ARIN-2018-1: Allow Inter-regional ASN Transfers

[David Farmer]

Yes, APNIC and RIPE both allow inter-RIR transfers of ASNs.

On Thu, Feb 1, 2018 at 11:46 AM, Roberts, Orin <oroberts at bell.ca> wrote:

> Question
> Has any other registry already adopted or implemented such a policy -
> Inter-regional ASN Transfers?
>
> Orin Roberts
>
>
> -----Original Message-----
> From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of Job
> Snijders
> Sent: February-01-18 12:40 PM
> To: hostmaster at uneedus.com
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Draft Policy ARIN-2018-1: Allow Inter-regional
> ASN Transfers
>
> On Thu, Feb 01, 2018 at 12:30:31PM -0500, hostmaster at uneedus.com wrote:
> > I would be opposed to allowing inter regional IPv6 Transfers.
> >
> > One of the main benefits of IPv6 over IPv4 is the reduction of routing
> > table size.  Allowing inter regional transfers would start the road to
> > larger routing tables.
>
> I'd appreciate evidence that allowing interregional transfers leads to
> larger routing tables. Administrative resource management is somewhat
> orthogonal to BGP announcements. Whether the resource is managed by RIR A
> vs RIR B bears no direct relation to the BGP announcements and routing
> tables.
>
> > We allowed a lot of this in IPv4 because of shortages of addresses.
> > This is not in fact true in the IPv6 world. Growth in address use in
> > IPv4 resulted in most networks having more than one block of
> > addresses.  From what I understand, sparse assigment methods are being
> > used in IPv6, allowing those few networks that actually had to grow
> > beyond their original allocation to grow into blocks of space right
> > next to the space they already occupy, helping to keep the routing
> > tables smaller.  During the time we were discussing 2017-5, I asked
> > how may ARIN members had grown beyond their original block of IPv6
> > addresses, and I believe the answer was zero.
> >
> > IPv6 allows for a host to use more than one address and network.  This
> > makes multihoming or renumbering a lot simpler than it was in the IPv4
> > world.  I can simply provide more than one router and associated
> > network block for each provider, and allow the hosts to obtain an
> > address on each of them and to route between them as they see fit.  I
> > can also deprecate one of the available networks, and all new
> > connections will be made using the remaining networks and routes.
> > This allows easy renumbering.
> >
> > It is not a big hardship to renumber in IPv6 unlike IPv4, so I would
> > like to not end up with lots of exceptions in the routing tables, and
> > to keep the registration records simpler.
>
> You are describing a very specific deployment model. We cannot assume that
> every deployment uses that model, nor build policy based on that
> assumption. My own experience tells me that renumbering IPv6 is as much
> work as renumbering IPv4.
>
> Kind regards,
>
> Job
> _______________________________________________
> 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:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> _______________________________________________
> 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:
> http://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
===============================================
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20180201/32f33fbd/attachment.htm>