Why would there be a need for a company to transfer an ASN between RIRs?
On Thu, Feb 1, 2018 at 7:17 PM, David Farmer <far...@umn.edu> wrote: > I'm not sure what you are asking, but there are no technical or policy > requirements, at least that I'm aware of, that an ASN only routes address > blocks from the same registry. In other words, a RIPE ASN can route ARIN IP > blocks and vice versa. > > But this does bring up an interesting question; we have the IRR consultation > going on, what should happen to IRR objects when ASNs or IP blocks are > transferred to another RIRs? > > My point was this policy is about ASN transfers if we want to talk about > IPv6 transfers that would be a different policy, and therefore should be a > different thread. It makes it easier to discern the support for a policy if > side threads are split out. > > Thanks > > On Thu, Feb 1, 2018 at 12:21 PM, Roberts, Orin <orobe...@bell.ca> wrote: >> >> You could, but then IPv6 routing/fragmentation becomes an issue. >> >> >> >> Unless when an ASN is transferred from ARIN all IP networks associated to >> that ASN are revoked/removed/deleted from ARIN. >> >> ie. I can acquire an ASN that currently exists at ARIN minus any >> associated IP networks, move it to APNIC/RIPE, then associate IP networks >> from APNIC/RIPE. >> >> >> >> ~the same for the reverse. >> >> >> >> A proviso would then be, only a clean(ed) ASN can be transferred in/out. >> >> >> >> Orin Roberts >> >> >> >> From: ARIN-PPML [mailto:arin-ppml-boun...@arin.net] On Behalf Of David >> Farmer >> Sent: February-01-18 1:03 PM >> To: Job Snijders <j...@ntt.net> >> Cc: email@example.com >> Subject: Re: [arin-ppml] IPv6 Transfers (was :Draft Policy ARIN-2018-1: >> Allow Inter-regional ASN Transfers >> >> >> >> First, let's move IPv6 transfers out of the ASN transfers thread. >> >> >> >> On Thu, Feb 1, 2018 at 11:40 AM, Job Snijders <j...@ntt.net> wrote: >> >> On Thu, Feb 01, 2018 at 12:30:31PM -0500, hostmas...@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. >> >> >> >> I agree, Inter-RIR transfers doesn't itself imply that the routing table >> will grow. However, the high level allocations from IANA to the RIRs which >> are fairly clean in IPv6 today will become fragmented, and likely seriously >> fragmented if their is signifigant inter-RIR transfers of IPv6. By itself >> this isn't necessarily a problem, however, IPv6 allocations and assignments >> have been made in a way to allow most of them to be enlarged in place. If >> an allocation is transfered this is no longer easily possilbe to expand the >> alloation in place. >> >> >> >> > 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. >> >> >> >> It is by no means zero, I know of seveal allocations that have been >> expanded. >> >> >> >> > 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. >> >> >> >> I also have to agree, the work involed in renumbering is very similar >> between IPv6 and IPv4. The diffrence is IPv6 has explicitly condiered >> renumbering and it is possilbe to renumber IPv6 without a flag day on the >> local subnet. Whereas with IPv4 each subnet requires a flag day to change >> from the old to the new addressing. >> >> >> >> So I would charterize the diffrence in renumbering in IPv6 verses IPv4, as >> the impact on an operational network is less with renumber in IPv6, its a >> far more graceful change with IPv6, but the sheer amount of operational work >> is comparable between renumbering in IPv6 and IPv4. >> >> >> >> Kind regards, >> >> Job >> >> >> >> -- >> >> =============================================== >> David Farmer Email:far...@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 >> =============================================== >> >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact i...@arin.net if you experience any issues. > > > > > -- > =============================================== > David Farmer Email:far...@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 > =============================================== > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML@arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact i...@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@arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact i...@arin.net if you experience any issues.