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

[Aaron Dudek]

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 <farmer at 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 <oroberts at 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-bounces at arin.net] On Behalf Of David
>> Farmer
>> Sent: February-01-18 1:03 PM
>> To: Job Snijders <job at ntt.net>
>> Cc: arin-ppml at arin.net
>> 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 <job at ntt.net> wrote:
>>
>> 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.
>>
>>
>>
>> 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: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
>> ===============================================
>>
>>
>> _______________________________________________
>> 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
> ===============================================
>
> _______________________________________________
> 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.