<div dir="ltr"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 16, 2018 at 11:53 AM, Jo Rhett <span dir="ltr"><<a href="mailto:jrhett@netconsonance.com" target="_blank">jrhett@netconsonance.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">"The only thing that I wish to express is that I do not want to ever see <br>IPv6 transfers"<div><br></div><div>I totally understand why someone would say this given a static marketplace, but buyouts and mergers and sales of business units (partial buyouts) do occur.</div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Aug 14, 2018 at 12:01 AM <<a href="mailto:hostmaster@uneedus.com" target="_blank">hostmaster@uneedus.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">+1 as to AS transfers.<br>
<br>
I have no heartburn regarding this, and the existing unused policy tends <br>
to show that this action is in fact quite rare and likely to be used only <br>
when absolutely needed.<br>
<br>
The only thing that I wish to express is that I do not want to ever see <br>
IPv6 transfers, since the sparse assignment policies of IPv6 were designed <br>
to control the bloat of the DFZ that is getting even worse under IPv4, <br>
largely driven by splits and transfers of smaller and smaller blocks being <br>
advertised in the DFZ. With the extreme size of the numbering space in <br>
IPv6, versus IPv4 we need to keep these routes consolidated as much as <br>
possible.<br>
<br>
We have put up with transfers in IPv4 because of need. This need does not <br>
exist in IPv6 at this time, and with the large numbers used need never <br>
happen. Please, let go of the legacy issues in the newer IPv6 protocol. <br>
While I may never see the retirement of IPv4, I can dream of the days <br>
where obtaining numbering resources is no longer an issue, nor where <br>
"hacks" like NAT and CIDR are needed because of lack of numbers, breaking <br>
peer to peer connections.<br>
<br>
Unlike in IPv4, there are actions that could be taken in IPv6 to expand <br>
the available numbering in the event that we ever get anywhere close to <br>
IPv6 exhaust. Among ideas I can think of would to deprecate the use of <br>
SLAAC in future numbering blocks (for example the blocks beginning with <br>
a-e), and allocating smaller in those last blocks. For example, instead <br>
of a /32 per LIR, /48 per site, and a /64 per network as the "default", <br>
reduce these values to /64, /80 and /96, using the local part to expand <br>
the addresses available for assignment by an LIR by many orders of <br>
magnitude. Many have already advanced getting rid of SLAAC for privacy and <br>
security reasons, so it might not be missed once Android learns to do <br>
DHCPv6 more universally. Android is the only real reason for SLAAC on many <br>
current networks. I am sure that other similar ideas may be advanced in a <br>
couple of centuries when this issue may need to be addressed.<br>
<br>
Keeping away transfers in IPv6 will go far to reducing the DFZ growth.<br>
<br>
Albert Erdmann<br>
Network Administrator<br>
Paradise On Line Inc.<br>
<br>
<br>
On Mon, 13 Aug 2018, Owen DeLong wrote:<br>
<br>
> Correction…<br>
><br>
> APNIC and RIPE already have policy to support this process with no utilization.<br>
><br>
> Owen<br>
><br>
><br>
>> On Aug 13, 2018, at 16:03 , Mike Burns <<a href="mailto:mike@iptrading.com" target="_blank">mike@iptrading.com</a>> wrote:<br>
>><br>
>><br>
>> I support the policy and note that:<br>
>><br>
>> The costs to implement are practically zero.<br>
>> Some community members have requested this ability, who are we to gainsay their reasons?<br>
>> The changes to the NRPM are tiny and discrete.<br>
>> No downsides to the implementation this policy have been offered in any comments, if the need is tiny, so is ARIN staff time expended.<br>
>> APNIC and RIPE are already engaged in this process with no ill effects.<br>
>><br>
>> Regards,<br>
>><br>
>> Mike<br>
>><br>
>><br>
>><br>
>><br>
>> ---- On Mon, 13 Aug 2018 19:00:28 -0400 Steven Ryerse <<a href="mailto:SRyerse@eclipse-networks.com" target="_blank">SRyerse@eclipse-networks.com</a> <mailto:<a href="mailto:SRyerse@eclipse-networks.com" target="_blank">SRyerse@eclipse-<wbr>networks.com</a>>> wrote ----<br>
>><br>
>> +1<br>
>><br>
>><br>
>> Steven Ryerse<br>
>> President<br>
>> 100 Ashford Center North, Suite 110, Atlanta, GA 30338<br>
>> 770.656.1460 - Cell<br>
>> 770.399.9099 - Office<br>
>> 770.392.0076 - Fax<br>
>><br>
>> <1.jpg>℠ Eclipse Networks, Inc.<br>
>> Conquering Complex Networks℠<br>
>><br>
>> From: ARIN-PPML <<a href="mailto:arin-ppml-bounces@arin.net" target="_blank">arin-ppml-bounces@arin.net</a> <mailto:<a href="mailto:arin-ppml-bounces@arin.net" target="_blank">arin-ppml-bounces@<wbr>arin.net</a>>> On Behalf Of Scott Leibrand<br>
>> Sent: Monday, August 13, 2018 6:52 PM<br>
>> To: Job Snijders <<a href="mailto:job@ntt.net" target="_blank">job@ntt.net</a> <mailto:<a href="mailto:job@ntt.net" target="_blank">job@ntt.net</a>>><br>
>> Cc: ARIN-PPML List <<a href="mailto:arin-ppml@arin.net" target="_blank">arin-ppml@arin.net</a> <mailto:<a href="mailto:arin-ppml@arin.net" target="_blank">arin-ppml@arin.net</a>>><br>
>> Subject: Re: [arin-ppml] ARIN-2018-1: Allow Inter-regional ASN Transfers<br>
>><br>
>><br>
>> If you operate a network with peering sessions, and you are forced to renumber your ASN, you either need to convince all of your peers to set up new sessions (which can be a lot of work, and usually means at least some of them will refuse/fail to do so), or you need to local-as prepend the old ASN onto your new one, resulting in a longer AS path over that session. Both outcomes are disruptive to a network's ability to maintain peering.<br>
>><br>
>> Given that there are valid technical and business justifications for needing to keep the same ASN on a network whose locus of control switches continents, I believe it is appropriate to allow organizations who need to do so to transfer administrative control of their ASN between RIRs, and therefore support this draft policy.<br>
>><br>
>> While it is certainly possible for some networks to easily renumber their ASN, that is not true of all networks, for valid technical reasons. I therefore do not find arguments of the "I've never needed to do that" or "I can't imagine why someone would need to do that" informative or convincing. To my mind, the only argument that would justify opposing ASN transfers would be one that details how such transfers would be burdensome to the RIRs or to the Internet community more generally, and would further show that such burden is greater than the benefit to those organizations it would help. As I, Job, and others have detailed the kind of organization that would be benefited by this proposal, it's not sufficient to assert that such organization do not (or should not) exist.<br>
>><br>
>> -Scott<br>
>><br>
>> On Mon, Aug 13, 2018 at 3:36 PM Job Snijders <<a href="mailto:job@ntt.net" target="_blank">job@ntt.net</a> <mailto:<a href="mailto:job@ntt.net" target="_blank">job@ntt.net</a>>> wrote:<br>
>> On Tue, 14 Aug 2018 at 01:23, Larry Ash <<a href="mailto:lar@mwtcorp.net" target="_blank">lar@mwtcorp.net</a> <mailto:<a href="mailto:lar@mwtcorp.net" target="_blank">lar@mwtcorp.net</a>>> wrote:<br>
>> On Mon, 13 Aug 2018 14:47:09 -0700<br>
>> Owen DeLong <<a href="mailto:owen@delong.com" target="_blank">owen@delong.com</a> <mailto:<a href="mailto:owen@delong.com" target="_blank">owen@delong.com</a>>> wrote:<br>
>>>> On Aug 13, 2018, at 14:42 , Job Snijders <<a href="mailto:job@ntt.net" target="_blank">job@ntt.net</a> <mailto:<a href="mailto:job@ntt.net" target="_blank">job@ntt.net</a>>> wrote:<br>
>>>><br>
>>>> I agree with the proposal.<br>
>>>><br>
>>>> I think this proposal is needed and addresses practical concerns: the alternative to transfers is “renumbering”, and renumbering<br>
>>>> ASNs is a very costly and operationally risky proposition. There is no upside to restricting or forbidding this type of resource<br>
>>>> transfer.<br>
>>>><br>
>>>> A question that remains: if you don’t want to transfer your ASN in or out of ARIN, then don’t, but why forbid others from doing<br>
>>>> it? All resources should be transferable.<br>
>>><br>
>>> We can agree to disagree.<br>
>><br>
>> I agree with Owen, I just can't see a burning need. Renumbering seems to be a bugaboo that is just not that difficult.<br>
>><br>
>><br>
>> Even if you don’t see a need, would you want to preclude others from transferring their resource if they concluded it is a requirement for their business operation?<br>
>><br>
>><br>
>> I would think the transfer of the ASN would as costly, difficult and risky as migrating the resources onto a new ASN.<br>
>><br>
>><br>
>> I’m puzzled by your statement. Renumbering an ASN may involve operations on hundreds of routers and tens of thousands of BGP sessions - such renumbering clearly is costly and operationally risky.<br>
>><br>
>> Transferring a resource from one RIR to another RIR is paperwork between RIRs - no router changes. A transfer and a renumbering don’t seem comparable at all. Do you consider IPv4 transfers costly and risky too?<br>
>><br>
>> Kind regards,<br>
>><br>
>> Job<br>
>> ______________________________<wbr>_________________<br>
>> ARIN-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" target="_blank">ARIN-PPML@arin.net</a> <mailto:<a href="mailto:ARIN-PPML@arin.net" target="_blank">ARIN-PPML@arin.net</a>>).<br>
>> Unsubscribe or manage your mailing list subscription at:<br>
>> <a href="https://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank">https://lists.arin.net/<wbr>mailman/listinfo/arin-ppml</a> <<a href="https://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank">https://lists.arin.net/<wbr>mailman/listinfo/arin-ppml</a>><br>
>> Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> <mailto:<a href="mailto:info@arin.net" target="_blank">info@arin.net</a>> if you experience any issues.<br>
>><br>
>> ______________________________<wbr>_________________<br>
>> ARIN-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" target="_blank">ARIN-PPML@arin.net</a> <mailto:<a href="mailto:ARIN-PPML@arin.net" target="_blank">ARIN-PPML@arin.net</a>>).<br>
>> Unsubscribe or manage your mailing list subscription at:<br>
>> <a href="https://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank">https://lists.arin.net/<wbr>mailman/listinfo/arin-ppml</a> <<a href="https://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank">https://lists.arin.net/<wbr>mailman/listinfo/arin-ppml</a>><br>
>> Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> <mailto:<a href="mailto:info@arin.net" target="_blank">info@arin.net</a>> if you experience any issues.<br>
>><br>
>><br>
>><br>
>> ______________________________<wbr>_________________<br>
>> ARIN-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" target="_blank">ARIN-PPML@arin.net</a>).<br>
>> Unsubscribe or manage your mailing list subscription at:<br>
>> <a href="https://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank">https://lists.arin.net/<wbr>mailman/listinfo/arin-ppml</a><br>
>> Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.<br>
><br>
>_____________________________<wbr>__________________<br>
ARIN-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" target="_blank">ARIN-PPML@arin.net</a>).<br>
Unsubscribe or manage your mailing list subscription at:<br>
<a href="https://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank">https://lists.arin.net/<wbr>mailman/listinfo/arin-ppml</a><br>
Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.<span class="HOEnZb"><font color="#888888"><br>
</font></span></blockquote></div><span class="HOEnZb"><font color="#888888"><br clear="all"><div><br></div>-- <br><div dir="ltr" class="m_-8390618747844510231gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Jo Rhett</div></div>
</font></span><br>______________________________<wbr>_________________<br>
ARIN-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="https://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank">https://lists.arin.net/<wbr>mailman/listinfo/arin-ppml</a><br>
Please contact <a href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.<br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">===============================================<br>David Farmer <a href="mailto:Email%3Afarmer@umn.edu" target="_blank">Email:farmer@umn.edu</a><br>Networking & Telecommunication Services<br>Office of Information Technology<br>University of Minnesota <br>2218 University Ave SE Phone: 612-626-0815<br>Minneapolis, MN 55414-3029 Cell: 612-812-9952<br>=============================================== </div>
</div>