<div dir="auto"><div data-smartmail="gmail_signature" dir="auto">I need a small clarification.</div><div data-smartmail="gmail_signature" dir="auto">The Caribbean region has 3 RIRs</div><div data-smartmail="gmail_signature" dir="auto"><br></div><div data-smartmail="gmail_signature" dir="auto">St Lucia is ARIN, Trinidad is LACNIC and Martinique is RIPE</div><div data-smartmail="gmail_signature" dir="auto">If my base is arin and offer wholesale services to same geo. Region countries.. Trinidad (lacnic) and Martinique (Ripe), do i need 3 separate AS numbers?</div><div data-smartmail="gmail_signature" dir="auto"><br></div><div data-smartmail="gmail_signature" dir="auto">rd</div><div data-smartmail="gmail_signature" dir="auto"><br></div><div data-smartmail="gmail_signature" dir="auto"><br></div><div data-smartmail="gmail_signature" dir="auto"><br></div><div class="gmail_extra" dir="auto"><br><div class="gmail_quote">On 3 Feb 2018 14:17, <<a href="mailto:arin-ppml-request@arin.net">arin-ppml-request@arin.net</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Send ARIN-PPML mailing list submissions to<br>
<a href="mailto:arin-ppml@arin.net">arin-ppml@arin.net</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="http://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank">http://lists.arin.net/mailman/<wbr>listinfo/arin-ppml</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:arin-ppml-request@arin.net">arin-ppml-request@arin.net</a><br><br>
<br>
<br>
Today's Topics:<br>
<br>
1. Weekly posting summary for <a href="mailto:ppml@arin.net">ppml@arin.net</a> (<a href="mailto:narten@us.ibm.com">narten@us.ibm.com</a>)<br>
2. Re: IPv6 Transfers (was :Draft Policy ARIN-2018-1: Allow<br>
Inter-regional ASN Transfers (Aaron Dudek)<br>
3. Re: IPv6 Transfers (was :Draft Policy ARIN-2018-1: Allow<br>
Inter-regional ASN Transfers (<a href="mailto:hostmaster@uneedus.com">hostmaster@uneedus.com</a>)<br>
4. Re: IPv6 Transfers (was :Draft Policy ARIN-2018-1: Allow<br>
Inter-regional ASN Transfers (Scott Leibrand)<br>
<br>
<br>
------------------------------<wbr>------------------------------<wbr>----------<br>
<br>
Message: 1<br>
Date: Fri, 02 Feb 2018 00:53:02 -0500<br>
From: <a href="mailto:narten@us.ibm.com">narten@us.ibm.com</a><br>
To: <a href="mailto:arin-ppml@arin.net">arin-ppml@arin.net</a><br>
Subject: [arin-ppml] Weekly posting summary for <a href="mailto:ppml@arin.net">ppml@arin.net</a><br>
Message-ID: <<a href="mailto:201802020553.w125r3Hv024154@rotala.raleigh.ibm.com">201802020553.w125r3Hv024154@<wbr>rotala.raleigh.ibm.com</a>><br>
Content-Type: text/plain; charset=us-ascii<br>
<br>
Total of 32 messages in the last 7 days.<br>
<br>
script run at: Fri Feb 2 00:53:02 EST 2018<br>
<br>
Messages | Bytes | Who<br>
--------+------+--------+-----<wbr>-----+------------------------<br>
21.88% | 7 | 27.63% | 169157 | <a href="mailto:farmer@umn.edu">farmer@umn.edu</a><br>
9.38% | 3 | 12.88% | 78835 | <a href="mailto:jschiller@google.com">jschiller@google.com</a><br>
9.38% | 3 | 7.02% | 42959 | <a href="mailto:jcurran@arin.net">jcurran@arin.net</a><br>
6.25% | 2 | 9.69% | 59336 | <a href="mailto:chris@semihuman.com">chris@semihuman.com</a><br>
6.25% | 2 | 8.93% | 54678 | <a href="mailto:owen@delong.com">owen@delong.com</a><br>
9.38% | 3 | 4.96% | 30392 | <a href="mailto:job@ntt.net">job@ntt.net</a><br>
6.25% | 2 | 7.37% | 45115 | <a href="mailto:oroberts@bell.ca">oroberts@bell.ca</a><br>
6.25% | 2 | 4.37% | 26761 | <a href="mailto:hvgeekwtrvl@gmail.com">hvgeekwtrvl@gmail.com</a><br>
6.25% | 2 | 3.81% | 23298 | <a href="mailto:hostmaster@uneedus.com">hostmaster@uneedus.com</a><br>
6.25% | 2 | 3.06% | 18719 | <a href="mailto:info@arin.net">info@arin.net</a><br>
3.12% | 1 | 3.86% | 23613 | <a href="mailto:mike@iptrading.com">mike@iptrading.com</a><br>
3.12% | 1 | 2.52% | 15439 | <a href="mailto:alison.wood@oregon.gov">alison.wood@oregon.gov</a><br>
3.12% | 1 | 2.27% | 13881 | <a href="mailto:scottleibrand@gmail.com">scottleibrand@gmail.com</a><br>
3.12% | 1 | 1.64% | 10023 | <a href="mailto:narten@us.ibm.com">narten@us.ibm.com</a><br>
--------+------+--------+-----<wbr>-----+------------------------<br>
100.00% | 32 |100.00% | 612206 | Total<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Fri, 2 Feb 2018 13:45:49 -0500<br>
From: Aaron Dudek <<a href="mailto:adudek16@gmail.com">adudek16@gmail.com</a>><br>
To: David Farmer <<a href="mailto:farmer@umn.edu">farmer@umn.edu</a>><br>
Cc: "Roberts, Orin" <<a href="mailto:oroberts@bell.ca">oroberts@bell.ca</a>>, "<a href="mailto:arin-ppml@arin.net">arin-ppml@arin.net</a>"<br>
<<a href="mailto:arin-ppml@arin.net">arin-ppml@arin.net</a>><br>
Subject: Re: [arin-ppml] IPv6 Transfers (was :Draft Policy<br>
ARIN-2018-1: Allow Inter-regional ASN Transfers<br>
Message-ID:<br>
<CAA0LXWV=<a href="mailto:LLHYzgA1THNE1hPF_4pMTiOWGKnoNh-aQSho7_RCag@mail.gmail.com">LLHYzgA1THNE1hPF_<wbr>4pMTiOWGKnoNh-aQSho7_RCag@<wbr>mail.gmail.com</a>><br>
Content-Type: text/plain; charset="UTF-8"<br>
<br>
Why would there be a need for a company to transfer an ASN between RIRs?<br>
<br>
<br>
On Thu, Feb 1, 2018 at 7:17 PM, David Farmer <<a href="mailto:farmer@umn.edu">farmer@umn.edu</a>> wrote:<br>
> I'm not sure what you are asking, but there are no technical or policy<br>
> requirements, at least that I'm aware of, that an ASN only routes address<br>
> blocks from the same registry. In other words, a RIPE ASN can route ARIN IP<br>
> blocks and vice versa.<br>
><br>
> But this does bring up an interesting question; we have the IRR consultation<br>
> going on, what should happen to IRR objects when ASNs or IP blocks are<br>
> transferred to another RIRs?<br>
><br>
> My point was this policy is about ASN transfers if we want to talk about<br>
> IPv6 transfers that would be a different policy, and therefore should be a<br>
> different thread. It makes it easier to discern the support for a policy if<br>
> side threads are split out.<br>
><br>
> Thanks<br>
><br>
> On Thu, Feb 1, 2018 at 12:21 PM, Roberts, Orin <<a href="mailto:oroberts@bell.ca">oroberts@bell.ca</a>> wrote:<br>
>><br>
>> You could, but then IPv6 routing/fragmentation becomes an issue.<br>
>><br>
>><br>
>><br>
>> Unless when an ASN is transferred from ARIN all IP networks associated to<br>
>> that ASN are revoked/removed/deleted from ARIN.<br>
>><br>
>> ie. I can acquire an ASN that currently exists at ARIN minus any<br>
>> associated IP networks, move it to APNIC/RIPE, then associate IP networks<br>
>> from APNIC/RIPE.<br>
>><br>
>><br>
>><br>
>> ~the same for the reverse.<br>
>><br>
>><br>
>><br>
>> A proviso would then be, only a clean(ed) ASN can be transferred in/out.<br>
>><br>
>><br>
>><br>
>> Orin Roberts<br>
>><br>
>><br>
>><br>
>> From: ARIN-PPML [mailto:<a href="mailto:arin-ppml-bounces@arin.net">arin-ppml-bounces@<wbr>arin.net</a>] On Behalf Of David<br>
>> Farmer<br>
>> Sent: February-01-18 1:03 PM<br>
>> To: Job Snijders <<a href="mailto:job@ntt.net">job@ntt.net</a>><br>
>> Cc: <a href="mailto:arin-ppml@arin.net">arin-ppml@arin.net</a><br>
>> Subject: Re: [arin-ppml] IPv6 Transfers (was :Draft Policy ARIN-2018-1:<br>
>> Allow Inter-regional ASN Transfers<br>
>><br>
>><br>
>><br>
>> First, let's move IPv6 transfers out of the ASN transfers thread.<br>
>><br>
>><br>
>><br>
>> On Thu, Feb 1, 2018 at 11:40 AM, Job Snijders <<a href="mailto:job@ntt.net">job@ntt.net</a>> wrote:<br>
>><br>
>> On Thu, Feb 01, 2018 at 12:30:31PM -0500, <a href="mailto:hostmaster@uneedus.com">hostmaster@uneedus.com</a> wrote:<br>
>> > I would be opposed to allowing inter regional IPv6 Transfers.<br>
>> ><br>
>> > One of the main benefits of IPv6 over IPv4 is the reduction of routing<br>
>> > table size. Allowing inter regional transfers would start the road to<br>
>> > larger routing tables.<br>
>><br>
>> I'd appreciate evidence that allowing interregional transfers leads to<br>
>> larger routing tables. Administrative resource management is somewhat<br>
>> orthogonal to BGP announcements. Whether the resource is managed by RIR<br>
>> A vs RIR B bears no direct relation to the BGP announcements and routing<br>
>> tables.<br>
>><br>
>><br>
>><br>
>> I agree, Inter-RIR transfers doesn't itself imply that the routing table<br>
>> will grow. However, the high level allocations from IANA to the RIRs which<br>
>> are fairly clean in IPv6 today will become fragmented, and likely seriously<br>
>> fragmented if their is signifigant inter-RIR transfers of IPv6. By itself<br>
>> this isn't necessarily a problem, however, IPv6 allocations and assignments<br>
>> have been made in a way to allow most of them to be enlarged in place. If<br>
>> an allocation is transfered this is no longer easily possilbe to expand the<br>
>> alloation in place.<br>
>><br>
>><br>
>><br>
>> > We allowed a lot of this in IPv4 because of shortages of addresses.<br>
>> > This is not in fact true in the IPv6 world. Growth in address use in<br>
>> > IPv4 resulted in most networks having more than one block of<br>
>> > addresses. From what I understand, sparse assigment methods are being<br>
>> > used in IPv6, allowing those few networks that actually had to grow<br>
>> > beyond their original allocation to grow into blocks of space right<br>
>> > next to the space they already occupy, helping to keep the routing<br>
>> > tables smaller. During the time we were discussing 2017-5, I asked<br>
>> > how may ARIN members had grown beyond their original block of IPv6<br>
>> > addresses, and I believe the answer was zero.<br>
>><br>
>><br>
>><br>
>> It is by no means zero, I know of seveal allocations that have been<br>
>> expanded.<br>
>><br>
>><br>
>><br>
>> > IPv6 allows for a host to use more than one address and network. This<br>
>> > makes multihoming or renumbering a lot simpler than it was in the IPv4<br>
>> > world. I can simply provide more than one router and associated<br>
>> > network block for each provider, and allow the hosts to obtain an<br>
>> > address on each of them and to route between them as they see fit. I<br>
>> > can also deprecate one of the available networks, and all new<br>
>> > connections will be made using the remaining networks and routes.<br>
>> > This allows easy renumbering.<br>
>> ><br>
>> > It is not a big hardship to renumber in IPv6 unlike IPv4, so I would<br>
>> > like to not end up with lots of exceptions in the routing tables, and<br>
>> > to keep the registration records simpler.<br>
>><br>
>> You are describing a very specific deployment model. We cannot assume<br>
>> that every deployment uses that model, nor build policy based on that<br>
>> assumption. My own experience tells me that renumbering IPv6 is as much<br>
>> work as renumbering IPv4.<br>
>><br>
>><br>
>><br>
>> I also have to agree, the work involed in renumbering is very similar<br>
>> between IPv6 and IPv4. The diffrence is IPv6 has explicitly condiered<br>
>> renumbering and it is possilbe to renumber IPv6 without a flag day on the<br>
>> local subnet. Whereas with IPv4 each subnet requires a flag day to change<br>
>> from the old to the new addressing.<br>
>><br>
>><br>
>><br>
>> So I would charterize the diffrence in renumbering in IPv6 verses IPv4, as<br>
>> the impact on an operational network is less with renumber in IPv6, its a<br>
>> far more graceful change with IPv6, but the sheer amount of operational work<br>
>> is comparable between renumbering in IPv6 and IPv4.<br>
>><br>
>><br>
>><br>
>> Kind regards,<br>
>><br>
>> Job<br>
>><br>
>><br>
>><br>
>> --<br>
>><br>
>> ==============================<wbr>=================<br>
>> David Farmer <a href="mailto:Email%3Afarmer@umn.edu">Email:farmer@umn.edu</a><br>
>> Networking & Telecommunication Services<br>
>> Office of Information Technology<br>
>> University of Minnesota<br>
>> 2218 University Ave SE Phone: <a href="tel:612-626-0815" value="+16126260815">612-626-0815</a><br>
>> Minneapolis, MN 55414-3029 Cell: <a href="tel:612-812-9952" value="+16128129952">612-812-9952</a><br>
>> ==============================<wbr>=================<br>
>><br>
>><br>
>> ______________________________<wbr>_________________<br>
>> PPML<br>
>> You are receiving this message because you are subscribed to<br>
>> the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).<br>
>> Unsubscribe or manage your mailing list subscription at:<br>
>> <a href="http://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank">http://lists.arin.net/mailman/<wbr>listinfo/arin-ppml</a><br>
>> Please contact <a href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.<br>
><br>
><br>
><br>
><br>
> --<br>
> ==============================<wbr>=================<br>
> David Farmer <a href="mailto:Email%3Afarmer@umn.edu">Email:farmer@umn.edu</a><br>
> Networking & Telecommunication Services<br>
> Office of Information Technology<br>
> University of Minnesota<br>
> 2218 University Ave SE Phone: <a href="tel:612-626-0815" value="+16126260815">612-626-0815</a><br>
> Minneapolis, MN 55414-3029 Cell: <a href="tel:612-812-9952" value="+16128129952">612-812-9952</a><br>
> ==============================<wbr>=================<br>
><br>
> ______________________________<wbr>_________________<br>
> PPML<br>
> You are receiving this message because you are subscribed to<br>
> the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).<br>
> Unsubscribe or manage your mailing list subscription at:<br>
> <a href="http://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank">http://lists.arin.net/mailman/<wbr>listinfo/arin-ppml</a><br>
> Please contact <a href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.<br>
<br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Sat, 3 Feb 2018 08:12:53 -0500 (EST)<br>
From: <a href="mailto:hostmaster@uneedus.com">hostmaster@uneedus.com</a><br>
To: "<a href="mailto:arin-ppml@arin.net">arin-ppml@arin.net</a>" <<a href="mailto:arin-ppml@arin.net">arin-ppml@arin.net</a>><br>
Subject: Re: [arin-ppml] IPv6 Transfers (was :Draft Policy<br>
ARIN-2018-1: Allow Inter-regional ASN Transfers<br>
Message-ID: <Pine.LNX.4.64.1802030743470.<wbr>21499@localhost.localdomain><br>
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed<br>
<br>
I can only really think of three:<br>
<br>
1) A company is relocating its headquarters from a location served by an<br>
RIR, to another location served by a different RIR, and wants everything<br>
in their new home region.<br>
<br>
2) A company decides to buy another company with few assets, but holds a<br>
16 bit ASN in another RIR region. They then want to bring that ASN back<br>
to ARIN so they can add it to their registration plan. This is similar to<br>
M&A of companies with IPv4 addresses as assets, since they can not get a<br>
16 bit ASN directly from ARIN.<br>
<br>
3) They have so much equipment scattered around the world with the old<br>
ASN, that they do not want to renumber just because their headquarters<br>
moved to a region served by a different RIR. If the region moved to is<br>
ARIN, in most cases they can save money by putting the moved ASN on their<br>
registration plan with their address space.<br>
<br>
In any case, if ARIN allows transfers, it is highly unlikely that that<br>
policy would ever be applied to anything other than a 16 bit ASN as there<br>
are plenty of 32 bit ASN's available in all regions.<br>
<br>
Albert Erdmann<br>
Network Administrator<br>
Paradise On Line Inc.<br>
<br>
On Fri, 2 Feb 2018, Aaron Dudek wrote:<br>
<br>
> Why would there be a need for a company to transfer an ASN between RIRs?<br>
><br>
><br>
> On Thu, Feb 1, 2018 at 7:17 PM, David Farmer <<a href="mailto:farmer@umn.edu">farmer@umn.edu</a>> wrote:<br>
>> I'm not sure what you are asking, but there are no technical or policy<br>
>> requirements, at least that I'm aware of, that an ASN only routes address<br>
>> blocks from the same registry. In other words, a RIPE ASN can route ARIN IP<br>
>> blocks and vice versa.<br>
>><br>
>> But this does bring up an interesting question; we have the IRR consultation<br>
>> going on, what should happen to IRR objects when ASNs or IP blocks are<br>
>> transferred to another RIRs?<br>
>><br>
>> My point was this policy is about ASN transfers if we want to talk about<br>
>> IPv6 transfers that would be a different policy, and therefore should be a<br>
>> different thread. It makes it easier to discern the support for a policy if<br>
>> side threads are split out.<br>
>><br>
>> Thanks<br>
>><br>
>> On Thu, Feb 1, 2018 at 12:21 PM, Roberts, Orin <<a href="mailto:oroberts@bell.ca">oroberts@bell.ca</a>> wrote:<br>
>>><br>
>>> You could, but then IPv6 routing/fragmentation becomes an issue.<br>
>>><br>
>>><br>
>>><br>
>>> Unless when an ASN is transferred from ARIN all IP networks associated to<br>
>>> that ASN are revoked/removed/deleted from ARIN.<br>
>>><br>
>>> ie. I can acquire an ASN that currently exists at ARIN minus any<br>
>>> associated IP networks, move it to APNIC/RIPE, then associate IP networks<br>
>>> from APNIC/RIPE.<br>
>>><br>
>>><br>
>>><br>
>>> ~the same for the reverse.<br>
>>><br>
>>><br>
>>><br>
>>> A proviso would then be, only a clean(ed) ASN can be transferred in/out.<br>
>>><br>
>>><br>
>>><br>
>>> Orin Roberts<br>
>>><br>
>>><br>
>>><br>
>>> From: ARIN-PPML [mailto:<a href="mailto:arin-ppml-bounces@arin.net">arin-ppml-bounces@<wbr>arin.net</a>] On Behalf Of David<br>
>>> Farmer<br>
>>> Sent: February-01-18 1:03 PM<br>
>>> To: Job Snijders <<a href="mailto:job@ntt.net">job@ntt.net</a>><br>
>>> Cc: <a href="mailto:arin-ppml@arin.net">arin-ppml@arin.net</a><br>
>>> Subject: Re: [arin-ppml] IPv6 Transfers (was :Draft Policy ARIN-2018-1:<br>
>>> Allow Inter-regional ASN Transfers<br>
>>><br>
>>><br>
>>><br>
>>> First, let's move IPv6 transfers out of the ASN transfers thread.<br>
>>><br>
>>><br>
>>><br>
>>> On Thu, Feb 1, 2018 at 11:40 AM, Job Snijders <<a href="mailto:job@ntt.net">job@ntt.net</a>> wrote:<br>
>>><br>
>>> On Thu, Feb 01, 2018 at 12:30:31PM -0500, <a href="mailto:hostmaster@uneedus.com">hostmaster@uneedus.com</a> wrote:<br>
>>>> I would be opposed to allowing inter regional IPv6 Transfers.<br>
>>>><br>
>>>> One of the main benefits of IPv6 over IPv4 is the reduction of routing<br>
>>>> table size. Allowing inter regional transfers would start the road to<br>
>>>> larger routing tables.<br>
>>><br>
>>> I'd appreciate evidence that allowing interregional transfers leads to<br>
>>> larger routing tables. Administrative resource management is somewhat<br>
>>> orthogonal to BGP announcements. Whether the resource is managed by RIR<br>
>>> A vs RIR B bears no direct relation to the BGP announcements and routing<br>
>>> tables.<br>
>>><br>
>>><br>
>>><br>
>>> I agree, Inter-RIR transfers doesn't itself imply that the routing table<br>
>>> will grow. However, the high level allocations from IANA to the RIRs which<br>
>>> are fairly clean in IPv6 today will become fragmented, and likely seriously<br>
>>> fragmented if their is signifigant inter-RIR transfers of IPv6. By itself<br>
>>> this isn't necessarily a problem, however, IPv6 allocations and assignments<br>
>>> have been made in a way to allow most of them to be enlarged in place. If<br>
>>> an allocation is transfered this is no longer easily possilbe to expand the<br>
>>> alloation in place.<br>
>>><br>
>>><br>
>>><br>
>>>> We allowed a lot of this in IPv4 because of shortages of addresses.<br>
>>>> This is not in fact true in the IPv6 world. Growth in address use in<br>
>>>> IPv4 resulted in most networks having more than one block of<br>
>>>> addresses. From what I understand, sparse assigment methods are being<br>
>>>> used in IPv6, allowing those few networks that actually had to grow<br>
>>>> beyond their original allocation to grow into blocks of space right<br>
>>>> next to the space they already occupy, helping to keep the routing<br>
>>>> tables smaller. During the time we were discussing 2017-5, I asked<br>
>>>> how may ARIN members had grown beyond their original block of IPv6<br>
>>>> addresses, and I believe the answer was zero.<br>
>>><br>
>>><br>
>>><br>
>>> It is by no means zero, I know of seveal allocations that have been<br>
>>> expanded.<br>
>>><br>
>>><br>
>>><br>
>>>> IPv6 allows for a host to use more than one address and network. This<br>
>>>> makes multihoming or renumbering a lot simpler than it was in the IPv4<br>
>>>> world. I can simply provide more than one router and associated<br>
>>>> network block for each provider, and allow the hosts to obtain an<br>
>>>> address on each of them and to route between them as they see fit. I<br>
>>>> can also deprecate one of the available networks, and all new<br>
>>>> connections will be made using the remaining networks and routes.<br>
>>>> This allows easy renumbering.<br>
>>>><br>
>>>> It is not a big hardship to renumber in IPv6 unlike IPv4, so I would<br>
>>>> like to not end up with lots of exceptions in the routing tables, and<br>
>>>> to keep the registration records simpler.<br>
>>><br>
>>> You are describing a very specific deployment model. We cannot assume<br>
>>> that every deployment uses that model, nor build policy based on that<br>
>>> assumption. My own experience tells me that renumbering IPv6 is as much<br>
>>> work as renumbering IPv4.<br>
>>><br>
>>><br>
>>><br>
>>> I also have to agree, the work involed in renumbering is very similar<br>
>>> between IPv6 and IPv4. The diffrence is IPv6 has explicitly condiered<br>
>>> renumbering and it is possilbe to renumber IPv6 without a flag day on the<br>
>>> local subnet. Whereas with IPv4 each subnet requires a flag day to change<br>
>>> from the old to the new addressing.<br>
>>><br>
>>><br>
>>><br>
>>> So I would charterize the diffrence in renumbering in IPv6 verses IPv4, as<br>
>>> the impact on an operational network is less with renumber in IPv6, its a<br>
>>> far more graceful change with IPv6, but the sheer amount of operational work<br>
>>> is comparable between renumbering in IPv6 and IPv4.<br>
>>><br>
>>><br>
>>><br>
>>> Kind regards,<br>
>>><br>
>>> Job<br>
>>><br>
>>><br>
>>><br>
>>> --<br>
>>><br>
>>> ==============================<wbr>=================<br>
>>> David Farmer <a href="mailto:Email%3Afarmer@umn.edu">Email:farmer@umn.edu</a><br>
>>> Networking & Telecommunication Services<br>
>>> Office of Information Technology<br>
>>> University of Minnesota<br>
>>> 2218 University Ave SE Phone: <a href="tel:612-626-0815" value="+16126260815">612-626-0815</a><br>
>>> Minneapolis, MN 55414-3029 Cell: <a href="tel:612-812-9952" value="+16128129952">612-812-9952</a><br>
>>> ==============================<wbr>=================<br>
>>><br>
>>><br>
>>> ______________________________<wbr>_________________<br>
>>> PPML<br>
>>> You are receiving this message because you are subscribed to<br>
>>> the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).<br>
>>> Unsubscribe or manage your mailing list subscription at:<br>
>>> <a href="http://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank">http://lists.arin.net/mailman/<wbr>listinfo/arin-ppml</a><br>
>>> Please contact <a href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.<br>
>><br>
>><br>
>><br>
>><br>
>> --<br>
>> ==============================<wbr>=================<br>
>> David Farmer <a href="mailto:Email%3Afarmer@umn.edu">Email:farmer@umn.edu</a><br>
>> Networking & Telecommunication Services<br>
>> Office of Information Technology<br>
>> University of Minnesota<br>
>> 2218 University Ave SE Phone: <a href="tel:612-626-0815" value="+16126260815">612-626-0815</a><br>
>> Minneapolis, MN 55414-3029 Cell: <a href="tel:612-812-9952" value="+16128129952">612-812-9952</a><br>
>> ==============================<wbr>=================<br>
>><br>
>> ______________________________<wbr>_________________<br>
>> PPML<br>
>> You are receiving this message because you are subscribed to<br>
>> the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).<br>
>> Unsubscribe or manage your mailing list subscription at:<br>
>> <a href="http://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank">http://lists.arin.net/mailman/<wbr>listinfo/arin-ppml</a><br>
>> Please contact <a href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.<br>
> ______________________________<wbr>_________________<br>
> PPML<br>
> You are receiving this message because you are subscribed to<br>
> the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).<br>
> Unsubscribe or manage your mailing list subscription at:<br>
> <a href="http://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank">http://lists.arin.net/mailman/<wbr>listinfo/arin-ppml</a><br>
> Please contact <a href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.<br>
><br>
<br>
<br>
------------------------------<br>
<br>
Message: 4<br>
Date: Sat, 3 Feb 2018 10:17:02 -0800<br>
From: Scott Leibrand <<a href="mailto:scottleibrand@gmail.com">scottleibrand@gmail.com</a>><br>
To: <a href="mailto:hostmaster@uneedus.com">hostmaster@uneedus.com</a><br>
Cc: "<a href="mailto:arin-ppml@arin.net">arin-ppml@arin.net</a>" <<a href="mailto:arin-ppml@arin.net">arin-ppml@arin.net</a>><br>
Subject: Re: [arin-ppml] IPv6 Transfers (was :Draft Policy<br>
ARIN-2018-1: Allow Inter-regional ASN Transfers<br>
Message-ID: <<a href="mailto:F2E4643C-184F-41B3-9516-9E27E1EE4CBC@gmail.com">F2E4643C-184F-41B3-9516-<wbr>9E27E1EE4CBC@gmail.com</a>><br>
Content-Type: text/plain; charset=utf-8<br>
<br>
<br>
> On Feb 3, 2018, at 5:12 AM, <a href="mailto:hostmaster@uneedus.com">hostmaster@uneedus.com</a> wrote:<br>
><br>
> I can only really think of three:<br>
><br>
> 1) A company is relocating its headquarters from a location served by an RIR, to another location served by a different RIR, and wants everything in their new home region.<br>
><br>
> 2) A company decides to buy another company with few assets, but holds a 16 bit ASN in another RIR region. They then want to bring that ASN back to ARIN so they can add it to their registration plan. This is similar to M&A of companies with IPv4 addresses as assets, since they can not get a 16 bit ASN directly from ARIN.<br>
><br>
> 3) They have so much equipment scattered around the world with the old ASN, that they do not want to renumber just because their headquarters moved to a region served by a different RIR. If the region moved to is ARIN, in most cases they can save money by putting the moved ASN on their registration plan with their address space.<br>
><br>
> In any case, if ARIN allows transfers, it is highly unlikely that that policy would ever be applied to anything other than a 16 bit ASN as there are plenty of 32 bit ASN's available in all regions.<br>
<br>
All three scenarios apply equally to 16 and 32 bit ASNs. If it?s easier for everyone involved to transfer an ASN between RIRs along with any IPv4 resources, there?s no reason to renumber (which requires cooperation from BGP peers).<br>
<br>
-Scott<br>
<br>
>> On Fri, 2 Feb 2018, Aaron Dudek wrote:<br>
>><br>
>> Why would there be a need for a company to transfer an ASN between RIRs?<br>
>><br>
>><br>
>>> On Thu, Feb 1, 2018 at 7:17 PM, David Farmer <<a href="mailto:farmer@umn.edu">farmer@umn.edu</a>> wrote:<br>
>>> I'm not sure what you are asking, but there are no technical or policy<br>
>>> requirements, at least that I'm aware of, that an ASN only routes address<br>
>>> blocks from the same registry. In other words, a RIPE ASN can route ARIN IP<br>
>>> blocks and vice versa.<br>
>>><br>
>>> But this does bring up an interesting question; we have the IRR consultation<br>
>>> going on, what should happen to IRR objects when ASNs or IP blocks are<br>
>>> transferred to another RIRs?<br>
>>><br>
>>> My point was this policy is about ASN transfers if we want to talk about<br>
>>> IPv6 transfers that would be a different policy, and therefore should be a<br>
>>> different thread. It makes it easier to discern the support for a policy if<br>
>>> side threads are split out.<br>
>>><br>
>>> Thanks<br>
>>><br>
>>>> On Thu, Feb 1, 2018 at 12:21 PM, Roberts, Orin <<a href="mailto:oroberts@bell.ca">oroberts@bell.ca</a>> wrote:<br>
>>>><br>
>>>> You could, but then IPv6 routing/fragmentation becomes an issue.<br>
>>>><br>
>>>><br>
>>>><br>
>>>> Unless when an ASN is transferred from ARIN all IP networks associated to<br>
>>>> that ASN are revoked/removed/deleted from ARIN.<br>
>>>><br>
>>>> ie. I can acquire an ASN that currently exists at ARIN minus any<br>
>>>> associated IP networks, move it to APNIC/RIPE, then associate IP networks<br>
>>>> from APNIC/RIPE.<br>
>>>><br>
>>>><br>
>>>><br>
>>>> ~the same for the reverse.<br>
>>>><br>
>>>><br>
>>>><br>
>>>> A proviso would then be, only a clean(ed) ASN can be transferred in/out.<br>
>>>><br>
>>>><br>
>>>><br>
>>>> Orin Roberts<br>
>>>><br>
>>>><br>
>>>><br>
>>>> From: ARIN-PPML [mailto:<a href="mailto:arin-ppml-bounces@arin.net">arin-ppml-bounces@<wbr>arin.net</a>] On Behalf Of David<br>
>>>> Farmer<br>
>>>> Sent: February-01-18 1:03 PM<br>
>>>> To: Job Snijders <<a href="mailto:job@ntt.net">job@ntt.net</a>><br>
>>>> Cc: <a href="mailto:arin-ppml@arin.net">arin-ppml@arin.net</a><br>
>>>> Subject: Re: [arin-ppml] IPv6 Transfers (was :Draft Policy ARIN-2018-1:<br>
>>>> Allow Inter-regional ASN Transfers<br>
>>>><br>
>>>><br>
>>>><br>
>>>> First, let's move IPv6 transfers out of the ASN transfers thread.<br>
>>>><br>
>>>><br>
>>>><br>
>>>> On Thu, Feb 1, 2018 at 11:40 AM, Job Snijders <<a href="mailto:job@ntt.net">job@ntt.net</a>> wrote:<br>
>>>><br>
>>>> On Thu, Feb 01, 2018 at 12:30:31PM -0500, <a href="mailto:hostmaster@uneedus.com">hostmaster@uneedus.com</a> wrote:<br>
>>>>> I would be opposed to allowing inter regional IPv6 Transfers.<br>
>>>>><br>
>>>>> One of the main benefits of IPv6 over IPv4 is the reduction of routing<br>
>>>>> table size. Allowing inter regional transfers would start the road to<br>
>>>>> larger routing tables.<br>
>>>><br>
>>>> I'd appreciate evidence that allowing interregional transfers leads to<br>
>>>> larger routing tables. Administrative resource management is somewhat<br>
>>>> orthogonal to BGP announcements. Whether the resource is managed by RIR<br>
>>>> A vs RIR B bears no direct relation to the BGP announcements and routing<br>
>>>> tables.<br>
>>>><br>
>>>><br>
>>>><br>
>>>> I agree, Inter-RIR transfers doesn't itself imply that the routing table<br>
>>>> will grow. However, the high level allocations from IANA to the RIRs which<br>
>>>> are fairly clean in IPv6 today will become fragmented, and likely seriously<br>
>>>> fragmented if their is signifigant inter-RIR transfers of IPv6. By itself<br>
>>>> this isn't necessarily a problem, however, IPv6 allocations and assignments<br>
>>>> have been made in a way to allow most of them to be enlarged in place. If<br>
>>>> an allocation is transfered this is no longer easily possilbe to expand the<br>
>>>> alloation in place.<br>
>>>><br>
>>>><br>
>>>><br>
>>>>> We allowed a lot of this in IPv4 because of shortages of addresses.<br>
>>>>> This is not in fact true in the IPv6 world. Growth in address use in<br>
>>>>> IPv4 resulted in most networks having more than one block of<br>
>>>>> addresses. From what I understand, sparse assigment methods are being<br>
>>>>> used in IPv6, allowing those few networks that actually had to grow<br>
>>>>> beyond their original allocation to grow into blocks of space right<br>
>>>>> next to the space they already occupy, helping to keep the routing<br>
>>>>> tables smaller. During the time we were discussing 2017-5, I asked<br>
>>>>> how may ARIN members had grown beyond their original block of IPv6<br>
>>>>> addresses, and I believe the answer was zero.<br>
>>>><br>
>>>><br>
>>>><br>
>>>> It is by no means zero, I know of seveal allocations that have been<br>
>>>> expanded.<br>
>>>><br>
>>>><br>
>>>><br>
>>>>> IPv6 allows for a host to use more than one address and network. This<br>
>>>>> makes multihoming or renumbering a lot simpler than it was in the IPv4<br>
>>>>> world. I can simply provide more than one router and associated<br>
>>>>> network block for each provider, and allow the hosts to obtain an<br>
>>>>> address on each of them and to route between them as they see fit. I<br>
>>>>> can also deprecate one of the available networks, and all new<br>
>>>>> connections will be made using the remaining networks and routes.<br>
>>>>> This allows easy renumbering.<br>
>>>>><br>
>>>>> It is not a big hardship to renumber in IPv6 unlike IPv4, so I would<br>
>>>>> like to not end up with lots of exceptions in the routing tables, and<br>
>>>>> to keep the registration records simpler.<br>
>>>><br>
>>>> You are describing a very specific deployment model. We cannot assume<br>
>>>> that every deployment uses that model, nor build policy based on that<br>
>>>> assumption. My own experience tells me that renumbering IPv6 is as much<br>
>>>> work as renumbering IPv4.<br>
>>>><br>
>>>><br>
>>>><br>
>>>> I also have to agree, the work involed in renumbering is very similar<br>
>>>> between IPv6 and IPv4. The diffrence is IPv6 has explicitly condiered<br>
>>>> renumbering and it is possilbe to renumber IPv6 without a flag day on the<br>
>>>> local subnet. Whereas with IPv4 each subnet requires a flag day to change<br>
>>>> from the old to the new addressing.<br>
>>>><br>
>>>><br>
>>>><br>
>>>> So I would charterize the diffrence in renumbering in IPv6 verses IPv4, as<br>
>>>> the impact on an operational network is less with renumber in IPv6, its a<br>
>>>> far more graceful change with IPv6, but the sheer amount of operational work<br>
>>>> is comparable between renumbering in IPv6 and IPv4.<br>
>>>><br>
>>>><br>
>>>><br>
>>>> Kind regards,<br>
>>>><br>
>>>> Job<br>
>>>><br>
>>>><br>
>>>><br>
>>>> --<br>
>>>><br>
>>>> ==============================<wbr>=================<br>
>>>> David Farmer <a href="mailto:Email%3Afarmer@umn.edu">Email:farmer@umn.edu</a><br>
>>>> Networking & Telecommunication Services<br>
>>>> Office of Information Technology<br>
>>>> University of Minnesota<br>
>>>> 2218 University Ave SE Phone: <a href="tel:612-626-0815" value="+16126260815">612-626-0815</a><br>
>>>> Minneapolis, MN 55414-3029 Cell: <a href="tel:612-812-9952" value="+16128129952">612-812-9952</a><br>
>>>> ==============================<wbr>=================<br>
>>>><br>
>>>><br>
>>>> ______________________________<wbr>_________________<br>
>>>> PPML<br>
>>>> You are receiving this message because you are subscribed to<br>
>>>> the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).<br>
>>>> Unsubscribe or manage your mailing list subscription at:<br>
>>>> <a href="http://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank">http://lists.arin.net/mailman/<wbr>listinfo/arin-ppml</a><br>
>>>> Please contact <a href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.<br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> --<br>
>>> ==============================<wbr>=================<br>
>>> David Farmer <a href="mailto:Email%3Afarmer@umn.edu">Email:farmer@umn.edu</a><br>
>>> Networking & Telecommunication Services<br>
>>> Office of Information Technology<br>
>>> University of Minnesota<br>
>>> 2218 University Ave SE Phone: <a href="tel:612-626-0815" value="+16126260815">612-626-0815</a><br>
>>> Minneapolis, MN 55414-3029 Cell: <a href="tel:612-812-9952" value="+16128129952">612-812-9952</a><br>
>>> ==============================<wbr>=================<br>
>>><br>
>>> ______________________________<wbr>_________________<br>
>>> PPML<br>
>>> You are receiving this message because you are subscribed to<br>
>>> the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).<br>
>>> Unsubscribe or manage your mailing list subscription at:<br>
>>> <a href="http://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank">http://lists.arin.net/mailman/<wbr>listinfo/arin-ppml</a><br>
>>> Please contact <a href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.<br>
>> ______________________________<wbr>_________________<br>
>> PPML<br>
>> You are receiving this message because you are subscribed to<br>
>> the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).<br>
>> Unsubscribe or manage your mailing list subscription at:<br>
>> <a href="http://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank">http://lists.arin.net/mailman/<wbr>listinfo/arin-ppml</a><br>
>> Please contact <a href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.<br>
>><br>
> ______________________________<wbr>_________________<br>
> PPML<br>
> You are receiving this message because you are subscribed to<br>
> the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).<br>
> Unsubscribe or manage your mailing list subscription at:<br>
> <a href="http://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank">http://lists.arin.net/mailman/<wbr>listinfo/arin-ppml</a><br>
> Please contact <a href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.<br>
<br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
______________________________<wbr>_________________<br>
ARIN-PPML mailing list<br>
<a href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a><br>
<a href="http://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank">http://lists.arin.net/mailman/<wbr>listinfo/arin-ppml</a><br>
<br>
------------------------------<br>
<br>
End of ARIN-PPML Digest, Vol 152, Issue 8<br>
******************************<wbr>***********<br>
</blockquote></div><br></div></div>